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

[Bruce Ashfield]

On Sat, Mar 31, 2018 at 11:35 AM, Seebs <seebs at seebs.net> wrote:
> On Fri, 30 Mar 2018 23:02:29 -0700
> Andre McCurdy <armccurdy at gmail.com> wrote:
>
>> On Fri, Mar 30, 2018 at 10:06 PM, Seebs <seebs at seebs.net> 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.
>
> I think you're right, but also you're being sorta rude about it. I

FWIW, I was thinking the same thing.

seebs is quite capable of working through this .. with all the bike shedding
here, it is taking up time that could actually be spent on the solution.

Cheers,

Bruce

> think you're missing the distinction between "broad enough experience
> with weird edge cases to be possibly-unduly cautious" and "has no idea
> which end of a compiler is up".
>
>> The arguments are not of unknown types - they are all of types which
>> are the same size as integer registers.
>
> It turns out, in C, "the same size" is *not enough information* to
> determine where an argument goes. It is probably enough information for
> the subset of arguments that syscall is using, on these architectures,
> but I say "probably" because I have no spec to point to that says it's
> necessarily the case.
>
>> The syscall manpage very
>> clearly documents the fact that all arguments to Linux syscalls are
>> passed to the kernel in registers. I think you even asked me why that
>> was important or useful.
>
> I'm still honestly not totally sure why it has to say *which*
> registers, specifically. Under what circumstances will my invocation of
> syscall(2) be changed by the knowledge that argument 5 to an OABI ARM
> system gets passed in v1? The information being present implies that I
> might need to know this to invoke syscall(2) correctly, but the only
> examples given are not actually specific to that information.
>
>> If there's any user space code out there which calls libc syscall()
>> and does not pass variables which libc syscall() (or a wrapper for it)
>> can unconditionally treat as a type which fits into integer registers
>> than it's a bug the caller. End of story.
>
> This raises an interesting point. The man page says that the dummy 0
> argument is needed for SYS_readahead because of an alignment issue, to
> force the value into r2/r3. It does not say that the manual split of the
> 64-bit value into two halves is needed, it just does that. Is that
> actually required anyway, or only because of the need to pad the
> argument list? (For instance, look at sync_file_range2(), which
> reorders the arguments to sync_file_range() for efficiency.
>
> ... Oh, wow. I went and checked on readahead():
>
>>> On some 32-bit architectures, the calling signature for this
>>> system call differs, for the reasons described in syscall(2).
>
> Note how they don't specify what the alternative calling signature is.
>
> -s
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"