On Fri, Mar 23, 2018 at 4:56 PM, Seebs <[email protected]> wrote: > On Fri, 23 Mar 2018 23:47:30 +0000 > Richard Purdie <[email protected]> wrote: >> On Fri, 2018-03-23 at 11:49 -0500, Seebs wrote: >> > On Fri, 23 Mar 2018 16:30:55 +0000 >> > "Burton, Ross" <[email protected]> wrote: >> > > Because in GNU's infinite wisdom they're using renameat2() to do >> > > atomic renames in the mv command, and as renameat2 isn't in the >> > > headers for F27 it just does a syscall directly. This is in >> > > upstream >> > > coreutils so once they make a release, everyone gets it. >> > UGH. >> > >> > I... am really unsure whether it's possible to catch that, because >> > I really, really, don't want to try to intercept raw syscall() >> > calls. I don't think that ends well. >> >> Just out of interest for my education, why is that a really bad idea? >> Loops, e.g. with memory allocation issues? > > Potentially. We rely pretty heavily on the assumption that an *actual* > syscall can go through. > > Although... Actually, I don't even know if this is an actual syscall. > This could be an actual glibc wrapper around the syscall interface, > just like all the others, which is not the *actual* raw syscall or > whatever,
It looks like coreutils calls into gnulib, which calls the libc's syscall wrapper: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/renameat2.c;h=a295ec33f33dfe14e1d29cfae5d2c36e82d01ef4;hb=HEAD#l74 Interposing the libc syscall wrapper doesn't seem to scary if you can transparently pass on everything apart from syscall(SYS_renameat2, ...) ? > and... I have no idea how often that is or isn't hit. > > It's totally possible it would work, but basically, I have a pretty > good intuition of when something sounds brittle and error-prone, and > trying to trap syscall() sounds brittle and error-prone and might work > today but not next week... -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
