[PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[Yibin Liu]

UnixBench execl/shellscript (dynamically linked binaries) at 64+ cores are
bottlenecked on the i_mmap_rwsem semaphore due to heavy vma insert/remove
operations on the i_mmap tree, where libc.so.6 is the most frequent,
followed by ld-linux-x86-64.so.2 and the test executable itself.

This patch marks such files to skip rmap operations, avoiding frequent
interval tree insert/remove that cause i_mmap_rwsem lock contention.
The downside is these files can no longer be reclaimed (along with compact
and ksm), but since they are small and resident anyway, it's acceptable.
When all mapping processes exit, files can still be reclaimed normally.

Performance testing shows ~80% improvement in UnixBench execl/shellscript
scores on Hygon 7490, AMD zen4 9754 and Intel emerald rapids platform.

Signed-off-by: Yibin Liu <liuyibin@hygon.cn>
---
 fs/fcntl.c                 | 1 +
 fs/open.c                  | 6 ++++++
 include/linux/fs.h         | 3 +++
 include/uapi/linux/fcntl.h | 1 +
 mm/mmap.c                  | 3 ++-
 mm/vma.c                   | 8 +++++---
 6 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/fs/fcntl.c b/fs/fcntl.c
index beab8080badf..9b7cc1544735 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -349,6 +349,7 @@ static bool rw_hint_valid(u64 hint)
 	case RWH_WRITE_LIFE_MEDIUM:
 	case RWH_WRITE_LIFE_LONG:
 	case RWH_WRITE_LIFE_EXTREME:
+	case RWH_RMAP_EXCLUDE:
 		return true;
 	default:
 		return false;
diff --git a/fs/open.c b/fs/open.c
index 681d405bc61e..643ab7c6b461 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -46,6 +46,10 @@ int do_truncate(struct mnt_idmap *idmap, struct dentry *dentry,
 	if (length < 0)
 		return -EINVAL;
 
+	/* Prevent truncate on files marked as RMAP_EXCLUDE (e.g., libc, ld.so) */
+	if (filp && (filp->f_mode & FMODE_RMAP_EXCLUDE))
+		return -EPERM;
+
 	newattrs.ia_size = length;
 	newattrs.ia_valid = ATTR_SIZE | time_attrs;
 	if (filp) {
@@ -892,6 +896,8 @@ static int do_dentry_open(struct file *f,
 	path_get(&f->f_path);
 	f->f_inode = inode;
 	f->f_mapping = inode->i_mapping;
+	if (inode->i_write_hint == RWH_RMAP_EXCLUDE)
+		f->f_mode |= FMODE_RMAP_EXCLUDE;
 	f->f_wb_err = filemap_sample_wb_err(f->f_mapping);
 	f->f_sb_err = file_sample_sb_err(f);
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 11559c513dfb..d5c9e5a4c2b9 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -189,6 +189,9 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset,
 /* File does not contribute to nr_files count */
 #define FMODE_NOACCOUNT		((__force fmode_t)(1 << 29))
 
+/* File should exclude vma from rmap interval tree */
+#define FMODE_RMAP_EXCLUDE	((__force fmode_t)(1 << 30))
+
 /*
  * The two FMODE_NONOTIFY* define which fsnotify events should not be generated
  * for an open file. These are the possible values of
diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
index aadfbf6e0cb3..4969b4762071 100644
--- a/include/uapi/linux/fcntl.h
+++ b/include/uapi/linux/fcntl.h
@@ -72,6 +72,7 @@
 #define RWH_WRITE_LIFE_MEDIUM	3
 #define RWH_WRITE_LIFE_LONG	4
 #define RWH_WRITE_LIFE_EXTREME	5
+#define RWH_RMAP_EXCLUDE	6
 
 /*
  * The originally introduced spelling is remained from the first
diff --git a/mm/mmap.c b/mm/mmap.c
index 2311ae7c2ff4..3eb00997e86a 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1830,7 +1830,8 @@ __latent_entropy int dup_mmap(struct mm_struct *mm, struct mm_struct *oldmm)
 				mapping_allow_writable(mapping);
 			flush_dcache_mmap_lock(mapping);
 			/* insert tmp into the share list, just after mpnt */
-			vma_interval_tree_insert_after(tmp, mpnt,
+			if (!(file->f_mode & FMODE_RMAP_EXCLUDE))
+				vma_interval_tree_insert_after(tmp, mpnt,
 					&mapping->i_mmap);
 			flush_dcache_mmap_unlock(mapping);
 			i_mmap_unlock_write(mapping);
diff --git a/mm/vma.c b/mm/vma.c
index 377321b48734..f1e36e6a8702 100644
--- a/mm/vma.c
+++ b/mm/vma.c
@@ -234,7 +234,8 @@ static void __vma_link_file(struct vm_area_struct *vma,
 		mapping_allow_writable(mapping);
 
 	flush_dcache_mmap_lock(mapping);
-	vma_interval_tree_insert(vma, &mapping->i_mmap);
+	if (!(vma->vm_file->f_mode & FMODE_RMAP_EXCLUDE))
+		vma_interval_tree_insert(vma, &mapping->i_mmap);
 	flush_dcache_mmap_unlock(mapping);
 }
 
@@ -339,10 +340,11 @@ static void vma_complete(struct vma_prepare *vp, struct vma_iterator *vmi,
 			 struct mm_struct *mm)
 {
 	if (vp->file) {
-		if (vp->adj_next)
+		if (vp->adj_next && !(vp->adj_next->vm_file->f_mode & FMODE_RMAP_EXCLUDE))
 			vma_interval_tree_insert(vp->adj_next,
 						 &vp->mapping->i_mmap);
-		vma_interval_tree_insert(vp->vma, &vp->mapping->i_mmap);
+		if (!(vp->vma->vm_file->f_mode & FMODE_RMAP_EXCLUDE))
+			vma_interval_tree_insert(vp->vma, &vp->mapping->i_mmap);
 		flush_dcache_mmap_unlock(vp->mapping);
 	}
 
-- 
2.34.1

Re: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[Matthew Wilcox]

On Tue, Apr 21, 2026 at 10:09:32AM +0800, Yibin Liu wrote:
> +	/* Prevent truncate on files marked as RMAP_EXCLUDE (e.g., libc, ld.so) */
> +	if (filp && (filp->f_mode & FMODE_RMAP_EXCLUDE))
> +		return -EPERM;

You can't do this.  It means I can prevent anybody else from truncating
a file which I can open.

Re: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[Pedro Falcato]

I'm not sure how you're using get_maintainer.pl, but PLEASE CC people
correctly.

On Tue, Apr 21, 2026 at 10:09:32AM +0800, Yibin Liu wrote:
> UnixBench execl/shellscript (dynamically linked binaries) at 64+ cores are
> bottlenecked on the i_mmap_rwsem semaphore due to heavy vma insert/remove
> operations on the i_mmap tree, where libc.so.6 is the most frequent,
> followed by ld-linux-x86-64.so.2 and the test executable itself.
> 
> This patch marks such files to skip rmap operations, avoiding frequent
> interval tree insert/remove that cause i_mmap_rwsem lock contention.
> The downside is these files can no longer be reclaimed (along with compact

This does not work.

> and ksm), but since they are small and resident anyway, it's acceptable.

Which ones? ELF executables commonly have a lot of padding. How do you know
what to mark as !no_rmap? Who has permissions for that? This patch allows
any user to create a full DoS of the system by simply marking a really large
file as no-reclaim.

> When all mapping processes exit, files can still be reclaimed normally.
> 
> Performance testing shows ~80% improvement in UnixBench execl/shellscript
> scores on Hygon 7490, AMD zen4 9754 and Intel emerald rapids platform.
> 
> Signed-off-by: Yibin Liu <liuyibin@hygon.cn>
> ---
>  fs/fcntl.c                 | 1 +
>  fs/open.c                  | 6 ++++++
>  include/linux/fs.h         | 3 +++
>  include/uapi/linux/fcntl.h | 1 +
>  mm/mmap.c                  | 3 ++-
>  mm/vma.c                   | 8 +++++---
>  6 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/fcntl.c b/fs/fcntl.c
> index beab8080badf..9b7cc1544735 100644
> --- a/fs/fcntl.c
> +++ b/fs/fcntl.c
> @@ -349,6 +349,7 @@ static bool rw_hint_valid(u64 hint)
>  	case RWH_WRITE_LIFE_MEDIUM:
>  	case RWH_WRITE_LIFE_LONG:
>  	case RWH_WRITE_LIFE_EXTREME:
> +	case RWH_RMAP_EXCLUDE:
>  		return true;
>  	default:
>  		return false;
> diff --git a/fs/open.c b/fs/open.c
> index 681d405bc61e..643ab7c6b461 100644
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -46,6 +46,10 @@ int do_truncate(struct mnt_idmap *idmap, struct dentry *dentry,
>  	if (length < 0)
>  		return -EINVAL;
>  
> +	/* Prevent truncate on files marked as RMAP_EXCLUDE (e.g., libc, ld.so) */
> +	if (filp && (filp->f_mode & FMODE_RMAP_EXCLUDE))
> +		return -EPERM;
> +
>  	newattrs.ia_size = length;
>  	newattrs.ia_valid = ATTR_SIZE | time_attrs;
>  	if (filp) {
> @@ -892,6 +896,8 @@ static int do_dentry_open(struct file *f,
>  	path_get(&f->f_path);
>  	f->f_inode = inode;
>  	f->f_mapping = inode->i_mapping;
> +	if (inode->i_write_hint == RWH_RMAP_EXCLUDE)
> +		f->f_mode |= FMODE_RMAP_EXCLUDE;
>  	f->f_wb_err = filemap_sample_wb_err(f->f_mapping);
>  	f->f_sb_err = file_sample_sb_err(f);
>  
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 11559c513dfb..d5c9e5a4c2b9 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -189,6 +189,9 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset,
>  /* File does not contribute to nr_files count */
>  #define FMODE_NOACCOUNT		((__force fmode_t)(1 << 29))
>  
> +/* File should exclude vma from rmap interval tree */
> +#define FMODE_RMAP_EXCLUDE	((__force fmode_t)(1 << 30))
> +
>  /*
>   * The two FMODE_NONOTIFY* define which fsnotify events should not be generated
>   * for an open file. These are the possible values of
> diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
> index aadfbf6e0cb3..4969b4762071 100644
> --- a/include/uapi/linux/fcntl.h
> +++ b/include/uapi/linux/fcntl.h
> @@ -72,6 +72,7 @@
>  #define RWH_WRITE_LIFE_MEDIUM	3
>  #define RWH_WRITE_LIFE_LONG	4
>  #define RWH_WRITE_LIFE_EXTREME	5
> +#define RWH_RMAP_EXCLUDE	6

Userspace does not know what "rmap" is, nor does it need to know. Even if you
found a workable solution for the permission side, this is not a good solution,
and it's not a good interface. It also might solve it for you, but definitely
does not solve the whole issue with having a lock there (which you are, for
the record, still acquiring).

-- 
Pedro

Re: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[David Hildenbrand (Arm)]

>> @@ -72,6 +72,7 @@
>>  #define RWH_WRITE_LIFE_MEDIUM	3
>>  #define RWH_WRITE_LIFE_LONG	4
>>  #define RWH_WRITE_LIFE_EXTREME	5
>> +#define RWH_RMAP_EXCLUDE	6
> 
> Userspace does not know what "rmap" is, nor does it need to know. Even if you
> found a workable solution for the permission side, this is not a good solution,
> and it's not a good interface. 

It's horrible and I am surprised this patch is not tagged as RFC :)

-- 
Cheers,

David

Re: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[Mateusz Guzik]

On Tue, Apr 21, 2026 at 4:11 AM Yibin Liu <liuyibin@hygon.cn> wrote:
>
> UnixBench execl/shellscript (dynamically linked binaries) at 64+ cores are
> bottlenecked on the i_mmap_rwsem semaphore due to heavy vma insert/remove
> operations on the i_mmap tree, where libc.so.6 is the most frequent,
> followed by ld-linux-x86-64.so.2 and the test executable itself.
>
> This patch marks such files to skip rmap operations, avoiding frequent
> interval tree insert/remove that cause i_mmap_rwsem lock contention.
> The downside is these files can no longer be reclaimed (along with compact
> and ksm), but since they are small and resident anyway, it's acceptable.
> When all mapping processes exit, files can still be reclaimed normally.
>
> Performance testing shows ~80% improvement in UnixBench execl/shellscript
> scores on Hygon 7490, AMD zen4 9754 and Intel emerald rapids platform.
>

The other responders have been a little harsh and despite raising
valid points I don't think they gave a proper review.

The bigger picture is that the problematic rwsem is taken several
times during fork + exec + exit cycle. Normally you end up with 5
distinct mappings per binary/so, each created with a separate lock
acquire.

Some time ago I patched exit to batch processing, leaving 1 acquire in
that codepath. fork can and should be patched in a similar vein, but I
don't know if unixbench runs it in this benchmark (i.e., real
workloads certainly suffer from it, I don't know if this particular
bench includes that aspect). This is on top of forking itself being
avoidable should the kernel grow a better interface for executing
binaries.

This leaves us with mapping creation on exec. This problem is
unfixable without introduction of better APIs for userspace, which
constitutes quite a challenge.

The end result is the absolutely horrible case of multiple acquires of
the same lock per iteration.

One common idea how to reduce contention boils down to shortening lock
hold time. This has very limited effect in face of the aforementioned
multiple acquires and is at best a stop gap -- no matter what, the
ceiling is dictated by the extra acquires and it is incredibly low.

Your patch keeps the problematic acquire pattern intact and while the
80% win might sound encouraging, the end result is still severely
underperforming even a state where the lock is taken once in total
during exec.

Besides that, the internally-visible side effect of non-functional
rmap is pretty bad (and thus e.g., truncate) is pretty bad in its own
right, but let's ignore it. The primary problem here is that the patch
exposes a mechanism for userspace to dictate this in the first place.
Even ignoring the question of who should be using it and when, the
real solution to the problem would be confined to the kernel. Suppose
this patch lands and such a solution is implemented later -- now the
kernel is stuck having to support a now-useless (if not outright
harmful) feature.

What will fix the problem is sharding the state in some capacity,
provided no unfixable stopgap shows up.

Any other approach is putting small bandaids on it and can be a
consideration only if the decentralizing locking is proven too
problematic.

Pedro apparently volunteered to do the work, so I think we can wait to
see what he is going to end up cooking.

I hope this helps.

答复: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[Yibin Liu]

> On Tue, Apr 21, 2026 at 4:11 AM Yibin Liu <liuyibin@hygon.cn> wrote:
> >
> > UnixBench execl/shellscript (dynamically linked binaries) at 64+ cores are
> > bottlenecked on the i_mmap_rwsem semaphore due to heavy vma
> insert/remove
> > operations on the i_mmap tree, where libc.so.6 is the most frequent,
> > followed by ld-linux-x86-64.so.2 and the test executable itself.
> >
> > This patch marks such files to skip rmap operations, avoiding frequent
> > interval tree insert/remove that cause i_mmap_rwsem lock contention.
> > The downside is these files can no longer be reclaimed (along with compact
> > and ksm), but since they are small and resident anyway, it's acceptable.
> > When all mapping processes exit, files can still be reclaimed normally.
> >
> > Performance testing shows ~80% improvement in UnixBench execl/shellscript
> > scores on Hygon 7490, AMD zen4 9754 and Intel emerald rapids platform.
> >
> 
> The other responders have been a little harsh and despite raising
> valid points I don't think they gave a proper review.
> 
> The bigger picture is that the problematic rwsem is taken several
> times during fork + exec + exit cycle. Normally you end up with 5
> distinct mappings per binary/so, each created with a separate lock
> acquire.
> 
> Some time ago I patched exit to batch processing, leaving 1 acquire in
> that codepath. fork can and should be patched in a similar vein, but I
> don't know if unixbench runs it in this benchmark (i.e., real
> workloads certainly suffer from it, I don't know if this particular
> bench includes that aspect). This is on top of forking itself being
> avoidable should the kernel grow a better interface for executing
> binaries.
> 
Thank you for your opnions and advices, I'll try this way
> This leaves us with mapping creation on exec. This problem is
> unfixable without introduction of better APIs for userspace, which
> constitutes quite a challenge.
> 
> The end result is the absolutely horrible case of multiple acquires of
> the same lock per iteration.
> 
> One common idea how to reduce contention boils down to shortening lock
> hold time. This has very limited effect in face of the aforementioned
> multiple acquires and is at best a stop gap -- no matter what, the
> ceiling is dictated by the extra acquires and it is incredibly low.
> 
> Your patch keeps the problematic acquire pattern intact and while the
> 80% win might sound encouraging, the end result is still severely
> underperforming even a state where the lock is taken once in total
> during exec.
> 
> Besides that, the internally-visible side effect of non-functional
> rmap is pretty bad (and thus e.g., truncate) is pretty bad in its own
> right, but let's ignore it. The primary problem here is that the patch
> exposes a mechanism for userspace to dictate this in the first place.
> Even ignoring the question of who should be using it and when, the
> real solution to the problem would be confined to the kernel. Suppose
> this patch lands and such a solution is implemented later -- now the
> kernel is stuck having to support a now-useless (if not outright
> harmful) feature.
OK. I understand it now.
> 
> What will fix the problem is sharding the state in some capacity,
> provided no unfixable stopgap shows up.
> 
> Any other approach is putting small bandaids on it and can be a
> consideration only if the decentralizing locking is proven too
> problematic.
> 
> Pedro apparently volunteered to do the work, so I think we can wait to
> see what he is going to end up cooking.
> 
> I hope this helps.
> 

Re: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[Lorenzo Stoakes]

NAK obviously.

I hate to keep saying this to people, but you've got no excuse at this stage
it's been a year or so since we added mm maintainers/reviewers and you're not
sending this to the right people.

How hard is doing:

$ scripts/get_maintainer.pl --no-git fs/fcntl.c fs/open.c include/linux/fs.h \
	include/uapi/linux/fcntl.h mm/mmap.c mm/vma.c
Jeff Layton <jlayton@kernel.org> (maintainer:FILE LOCKING (flock() and fcntl()/lockf()))
Chuck Lever <chuck.lever@oracle.com> (maintainer:FILE LOCKING (flock() and fcntl()/lockf()))
Alexander Aring <alex.aring@gmail.com> (reviewer:FILE LOCKING (flock() and fcntl()/lockf()))
Alexander Viro <viro@zeniv.linux.org.uk> (maintainer:FILESYSTEMS (VFS and infrastructure))
Christian Brauner <brauner@kernel.org> (maintainer:FILESYSTEMS (VFS and infrastructure))
Jan Kara <jack@suse.cz> (reviewer:FILESYSTEMS (VFS and infrastructure))
Andrew Morton <akpm@linux-foundation.org> (maintainer:MEMORY MAPPING)
"Liam R. Howlett" <Liam.Howlett@oracle.com> (maintainer:MEMORY MAPPING)
Lorenzo Stoakes <ljs@kernel.org> (maintainer:MEMORY MAPPING)
Vlastimil Babka <vbabka@kernel.org> (reviewer:MEMORY MAPPING)
Jann Horn <jannh@google.com> (reviewer:MEMORY MAPPING)
Pedro Falcato <pfalcato@suse.de> (reviewer:MEMORY MAPPING)
linux-fsdevel@vger.kernel.org (open list:FILE LOCKING (flock() and fcntl()/lockf()))
linux-kernel@vger.kernel.org (open list)
linux-mm@kvack.org (open list:MEMORY MAPPING)

?

You're sending an insane patch that breaks core mm and you can't even send it to
the right people...

(And yet Mateusz is somehow cc'd (he loves that :))

This kind of craziness should be an RFC also as David said.

Both of these things are just rude and not helpful wrt upstream.

On Tue, Apr 21, 2026 at 10:09:32AM +0800, Yibin Liu wrote:
> UnixBench execl/shellscript (dynamically linked binaries) at 64+ cores are
> bottlenecked on the i_mmap_rwsem semaphore due to heavy vma insert/remove
> operations on the i_mmap tree, where libc.so.6 is the most frequent,
> followed by ld-linux-x86-64.so.2 and the test executable itself.

OK that's good to know, but please provide _actual data_. Hand waving isn't ok.

>
> This patch marks such files to skip rmap operations, avoiding frequent
> interval tree insert/remove that cause i_mmap_rwsem lock contention.

OK that's totally insane.

This is a classic example of 'I have problem X, therefore <do something insane
that happens to addess X>'.

> The downside is these files can no longer be reclaimed (along with compact
> and ksm), but since they are small and resident anyway, it's acceptable.
> When all mapping processes exit, files can still be reclaimed normally.
>

Yeah, that's quite the bloody downside. And 'they're small and resident
anyway'... err what on earth makes that a thing?

Also as Matthew points out, you're impacting _everybody else_, you're giving
avenues for unprivileged users to trigger total kernel lockups, you're breaking
migration, you're breaking reclaim, you're breaking basically all of rmap to fix
a performance issue.

> Performance testing shows ~80% improvement in UnixBench execl/shellscript
> scores on Hygon 7490, AMD zen4 9754 and Intel emerald rapids platform.

Yeah ok, I'm sure if I remove rmap altogether I'll get even better numbers :)

I can also take the oxygen system out of a plane and make it way more fuel
efficient!

>
> Signed-off-by: Yibin Liu <liuyibin@hygon.cn>
> ---
>  fs/fcntl.c                 | 1 +
>  fs/open.c                  | 6 ++++++
>  include/linux/fs.h         | 3 +++
>  include/uapi/linux/fcntl.h | 1 +
>  mm/mmap.c                  | 3 ++-
>  mm/vma.c                   | 8 +++++---
>  6 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/fs/fcntl.c b/fs/fcntl.c
> index beab8080badf..9b7cc1544735 100644
> --- a/fs/fcntl.c
> +++ b/fs/fcntl.c
> @@ -349,6 +349,7 @@ static bool rw_hint_valid(u64 hint)
>  	case RWH_WRITE_LIFE_MEDIUM:
>  	case RWH_WRITE_LIFE_LONG:
>  	case RWH_WRITE_LIFE_EXTREME:
> +	case RWH_RMAP_EXCLUDE:
>  		return true;
>  	default:
>  		return false;
> diff --git a/fs/open.c b/fs/open.c
> index 681d405bc61e..643ab7c6b461 100644
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -46,6 +46,10 @@ int do_truncate(struct mnt_idmap *idmap, struct dentry *dentry,
>  	if (length < 0)
>  		return -EINVAL;
>
> +	/* Prevent truncate on files marked as RMAP_EXCLUDE (e.g., libc, ld.so) */

Prevent truncation :)

RMAP_EXCLUDE :)))

Seriously no.

> +	if (filp && (filp->f_mode & FMODE_RMAP_EXCLUDE))
> +		return -EPERM;
> +
>  	newattrs.ia_size = length;
>  	newattrs.ia_valid = ATTR_SIZE | time_attrs;
>  	if (filp) {
> @@ -892,6 +896,8 @@ static int do_dentry_open(struct file *f,
>  	path_get(&f->f_path);
>  	f->f_inode = inode;
>  	f->f_mapping = inode->i_mapping;
> +	if (inode->i_write_hint == RWH_RMAP_EXCLUDE)
> +		f->f_mode |= FMODE_RMAP_EXCLUDE;
>  	f->f_wb_err = filemap_sample_wb_err(f->f_mapping);
>  	f->f_sb_err = file_sample_sb_err(f);
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 11559c513dfb..d5c9e5a4c2b9 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -189,6 +189,9 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset,
>  /* File does not contribute to nr_files count */
>  #define FMODE_NOACCOUNT		((__force fmode_t)(1 << 29))
>
> +/* File should exclude vma from rmap interval tree */
> +#define FMODE_RMAP_EXCLUDE	((__force fmode_t)(1 << 30))
> +
>  /*
>   * The two FMODE_NONOTIFY* define which fsnotify events should not be generated
>   * for an open file. These are the possible values of
> diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
> index aadfbf6e0cb3..4969b4762071 100644
> --- a/include/uapi/linux/fcntl.h
> +++ b/include/uapi/linux/fcntl.h
> @@ -72,6 +72,7 @@
>  #define RWH_WRITE_LIFE_MEDIUM	3
>  #define RWH_WRITE_LIFE_LONG	4
>  #define RWH_WRITE_LIFE_EXTREME	5
> +#define RWH_RMAP_EXCLUDE	6

As others have pointed out, rmap is not a user API, and it will NEVER be.

>
>  /*
>   * The originally introduced spelling is remained from the first
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 2311ae7c2ff4..3eb00997e86a 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1830,7 +1830,8 @@ __latent_entropy int dup_mmap(struct mm_struct *mm, struct mm_struct *oldmm)
>  				mapping_allow_writable(mapping);
>  			flush_dcache_mmap_lock(mapping);
>  			/* insert tmp into the share list, just after mpnt */
> -			vma_interval_tree_insert_after(tmp, mpnt,
> +			if (!(file->f_mode & FMODE_RMAP_EXCLUDE))
> +				vma_interval_tree_insert_after(tmp, mpnt,

Yeah this is just... this seems completely broken?

I'd be curious to see what sashiko finds for this lord :)

>  					&mapping->i_mmap);
>  			flush_dcache_mmap_unlock(mapping);
>  			i_mmap_unlock_write(mapping);
> diff --git a/mm/vma.c b/mm/vma.c
> index 377321b48734..f1e36e6a8702 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -234,7 +234,8 @@ static void __vma_link_file(struct vm_area_struct *vma,
>  		mapping_allow_writable(mapping);
>
>  	flush_dcache_mmap_lock(mapping);
> -	vma_interval_tree_insert(vma, &mapping->i_mmap);
> +	if (!(vma->vm_file->f_mode & FMODE_RMAP_EXCLUDE))
> +		vma_interval_tree_insert(vma, &mapping->i_mmap);
>  	flush_dcache_mmap_unlock(mapping);
>  }
>
> @@ -339,10 +340,11 @@ static void vma_complete(struct vma_prepare *vp, struct vma_iterator *vmi,
>  			 struct mm_struct *mm)
>  {
>  	if (vp->file) {
> -		if (vp->adj_next)
> +		if (vp->adj_next && !(vp->adj_next->vm_file->f_mode & FMODE_RMAP_EXCLUDE))
>  			vma_interval_tree_insert(vp->adj_next,
>  						 &vp->mapping->i_mmap);
> -		vma_interval_tree_insert(vp->vma, &vp->mapping->i_mmap);
> +		if (!(vp->vma->vm_file->f_mode & FMODE_RMAP_EXCLUDE))
> +			vma_interval_tree_insert(vp->vma, &vp->mapping->i_mmap);

Hang on, this is struct file * state that impacts folio-granularity behaviour?

I mean ugh anyway.

>  		flush_dcache_mmap_unlock(vp->mapping);
>  	}
>
> --
> 2.34.1
>
>
>

This idea is totally broken.

If you want to contribute usefully, PLEASE drop this silly idea, come back with
some NUMBERS about the contention you see, and let's have a sensible discussion
about what we can do to address that?

Also follow standard upstream kernel procedures - figure out who to email
properly, RFC insane ideas, etc.

Thanks, Lorenzo

答复: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[Yibin Liu]

First of all, I am truly sorry for not using RFC.
Secondly, I omitted many maintainers because I wanted to “not disturb too many people”, 
and I apologize deeply for that. I will fully follow these two rules from now on.

As for this patch, indeed, as Matthew said, the truncate part is not feasible. 
My original intention was to apply this to frequently used library files like libc and ld.
Contention on the i_mmap_rwsem lock (which eventually turns into osq_lock) caused by
these two files alone reaches up to 70% in the “256-core execl” case, as observed from
flame graphs. Besides, no one performs truncate operations on libc and ld anyway.

So I wanted to try skipping rmap for them. Since they are small, even if they cannot
be reclaimed or migrated, I assumed it would not cause much trouble. Of course,
this idea was totally wrong, and I will definitely mark such insane proposals with RFC in the future.

These ideas are inspired by Mateusz’s work and thoughts
(https://lore.kernel.org/linux-mm/CAGudoHEfiOPJ2VGEV3fDT9cDsuoHB-wk8jg-k-EK6JhWgiHkWw@mail.gmail.com/),
so I specifically CC’d him to seek more opinions and insights.

Lastly, I sincerely apologize for the trouble I have caused the community.
I will strictly follow community conventions when sending patches in the future.

> NAK obviously.
> 
> I hate to keep saying this to people, but you've got no excuse at this stage
> it's been a year or so since we added mm maintainers/reviewers and you're not
> sending this to the right people.
> 
> How hard is doing:
> 
> $ scripts/get_maintainer.pl --no-git fs/fcntl.c fs/open.c include/linux/fs.h \
> 	include/uapi/linux/fcntl.h mm/mmap.c mm/vma.c
> Jeff Layton <jlayton@kernel.org> (maintainer:FILE LOCKING (flock() and
> fcntl()/lockf()))
> Chuck Lever <chuck.lever@oracle.com> (maintainer:FILE LOCKING (flock() and
> fcntl()/lockf()))
> Alexander Aring <alex.aring@gmail.com> (reviewer:FILE LOCKING (flock() and
> fcntl()/lockf()))
> Alexander Viro <viro@zeniv.linux.org.uk> (maintainer:FILESYSTEMS (VFS and
> infrastructure))
> Christian Brauner <brauner@kernel.org> (maintainer:FILESYSTEMS (VFS and
> infrastructure))
> Jan Kara <jack@suse.cz> (reviewer:FILESYSTEMS (VFS and infrastructure))
> Andrew Morton <akpm@linux-foundation.org> (maintainer:MEMORY
> MAPPING)
> "Liam R. Howlett" <Liam.Howlett@oracle.com> (maintainer:MEMORY
> MAPPING)
> Lorenzo Stoakes <ljs@kernel.org> (maintainer:MEMORY MAPPING)
> Vlastimil Babka <vbabka@kernel.org> (reviewer:MEMORY MAPPING)
> Jann Horn <jannh@google.com> (reviewer:MEMORY MAPPING)
> Pedro Falcato <pfalcato@suse.de> (reviewer:MEMORY MAPPING)
> linux-fsdevel@vger.kernel.org (open list:FILE LOCKING (flock() and fcntl()/lockf()))
> linux-kernel@vger.kernel.org (open list)
> linux-mm@kvack.org (open list:MEMORY MAPPING)
> 
> ?
> 
> You're sending an insane patch that breaks core mm and you can't even send it
> to
> the right people...
> 
> (And yet Mateusz is somehow cc'd (he loves that :))
> 
> This kind of craziness should be an RFC also as David said.
> 
> Both of these things are just rude and not helpful wrt upstream.
> ... ...
> ... ...
> This idea is totally broken.
> 
> If you want to contribute usefully, PLEASE drop this silly idea, come back with
> some NUMBERS about the contention you see, and let's have a sensible
> discussion
> about what we can do to address that?
> 
> Also follow standard upstream kernel procedures - figure out who to email
> properly, RFC insane ideas, etc.
> 
> Thanks, Lorenzo

Re: 答复: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[Lorenzo Stoakes]

On Wed, Apr 22, 2026 at 12:51:06PM +0000, Yibin Liu wrote:
> First of all, I am truly sorry for not using RFC.
> Secondly, I omitted many maintainers because I wanted to “not disturb too many people”,
> and I apologize deeply for that. I will fully follow these two rules from now on.
>
> As for this patch, indeed, as Matthew said, the truncate part is not feasible.
> My original intention was to apply this to frequently used library files like libc and ld.
> Contention on the i_mmap_rwsem lock (which eventually turns into osq_lock) caused by
> these two files alone reaches up to 70% in the “256-core execl” case, as observed from
> flame graphs. Besides, no one performs truncate operations on libc and ld anyway.

Interesting, would be good to see these? And more details on the scenario?

What workloads are contending that exactly?

>
> So I wanted to try skipping rmap for them. Since they are small, even if they cannot
> be reclaimed or migrated, I assumed it would not cause much trouble. Of course,
> this idea was totally wrong, and I will definitely mark such insane proposals with RFC in the future.
>
> These ideas are inspired by Mateusz’s work and thoughts
> (https://lore.kernel.org/linux-mm/CAGudoHEfiOPJ2VGEV3fDT9cDsuoHB-wk8jg-k-EK6JhWgiHkWw@mail.gmail.com/),
> so I specifically CC’d him to seek more opinions and insights.

I think the best thing in general going forwards is to bring up this issues in
advance, we're more than happy to look into things and very interested in issues
with lock contention, latency, etc.

And that way you can discuss ideas you might have to tackle up front and we can
give you early feedback, which should save time all round and help get us to a
good solution :)

Just send with a [DISCUSSION] preface and cc- people you feel are relevant (use
MAINTAINERS to figure out e.g. maintainers of relevant things, like rmap, mmap,
etc.)

>
> Lastly, I sincerely apologize for the trouble I have caused the community.
> I will strictly follow community conventions when sending patches in the future.

It's no problem, better to be direct about this - it's more useful to discuss
rather than to jump to a solution without community involvement, which might not
work out/conflict with other stuff etc.

Thanks, Lorenzo

答复: 答复: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[Yibin Liu]

> On Wed, Apr 22, 2026 at 12:51:06PM +0000, Yibin Liu wrote:
> > First of all, I am truly sorry for not using RFC.
> > Secondly, I omitted many maintainers because I wanted to “not disturb too
> many people”,
> > and I apologize deeply for that. I will fully follow these two rules from now on.
> >
> > As for this patch, indeed, as Matthew said, the truncate part is not feasible.
> > My original intention was to apply this to frequently used library files like libc
> and ld.
> > Contention on the i_mmap_rwsem lock (which eventually turns into osq_lock)
> caused by
> > these two files alone reaches up to 70% in the “256-core execl” case, as
> observed from
> > flame graphs. Besides, no one performs truncate operations on libc and ld
> anyway.
> 
> Interesting, would be good to see these? And more details on the scenario?
> 
> What workloads are contending that exactly?
> 

It is good to see.
On an Intel Emerald Rapids server (112 cores), run the execl benchmark from
UnixBench with the command: ./Run -c 220 execl
Then perf top shows:

  91.53%  [kernel]                    [k] osq_lock
   0.50%  [kernel]                    [k] rwsem_spin_on_owner
   0.45%  perf                        [.] queue_event
   0.42%  [kernel]                    [k] vma_interval_tree_insert
   0.36%  [kernel]                    [k] next_uptodate_folio
   0.25%  [kernel]                    [k] __zap_vma_range

All the osq_lock overhead here comes from rwsem_optimistic_spin, and
rwsem_optimistic_spin has many call sources.
The breakdown is roughly as follows:

6.13%  _dl_main-->mprotect-->...-->__split_vma-->vma_prepare-->down_write(&mapping->i_mmap_rwsem)
6.15%  bprm_execve-->...-->exit_mmap-->...-->unlink_file_vma_batch_process-->down_write(&mapping->i_mmap_rwsem)
24.71% vma_link_file-->...-->down_write(&mapping->i_mmap_rwsem)
24.82% mmap_region-->...-->free_pgtalbes-->unlink_file_vma_batch_process-->down_write(&mapping->i_mmap_rwsem)
18.5%  mmap_region-->...-->__split_vma->vma_preapre-->down_write(&mapping->i_mmap_rwsem)
12.44% _dl_map_project-->mprotect-->...-->__split_vma-->vma_prepare-->down_write(&mapping->i_mmap_rwsem)

And AMD Zen5(9755) performs pretty much the same way (tested with ./Run -c 250 execl).

> >
> > So I wanted to try skipping rmap for them. Since they are small, even if they
> cannot
> > be reclaimed or migrated, I assumed it would not cause much trouble. Of
> course,
> > this idea was totally wrong, and I will definitely mark such insane proposals
> with RFC in the future.
> >
> > These ideas are inspired by Mateusz’s work and thoughts
> >
> (https://lore.kernel.org/linux-mm/CAGudoHEfiOPJ2VGEV3fDT9cDsuoHB-wk8jg-k
> -EK6JhWgiHkWw@mail.gmail.com/),
> > so I specifically CC’d him to seek more opinions and insights.
> 
> I think the best thing in general going forwards is to bring up this issues in
> advance, we're more than happy to look into things and very interested in issues
> with lock contention, latency, etc.
> 
> And that way you can discuss ideas you might have to tackle up front and we can
> give you early feedback, which should save time all round and help get us to a
> good solution :)
> 
> Just send with a [DISCUSSION] preface and cc- people you feel are relevant (use
> MAINTAINERS to figure out e.g. maintainers of relevant things, like rmap,
> mmap,
> etc.)
> 
> >
> > Lastly, I sincerely apologize for the trouble I have caused the community.
> > I will strictly follow community conventions when sending patches in the
> future.
> 
> It's no problem, better to be direct about this - it's more useful to discuss
> rather than to jump to a solution without community involvement, which might
> not
> work out/conflict with other stuff etc.
> 
> Thanks, Lorenzo

Thanks for the kind advice.

I will start a discussion first with a [DISCUSSION] tag and involve relevant
maintainers for similar ideas in the future.

Thanks, Yibin

Re: 答复: 答复: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[Matthew Wilcox]

On Fri, Apr 24, 2026 at 01:08:35AM +0000, Yibin Liu wrote:
> On an Intel Emerald Rapids server (112 cores), run the execl benchmark from
> UnixBench with the command: ./Run -c 220 execl
> Then perf top shows:
> 
>   91.53%  [kernel]                    [k] osq_lock
>    0.50%  [kernel]                    [k] rwsem_spin_on_owner

OK, but does this represent a realistic workload?  It's pretty easy to
construct workloads that hammer on particular locks; the question is
whether it's a relevant performance bottleneck that customers care about.

Re: 答复: 答复: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[Mateusz Guzik]

On Fri, Apr 24, 2026 at 5:20 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Fri, Apr 24, 2026 at 01:08:35AM +0000, Yibin Liu wrote:
> > On an Intel Emerald Rapids server (112 cores), run the execl benchmark from
> > UnixBench with the command: ./Run -c 220 execl
> > Then perf top shows:
> >
> >   91.53%  [kernel]                    [k] osq_lock
> >    0.50%  [kernel]                    [k] rwsem_spin_on_owner
>
> OK, but does this represent a realistic workload?  It's pretty easy to
> construct workloads that hammer on particular locks; the question is
> whether it's a relevant performance bottleneck that customers care about.

This is a genuine problem when doing large-scale package building.
I'll say upfront I have extensive experience with this crap on
FreeBSD, I did not run it on Linux myself, but bear with me here --
while FreeBSD is in doubt a less scalable kernel, Linux demonstrated
to be suffering from the same problems.

Say you have a box with a core count of 100 and get it to work
building up to 100 packages at a time. Further, even if you use some
form of separation from file-system standpoint on userspace level, you
still want to share the common binaries to reduce memory + cache
footprint so you at least --bind them. Then you are susceptible to
contention issues at least on paper.

Granted, building a pig like chromium scales great because it is
written in c++ and almost all of the time is spent in userspace, with
forks and execs of the compiler highly spread out in time, in turn
putting very little pressure on the locks.

However, vast majority of packages is very tiny in comparison
(literally a few .c files) and this is where things go south as they
engage in exec frenzy, looking like a borderline microbenchmark. The
primary culprit is configure scripts, issuing an idiotic number of
back-to-back execs of short-lived processes (notably sed, but also
grep, rm and others). There is a lot of evil in makefiles as well.

I don't have numbers handy, but in case of the FreeBSD ports tree we
are talking about over 10 000 ports which on their own take few
seconds to build. Since these are largely single-threaded, if you have
package-building machinery which can saturate the box, you easily end
up with parallel builds matching your core count. And when they engage
in exec-frenzy for the duration, you may as well be microbenchmarking
it.

A sufficiently pessimized workload is indistinguishable from a
microbenchmark and this here is an example of one.

iow this is a real problem, but I don't have specific numbers for Linux.

Re: 答复: 答复: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[Mateusz Guzik]

On Fri, Apr 24, 2026 at 8:20 AM Mateusz Guzik <mjguzik@gmail.com> wrote:
>
> On Fri, Apr 24, 2026 at 5:20 AM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Fri, Apr 24, 2026 at 01:08:35AM +0000, Yibin Liu wrote:
> > > On an Intel Emerald Rapids server (112 cores), run the execl benchmark from
> > > UnixBench with the command: ./Run -c 220 execl
> > > Then perf top shows:
> > >
> > >   91.53%  [kernel]                    [k] osq_lock
> > >    0.50%  [kernel]                    [k] rwsem_spin_on_owner
> >
> > OK, but does this represent a realistic workload?  It's pretty easy to
> > construct workloads that hammer on particular locks; the question is
> > whether it's a relevant performance bottleneck that customers care about.
>
> This is a genuine problem when doing large-scale package building.
> I'll say upfront I have extensive experience with this crap on
> FreeBSD, I did not run it on Linux myself, but bear with me here --
> while FreeBSD is in doubt a less scalable kernel, Linux demonstrated
> to be suffering from the same problems.
>
> Say you have a box with a core count of 100 and get it to work
> building up to 100 packages at a time. Further, even if you use some
> form of separation from file-system standpoint on userspace level, you
> still want to share the common binaries to reduce memory + cache
> footprint so you at least --bind them. Then you are susceptible to
> contention issues at least on paper.
>
> Granted, building a pig like chromium scales great because it is
> written in c++ and almost all of the time is spent in userspace, with
> forks and execs of the compiler highly spread out in time, in turn
> putting very little pressure on the locks.
>
> However, vast majority of packages is very tiny in comparison
> (literally a few .c files) and this is where things go south as they
> engage in exec frenzy, looking like a borderline microbenchmark. The
> primary culprit is configure scripts, issuing an idiotic number of
> back-to-back execs of short-lived processes (notably sed, but also
> grep, rm and others). There is a lot of evil in makefiles as well.
>
> I don't have numbers handy, but in case of the FreeBSD ports tree we
> are talking about over 10 000 ports which on their own take few
> seconds to build. Since these are largely single-threaded, if you have
> package-building machinery which can saturate the box, you easily end
> up with parallel builds matching your core count. And when they engage
> in exec-frenzy for the duration, you may as well be microbenchmarking
> it.
>
> A sufficiently pessimized workload is indistinguishable from a
> microbenchmark and this here is an example of one.
>
> iow this is a real problem, but I don't have specific numbers for Linux.

I had gcc handy on Linux, so I ran configure on it by hand. This is
all autotools generated, so general theme matches the small programs
as well.

I ended up with the following execs:
    285 /usr/bin/sed
     95 /usr/bin/rm
     88 /usr/bin/grep
     77 /usr/bin/cat
     30 /usr/bin/gcc
     27 /usr/bin/expr
     23 /usr/libexec/gcc/x86_64-linux-gnu/15/cc1
     21 /usr/bin/as
     10 /usr/bin/uname
      8 /usr/libexec/gcc/x86_64-linux-gnu/15/collect2
      8 /usr/bin/ld
      8 /bin/bash
      7 /usr/bin/mv
      7 /usr/bin/c++
      6 /usr/bin/mkdir
      6 /usr/bin/basename
      5 /usr/bin/ln
      5 /usr/bin/cmp
      4 /usr/bin/sort
      4 /usr/bin/dirname
      3 /usr/bin/rmdir
      3 /usr/bin/hostname
      3 /usr/bin/gawk
      3 /usr/bin/cc
      2 /usr/bin/strip
      2 /usr/bin/mktemp
      2 /usr/bin/ls
      2 /usr/bin/egrep
      2 /usr/bin/cp
      2 /usr/bin/ar
      2 /bin/sh
      1 /usr/lib/llvm-20/bin/clang
      1 /usr/bin/tr
      1 /usr/bin/touch
      1 /usr/bin/ranlib
      1 /usr/bin/install
      1 /usr/bin/diff
      1 /usr/bin/chmod
      1 /usr/bin/arch
      1 /home/mjg/repos/gcc/missing
      1 /bin/uname
      1 /bin/arch
      1 ./contrib/compare-debug
      1 ./conftest
      1 ./configure

It spent almost half of the runtime in the kernel, all while there was
no contention.

So imagine all that to compile a few .c files & rinse & repeat
thousands of times in parallel on 100+ cores.

Re: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[kernel test robot]

:::::: 
:::::: Manual check reason: "low confidence bisect report"
:::::: 

BCC: lkp@intel.com
CC: oe-kbuild-all@lists.linux.dev
In-Reply-To: <20260421020932.3212532-1-liuyibin@hygon.cn>
References: <20260421020932.3212532-1-liuyibin@hygon.cn>
TO: Yibin Liu <liuyibin@hygon.cn>
TO: linux-mm@kvack.org
CC: akpm@linux-foundation.org
CC: Liam.Howlett@oracle.com
CC: viro@zeniv.linux.org.uk
CC: brauner@kernel.org
CC: mjguzik@gmail.com
CC: wujianyong@hygon.cn
CC: huangsj@hygon.cn
CC: zhongyuan@hygon.cn

Hi Yibin,

kernel test robot noticed the following build errors:

[auto build test ERROR on akpm-mm/mm-everything]

url:    https://github.com/intel-lab-lkp/linux/commits/Yibin-Liu/mm-Add-RWH_RMAP_EXCLUDE-flag-to-exclude-files-from-rmap-sharing/20260423-115604
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link:    https://lore.kernel.org/r/20260421020932.3212532-1-liuyibin%40hygon.cn
patch subject: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing
:::::: branch date: 8 days ago
:::::: commit date: 8 days ago
config: x86_64-allnoconfig-bpf (https://download.01.org/0day-ci/archive/20260501/202605010820.9zCdrX8I-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260501/202605010820.9zCdrX8I-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/r/202605010820.9zCdrX8I-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from main.c:10:
   ../../../mm/vma.c: In function '__vma_link_file':
>> ../../../mm/vma.c:237:27: error: 'struct file' has no member named 'f_mode'
     237 |         if (!(vma->vm_file->f_mode & FMODE_RMAP_EXCLUDE))
         |                           ^~
>> ../../../mm/vma.c:237:38: error: 'FMODE_RMAP_EXCLUDE' undeclared (first use in this function)
     237 |         if (!(vma->vm_file->f_mode & FMODE_RMAP_EXCLUDE))
         |                                      ^~~~~~~~~~~~~~~~~~
   ../../../mm/vma.c:237:38: note: each undeclared identifier is reported only once for each function it appears in
   ../../../mm/vma.c: In function 'vma_complete':
   ../../../mm/vma.c:343:60: error: 'struct file' has no member named 'f_mode'
     343 |                 if (vp->adj_next && !(vp->adj_next->vm_file->f_mode & FMODE_RMAP_EXCLUDE))
         |                                                            ^~
   ../../../mm/vma.c:343:71: error: 'FMODE_RMAP_EXCLUDE' undeclared (first use in this function)
     343 |                 if (vp->adj_next && !(vp->adj_next->vm_file->f_mode & FMODE_RMAP_EXCLUDE))
         |                                                                       ^~~~~~~~~~~~~~~~~~
   ../../../mm/vma.c:346:39: error: 'struct file' has no member named 'f_mode'
     346 |                 if (!(vp->vma->vm_file->f_mode & FMODE_RMAP_EXCLUDE))
         |                                       ^~

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki