[llvm-dev] Experiment on how to improve our temporary file handing.
Nikodemus Siivola via llvm-dev
llvm-dev at lists.llvm.org
Fri Nov 10 08:39:41 PST 2017
In a very large class of cases the correct thing is to cleanup on next run.
Not sure clang is in that class by any means, just tossing this out there...
On 10 Nov 2017 18.21, "Mark Kettenis via llvm-dev" <llvm-dev at lists.llvm.org>
wrote:
> > 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.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171110/62a31f44/attachment.html>
More information about the llvm-dev
mailing list