Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On 4/4/18 2:45 PM, Seebs wrote: > On Wed, 4 Apr 2018 14:28:11 -0700 > Khem Raj wrote: > >> what is the performance impact of adding another stack frame and >> function call in the chain here. Do we have data ? > > Very close to unmeasurable, because *almost nothing ever uses

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On Wed, Apr 4, 2018 at 2:28 PM, Khem Raj wrote: > On 3/27/18 8:48 AM, Ross Burton wrote: >> coreutils is now using renameat2() in mv(1) but as this syscall isn't in most >> glibc headers yet it falls back to directly calling syscall(), which pseudo >> doesn't intercept. This

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On Wed, 4 Apr 2018 14:28:11 -0700 Khem Raj wrote: > what is the performance impact of adding another stack frame and > function call in the chain here. Do we have data ? Very close to unmeasurable, because *almost nothing ever uses syscall*. This is used only for the case

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On 3/27/18 8:48 AM, Ross Burton wrote: > coreutils is now using renameat2() in mv(1) but as this syscall isn't in most > glibc headers yet it falls back to directly calling syscall(), which pseudo > doesn't intercept. This results in permission problems as files mysteriously > move without pseudo

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

And on a happier note this time, pseudo master appears much happier and 19f18124f16c4c85405b140a1fb8cb3b31d865bf seems to pass on the autobuilders. I'll do some specific checks on f27 but things are looking good, thanks everyone who's helped with this. Cheers, Richard --

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On Sat, 31 Mar 2018 16:03:01 -0500 Joshua Watt wrote: > Looks like maybe gdk-pixbuf-query-loaders has the unlucky honour of > being one of the few programs that invokes the pseudo syscall() > wrapper before any other functions that pseudo wraps and the missing > initializer

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On Sat, Mar 31, 2018 at 8:12 AM, Richard Purdie wrote: > Just to report back, I've tried testing an earlier version of pseudo > master with the path changes reverted and current master. With both I'm > seeing librsvg fail during do_install with a segfault (you

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On Sat, Mar 31, 2018 at 11:35 AM, Seebs wrote: > On Fri, 30 Mar 2018 23:02:29 -0700 > Andre McCurdy wrote: > >> On Fri, Mar 30, 2018 at 10:06 PM, Seebs wrote: >> > That's the problem: There's no sane way to express "the size that >> > you

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On Sat, 31 Mar 2018 14:12:55 +0100 Richard Purdie wrote: > I believe that libglib-2.0 does use syscall() for something and that > the above programs are calling into it and faulting. Interesting! I'll poke around and see what I can find. -s --

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On Fri, 30 Mar 2018 23:02:29 -0700 Andre McCurdy wrote: > On Fri, Mar 30, 2018 at 10:06 PM, Seebs wrote: > > That's the problem: There's no sane way to express "the size that > > you would have gotten for these arguments of unknown types" > > And there I

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

Just to report back, I've tried testing an earlier version of pseudo master with the path changes reverted and current master. With both I'm seeing librsvg fail during do_install with a segfault (you have to remove the 2> /dev/null to see it). I'm seeing multiple entries in the host's dmesg:

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On Fri, Mar 30, 2018 at 10:06 PM, Seebs wrote: > That's the problem: There's no sane way to express "the size that you > would have gotten for these arguments of unknown types" And there I think lies the key point that you still haven't grasped. The arguments are not of unknown

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On Fri, 30 Mar 2018 21:15:18 -0700 Andre McCurdy wrote: > Arguments passed by the caller will be put on the stack before any > stack frame is created by the callee. You can argue about which way a > stack grows (up or down) but however you define it, reading past the > end of

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On Wed, Mar 28, 2018 at 2:15 AM, Burton, Ross wrote: > With this patch I was getting occasional failures of the pseudo-using > bitbake-worker, so its not quite ready, but Peter is working on a > better form anyway. The "better form" seems to have been committed to the

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On 27 March 2018 at 23:43, Andre McCurdy wrote: >> ++ //va_start (ap, number); > > Without knowing anything about pseudo, commenting this out looks odd? It appears that pseudo's wrappers pass a va_list for you. Then again I know little about pseudo and just hacked

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On Tue, Mar 27, 2018 at 8:48 AM, Ross Burton wrote: > coreutils is now using renameat2() in mv(1) but as this syscall isn't in most > glibc headers yet it falls back to directly calling syscall(), which pseudo > doesn't intercept. This results in permission problems as

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On Tue, 27 Mar 2018 16:48:02 +0100 Ross Burton wrote: > This patch intercepts syscall() and returns ENOTSUP if renameat2() is > being called. I am inclined to NAK this until we have a clearer understanding of the mechanics observed in glibc's syscall implementation; it's