[llvm-dev] Experiment on how to improve our temporary file handing.

Mark Kettenis via llvm-dev llvm-dev at lists.llvm.org
Fri Nov 10 08:21:08 PST 2017


> Date: Thu, 09 Nov 2017 13:13:52 -0800
> From: Rafael Avila de Espindola via llvm-dev <llvm-dev at lists.llvm.org>
> 
> Currently a power failure or other hard crash can cause lld leave a temporary
> file around. The same is true for other llvm tools.
> 
> As an example, put a breakpoint in Writer.cpp:236 ("writeBuildId()") and
> restart the run a few times. You will get
> 
> t.tmp43a735a  t.tmp4deeabb  t.tmp9bacdd3  t.tmpe4115c4  t.tmpeb01fff
> 
> The same would happen if there was a fatal error between the
> FileOutputBuffer creation and commit. I don't think that is a code path
> where that is possible right now, but it would be an easy thing to miss
> in a code review.
> 
> I was hopping the OS could help us manage the temporary file so that
> there was no way to accidentally leave it behind.
> 
> On linux there is O_TMPFILE, which allows us to create a file with no
> name in the file system.

For the LLVM use case creatinmg the file and immediately unlinking it
would probably be good enough.  Howver...

> A name can be given with linkat. Unfortunately we can't use
> 
> linkat(fd, "", AT_FDCWD, "destination", AT_EMPTY_PATH)
> 
> Without special permissions and have instead to depend on proc:
> 
> linkat(AT_FDCWD, "/proc/self/fd/<num>", AT_FDCWD, "destination",
>        AT_SYMLINK_FOLLOW)
> 
> Another annoyance is that linkat will not replace the destination and
> renameat2 doesn't support AT_EMPTY_PATH. The result is that we have to
> use unlink+linkat and loop.

I'd strongly recommend avoiding such unportable cleverness.

I'm actually surprised Linux allows this as there are some serious
security implications as this allows programs to create an entry in
the filesystem for file descriptors passed over a socket.


More information about the llvm-dev mailing list