From: Usama Arif <usama.arif@linux.dev>
To: "Lorenzo Stoakes (Oracle)" <ljs@kernel.org>
Cc: Usama Arif <usama.arif@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
Clemens Ladisch <clemens@ladisch.de>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"K . Y . Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Long Li <longli@microsoft.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Bodo Stroesser <bostroesser@gmail.com>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
David Howells <dhowells@redhat.com>,
Marc Dionne <marc.dionne@auristor.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
David Hildenbrand <david@kernel.org>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Jann Horn <jannh@google.com>,
Pedro Falcato <pfalcato@suse.de>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-hyperv@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-mtd@lists.infradead.org, linux-staging@lists.linux.dev,
linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
linux-afs@lists.infradead.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, Ryan Roberts <ryan.roberts@arm.com>
Subject: Re: [PATCH 05/15] fs: afs: correctly drop reference count on mapping failure
Date: Fri, 13 Mar 2026 04:07:43 -0700 [thread overview]
Message-ID: <20260313110745.2573005-1-usama.arif@linux.dev> (raw)
In-Reply-To: <4a5fa45119220b9d99ed72a36308aed01a30d2c1.1773346620.git.ljs@kernel.org>
On Thu, 12 Mar 2026 20:27:20 +0000 "Lorenzo Stoakes (Oracle)" <ljs@kernel.org> wrote:
> Commit 9d5403b1036c ("fs: convert most other generic_file_*mmap() users to
> .mmap_prepare()") updated AFS to use the mmap_prepare callback in favour of
> the deprecated mmap callback.
>
> However, it did not account for the fact that mmap_prepare can fail to map
> due to an out of memory error, and thus should not be incrementing a
> reference count on mmap_prepare.
>
> With the newly added vm_ops->mapped callback available, we can simply defer
> this operation to that callback which is only invoked once the mapping is
> successfully in place (but not yet visible to userspace as the mmap and VMA
> write locks are held).
>
> Therefore add afs_mapped() to implement this callback for AFS.
>
> In practice the mapping allocations are 'too small to fail' so this is
> something that realistically should never happen in practice (or would do
> so in a case where the process is about to die anyway), but we should still
> handle this.
>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
> ---
> fs/afs/file.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/fs/afs/file.c b/fs/afs/file.c
> index f609366fd2ac..69ef86f5e274 100644
> --- a/fs/afs/file.c
> +++ b/fs/afs/file.c
> @@ -28,6 +28,8 @@ static ssize_t afs_file_splice_read(struct file *in, loff_t *ppos,
> static void afs_vm_open(struct vm_area_struct *area);
> static void afs_vm_close(struct vm_area_struct *area);
> static vm_fault_t afs_vm_map_pages(struct vm_fault *vmf, pgoff_t start_pgoff, pgoff_t end_pgoff);
> +static int afs_mapped(unsigned long start, unsigned long end, pgoff_t pgoff,
> + const struct file *file, void **vm_private_data);
>
> const struct file_operations afs_file_operations = {
> .open = afs_open,
> @@ -61,6 +63,7 @@ const struct address_space_operations afs_file_aops = {
> };
>
> static const struct vm_operations_struct afs_vm_ops = {
> + .mapped = afs_mapped,
> .open = afs_vm_open,
> .close = afs_vm_close,
> .fault = filemap_fault,
> @@ -500,13 +503,22 @@ static int afs_file_mmap_prepare(struct vm_area_desc *desc)
> afs_add_open_mmap(vnode);
Is the above afs_add_open_mmap an additional one, which could cause a reference
leak? Does the above one need to be removed and only the one in afs_mapped()
needs to be kept?
>
> ret = generic_file_mmap_prepare(desc);
> - if (ret == 0)
> - desc->vm_ops = &afs_vm_ops;
> - else
> - afs_drop_open_mmap(vnode);
> + if (ret)
> + return ret;
> +
> + desc->vm_ops = &afs_vm_ops;
> return ret;
> }
>
> +static int afs_mapped(unsigned long start, unsigned long end, pgoff_t pgoff,
> + const struct file *file, void **vm_private_data)
> +{
> + struct afs_vnode *vnode = AFS_FS_I(file_inode(file));
> +
> + afs_add_open_mmap(vnode);
> + return 0;
> +}
> +
> static void afs_vm_open(struct vm_area_struct *vma)
> {
> afs_add_open_mmap(AFS_FS_I(file_inode(vma->vm_file)));
> --
> 2.53.0
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Usama Arif <usama.arif@linux.dev>
To: "Lorenzo Stoakes (Oracle)" <ljs@kernel.org>
Cc: Usama Arif <usama.arif@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
Clemens Ladisch <clemens@ladisch.de>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"K . Y . Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Long Li <longli@microsoft.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Bodo Stroesser <bostroesser@gmail.com>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
David Howells <dhowells@redhat.com>,
Marc Dionne <marc.dionne@auristor.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
David Hildenbrand <david@kernel.org>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Jann Horn <jannh@google.com>,
Pedro Falcato <pfalcato@suse.de>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-hyperv@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-mtd@lists.infradead.org, linux-staging@lists.linux.dev,
linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
linux-afs@lists.infradead.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, Ryan Roberts <ryan.roberts@arm.com>
Subject: Re: [PATCH 05/15] fs: afs: correctly drop reference count on mapping failure
Date: Fri, 13 Mar 2026 04:07:43 -0700 [thread overview]
Message-ID: <20260313110745.2573005-1-usama.arif@linux.dev> (raw)
In-Reply-To: <4a5fa45119220b9d99ed72a36308aed01a30d2c1.1773346620.git.ljs@kernel.org>
On Thu, 12 Mar 2026 20:27:20 +0000 "Lorenzo Stoakes (Oracle)" <ljs@kernel.org> wrote:
> Commit 9d5403b1036c ("fs: convert most other generic_file_*mmap() users to
> .mmap_prepare()") updated AFS to use the mmap_prepare callback in favour of
> the deprecated mmap callback.
>
> However, it did not account for the fact that mmap_prepare can fail to map
> due to an out of memory error, and thus should not be incrementing a
> reference count on mmap_prepare.
>
> With the newly added vm_ops->mapped callback available, we can simply defer
> this operation to that callback which is only invoked once the mapping is
> successfully in place (but not yet visible to userspace as the mmap and VMA
> write locks are held).
>
> Therefore add afs_mapped() to implement this callback for AFS.
>
> In practice the mapping allocations are 'too small to fail' so this is
> something that realistically should never happen in practice (or would do
> so in a case where the process is about to die anyway), but we should still
> handle this.
>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
> ---
> fs/afs/file.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/fs/afs/file.c b/fs/afs/file.c
> index f609366fd2ac..69ef86f5e274 100644
> --- a/fs/afs/file.c
> +++ b/fs/afs/file.c
> @@ -28,6 +28,8 @@ static ssize_t afs_file_splice_read(struct file *in, loff_t *ppos,
> static void afs_vm_open(struct vm_area_struct *area);
> static void afs_vm_close(struct vm_area_struct *area);
> static vm_fault_t afs_vm_map_pages(struct vm_fault *vmf, pgoff_t start_pgoff, pgoff_t end_pgoff);
> +static int afs_mapped(unsigned long start, unsigned long end, pgoff_t pgoff,
> + const struct file *file, void **vm_private_data);
>
> const struct file_operations afs_file_operations = {
> .open = afs_open,
> @@ -61,6 +63,7 @@ const struct address_space_operations afs_file_aops = {
> };
>
> static const struct vm_operations_struct afs_vm_ops = {
> + .mapped = afs_mapped,
> .open = afs_vm_open,
> .close = afs_vm_close,
> .fault = filemap_fault,
> @@ -500,13 +503,22 @@ static int afs_file_mmap_prepare(struct vm_area_desc *desc)
> afs_add_open_mmap(vnode);
Is the above afs_add_open_mmap an additional one, which could cause a reference
leak? Does the above one need to be removed and only the one in afs_mapped()
needs to be kept?
>
> ret = generic_file_mmap_prepare(desc);
> - if (ret == 0)
> - desc->vm_ops = &afs_vm_ops;
> - else
> - afs_drop_open_mmap(vnode);
> + if (ret)
> + return ret;
> +
> + desc->vm_ops = &afs_vm_ops;
> return ret;
> }
>
> +static int afs_mapped(unsigned long start, unsigned long end, pgoff_t pgoff,
> + const struct file *file, void **vm_private_data)
> +{
> + struct afs_vnode *vnode = AFS_FS_I(file_inode(file));
> +
> + afs_add_open_mmap(vnode);
> + return 0;
> +}
> +
> static void afs_vm_open(struct vm_area_struct *vma)
> {
> afs_add_open_mmap(AFS_FS_I(file_inode(vma->vm_file)));
> --
> 2.53.0
>
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2026-03-13 11:08 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-12 20:27 [PATCH 00/15] mm: expand mmap_prepare functionality and usage Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` [PATCH 01/15] mm: various small mmap_prepare cleanups Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-12 21:14 ` Andrew Morton
2026-03-12 21:14 ` Andrew Morton
2026-03-13 12:13 ` Lorenzo Stoakes (Oracle)
2026-03-13 12:13 ` Lorenzo Stoakes (Oracle)
2026-03-13 8:00 ` kernel test robot
2026-03-16 14:44 ` Lorenzo Stoakes (Oracle)
2026-03-15 22:56 ` Suren Baghdasaryan
2026-03-15 22:56 ` Suren Baghdasaryan
2026-03-15 23:06 ` Suren Baghdasaryan
2026-03-15 23:06 ` Suren Baghdasaryan
2026-03-16 14:47 ` Lorenzo Stoakes (Oracle)
2026-03-16 14:47 ` Lorenzo Stoakes (Oracle)
2026-03-16 14:44 ` Lorenzo Stoakes (Oracle)
2026-03-16 14:44 ` Lorenzo Stoakes (Oracle)
2026-03-16 21:27 ` Suren Baghdasaryan
2026-03-16 21:27 ` Suren Baghdasaryan
2026-03-12 20:27 ` [PATCH 02/15] mm: add documentation for the mmap_prepare file operation callback Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-13 0:12 ` Randy Dunlap
2026-03-13 0:12 ` Randy Dunlap
2026-03-16 14:51 ` Lorenzo Stoakes (Oracle)
2026-03-16 14:51 ` Lorenzo Stoakes (Oracle)
2026-03-15 23:23 ` Suren Baghdasaryan
2026-03-15 23:23 ` Suren Baghdasaryan
2026-03-16 19:16 ` Lorenzo Stoakes (Oracle)
2026-03-16 19:16 ` Lorenzo Stoakes (Oracle)
2026-03-16 22:59 ` Suren Baghdasaryan
2026-03-16 22:59 ` Suren Baghdasaryan
2026-03-12 20:27 ` [PATCH 03/15] mm: document vm_operations_struct->open the same as close() Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-16 0:43 ` Suren Baghdasaryan
2026-03-16 0:43 ` Suren Baghdasaryan
2026-03-16 14:31 ` Lorenzo Stoakes (Oracle)
2026-03-16 14:31 ` Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` [PATCH 04/15] mm: add vm_ops->mapped hook Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-13 11:02 ` Usama Arif
2026-03-13 11:02 ` Usama Arif
2026-03-13 11:58 ` Lorenzo Stoakes (Oracle)
2026-03-13 11:58 ` Lorenzo Stoakes (Oracle)
2026-03-16 2:18 ` Suren Baghdasaryan
2026-03-16 2:18 ` Suren Baghdasaryan
2026-03-16 13:39 ` Lorenzo Stoakes (Oracle)
2026-03-16 13:39 ` Lorenzo Stoakes (Oracle)
2026-03-16 23:39 ` Suren Baghdasaryan
2026-03-16 23:39 ` Suren Baghdasaryan
2026-03-17 8:42 ` Lorenzo Stoakes (Oracle)
2026-03-17 8:42 ` Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` [PATCH 05/15] fs: afs: correctly drop reference count on mapping failure Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-13 11:07 ` Usama Arif [this message]
2026-03-13 11:07 ` Usama Arif
2026-03-13 12:00 ` Lorenzo Stoakes (Oracle)
2026-03-13 12:00 ` Lorenzo Stoakes (Oracle)
2026-03-16 2:32 ` Suren Baghdasaryan
2026-03-16 2:32 ` Suren Baghdasaryan
2026-03-16 14:29 ` Lorenzo Stoakes (Oracle)
2026-03-16 14:29 ` Lorenzo Stoakes (Oracle)
2026-03-17 3:41 ` Suren Baghdasaryan
2026-03-17 3:41 ` Suren Baghdasaryan
2026-03-17 8:58 ` Lorenzo Stoakes (Oracle)
2026-03-17 8:58 ` Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` [PATCH 06/15] mm: add mmap_action_simple_ioremap() Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` [PATCH 07/15] misc: open-dice: replace deprecated mmap hook with mmap_prepare Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` [PATCH 08/15] hpet: " Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` [PATCH 09/15] mtdchar: replace deprecated mmap hook with mmap_prepare, clean up Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` [PATCH 10/15] stm: replace deprecated mmap hook with mmap_prepare Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` [PATCH 11/15] staging: vme_user: " Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` [PATCH 12/15] mm: allow handling of stacked mmap_prepare hooks in more drivers Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` [PATCH 13/15] drivers: hv: vmbus: replace deprecated mmap hook with mmap_prepare Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` [PATCH 14/15] uio: replace deprecated mmap hook with mmap_prepare in uio_info Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` [PATCH 15/15] mm: add mmap_action_map_kernel_pages[_full]() Lorenzo Stoakes (Oracle)
2026-03-12 20:27 ` Lorenzo Stoakes (Oracle)
2026-03-12 23:15 ` Randy Dunlap
2026-03-12 23:15 ` Randy Dunlap
2026-03-16 14:54 ` Lorenzo Stoakes (Oracle)
2026-03-16 14:54 ` Lorenzo Stoakes (Oracle)
2026-03-12 21:23 ` [PATCH 00/15] mm: expand mmap_prepare functionality and usage Andrew Morton
2026-03-12 21:23 ` Andrew Morton
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=20260313110745.2573005-1-usama.arif@linux.dev \
--to=usama.arif@linux.dev \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexandre.torgue@foss.st.com \
--cc=arnd@arndb.de \
--cc=bostroesser@gmail.com \
--cc=brauner@kernel.org \
--cc=clemens@ladisch.de \
--cc=david@kernel.org \
--cc=decui@microsoft.com \
--cc=dhowells@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=haiyangz@microsoft.com \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=kys@microsoft.com \
--cc=linux-afs@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=ljs@kernel.org \
--cc=longli@microsoft.com \
--cc=marc.dionne@auristor.com \
--cc=martin.petersen@oracle.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mhocko@suse.com \
--cc=miquel.raynal@bootlin.com \
--cc=pfalcato@suse.de \
--cc=richard@nod.at \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=surenb@google.com \
--cc=target-devel@vger.kernel.org \
--cc=vbabka@kernel.org \
--cc=vigneshr@ti.com \
--cc=viro@zeniv.linux.org.uk \
--cc=wei.liu@kernel.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 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.