Re: Is number of process_madvise()-able ranges limited to 8? (was Re: [PATCH 1/6] prctl: introduce PR_THP_POLICY_DEFAULT_HUGE for the process)

[SeongJae Park <sj@kernel.org>]

On Sat, 17 May 2025 19:50:34 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> 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

[...]