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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250711120938.15270-1-lianux.mm@gmail.com>
Date: Fri, 11 Jul 2025 20:09:38 +0800
From: wang lian <lianux.mm@...il.com>
To: lorenzo.stoakes@...cle.com
Cc: Liam.Howlett@...cle.com,
	akpm@...ux-foundation.org,
	brauner@...nel.org,
	broonie@...nel.org,
	david@...hat.com,
	gkwang@...x-info.com,
	jannh@...gle.com,
	lianux.mm@...il.com,
	linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org,
	linux-mm@...ck.org,
	p1ucky0923@...il.com,
	ryncsn@...il.com,
	shuah@...nel.org,
	sj@...nel.org,
	vbabka@...e.cz,
	zijing.zhang@...ton.me,
	ziy@...dia.com
Subject: Re: [PATCH v3] selftests/mm: add process_madvise() tests

Hi Lorenzo Stoakes,

> On Fri, Jul 11, 2025 at 09:34:38AM +0100, Mark Brown wrote:
> > On Thu, Jul 10, 2025 at 12:28:13PM -0400, Zi Yan wrote:
> > > On 10 Jul 2025, at 4:42, Mark Brown wrote:
> > > > On Wed, Jul 09, 2025 at 10:46:07AM -0400, Zi Yan wrote:
> > > >
> > > > > Right. My /usr/include/sys does not have pidfd.h. IMHO selftests
> > > > > should not rely on userspace headers, otherwise we cannot test
> > > > > latest kernel changes.
> > > >
> > > > That's not realistic, we need to be able to use things like libc and for
> > > > many areas you'd just end up copying or reimplmenenting the userspace
> > > > libraries.  There's some concerns for sure, for example we used to have
> > >
> > > Sure. For libraries like libc, it is unrealistic to not rely on it.
> > > But for header files, are we expecting to install any kernel headers
> > > to the running system to get selftests compiled? If we are testing
> > > RC versions and header files might change before the actual release,
> > > that would pollute the system header files, right?
> >
> > Right, for the kernel's headers there's two things - we use a
> > combination of tools/include and 'make headers_install' which populates
> > usr/include in the kernel tree (apparently mm rejects the latter but it
> > is widely used in the selftests, especially for architecture specifics).
> > These install locally and used before the system headers.
> >
> > > > OTOH in a case like this where we can just refer directly to a kernel
> > > > header for some constants or structs then it does make sense to use the
> > > > kernel headers, or in other cases where we're testing things that are
> >
> > > That is exactly my point above.
> >
> > What was said was a bit stronger though, and might lead people down a
> > wheel reinvention path.
>
> Let's PLEASE not rehash all this again...
>
> This patch literally just needs PIDFD_SELF, I've provided a couple of ways
> of doing that without introducing this requirement.
>
> We already have a test that uses this with no problems ever reported on
> which this patch was based.
>
> Thanks.

You are absolutely right, and my apologies for introducing this
unnecessary header dependency.

Just to clarify, the build failure Zi Yan reported on arm64 was not
caused by PIDFD_SELF. It was from my use of the pidfd_open() glibc
wrapper in the test, which incorrectly pulled in the system's
<sys/pidfd.h>.

Based on our discussion and a review of other tests, I understand the
correct approach is to avoid such dependencies. I will fix this properly
in the next version by using a direct syscall wrapper for pidfd_open.
Thank you for the guidance.

Best regards,
Wang Lian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ