From nobody Tue Apr 7 16:14:45 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CCA783803EF; Thu, 12 Mar 2026 20:28:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773347280; cv=none; b=itjex1aVRYLD0NdIAG+r5dg55sDx9z86/Xrzfs+QOCNGrwFu+/Cpn//jI7PVrMqpMprNWbdNT2tWXFvo+5MK5EW8kb4LmrueD+tkekcoBdh2s1D8xZM5taklvDlaEyA3SWohGZMZhzc9c4uC6xuAEwkbuO1ycqK+ooDDx4KUWLs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773347280; c=relaxed/simple; bh=+y+8TQWjiS/6OrohqiWfuyvPwbhSgEN2DOnPq14pRqA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YbMfedfqDUDIFxL2JoL5zUWiXtKC/jfMtjtghuqe2jL+zPZXO127jwWu2T8sNlL32Agm0qo1wYalAcJYznpyR1osg8OrIkUbbDYN7rYV0XMkl7z0Byphg4PpH8XI4YdOA27Z1Ifp3Rm1jxE1rHJTsGlBZc4nMsBSSTlmy6XAKDw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LfFsDlKL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LfFsDlKL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB1CFC4CEF7; Thu, 12 Mar 2026 20:27:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773347280; bh=+y+8TQWjiS/6OrohqiWfuyvPwbhSgEN2DOnPq14pRqA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LfFsDlKLNAp/oUkhFt8+RJpJFNYhJzB9jojo7IzLuXDt50MFkYyLL3CyAZ4orGL89 khtFo/M99wAIHGfgccHgA4i9BOZL5xKbg+QwXzkPEfJGsVsqudSj1PcBlmszAf6jUb ZdlUOHKcaob0y3vsG/pBzy4NU5HZTOTpdAht1Fp4UVqk0c69cBrynC1//SoepQdeej tzFBQxTBarGSS/viTR8OOOWGPKeCyBr/USYqWgbRQ/5DPHfa1oDWDRhxg/xB4dHxSF p5vuEySpbc07otTTLQ4eERmCocSh+bkDcVL8rWtVelKhT6mEOsZ0bVdv3mUICoipaS atIMiOhViZuxQ== From: "Lorenzo Stoakes (Oracle)" To: Andrew Morton Cc: Jonathan Corbet , Clemens Ladisch , Arnd Bergmann , Greg Kroah-Hartman , "K . Y . Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Alexander Shishkin , Maxime Coquelin , Alexandre Torgue , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Bodo Stroesser , "Martin K . Petersen" , David Howells , Marc Dionne , Alexander Viro , Christian Brauner , Jan Kara , David Hildenbrand , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jann Horn , Pedro Falcato , 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 Subject: [PATCH 05/15] fs: afs: correctly drop reference count on mapping failure Date: Thu, 12 Mar 2026 20:27:20 +0000 Message-ID: <4a5fa45119220b9d99ed72a36308aed01a30d2c1.1773346620.git.ljs@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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) --- 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_pgo= ff, pgoff_t end_pgoff); +static int afs_mapped(unsigned long start, unsigned long end, pgoff_t pgof= f, + const struct file *file, void **vm_private_data); =20 const struct file_operations afs_file_operations =3D { .open =3D afs_open, @@ -61,6 +63,7 @@ const struct address_space_operations afs_file_aops =3D { }; =20 static const struct vm_operations_struct afs_vm_ops =3D { + .mapped =3D afs_mapped, .open =3D afs_vm_open, .close =3D afs_vm_close, .fault =3D filemap_fault, @@ -500,13 +503,22 @@ static int afs_file_mmap_prepare(struct vm_area_desc = *desc) afs_add_open_mmap(vnode); =20 ret =3D generic_file_mmap_prepare(desc); - if (ret =3D=3D 0) - desc->vm_ops =3D &afs_vm_ops; - else - afs_drop_open_mmap(vnode); + if (ret) + return ret; + + desc->vm_ops =3D &afs_vm_ops; return ret; } =20 +static int afs_mapped(unsigned long start, unsigned long end, pgoff_t pgof= f, + const struct file *file, void **vm_private_data) +{ + struct afs_vnode *vnode =3D 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))); --=20 2.53.0