From: David Laight <David.Laight@ACULAB.COM>
To: 'Christian Brauner' <brauner@kernel.org>,
Aleksa Sarai <cyphar@cyphar.com>,
Jonathan Corbet <corbet@lwn.net>
Cc: "luca.boccassi@gmail.com" <luca.boccassi@gmail.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"christian@brauner.io" <christian@brauner.io>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"oleg@redhat.com" <oleg@redhat.com>
Subject: RE: [PATCH v9] pidfd: add ioctl to retrieve pid info
Date: Thu, 10 Oct 2024 13:16:20 +0000 [thread overview]
Message-ID: <f25c1e8cbad04c4fbc5b2f5e41ea6a59@AcuMS.aculab.com> (raw)
In-Reply-To: <20241010-bewilligen-wortkarg-3c1195a5fb70@brauner>
...
> pidfd_info overwrites the request_mask with what is supported by the
> kernel. I don't think userspace setting random stuff in the request_mask
> is a problem. It would already be a problem with statx() and we haven't
> seen that so far.
I don't think it is wise/necessary for the kernel to set bits that
weren't set in the request (for values that aren't being returned).
That would let you add some mutually exclusive options that use
the same part of the buffer area.
> If userspace happens to set a some random bit in the request_mask and
> that bit ends up being used a few kernel releases later to e.g.,
> retrieve additional information then all that happens is that userspace
> would now receive information they didn't need. That's not a problem.
Especially since the buffer is unlikely to be large enough.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2024-10-10 13:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-08 12:18 [PATCH v9] pidfd: add ioctl to retrieve pid info luca.boccassi
2024-10-08 13:06 ` Christian Brauner
2024-10-08 13:10 ` Luca Boccassi
2024-10-09 20:52 ` Aleksa Sarai
2024-10-10 9:38 ` Christian Brauner
2024-10-08 13:23 ` Christian Brauner
2024-10-09 19:20 ` Jonathan Corbet
2024-10-09 20:56 ` Aleksa Sarai
2024-10-09 21:06 ` Aleksa Sarai
2024-10-09 22:05 ` Jonathan Corbet
2024-10-13 5:57 ` Aleksa Sarai
2024-10-10 9:36 ` Christian Brauner
2024-10-10 12:41 ` Jonathan Corbet
2024-10-10 13:16 ` David Laight [this message]
2024-10-10 9:26 ` Christian Brauner
2024-10-09 20:50 ` Aleksa Sarai
2024-10-10 9:46 ` Christian Brauner
2024-10-10 15:55 ` Luca Boccassi
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=f25c1e8cbad04c4fbc5b2f5e41ea6a59@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=brauner@kernel.org \
--cc=christian@brauner.io \
--cc=corbet@lwn.net \
--cc=cyphar@cyphar.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.boccassi@gmail.com \
--cc=oleg@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).