On Sat, 17 May 2025 19:50:34 +0100 Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> wrote:
[...]
> Let's keep this simple - I'm just wrong here :) apologies, entirely my
> fault.
No worry, appreciate your kind and detailed answer.
[...]
> Anyway, let's dig into the code to get things right:
[...]
> So - this confirms it - we're fine, it just tries to use the stack-based
> array if it can - otherwise it kmalloc()'s.
>
> Of course, UIO_MAXIOV remains the _actual_ hard limit (hardcoded to 1,024
> in include/uapi/linux/uio.h).
Thanks for kind clarifications. All your explanations perfectly matches with
my understanding. I'm happy to be on the same page with you!
>
> The other points I made about the proposed interface remain, but I won't go
> into more detail as we are obviously lacking that context here.
>
> Thanks for bringing this up and correcting my misinterpretation, as well as
> providing the below repro code, and let's revisit your old series... but on
> Monday :)
Sure, and no worry, take your time :)
>
> I should really not be looking at work mail on a Saturday (mea culpa, once
> again... :)
I hope your remaining weekend be calm and uninterruptable. Keeping you not
burned out is important for the community :)
>
> One small nit in the repro code below (hey I'm a kernel dev, can't help
> myself... ;)
To me, being a kernel programmer rather than a user-space c code programmer is
a good excuse for asking to be generous to my user-space bugs ;) Thank you for
your kind comment below, anyway :)
>
> Cheers, Lorenzo
>
> >
> > Attaching my test code below. You could simply run it as below.
> >
> > gcc test.c && ./a.out
> >
> > ==== Attachment 0 (test.c) ====
[...]
> > ret = syscall(SYS_process_madvise, pidfd, vec, NR_PAGES,
> > MADV_DONTNEED, 0);
> > if (ret != MMAP_SZ) {
> > printf("process_madvise fail\n");
> > return -1;
> > }
>
> To be pedantic, you are really only checking to see if an error was
> returned, in theory no error might have been returned but the operation
> might have not proceeded, so a more proper check here would be to populated
> the anon memory with non-zero data, then check afterwards that it's zeroed.
>
> Given this outcome would probably imply iovec issues, it's not likely, but
> to really assert the point you'd probably want to do that!
Good points! I once considered making this test better and posting to be
included in mm selftests, but found no time to do that so far. Above input
must be very helpful in a case that I (or someone else) find a time to write
such process_madvise() selftest.
Thanks,
SJ
[...]
