Re: [PATCH 1/5] uaccess: fix ignored_trailing logic in copy_struct_to_user()

[Stefan Metzmacher]

Hi Aleksa,

> On 2026-04-07, Stefan Metzmacher <metze@xxxxxxxxx> wrote:
> > Currently all callers pass ignored_trailing=NULL, but I have
> > code that will make use of.
> >
> > Now it actually behaves like documented:
> >
> > * If @usize < @ksize, then the kernel is trying to pass userspace a newer
> >    struct than it supports. Thus we only copy the interoperable portions
> >    (@usize) and ignore the rest (but @ignored_trailing is set to %true if
> >    any of the trailing (@ksize - @usize) bytes are non-zero).
>
> Good catch, though I want to mention that the current API design for
> copy_struct_to_user() is a bit of a compromise -- I was trying to think
> of a way of making it generic but what information you need really
> depends on your API.
>
> For request-flag APIs (like statx) then you can just unset the bits in
> the response mask for fields past usize and so it is a non-fatal error,
> but it requires knowing which field offsets map to which flags.
>
> My initial idea for ignored_trailing was for it to return the offset
> memchr_inv() gives you -- but unfortunately, this doesn't help in the
> more generic case where you have multiple non-zero bits that need to
> unset multiple flags.

I guess the caller could use if (ignored_trailing) { ... }
to check more complex stuff and then decide ignore or return an error.

> Out of interest, how did you plan on using it? It might be a good idea
> to rethink this API before it starts getting used "in anger" in a way
> that leaks to uAPIs we can't change.

Currently I only use it with WARN_ON_ONCE(ignored_trailing);
in order to catch internal errors. See
https://git.samba.org/?p=metze/linux/wip.git;a=blob;f=fs/smb/common/smbdirect/smbdirect_proto.c;h=ce7c78eb6795041ba672da434ffb01db73269cb7;hb=37c61ef9758f3e113d4078220d8fc2aee366c955#l1625
But I guess I will at least change it to
if (WARN_ON_ONCE(ignored_trailing))
    return...

And in general I thought it would be good practice to
check that case in new code in order to avoid unexpected
behavior.

> In any case, for this patch feel free to take my
>
> Reviewed-by: Aleksa Sarai <aleksa@xxxxxxxxxxxx>

Thanks!
metze