linux-kernel - Re: Is number of process_madvise()-able ranges limited to 8? (was Re: [PATCH 1/6] prctl: introduce PR_THP_POLICY_DEFAULT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20250517202526.39730-1-sj@kernel.org>
Date: Sat, 17 May 2025 13:25:26 -0700
From: SeongJae Park <sj@...nel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: SeongJae Park <sj@...nel.org>,
	David Hildenbrand <david@...hat.com>,
	Usama Arif <usamaarif642@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-mm@...ck.org,
	hannes@...xchg.org,
	shakeel.butt@...ux.dev,
	riel@...riel.com,
	ziy@...dia.com,
	laoar.shao@...il.com,
	baolin.wang@...ux.alibaba.com,
	Liam.Howlett@...cle.com,
	npache@...hat.com,
	ryan.roberts@....com,
	linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org,
	kernel-team@...a.com
Subject: 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)

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

[...]