From: Shuah Khan <skhan@linuxfoundation.org>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Christian Brauner <christian@brauner.io>,
Shuah Khan <shuah@kernel.org>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
pedro.falcato@gmail.com, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
Oliver Sang <oliver.sang@intel.com>,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH v3 3/3] selftests: pidfd: add tests for PIDFD_SELF_*
Date: Wed, 16 Oct 2024 16:38:50 -0600 [thread overview]
Message-ID: <84c0de17-899e-46fd-8b72-534d8a02c259@linuxfoundation.org> (raw)
In-Reply-To: <a6133831-3fc3-49aa-83c6-f9aeef3713c9@lucifer.local>
On 10/16/24 16:06, Lorenzo Stoakes wrote:
> On Wed, Oct 16, 2024 at 02:00:27PM -0600, Shuah Khan wrote:
>> On 10/16/24 04:20, Lorenzo Stoakes wrote:
>>> Add tests to assert that PIDFD_SELF_* correctly refers to the current
>>> thread and process.
>>>
>>> This is only practically meaningful to pidfd_send_signal() and
>>> pidfd_getfd(), but also explicitly test that we disallow this feature for
>>> setns() where it would make no sense.
>>>
>>> We cannot reasonably wait on ourself using waitid(P_PIDFD, ...) so while in
>>> theory PIDFD_SELF_* would work here, we'd be left blocked if we tried it.
>>>
>>> We defer testing of mm-specific functionality which uses pidfd, namely
>>> process_madvise() and process_mrelease() to mm testing (though note the
>>> latter can not be sensibly tested as it would require the testing process
>>> to be dying).
>>>
>>> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>>> ---
>>> tools/testing/selftests/pidfd/pidfd.h | 8 +
>>> .../selftests/pidfd/pidfd_getfd_test.c | 141 ++++++++++++++++++
>>> .../selftests/pidfd/pidfd_setns_test.c | 11 ++
>>> tools/testing/selftests/pidfd/pidfd_test.c | 76 ++++++++--
>>> 4 files changed, 224 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/tools/testing/selftests/pidfd/pidfd.h b/tools/testing/selftests/pidfd/pidfd.h
>>> index 88d6830ee004..1640b711889b 100644
>>> --- a/tools/testing/selftests/pidfd/pidfd.h
>>> +++ b/tools/testing/selftests/pidfd/pidfd.h
>>> @@ -50,6 +50,14 @@
>>> #define PIDFD_NONBLOCK O_NONBLOCK
>>> #endif
>>> +/* System header file may not have this available. */
>>> +#ifndef PIDFD_SELF_THREAD
>>> +#define PIDFD_SELF_THREAD -100
>>> +#endif
>>> +#ifndef PIDFD_SELF_THREAD_GROUP
>>> +#define PIDFD_SELF_THREAD_GROUP -200
>>> +#endif
>>> +
>>
>> As mentioned in my response to v1 patch:
>>
>> kselftest has dependency on "make headers" and tests include
>> headers from linux/ directory
>
> Right but that assumes you install the kernel headers on the build system,
> which is quite a painful thing to have to do when you are quickly iterating
> on a qemu setup.
Yes that is exactly what we do. kselftest build depends on headers
install. The way it works for qemu is either using vitme-ng or
building tests and installing them in your vm.. This is what CIs do.
>
> This is a use case I use all the time so not at all theoretical.
This is what CIs do. Yes - it works for them to build and install
headers. You don't have to install them on the build system. You
run "make headers" in your repo. You could use O= option for
relocatable build.
>
> Unfortunately this seems broken on my system anyway :( - see below.
>
>>
>> These local make it difficult to maintain these tests in the
>> longer term. Somebody has to go clean these up later.
>
> I don't agree, tests have to be maintained alongside the core code, and if
> these values change (seems unlikely) then the tests will fail and can
> easily be updated.
>
> This was the approach already taken in this file with other linux
> header-defined values, so we'll also be breaking the precendence.
Some of these defines were added a while back. Often these defines
need cleaning up. I would rather not see new ones added unless it is
absolutely necessary.
>
>>
>> The import will be fine and you can control that with -I flag in
>> the makefile. Remove these and try to get including linux/pidfd.h
>> working.
>
> I just tried this and it's not fine :) it immediately broke the build as
> pidfd.h imports linux/fcntl.h which conflicts horribly with system headers
> on my machine.
>
> For instance f_owner_ex gets redefined among others and fails the build e..g:
>
> /usr/include/asm-generic/fcntl.h:155:8: error: redefinition of ‘struct f_owner_ex’
> 155 | struct f_owner_ex {
> | ^~~~~~~~~~
> In file included from /usr/include/bits/fcntl.h:61,
> from /usr/include/fcntl.h:35,
> from pidfd_test.c:6:
> /usr/include/bits/fcntl-linux.h:274:8: note: originally defined here
> 274 | struct f_owner_ex
> | ^~~~~~~~~~
>
> It seems only one other test tries to do this as far as I can tell (I only
> did a quick grep), so it's not at all standard it seems.
>
> This issue occurred even when I used make headers_install to create
> sanitised user headers and added them to the include path.
>
> A quick google suggests linux/fcntl.h (imported by this pidfd.h uapi
> header) and system fcntl.h is a known thing. Slightly bizarre...
>
> I tried removing the <fcntl.h> include and that resulted in <sys/mount.h>
> conflicting:
>
> In file included from /usr/include/fcntl.h:35,
> from /usr/include/sys/mount.h:24,
> from pidfd.h:17,
> from pidfd_test.c:22:
> /usr/include/bits/fcntl.h:35:8: error: redefinition of ‘struct flock’
> 35 | struct flock
> | ^~~~~
> In file included from /tmp/hdr/include/asm/fcntl.h:1,
> from /tmp/hdr/include/linux/fcntl.h:5,
> from /tmp/hdr/include/linux/pidfd.h:7,
> from pidfd.h:6:
> /usr/include/asm-generic/fcntl.h:195:8: note: originally defined here
> 195 | struct flock {
> | ^~~~~
>
> So I don't think I can actually work around this, at least on my system,
> and I can't really sensibly submit a patch that I can't run on my own
> machine :)
>
> I may be missing something here.
>
>>
>> Please revise this patch to include the header file and remove
>> these local defines.
>
> I'm a little stuck because of the above, but I _could_ do the following in
> the test pidfd.h header.:
>
> #define _LINUX_FCNTL_H
> #include "../../../../include/uapi/linux/pidfd.h"
> #undef _LINUX_FCNTL_H
>
Does this test really need fcntl.h is another question.
This is another problem with too many includes. The test
built just fine on my system on 6.12-rc3 with
+/* #include <fcntl.h> */
> Which prevents the problematic linux/fcntl.h header from being included and
> includes the right header.
>
> But I'm not sure this is hugely better than what we already have
> maintinability-wise? Either way if something changes to break it it'll
> break the test build.
>
If these defines are in a header file - tests include them. Part
of test development is figuring out these problems.
> Let me know if this is what you want me to do. Otherwise I'm not sure how
> to proceed - this header just seems broken at least on my system (arch
> linux at 6.11.1).
>
> An aside:
>
> The existing code already taken the approach I take (this is partly why I
> did it), I think it'd be out of the scope of my series to change that, for
> instance in pidfd.h:
>
> #ifndef PIDFD_NONBLOCK
> #define PIDFD_NONBLOCK O_NONBLOCK
> #endif
>
> Alongside a number of other defines. So those will have to stay at least
> for now for being out of scope, but obviously if people would prefer to
> move the whole thing that can be followed up later.
>
>>
I would like us to explore before giving up and saying these will
stay.
thanks,
-- Shuah
next prev parent reply other threads:[~2024-10-16 22:38 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-16 10:20 [PATCH v3 0/3] introduce PIDFD_SELF* sentinels Lorenzo Stoakes
2024-10-16 10:20 ` [PATCH v3 1/3] pidfd: extend pidfd_get_pid() and de-duplicate pid lookup Lorenzo Stoakes
2024-10-16 10:20 ` [PATCH v3 2/3] pidfd: add PIDFD_SELF_* sentinels to refer to own thread/process Lorenzo Stoakes
2024-10-16 10:20 ` [PATCH v3 3/3] selftests: pidfd: add tests for PIDFD_SELF_* Lorenzo Stoakes
2024-10-16 20:00 ` Shuah Khan
2024-10-16 22:06 ` Lorenzo Stoakes
2024-10-16 22:30 ` Lorenzo Stoakes
2024-10-16 22:38 ` Shuah Khan [this message]
2024-10-17 8:08 ` Lorenzo Stoakes
2024-10-17 12:06 ` Lorenzo Stoakes
2024-10-17 17:17 ` John Hubbard
2024-10-17 17:28 ` Lorenzo Stoakes
2024-10-17 17:37 ` John Hubbard
2024-10-17 17:38 ` Lorenzo Stoakes
2024-10-17 19:37 ` Shuah Khan
2024-10-17 19:40 ` Lorenzo Stoakes
2024-10-17 2:14 ` John Hubbard
2024-10-17 7:54 ` Lorenzo Stoakes
2025-05-01 11:42 ` Peter Zijlstra
2025-05-01 12:46 ` Peter Zijlstra
2025-05-01 19:50 ` Sean Christopherson
2025-05-05 13:35 ` Christian Brauner
2025-05-06 9:28 ` Lorenzo Stoakes
2025-05-06 21:18 ` Shuah Khan
2025-05-06 21:34 ` John Hubbard
2025-05-07 20:49 ` Shuah Khan
2024-10-17 2:01 ` The "make headers" requirement, revisited: " John Hubbard
2024-10-17 16:33 ` Shuah Khan
2024-10-17 16:47 ` John Hubbard
2025-05-07 20:50 ` Shuah Khan
2025-05-08 14:04 ` Sean Christopherson
2025-05-08 15:06 ` Shuah Khan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84c0de17-899e-46fd-8b72-534d8a02c259@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=Liam.Howlett@oracle.com \
--cc=christian@brauner.io \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=oliver.sang@intel.com \
--cc=pedro.falcato@gmail.com \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox