All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: SeongJae Park <sj@kernel.org>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Muchun Song <muchun.song@linux.dev>,
	Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>,
	Hugh Dickins <hughd@google.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Isaac Manjarres <isaacmanjarres@google.com>,
	Kalesh Singh <kaleshsingh@google.com>
Subject: Re: [PATCH] mm: perform all memfd seal checks in a single place
Date: Sat,  7 Dec 2024 11:22:51 -0800	[thread overview]
Message-ID: <20241207192251.204814-1-sj@kernel.org> (raw)
In-Reply-To: <20241206212846.210835-1-lorenzo.stoakes@oracle.com>

Hi Lorenzo,

On Fri, 6 Dec 2024 21:28:46 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:

> We no longer actually need to perform these checks in the f_op->mmap() hook
> any longer.
> 
> We already moved the operation which clears VM_MAYWRITE on a read-only
> mapping of a write-sealed memfd in order to work around the restrictions
> imposed by commit 5de195060b2e ("mm: resolve faulty mmap_region() error
> path behaviour").
> 
> There is no reason for us not to simply go ahead and additionally check to
> see if any pre-existing seals are in place here rather than defer this to
> the f_op->mmap() hook.
> 
> By doing this we remove more logic from shmem_mmap() which doesn't belong
> there, as well as doing the same for hugetlbfs_file_mmap(). We also remove
> dubious shared logic in mm.h which simply does not belong there either.
> 
> It makes sense to do these checks at the earliest opportunity, we know
> these are shmem (or hugetlbfs) mappings whose relevant VMA flags will not
> change from the invoking do_mmap() so there is simply no need to wait.
> 
> This also means the implementation of further memfd seal flags can be done
> within mm/memfd.c and also have the opportunity to modify VMA flags as
> necessary early in the mapping logic.
> 
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> ---
>  fs/hugetlbfs/inode.c  |  5 ----
>  include/linux/memfd.h | 22 ++++++++---------
>  include/linux/mm.h    | 55 -------------------------------------------
>  mm/memfd.c            | 44 +++++++++++++++++++++++++++++++++-
>  mm/mmap.c             | 12 +++++++---
>  mm/shmem.c            |  6 -----
>  6 files changed, 62 insertions(+), 82 deletions(-)
> 
[...]
> diff --git a/include/linux/memfd.h b/include/linux/memfd.h
> index d437e3070850..d53408b0bd31 100644
> --- a/include/linux/memfd.h
> +++ b/include/linux/memfd.h
> @@ -7,7 +7,14 @@
>  #ifdef CONFIG_MEMFD_CREATE
>  extern long memfd_fcntl(struct file *file, unsigned int cmd, unsigned int arg);
>  struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx);
> -unsigned int *memfd_file_seals_ptr(struct file *file);
> +/*
> + * Check for any existing seals on mmap, return an error if access is denied due
> + * to sealing, or 0 otherwise.
> + *
> + * We also update VMA flags if appropriate by manipulating the VMA flags pointed
> + * to by vm_flags_ptr.
> + */
> +int memfd_check_seals_mmap(struct file *file, unsigned long *vm_flags_ptr);
>  #else
>  static inline long memfd_fcntl(struct file *f, unsigned int c, unsigned int a)
>  {
> @@ -17,19 +24,10 @@ static inline struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx)
>  {
>  	return ERR_PTR(-EINVAL);
>  }
> -
> -static inline unsigned int *memfd_file_seals_ptr(struct file *file)
> +int memfd_check_seals_mmap(struct file *file, unsigned long *vm_flags)

Shouldn't we set this function as 'static inline'?  Otherwise, build fails when
CONFIG_MEMFD_CREATE is not defined, like below.

    ld: mm/mmap.o: in function `memfd_check_seals_mmap':
    mmap.c:(.text+0x...): multiple definition of `memfd_check_seals_mmap'; mm/gup.o:gup.c:(.text+0x...): first defined here
    ld: mm/secretmem.o: in function `memfd_check_seals_mmap':
    secretmem.c:(.text+0x...): multiple definition of `memfd_check_seals_mmap'; mm/gup.o:gup.c:(.text+0x...): first defined here

Also a trivial nit.  The second argument's name (vm_flags) is different from
that for CONFIG_MEMFD_CREATE=y (vm_flags_ptr).

>  {
> -	return NULL;
> +	return 0;
>  }
>  #endif
>  
> -/* Retrieve memfd seals associated with the file, if any. */
> -static inline unsigned int memfd_file_seals(struct file *file)
> -{
> -	unsigned int *sealsp = memfd_file_seals_ptr(file);
> -
> -	return sealsp ? *sealsp : 0;
> -}
> -
>  #endif /* __LINUX_MEMFD_H */


Thanks,
SJ

[...]


  reply	other threads:[~2024-12-07 19:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-06 21:28 [PATCH] mm: perform all memfd seal checks in a single place Lorenzo Stoakes
2024-12-07 19:22 ` SeongJae Park [this message]
2024-12-09 10:10   ` Lorenzo Stoakes
2024-12-09  3:54 ` kernel test robot
2024-12-09  3:59 ` kernel test robot
2024-12-09 10:11   ` Lorenzo Stoakes
2024-12-09 11:13 ` Lorenzo Stoakes
2024-12-09 22:21   ` Isaac Manjarres

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=20241207192251.204814-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=hughd@google.com \
    --cc=isaacmanjarres@google.com \
    --cc=jannh@google.com \
    --cc=kaleshsingh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=muchun.song@linux.dev \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.