| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <cover.1750099179.git.lorenzo.stoakes@oracle.com>
Date: Mon, 16 Jun 2025 20:33:19 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "Liam R . Howlett" <Liam.Howlett@...cle.com>, Jens Axboe <axboe@...nel.dk>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Tvrtko Ursulin <tursulin@...ulin.net>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Eric Van Hensbergen <ericvh@...nel.org>,
Latchesar Ionkov <lucho@...kov.net>,
Dominique Martinet <asmadeus@...ewreck.org>,
Christian Schoenebeck <linux_oss@...debyte.com>,
David Sterba <dsterba@...e.com>, David Howells <dhowells@...hat.com>,
Marc Dionne <marc.dionne@...istor.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
Benjamin LaHaise <bcrl@...ck.org>, Miklos Szeredi <miklos@...redi.hu>,
Amir Goldstein <amir73il@...il.com>,
Kent Overstreet <kent.overstreet@...ux.dev>,
"Tigran A . Aivazian" <aivazian.tigran@...il.com>,
Kees Cook <kees@...nel.org>, Chris Mason <clm@...com>,
Josef Bacik <josef@...icpanda.com>, Xiubo Li <xiubli@...hat.com>,
Ilya Dryomov <idryomov@...il.com>, Jan Harkes <jaharkes@...cmu.edu>,
coda@...cmu.edu, Tyler Hicks <code@...icks.com>,
Gao Xiang <xiang@...nel.org>, Chao Yu <chao@...nel.org>,
Yue Hu <zbestahu@...il.com>, Jeffle Xu <jefflexu@...ux.alibaba.com>,
Sandeep Dhavale <dhavale@...gle.com>,
Hongbo Li <lihongbo22@...wei.com>, Namjae Jeon <linkinjeon@...nel.org>,
Sungjong Seo <sj1557.seo@...sung.com>,
Yuezhang Mo <yuezhang.mo@...y.com>, Theodore Ts'o <tytso@....edu>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Jaegeuk Kim <jaegeuk@...nel.org>,
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
Viacheslav Dubeyko <slava@...eyko.com>,
John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
Yangtao Li <frank.li@...o.com>, Richard Weinberger <richard@....at>,
Anton Ivanov <anton.ivanov@...bridgegreys.com>,
Johannes Berg <johannes@...solutions.net>,
Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>,
David Woodhouse <dwmw2@...radead.org>,
Dave Kleikamp <shaggy@...nel.org>,
Trond Myklebust <trondmy@...nel.org>, Anna Schumaker <anna@...nel.org>,
Ryusuke Konishi <konishi.ryusuke@...il.com>,
Konstantin Komarov <almaz.alexandrovich@...agon-software.com>,
Mark Fasheh <mark@...heh.com>, Joel Becker <jlbec@...lplan.org>,
Joseph Qi <joseph.qi@...ux.alibaba.com>,
Bob Copeland <me@...copeland.com>, Mike Marshall <hubcap@...ibond.com>,
Martin Brandenburg <martin@...ibond.com>,
Steve French <sfrench@...ba.org>, Paulo Alcantara <pc@...guebit.org>,
Ronnie Sahlberg <ronniesahlberg@...il.com>,
Shyam Prasad N <sprasad@...rosoft.com>, Tom Talpey <tom@...pey.com>,
Bharath SM <bharathsm@...rosoft.com>,
Zhihao Cheng <chengzhihao1@...wei.com>,
Hans de Goede <hdegoede@...hat.com>, Carlos Maiolino <cem@...nel.org>,
Damien Le Moal <dlemoal@...nel.org>,
Naohiro Aota <naohiro.aota@....com>,
Johannes Thumshirn <jth@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
Matthew Wilcox <willy@...radead.org>, Vlastimil Babka <vbabka@...e.cz>,
Jann Horn <jannh@...gle.com>, Pedro Falcato <pfalcato@...e.de>,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
v9fs@...ts.linux.dev, linux-fsdevel@...r.kernel.org,
linux-afs@...ts.infradead.org, linux-aio@...ck.org,
linux-unionfs@...r.kernel.org, linux-bcachefs@...r.kernel.org,
linux-mm@...ck.org, linux-btrfs@...r.kernel.org,
ceph-devel@...r.kernel.org, codalist@...a.cs.cmu.edu,
ecryptfs@...r.kernel.org, linux-erofs@...ts.ozlabs.org,
linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
linux-um@...ts.infradead.org, linux-mtd@...ts.infradead.org,
jfs-discussion@...ts.sourceforge.net, linux-nfs@...r.kernel.org,
linux-nilfs@...r.kernel.org, ntfs3@...ts.linux.dev,
ocfs2-devel@...ts.linux.dev, linux-karma-devel@...ts.sourceforge.net,
devel@...ts.orangefs.org, linux-cifs@...r.kernel.org,
samba-technical@...ts.samba.org, linux-xfs@...r.kernel.org,
nvdimm@...ts.linux.dev
Subject: [PATCH 00/10] convert the majority of file systems to mmap_prepare
REVIEWER'S NOTES
================
I am basing this on the mm-new branch in Andrew's tree, so let me know if I
should rebase anything here. Given the mm bits touched I did think perhaps
we should take it through the mm tree, however it may be more sensible to
take it through an fs tree - let me know!
Apologies for the noise/churn, but there are some prerequisite steps here
that inform an ordering - "fs: consistently use file_has_valid_mmap_hooks()
helper" being especially critical, and so I put the bulk of the work in the
same series.
Let me know if there's anything I can do to make life easier here.
Thanks!
===============
In commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
callback"), a new hook for mmap was introduced - f_op->mmap_prepare().
This is preferred to the existing f_op->mmap() hook as it does require a
VMA to be established yet, thus allowing the mmap logic to invoke this hook
far, far earlier, prior to inserting a VMA into the virtual address space,
or performing any other heavy handed operations.
This allows for much simpler unwinding on error, and for there to be a
single attempt at merging a VMA rather than having to possibly reattempt a
merge based on potentially altered VMA state.
Far more importantly, it prevents inappropriate manipulation of
incompletely initialised VMA state, which is something that has been the
cause of bugs and complexity in the past.
The intent is to gradually deprecate f_op->mmap, and in that vein this
series coverts the majority of file systems to using f_op->mmap_prepare.
Prerequisite steps are taken - firstly ensuring all checks for mmap
capabilities use the file_has_valid_mmap_hooks() helper rather than
directly checking for f_op->mmap (which is now not a valid check) and
secondly updating daxdev_mapping_supported() to not require a VMA parameter
to allow ext4 and xfs to be converted.
Commit bb666b7c2707 ("mm: add mmap_prepare() compatibility layer for nested
file systems") handles the nasty edge-case of nested file systems like
overlayfs, which introduces a compatibility shim to allow
f_op->mmap_prepare() to be invoked from an f_op->mmap() callback.
This allows for nested filesystems to continue to function correctly with
all file systems regardless of which callback is used. Once we finally
convert all file systems, this shim can be removed.
As a result, ecryptfs, fuse, and overlayfs remain unaltered so they can
nest all other file systems.
We additionally do not update resctl - as this requires an update to
remap_pfn_range() (or an alternative to it) which we defer to a later
series, equally we do not update cramfs which needs a mixed mapping
insertion with the same issue, nor do we update procfs, hugetlbfs, syfs or
kernfs all of which require VMAs for internal state and hooks. We shall
return to all of these later.
Lorenzo Stoakes (10):
mm: rename call_mmap/mmap_prepare to vfs_mmap/mmap_prepare
mm/nommu: use file_has_valid_mmap_hooks() helper
fs: consistently use file_has_valid_mmap_hooks() helper
fs/dax: make it possible to check dev dax support without a VMA
fs/ext4: transition from deprecated .mmap hook to .mmap_prepare
fs/xfs: transition from deprecated .mmap hook to .mmap_prepare
mm/filemap: introduce generic_file_*_mmap_prepare() helpers
fs: convert simple use of generic_file_*_mmap() to .mmap_prepare()
fs: convert most other generic_file_*mmap() users to .mmap_prepare()
fs: replace mmap hook with .mmap_prepare for simple mappings
block/fops.c | 9 +++---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
fs/9p/vfs_file.c | 13 +++++----
fs/adfs/file.c | 2 +-
fs/affs/file.c | 2 +-
fs/afs/file.c | 11 ++++----
fs/aio.c | 8 +++---
fs/backing-file.c | 4 +--
fs/bcachefs/fs.c | 8 +++---
fs/bfs/file.c | 2 +-
fs/binfmt_elf.c | 4 +--
fs/binfmt_elf_fdpic.c | 2 +-
fs/btrfs/file.c | 7 +++--
fs/ceph/addr.c | 5 ++--
fs/ceph/file.c | 2 +-
fs/ceph/super.h | 2 +-
fs/coda/file.c | 6 ++--
fs/ecryptfs/file.c | 2 +-
fs/erofs/data.c | 16 ++++++-----
fs/exfat/file.c | 7 +++--
fs/ext2/file.c | 12 ++++----
fs/ext4/file.c | 13 +++++----
fs/f2fs/file.c | 7 +++--
fs/fat/file.c | 2 +-
fs/hfs/inode.c | 2 +-
fs/hfsplus/inode.c | 2 +-
fs/hostfs/hostfs_kern.c | 2 +-
fs/hpfs/file.c | 2 +-
fs/jffs2/file.c | 2 +-
fs/jfs/file.c | 2 +-
fs/minix/file.c | 2 +-
fs/nfs/file.c | 13 +++++----
fs/nfs/internal.h | 2 +-
fs/nfs/nfs4file.c | 2 +-
fs/nilfs2/file.c | 8 +++---
fs/ntfs3/file.c | 15 +++++-----
fs/ocfs2/file.c | 4 +--
fs/ocfs2/mmap.c | 5 ++--
fs/ocfs2/mmap.h | 2 +-
fs/omfs/file.c | 2 +-
fs/orangefs/file.c | 10 ++++---
fs/ramfs/file-mmu.c | 2 +-
fs/ramfs/file-nommu.c | 12 ++++----
fs/read_write.c | 2 +-
fs/romfs/mmap-nommu.c | 6 ++--
fs/smb/client/cifsfs.c | 12 ++++----
fs/smb/client/cifsfs.h | 4 +--
fs/smb/client/file.c | 14 ++++++----
fs/ubifs/file.c | 8 +++---
fs/ufs/file.c | 2 +-
fs/vboxsf/file.c | 8 +++---
fs/xfs/xfs_file.c | 15 +++++-----
fs/zonefs/file.c | 10 ++++---
include/linux/dax.h | 16 ++++++-----
include/linux/fs.h | 11 ++++----
ipc/shm.c | 2 +-
mm/filemap.c | 29 ++++++++++++++++++++
mm/internal.h | 2 +-
mm/nommu.c | 2 +-
mm/vma.c | 2 +-
tools/testing/vma/vma_internal.h | 32 ++++++++++++++++++----
61 files changed, 245 insertions(+), 171 deletions(-)
--
2.49.0
Powered by blists - more mailing lists