[PATCH] D75933: Revert D45736 [SimplifyLibcalls] Replace locked IO with unlocked IO

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 10 10:19:28 PDT 2020


MaskRay created this revision.
MaskRay added reviewers: dalias, echristo, efriedma, mstorsjo, nsz, xbolva00.
Herald added subscribers: llvm-commits, hiraditya.
Herald added a project: LLVM.

C11 7.21.5.2 The fflush function

> If stream is a null pointer, the fflush function performs this flushing action on all streams for which the behavior is defined above.

i.e. fopen'ed FILE* is inherently captured.

POSIX.1-2017 getc_unlocked, getchar_unlocked, putc_unlocked, putchar_unlocked - stdio with explicit client locking

> These functions can safely be used in a multi-threaded program if and only if they are called while the invoking thread owns the ( FILE *) object, as is the case after a successful call to the flockfile() or ftrylockfile() functions.

After a thread fopen'ed a FILE*, when it is calling foobar() which is now replaced by foobar_unlocked(),
if another thread is concurrently calling fflush(0), the behavior is undefined.

C11 7.22.4.4 The exit function

> Next, all open streams with unwritten buffered data are flushed, all open streams are closed, and all files created by the tmpfile function are removed.

The replacement is only feasible if the program is single threaded, or exit or fflush(0) is never called.
See also http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180528/556615.html
for how the replacement makes libc interceptors difficult to implement.

dalias: in a worst case, it's unbounded data corruption because of concurrent access to pointers
without synchronization.  f->wpos or rpos could get outside of the buffer, thread A could do
f->wpos += j after knowing j is in bounds, while thread B also changes it concurrently.

This can produce exploitable conditions depending on libc internals.

Revert because the cons obviously overweigh the pros.  Even when the replacement is feasible, the
benefit is indemonstrable, more so in an application instead of an artificial glibc benchmark.
Theoretically the replacement could be beneficial when calling getc_unlocked/putc_unlocked in a
loop, but then it is better using a blocked IO operation and the user is likely aware of that.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D75933

Files:
  llvm/include/llvm/Analysis/TargetLibraryInfo.def
  llvm/include/llvm/Transforms/Utils/BuildLibCalls.h
  llvm/lib/Analysis/TargetLibraryInfo.cpp
  llvm/lib/Transforms/Utils/BuildLibCalls.cpp
  llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
  llvm/test/Transforms/InferFunctionAttrs/annotate.ll
  llvm/test/Transforms/InstCombine/unlocked-stdio.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D75933.249429.patch
Type: text/x-patch
Size: 37829 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200310/1ca2e819/attachment.bin>


More information about the llvm-commits mailing list