From: David Hildenbrand <david@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Joey Pabalinas <joeypabalinas@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Hugh Dickins <hughd@google.com>
Subject: Re: [PATCH] mm/memfd: remove redundant casts
Date: Mon, 1 Sep 2025 15:23:22 +0200 [thread overview]
Message-ID: <177f4c8a-1ac7-4fee-bb34-ebecc4ba9384@redhat.com> (raw)
In-Reply-To: <20250831123426.3ce56a2448b520aba75f8edc@linux-foundation.org>
On 31.08.25 21:34, Andrew Morton wrote:
> On Sun, 31 Aug 2025 01:47:48 -1000 Joey Pabalinas <joeypabalinas@gmail.com> wrote:
>
>> MFD_ALL_FLAGS is already an unsigned int. Remove redundant casts to
>> unsigned int.
>
> lgtm.
>
> It's rather annoying that the MFD_ALL_FLAGS definition is so far away
> from the other MFD_* definitions. What do peope think of this little
> cleanup?
>
> From: Andrew Morton <akpm@linux-foundation.org>
> Subject: memfd: move MFD_ALL_FLAGS definition to memfd.h
> Date: Sun Aug 31 12:29:57 PM PDT 2025
>
> It's not part of the UAPI, but putting it here is better from a
> maintainability POV.
>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> include/uapi/linux/memfd.h | 2 ++
> mm/memfd.c | 2 --
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> --- a/mm/memfd.c~memfd-move-mfd_all_flags-definition-to-memfdh
> +++ a/mm/memfd.c
> @@ -313,8 +313,6 @@ long memfd_fcntl(struct file *file, unsi
> #define MFD_NAME_PREFIX_LEN (sizeof(MFD_NAME_PREFIX) - 1)
> #define MFD_NAME_MAX_LEN (NAME_MAX - MFD_NAME_PREFIX_LEN)
>
> -#define MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING | MFD_HUGETLB | MFD_NOEXEC_SEAL | MFD_EXEC)
> -
> static int check_sysctl_memfd_noexec(unsigned int *flags)
> {
> #ifdef CONFIG_SYSCTL
> --- a/include/uapi/linux/memfd.h~memfd-move-mfd_all_flags-definition-to-memfdh
> +++ a/include/uapi/linux/memfd.h
> @@ -12,6 +12,8 @@
> #define MFD_NOEXEC_SEAL 0x0008U
> /* executable */
> #define MFD_EXEC 0x0010U
> +#define MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING | \
> + MFD_HUGETLB | MFD_NOEXEC_SEAL | MFD_EXEC)
No strong opinion.
When we are exposing this through uapi, wondering if we should rename it
to something else that includes "MASK".
Quickly search for similar instances. For mmap we have the internal
"LEGACY_MAP_MASK", but that's also a bit different.
There is this oddity that we store the hugetlb size in the upper bits of
flags, masked by (MFD_HUGE_MASK << MFD_HUGE_SHIFT).
MFD_FLAGS_MASK maybe? not sure.
--
Cheers
David / dhildenb
prev parent reply other threads:[~2025-09-01 13:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-31 11:47 Joey Pabalinas
2025-08-31 19:34 ` Andrew Morton
2025-09-01 13:23 ` David Hildenbrand [this message]
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=177f4c8a-1ac7-4fee-bb34-ebecc4ba9384@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=hughd@google.com \
--cc=joeypabalinas@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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