From richard.weiyang at gmail.com  Thu Jan 16 21:49:42 2025
From: richard.weiyang at gmail.com (Wei Yang)
Date: Fri, 17 Jan 2025 05:49:42 +0000
Subject: [PATCH 0/7] spanning write related cleanup
In-Reply-To: <cqulekn3csbs5q6vo3uormpplgbn7vvqir4a4pnaavgvhcsd3b@js4s5ncaritj>
References: <20241127012753.3393-1-richard.weiyang@gmail.com>
 <cqulekn3csbs5q6vo3uormpplgbn7vvqir4a4pnaavgvhcsd3b@js4s5ncaritj>
Message-ID: <20250117054942.w6vgrllnaasjaww3@master>

On Wed, Nov 27, 2024 at 08:31:13AM -0500, Liam R. Howlett wrote:
>* Wei Yang <richard.weiyang at gmail.com> [241126 20:28]:
>> Here is some cleanup related to spanning write.
>
>None of these fix anything, but do fiddle with code that's pretty
>critical to the kernel.  Most of the changes will be immeasurable in
>change but carry risk to causing subtle changes.
>
>Some are simple removal of returns that aren't used while others change
>things because you think they are probably the equivalent.  This seems
>like unnecessary chrun at this point.  I'm all for efficient code but
>this is getting a bit much, some of these are just preference of what to
>use that will already exist in the cpu cache.
>
>I'll get back to you when I dig through them, as some need a deeper look
>for sure.
>
>Liam
>

Hi, Liam

Would you mind taking a look when you have time?

-- 
Wei Yang
Help you, Help me


From Liam.Howlett at oracle.com  Thu Jan 23 09:52:40 2025
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Thu, 23 Jan 2025 12:52:40 -0500
Subject: [PATCH 0/7] spanning write related cleanup
In-Reply-To: <20250117054942.w6vgrllnaasjaww3@master>
References: <20241127012753.3393-1-richard.weiyang@gmail.com>
 <cqulekn3csbs5q6vo3uormpplgbn7vvqir4a4pnaavgvhcsd3b@js4s5ncaritj>
 <20250117054942.w6vgrllnaasjaww3@master>
Message-ID: <acq3uafsy54fo6nwcrrrqjkpojw7dnfy5ubwrissrn2726p64d@4izyq742k5ym>

* Wei Yang <richard.weiyang at gmail.com> [250117 00:49]:
> On Wed, Nov 27, 2024 at 08:31:13AM -0500, Liam R. Howlett wrote:
> >* Wei Yang <richard.weiyang at gmail.com> [241126 20:28]:
> >> Here is some cleanup related to spanning write.
> >
> >None of these fix anything, but do fiddle with code that's pretty
> >critical to the kernel.  Most of the changes will be immeasurable in
> >change but carry risk to causing subtle changes.
> >
> >Some are simple removal of returns that aren't used while others change
> >things because you think they are probably the equivalent.  This seems
> >like unnecessary chrun at this point.  I'm all for efficient code but
> >this is getting a bit much, some of these are just preference of what to
> >use that will already exist in the cpu cache.
> >
> >I'll get back to you when I dig through them, as some need a deeper look
> >for sure.
> >
> >Liam
> >
> 
> Hi, Liam
> 
> Would you mind taking a look when you have time?

Yes, I'll have a look soon.  I don't love changes that dive deep into
complex code that results in no gains (performance or feature wise).

It's also odd to have simple "this return isn't use" and things moving
code blocks to be executed only in certain scenarios, as the difficulty
to verify the latter is much higher.

Can we please limit changes to areas where there is a performance change
or coupled with a change that is needed?  ie: stop sending patches that
change things unless it's with a feature or improvement (performance or
otherwise).  I'm just not convinced some of these are worth the
cost vs risk.

Thanks,
Liam



From Liam.Howlett at oracle.com  Thu Jan 23 12:58:49 2025
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Thu, 23 Jan 2025 15:58:49 -0500
Subject: [PATCH] kernel/fork: Be more careful about dup_mmap() failures
Message-ID: <20250123205849.793810-1-Liam.Howlett@oracle.com>

From: "Liam R. Howlett" <Liam.Howlett at Oracle.com>

In the even that there is a failure during dup_mmap(), the maple tree
can be left in an unsafe state for other iterators besides the exit
path.

The unsafe state is created after the tree is cloned, but before the
vmas are replaced; if a vma allocation fails (for instance), then the
tree will have a marker (XA_ZERO_ENTRY) to denote where to stop
destroying vmas on the exit path.  This marker replaces a vma in the
tree and may be treated as a pointer to a vma in iterators besides the
special case exit_mmap() iterator.

All the locks are dropped before the exit_mmap() call, but the
incomplete mm_struct can be reached through (at least) the rmap finding
the vmas which have a pointer back to the mm_struct.

Up to this point, there have been no issues with being able to find an
mm_sturct that was only partially initialised.  Syzbot was able to make
the incomplete mm_struct fail with recent forking changes, so it has
been proven unsafe to use the mm_sturct that hasn't been initialised, as
referenced in the link below.

Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to
invalid mm") fixed the uprobe access, it does not completely remove the
race.

This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on
the oom side (even though this is extremely unlikely to be selected as
an oom victim in the race window), and sets MMF_UNSTABLE to avoid other
potential users from using a partially initialised mm_struct.

Link: https://lore.kernel.org/all/6756d273.050a0220.2477f.003d.GAE at google.com/
Fixes: d240629148377 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()")
Cc: Jann Horn <jannh at google.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes at oracle.com>
Cc: Peter Zijlstra <peterz at infradead.org>
Cc: Michal Hocko <mhocko at suse.com>
Cc: Peng Zhang <zhangpeng.00 at bytedance.com>
Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
---
 kernel/fork.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index ded49f18cd95c..20b2120f019ca 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -760,7 +760,8 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
 		mt_set_in_rcu(vmi.mas.tree);
 		ksm_fork(mm, oldmm);
 		khugepaged_fork(mm, oldmm);
-	} else if (mpnt) {
+	} else {
+
 		/*
 		 * The entire maple tree has already been duplicated. If the
 		 * mmap duplication fails, mark the failure point with
@@ -768,8 +769,18 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
 		 * stop releasing VMAs that have not been duplicated after this
 		 * point.
 		 */
-		mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
-		mas_store(&vmi.mas, XA_ZERO_ENTRY);
+		if (mpnt) {
+			mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
+			mas_store(&vmi.mas, XA_ZERO_ENTRY);
+			/* Avoid OOM iterating a broken tree */
+			set_bit(MMF_OOM_SKIP, &mm->flags);
+		}
+		/*
+		 * The mm_struct is going to exit, but the locks will be dropped
+		 * first.  Set the mm_struct as unstable is advisable as it is
+		 * not fully initialised.
+		 */
+		set_bit(MMF_UNSTABLE, &mm->flags);
 	}
 out:
 	mmap_write_unlock(mm);
-- 
2.43.0



From simon at gosfordukfinanceltd.com  Thu Jan 23 23:54:45 2025
From: simon at gosfordukfinanceltd.com (Mr Simon)
Date: 23 Jan 2025 23:54:45 -0800
Subject: NEW BUSINESS PLAN
Message-ID: <20250123235445.82366562236A2DB1@gosfordukfinanceltd.com>

Greetings,

The GOSFORD FINANCE & LOANS LTD (UK) invites you to partner with 
us and benefit from our new Loan and Project funding program. We
offer loans and funding for various good projects. This is 
however in the form of a partnership.

Do you have projects and businesses that require funding? We are 
ready to give out Loans (big or small), at just 2% per annum for
15 years. If you're interested in any of our proposals, then send 
me your mobile phone number so that I can write to you or give
you a call for more details on our Loan Investment Funding Plan.

I look forward to your response

Mr Simon
GOSFORD FINANCE &
LOANS LTD


From richard.weiyang at gmail.com  Thu Jan 23 17:43:56 2025
From: richard.weiyang at gmail.com (Wei Yang)
Date: Fri, 24 Jan 2025 01:43:56 +0000
Subject: [PATCH 0/7] spanning write related cleanup
In-Reply-To: <acq3uafsy54fo6nwcrrrqjkpojw7dnfy5ubwrissrn2726p64d@4izyq742k5ym>
References: <20241127012753.3393-1-richard.weiyang@gmail.com>
 <cqulekn3csbs5q6vo3uormpplgbn7vvqir4a4pnaavgvhcsd3b@js4s5ncaritj>
 <20250117054942.w6vgrllnaasjaww3@master>
 <acq3uafsy54fo6nwcrrrqjkpojw7dnfy5ubwrissrn2726p64d@4izyq742k5ym>
Message-ID: <20250124013412.2vpf7davx63s377d@master>

On Thu, Jan 23, 2025 at 12:52:40PM -0500, Liam R. Howlett wrote:
>* Wei Yang <richard.weiyang at gmail.com> [250117 00:49]:
>> On Wed, Nov 27, 2024 at 08:31:13AM -0500, Liam R. Howlett wrote:
>> >* Wei Yang <richard.weiyang at gmail.com> [241126 20:28]:
>> >> Here is some cleanup related to spanning write.
>> >
>> >None of these fix anything, but do fiddle with code that's pretty
>> >critical to the kernel.  Most of the changes will be immeasurable in
>> >change but carry risk to causing subtle changes.
>> >
>> >Some are simple removal of returns that aren't used while others change
>> >things because you think they are probably the equivalent.  This seems
>> >like unnecessary chrun at this point.  I'm all for efficient code but
>> >this is getting a bit much, some of these are just preference of what to
>> >use that will already exist in the cpu cache.
>> >
>> >I'll get back to you when I dig through them, as some need a deeper look
>> >for sure.
>> >
>> >Liam
>> >
>> 
>> Hi, Liam
>> 
>> Would you mind taking a look when you have time?
>
>Yes, I'll have a look soon.  I don't love changes that dive deep into
>complex code that results in no gains (performance or feature wise).
>
>It's also odd to have simple "this return isn't use" and things moving
>code blocks to be executed only in certain scenarios, as the difficulty
>to verify the latter is much higher.
>
>Can we please limit changes to areas where there is a performance change
>or coupled with a change that is needed?  ie: stop sending patches that
>change things unless it's with a feature or improvement (performance or
>otherwise).  I'm just not convinced some of these are worth the
>cost vs risk.
>

Ok.

So you would drop this patch set or still want to take a look?

>Thanks,
>Liam

-- 
Wei Yang
Help you, Help me


From lorenzo.stoakes at oracle.com  Fri Jan 24 03:15:38 2025
From: lorenzo.stoakes at oracle.com (Lorenzo Stoakes)
Date: Fri, 24 Jan 2025 11:15:38 +0000
Subject: [PATCH] kernel/fork: Be more careful about dup_mmap() failures
In-Reply-To: <20250123205849.793810-1-Liam.Howlett@oracle.com>
References: <20250123205849.793810-1-Liam.Howlett@oracle.com>
Message-ID: <7a16bf18-e193-4e0a-9e3b-83f609cb9e72@lucifer.local>

On Thu, Jan 23, 2025 at 03:58:49PM -0500, Liam R. Howlett wrote:
> From: "Liam R. Howlett" <Liam.Howlett at Oracle.com>
>
> In the even that there is a failure during dup_mmap(), the maple tree
> can be left in an unsafe state for other iterators besides the exit
> path.
>
> The unsafe state is created after the tree is cloned, but before the
> vmas are replaced; if a vma allocation fails (for instance), then the
> tree will have a marker (XA_ZERO_ENTRY) to denote where to stop
> destroying vmas on the exit path.  This marker replaces a vma in the
> tree and may be treated as a pointer to a vma in iterators besides the
> special case exit_mmap() iterator.

Thanks for addresing this.

In the original issue, the problem arose in vm_area_dup() which I tracked
down to vma_iter_load() -> mas_walk() (see [0]).

I'm not sure if your change would actually have addressed this? Would the
MMF_UNSTABLE flag prevent this code path from being taken (if so where?),
if not don't we need to add a check for this somewhere?

[0]:https://lore.kernel.org/all/aa2c1930-becc-4bc5-adfb-96e88290acc7 at lucifer.local/

>
> All the locks are dropped before the exit_mmap() call, but the
> incomplete mm_struct can be reached through (at least) the rmap finding
> the vmas which have a pointer back to the mm_struct.
>
> Up to this point, there have been no issues with being able to find an
> mm_sturct that was only partially initialised.  Syzbot was able to make
> the incomplete mm_struct fail with recent forking changes, so it has
> been proven unsafe to use the mm_sturct that hasn't been initialised, as
> referenced in the link below.
>
> Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to
> invalid mm") fixed the uprobe access, it does not completely remove the
> race.
>
> This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on
> the oom side (even though this is extremely unlikely to be selected as
> an oom victim in the race window), and sets MMF_UNSTABLE to avoid other
> potential users from using a partially initialised mm_struct.

Good to have it set also I think.

We were concerned that _somehow_ MMF_UNSTABLE might cause some issue in
OOM, which was why when I first thought of this we decided maybe not just
to be safe, but I am confident this will not be an issue as indicating that
something is about to be torn down and is unstable when it is in fact
unstable and about to be torn down is correct, plus I checked all the paths
where this impacted and found no issues.

And in any case, setting this flag avoids the problem...!

>
> Link: https://lore.kernel.org/all/6756d273.050a0220.2477f.003d.GAE at google.com/
> Fixes: d240629148377 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()")
> Cc: Jann Horn <jannh at google.com>
> Cc: Lorenzo Stoakes <lorenzo.stoakes at oracle.com>
> Cc: Peter Zijlstra <peterz at infradead.org>
> Cc: Michal Hocko <mhocko at suse.com>
> Cc: Peng Zhang <zhangpeng.00 at bytedance.com>
> Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> ---
>  kernel/fork.c | 17 ++++++++++++++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index ded49f18cd95c..20b2120f019ca 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -760,7 +760,8 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
>  		mt_set_in_rcu(vmi.mas.tree);
>  		ksm_fork(mm, oldmm);
>  		khugepaged_fork(mm, oldmm);
> -	} else if (mpnt) {
> +	} else {
> +
>  		/*
>  		 * The entire maple tree has already been duplicated. If the
>  		 * mmap duplication fails, mark the failure point with
> @@ -768,8 +769,18 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
>  		 * stop releasing VMAs that have not been duplicated after this
>  		 * point.
>  		 */
> -		mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
> -		mas_store(&vmi.mas, XA_ZERO_ENTRY);
> +		if (mpnt) {
> +			mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
> +			mas_store(&vmi.mas, XA_ZERO_ENTRY);
> +			/* Avoid OOM iterating a broken tree */
> +			set_bit(MMF_OOM_SKIP, &mm->flags);
> +		}
> +		/*
> +		 * The mm_struct is going to exit, but the locks will be dropped
> +		 * first.  Set the mm_struct as unstable is advisable as it is
> +		 * not fully initialised.
> +		 */
> +		set_bit(MMF_UNSTABLE, &mm->flags);

Do we still need to do this if !mpnt?

Also 'mpnt' is in the running for the worst variable name in mm...

>  	}
>  out:
>  	mmap_write_unlock(mm);
> --
> 2.43.0
>


From Liam.Howlett at oracle.com  Fri Jan 24 10:19:45 2025
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Fri, 24 Jan 2025 13:19:45 -0500
Subject: [PATCH] kernel/fork: Be more careful about dup_mmap() failures
In-Reply-To: <7a16bf18-e193-4e0a-9e3b-83f609cb9e72@lucifer.local>
Message-ID: <zsmj4kvuaqhq7bo7e3nenetshuyfinshhej5qjftwj2eq7jtkm@zekug2ivnzby>

Adding Oleg, who I forgot on the start of this patch..


* Lorenzo Stoakes <lorenzo.stoakes at oracle.com> [250124 06:15]:
> On Thu, Jan 23, 2025 at 03:58:49PM -0500, Liam R. Howlett wrote:
> > From: "Liam R. Howlett" <Liam.Howlett at Oracle.com>
> >
> > In the even that there is a failure during dup_mmap(), the maple tree
> > can be left in an unsafe state for other iterators besides the exit
> > path.
> >
> > The unsafe state is created after the tree is cloned, but before the
> > vmas are replaced; if a vma allocation fails (for instance), then the
> > tree will have a marker (XA_ZERO_ENTRY) to denote where to stop
> > destroying vmas on the exit path.  This marker replaces a vma in the
> > tree and may be treated as a pointer to a vma in iterators besides the
> > special case exit_mmap() iterator.
> 
> Thanks for addresing this.

Thanks for looking at the patch.

> 
> In the original issue, the problem arose in vm_area_dup() which I tracked
> down to vma_iter_load() -> mas_walk() (see [0]).
> 
> I'm not sure if your change would actually have addressed this? Would the
> MMF_UNSTABLE flag prevent this code path from being taken (if so where?),
> if not don't we need to add a check for this somewhere?
> 
> [0]:https://lore.kernel.org/all/aa2c1930-becc-4bc5-adfb-96e88290acc7 at lucifer.local/

Remote vma accesses use check_stable_address_space() to avoid races
with the oom killer, which checks MMF_UNSTABLE.

Yeah, uprobe needs to do this and doesn't today.

Oleg suggested this be done in build_map_info(), but the MMF_UNSTABLE
bit is set under the mmap read lock and that function uses the read lock
on the rmap, takes an mm references and records the address -  then
revisits the mm later to get the vma in register_for_each_vma().

I think we need to check in register_for_each_vma(), prior to looking up
the vma.  This way we hold the write lock on the mm and will ensure the
vma is stable from both the fork setup and a potential OOM events.  The
concern is that we have an invalid vma or the prev/next is invalid and
that will only be a concern when operating on the vma itself, so this
would be the safest place imo.

The problem that has been created is that the next vma may be invalid.
This arises when the rmap is used to find a vma then changes that vma.
In this scenario, the mmap lock of the vma needs to be held and that mm
needs to be checked as stable/not oom'ed.  So we can limit the checking
of the code to the scenario where another mm's vma is found and
modified - which may cause a merge and look at the next vma.

I haven't found anywhere else that looks up another mm_struct's vma and
makes a change to the vma.  Considering what that would mean, it makes
sense that this is rare.

So, I'll just do this:

--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1260,6 +1260,9 @@ register_for_each_vma(struct uprobe *uprobe, struct uprobe_consumer *new)
                 * returns NULL in find_active_uprobe_rcu().
                 */
                mmap_write_lock(mm);
+               if (check_stable_address_space(mm)
+                               goto unlock;
+




> 
> >
> > All the locks are dropped before the exit_mmap() call, but the
> > incomplete mm_struct can be reached through (at least) the rmap finding
> > the vmas which have a pointer back to the mm_struct.
> >
> > Up to this point, there have been no issues with being able to find an
> > mm_sturct that was only partially initialised.  Syzbot was able to make
> > the incomplete mm_struct fail with recent forking changes, so it has
> > been proven unsafe to use the mm_sturct that hasn't been initialised, as
> > referenced in the link below.
> >
> > Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to
> > invalid mm") fixed the uprobe access, it does not completely remove the
> > race.
> >
> > This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on
> > the oom side (even though this is extremely unlikely to be selected as
> > an oom victim in the race window), and sets MMF_UNSTABLE to avoid other
> > potential users from using a partially initialised mm_struct.
> 
> Good to have it set also I think.
> 
> We were concerned that _somehow_ MMF_UNSTABLE might cause some issue in
> OOM, which was why when I first thought of this we decided maybe not just
> to be safe, but I am confident this will not be an issue as indicating that
> something is about to be torn down and is unstable when it is in fact
> unstable and about to be torn down is correct, plus I checked all the paths
> where this impacted and found no issues.
> 
> And in any case, setting this flag avoids the problem...!
> 
> >
> > Link: https://lore.kernel.org/all/6756d273.050a0220.2477f.003d.GAE at google.com/
> > Fixes: d240629148377 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()")
> > Cc: Jann Horn <jannh at google.com>
> > Cc: Lorenzo Stoakes <lorenzo.stoakes at oracle.com>
> > Cc: Peter Zijlstra <peterz at infradead.org>
> > Cc: Michal Hocko <mhocko at suse.com>
> > Cc: Peng Zhang <zhangpeng.00 at bytedance.com>
> > Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> > ---
> >  kernel/fork.c | 17 ++++++++++++++---
> >  1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index ded49f18cd95c..20b2120f019ca 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -760,7 +760,8 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
> >  		mt_set_in_rcu(vmi.mas.tree);
> >  		ksm_fork(mm, oldmm);
> >  		khugepaged_fork(mm, oldmm);
> > -	} else if (mpnt) {
> > +	} else {
> > +
> >  		/*
> >  		 * The entire maple tree has already been duplicated. If the
> >  		 * mmap duplication fails, mark the failure point with
> > @@ -768,8 +769,18 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
> >  		 * stop releasing VMAs that have not been duplicated after this
> >  		 * point.
> >  		 */
> > -		mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
> > -		mas_store(&vmi.mas, XA_ZERO_ENTRY);
> > +		if (mpnt) {
> > +			mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
> > +			mas_store(&vmi.mas, XA_ZERO_ENTRY);
> > +			/* Avoid OOM iterating a broken tree */
> > +			set_bit(MMF_OOM_SKIP, &mm->flags);
> > +		}
> > +		/*
> > +		 * The mm_struct is going to exit, but the locks will be dropped
> > +		 * first.  Set the mm_struct as unstable is advisable as it is
> > +		 * not fully initialised.
> > +		 */
> > +		set_bit(MMF_UNSTABLE, &mm->flags);
> 
> Do we still need to do this if !mpnt?

No, we probably don't need this now.  But it still makes sense to do
this considering what we are saying.  There is a failed mm, let's mark
it as unstable because it's going away in a moment - it's not stable,
it's not even a complete mm.

> 
> Also 'mpnt' is in the running for the worst variable name in mm...
> 

mpnt is the oldMm vma Pointer, Now isn'T it?  I think that's self
documenting.

Thanks,
Liam


From lorenzo.stoakes at oracle.com  Fri Jan 24 11:09:14 2025
From: lorenzo.stoakes at oracle.com (Lorenzo Stoakes)
Date: Fri, 24 Jan 2025 19:09:14 +0000
Subject: [PATCH] kernel/fork: Be more careful about dup_mmap() failures
In-Reply-To: <zsmj4kvuaqhq7bo7e3nenetshuyfinshhej5qjftwj2eq7jtkm@zekug2ivnzby>
References: <7a16bf18-e193-4e0a-9e3b-83f609cb9e72@lucifer.local>
 <zsmj4kvuaqhq7bo7e3nenetshuyfinshhej5qjftwj2eq7jtkm@zekug2ivnzby>
Message-ID: <2a9fee95-425d-4b27-8253-10540669d94c@lucifer.local>

On Fri, Jan 24, 2025 at 01:19:45PM -0500, Liam R. Howlett wrote:
> Adding Oleg, who I forgot on the start of this patch..
>
>
> * Lorenzo Stoakes <lorenzo.stoakes at oracle.com> [250124 06:15]:
> > On Thu, Jan 23, 2025 at 03:58:49PM -0500, Liam R. Howlett wrote:
> > > From: "Liam R. Howlett" <Liam.Howlett at Oracle.com>
> > >
> > > In the even that there is a failure during dup_mmap(), the maple tree
> > > can be left in an unsafe state for other iterators besides the exit
> > > path.
> > >
> > > The unsafe state is created after the tree is cloned, but before the
> > > vmas are replaced; if a vma allocation fails (for instance), then the
> > > tree will have a marker (XA_ZERO_ENTRY) to denote where to stop
> > > destroying vmas on the exit path.  This marker replaces a vma in the
> > > tree and may be treated as a pointer to a vma in iterators besides the
> > > special case exit_mmap() iterator.
> >
> > Thanks for addresing this.
>
> Thanks for looking at the patch.
>
> >
> > In the original issue, the problem arose in vm_area_dup() which I tracked
> > down to vma_iter_load() -> mas_walk() (see [0]).
> >
> > I'm not sure if your change would actually have addressed this? Would the
> > MMF_UNSTABLE flag prevent this code path from being taken (if so where?),
> > if not don't we need to add a check for this somewhere?
> >
> > [0]:https://lore.kernel.org/all/aa2c1930-becc-4bc5-adfb-96e88290acc7 at lucifer.local/
>
> Remote vma accesses use check_stable_address_space() to avoid races
> with the oom killer, which checks MMF_UNSTABLE.
>
> Yeah, uprobe needs to do this and doesn't today.
>
> Oleg suggested this be done in build_map_info(), but the MMF_UNSTABLE
> bit is set under the mmap read lock and that function uses the read lock
> on the rmap, takes an mm references and records the address -  then
> revisits the mm later to get the vma in register_for_each_vma().
>
> I think we need to check in register_for_each_vma(), prior to looking up
> the vma.  This way we hold the write lock on the mm and will ensure the
> vma is stable from both the fork setup and a potential OOM events.  The
> concern is that we have an invalid vma or the prev/next is invalid and
> that will only be a concern when operating on the vma itself, so this
> would be the safest place imo.
>
> The problem that has been created is that the next vma may be invalid.
> This arises when the rmap is used to find a vma then changes that vma.
> In this scenario, the mmap lock of the vma needs to be held and that mm
> needs to be checked as stable/not oom'ed.  So we can limit the checking
> of the code to the scenario where another mm's vma is found and
> modified - which may cause a merge and look at the next vma.
>
> I haven't found anywhere else that looks up another mm_struct's vma and
> makes a change to the vma.  Considering what that would mean, it makes
> sense that this is rare.
>
> So, I'll just do this:
>
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -1260,6 +1260,9 @@ register_for_each_vma(struct uprobe *uprobe, struct uprobe_consumer *new)
>                  * returns NULL in find_active_uprobe_rcu().
>                  */
>                 mmap_write_lock(mm);
> +               if (check_stable_address_space(mm)
> +                               goto unlock;
> +
>
>

Yeah I think on reflection this is sensible, at least as a proximate
solution. It certainly doesn't harm to apply the MMF_UNSTABLE flag on top
of this and we can always expand where we check/what we do with this.

>
>
> >
> > >
> > > All the locks are dropped before the exit_mmap() call, but the
> > > incomplete mm_struct can be reached through (at least) the rmap finding
> > > the vmas which have a pointer back to the mm_struct.
> > >
> > > Up to this point, there have been no issues with being able to find an
> > > mm_sturct that was only partially initialised.  Syzbot was able to make
> > > the incomplete mm_struct fail with recent forking changes, so it has
> > > been proven unsafe to use the mm_sturct that hasn't been initialised, as
> > > referenced in the link below.
> > >
> > > Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to
> > > invalid mm") fixed the uprobe access, it does not completely remove the
> > > race.
> > >
> > > This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on
> > > the oom side (even though this is extremely unlikely to be selected as
> > > an oom victim in the race window), and sets MMF_UNSTABLE to avoid other
> > > potential users from using a partially initialised mm_struct.
> >
> > Good to have it set also I think.
> >
> > We were concerned that _somehow_ MMF_UNSTABLE might cause some issue in
> > OOM, which was why when I first thought of this we decided maybe not just
> > to be safe, but I am confident this will not be an issue as indicating that
> > something is about to be torn down and is unstable when it is in fact
> > unstable and about to be torn down is correct, plus I checked all the paths
> > where this impacted and found no issues.
> >
> > And in any case, setting this flag avoids the problem...!
> >
> > >
> > > Link: https://lore.kernel.org/all/6756d273.050a0220.2477f.003d.GAE at google.com/
> > > Fixes: d240629148377 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()")
> > > Cc: Jann Horn <jannh at google.com>
> > > Cc: Lorenzo Stoakes <lorenzo.stoakes at oracle.com>
> > > Cc: Peter Zijlstra <peterz at infradead.org>
> > > Cc: Michal Hocko <mhocko at suse.com>
> > > Cc: Peng Zhang <zhangpeng.00 at bytedance.com>
> > > Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> > > ---
> > >  kernel/fork.c | 17 ++++++++++++++---
> > >  1 file changed, 14 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/kernel/fork.c b/kernel/fork.c
> > > index ded49f18cd95c..20b2120f019ca 100644
> > > --- a/kernel/fork.c
> > > +++ b/kernel/fork.c
> > > @@ -760,7 +760,8 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
> > >  		mt_set_in_rcu(vmi.mas.tree);
> > >  		ksm_fork(mm, oldmm);
> > >  		khugepaged_fork(mm, oldmm);
> > > -	} else if (mpnt) {
> > > +	} else {
> > > +
> > >  		/*
> > >  		 * The entire maple tree has already been duplicated. If the
> > >  		 * mmap duplication fails, mark the failure point with
> > > @@ -768,8 +769,18 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
> > >  		 * stop releasing VMAs that have not been duplicated after this
> > >  		 * point.
> > >  		 */
> > > -		mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
> > > -		mas_store(&vmi.mas, XA_ZERO_ENTRY);
> > > +		if (mpnt) {
> > > +			mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
> > > +			mas_store(&vmi.mas, XA_ZERO_ENTRY);
> > > +			/* Avoid OOM iterating a broken tree */
> > > +			set_bit(MMF_OOM_SKIP, &mm->flags);
> > > +		}
> > > +		/*
> > > +		 * The mm_struct is going to exit, but the locks will be dropped
> > > +		 * first.  Set the mm_struct as unstable is advisable as it is
> > > +		 * not fully initialised.
> > > +		 */
> > > +		set_bit(MMF_UNSTABLE, &mm->flags);
> >
> > Do we still need to do this if !mpnt?
>
> No, we probably don't need this now.  But it still makes sense to do
> this considering what we are saying.  There is a failed mm, let's mark
> it as unstable because it's going away in a moment - it's not stable,
> it's not even a complete mm.
>
> >
> > Also 'mpnt' is in the running for the worst variable name in mm...
> >
>
> mpnt is the oldMm vma Pointer, Now isn'T it?  I think that's self
> documenting.

:)))

>
> Thanks,
> Liam


From Liam.Howlett at oracle.com  Mon Jan 27 06:36:11 2025
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Mon, 27 Jan 2025 09:36:11 -0500
Subject: [PATCH 0/7] spanning write related cleanup
In-Reply-To: <20250124013412.2vpf7davx63s377d@master>
References: <20241127012753.3393-1-richard.weiyang@gmail.com>
 <cqulekn3csbs5q6vo3uormpplgbn7vvqir4a4pnaavgvhcsd3b@js4s5ncaritj>
 <20250117054942.w6vgrllnaasjaww3@master>
 <acq3uafsy54fo6nwcrrrqjkpojw7dnfy5ubwrissrn2726p64d@4izyq742k5ym>
 <20250124013412.2vpf7davx63s377d@master>
Message-ID: <axz4cvmddhompm72cj6wga6hrqdkl56zcixol55gzisxf433wh@ycau3ttsbzg7>

* Wei Yang <richard.weiyang at gmail.com> [250123 20:44]:
> On Thu, Jan 23, 2025 at 12:52:40PM -0500, Liam R. Howlett wrote:
> >* Wei Yang <richard.weiyang at gmail.com> [250117 00:49]:
> >> On Wed, Nov 27, 2024 at 08:31:13AM -0500, Liam R. Howlett wrote:
> >> >* Wei Yang <richard.weiyang at gmail.com> [241126 20:28]:
> >> >> Here is some cleanup related to spanning write.
> >> >
> >> >None of these fix anything, but do fiddle with code that's pretty
> >> >critical to the kernel.  Most of the changes will be immeasurable in
> >> >change but carry risk to causing subtle changes.
> >> >
> >> >Some are simple removal of returns that aren't used while others change
> >> >things because you think they are probably the equivalent.  This seems
> >> >like unnecessary chrun at this point.  I'm all for efficient code but
> >> >this is getting a bit much, some of these are just preference of what to
> >> >use that will already exist in the cpu cache.
> >> >
> >> >I'll get back to you when I dig through them, as some need a deeper look
> >> >for sure.
> >> >
> >> >Liam
> >> >
> >> 
> >> Hi, Liam
> >> 
> >> Would you mind taking a look when you have time?
> >
> >Yes, I'll have a look soon.  I don't love changes that dive deep into
> >complex code that results in no gains (performance or feature wise).
> >
> >It's also odd to have simple "this return isn't use" and things moving
> >code blocks to be executed only in certain scenarios, as the difficulty
> >to verify the latter is much higher.
> >
> >Can we please limit changes to areas where there is a performance change
> >or coupled with a change that is needed?  ie: stop sending patches that
> >change things unless it's with a feature or improvement (performance or
> >otherwise).  I'm just not convinced some of these are worth the
> >cost vs risk.
> >
> 
> Ok.
> 
> So you would drop this patch set or still want to take a look?

I was going to look at it, but after I send my reply, I received a
report of an issue caused in a certain configuration that caused the
stack frame to grow out of the configured 1024 limit, which was tracked
to a patch you added to simplify a previous function.

So, I think we should drop these patches since they don't make a
measurable difference and are not without risk.

Thanks,
Liam


From Liam.Howlett at oracle.com  Mon Jan 27 09:02:21 2025
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Mon, 27 Jan 2025 12:02:21 -0500
Subject: [PATCH v2] kernel: Be more careful about dup_mmap() failures and uprobe registering
Message-ID: <20250127170221.1761366-1-Liam.Howlett@oracle.com>

From: "Liam R. Howlett" <Liam.Howlett at Oracle.com>

In the even that there is a failure during dup_mmap(), the maple tree
can be left in an unsafe state for other iterators besides the exit
path.  All the locks are dropped before the exit_mmap() call (in
mm/mmap.c), but the incomplete mm_struct can be reached through (at
least) the rmap finding the vmas which have a pointer back to the
mm_struct.

Up to this point, there have been no issues with being able to find an
mm_struct that was only partially initialised.  Syzbot was able to make
the incomplete mm_struct fail with recent forking changes, so it has
been proven unsafe to use the mm_struct that hasn't been initialised, as
referenced in the link below.

Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to
invalid mm") fixed the uprobe access, it does not completely remove the
race.

This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on
the oom side (even though this is extremely unlikely to be selected as
an oom victim in the race window), and sets MMF_UNSTABLE to avoid other
potential users from using a partially initialised mm_struct.

When registering vmas for uprobe, skip the vmas in an mm that is marked
unstable.  Modifying a vma in an unstable mm may cause issues if the mm
isn't fully initialised.

Link: https://lore.kernel.org/all/6756d273.050a0220.2477f.003d.GAE at google.com/
Fixes: d240629148377 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()")
Cc: Oleg Nesterov <oleg at redhat.com>
Cc: Masami Hiramatsu <mhiramat at kernel.org>
Cc: Jann Horn <jannh at google.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes at oracle.com>
Cc: Peter Zijlstra <peterz at infradead.org>
Cc: Michal Hocko <mhocko at suse.com>
Cc: Peng Zhang <zhangpeng.00 at bytedance.com>
Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
---

v1: https://lore.kernel.org/all/20250123205849.793810-1-Liam.Howlett at oracle.com/

Changes since:
v1
 - Added check_stable_address_space() to uprobe code - Thanks Lorenzo
 - Added Oleg & Masami to Cc list.

 kernel/events/uprobes.c |  4 ++++
 kernel/fork.c           | 17 ++++++++++++++---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index fa04b14a7d723..90ebcdbad05ca 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -28,6 +28,7 @@
 #include <linux/rcupdate_trace.h>
 #include <linux/workqueue.h>
 #include <linux/srcu.h>
+#include <linux/oom.h>          /* check_stable_address_space */
 
 #include <linux/uprobes.h>
 
@@ -1260,6 +1261,9 @@ register_for_each_vma(struct uprobe *uprobe, struct uprobe_consumer *new)
 		 * returns NULL in find_active_uprobe_rcu().
 		 */
 		mmap_write_lock(mm);
+		if (check_stable_address_space(mm))
+			goto unlock;
+
 		vma = find_vma(mm, info->vaddr);
 		if (!vma || !valid_vma(vma, is_register) ||
 		    file_inode(vma->vm_file) != uprobe->inode)
diff --git a/kernel/fork.c b/kernel/fork.c
index ded49f18cd95c..20b2120f019ca 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -760,7 +760,8 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
 		mt_set_in_rcu(vmi.mas.tree);
 		ksm_fork(mm, oldmm);
 		khugepaged_fork(mm, oldmm);
-	} else if (mpnt) {
+	} else {
+
 		/*
 		 * The entire maple tree has already been duplicated. If the
 		 * mmap duplication fails, mark the failure point with
@@ -768,8 +769,18 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
 		 * stop releasing VMAs that have not been duplicated after this
 		 * point.
 		 */
-		mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
-		mas_store(&vmi.mas, XA_ZERO_ENTRY);
+		if (mpnt) {
+			mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
+			mas_store(&vmi.mas, XA_ZERO_ENTRY);
+			/* Avoid OOM iterating a broken tree */
+			set_bit(MMF_OOM_SKIP, &mm->flags);
+		}
+		/*
+		 * The mm_struct is going to exit, but the locks will be dropped
+		 * first.  Set the mm_struct as unstable is advisable as it is
+		 * not fully initialised.
+		 */
+		set_bit(MMF_UNSTABLE, &mm->flags);
 	}
 out:
 	mmap_write_unlock(mm);
-- 
2.43.0



From willy at infradead.org  Mon Jan 27 09:08:19 2025
From: willy at infradead.org (Matthew Wilcox)
Date: Mon, 27 Jan 2025 17:08:19 +0000
Subject: [PATCH v2] kernel: Be more careful about dup_mmap() failures and
 uprobe registering
In-Reply-To: <20250127170221.1761366-1-Liam.Howlett@oracle.com>
References: <20250127170221.1761366-1-Liam.Howlett@oracle.com>
Message-ID: <Z5e9g3QUHVE-imrU@casper.infradead.org>

On Mon, Jan 27, 2025 at 12:02:21PM -0500, Liam R. Howlett wrote:
> From: "Liam R. Howlett" <Liam.Howlett at Oracle.com>
> 
> In the even that there is a failure during dup_mmap(), the maple tree

"event".  Although the writing is a little clumsy here.  You could just
say "If there is a failure".  But that begs the question of what kind of
failure, and I think it's only a memory allocation failure?  So you
could say

"If a memory allocation fails during dup_mmap(),"

> can be left in an unsafe state for other iterators besides the exit
> path.  All the locks are dropped before the exit_mmap() call (in
> mm/mmap.c), but the incomplete mm_struct can be reached through (at
> least) the rmap finding the vmas which have a pointer back to the
> mm_struct.
> 
> Up to this point, there have been no issues with being able to find an
> mm_struct that was only partially initialised.  Syzbot was able to make
> the incomplete mm_struct fail with recent forking changes, so it has
> been proven unsafe to use the mm_struct that hasn't been initialised, as
> referenced in the link below.
> 
> Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to
> invalid mm") fixed the uprobe access, it does not completely remove the
> race.
> 
> This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on
> the oom side (even though this is extremely unlikely to be selected as
> an oom victim in the race window), and sets MMF_UNSTABLE to avoid other
> potential users from using a partially initialised mm_struct.
> 
> When registering vmas for uprobe, skip the vmas in an mm that is marked
> unstable.  Modifying a vma in an unstable mm may cause issues if the mm
> isn't fully initialised.
> 
> Link: https://lore.kernel.org/all/6756d273.050a0220.2477f.003d.GAE at google.com/
> Fixes: d240629148377 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()")
> Cc: Oleg Nesterov <oleg at redhat.com>
> Cc: Masami Hiramatsu <mhiramat at kernel.org>
> Cc: Jann Horn <jannh at google.com>
> Cc: Lorenzo Stoakes <lorenzo.stoakes at oracle.com>
> Cc: Peter Zijlstra <peterz at infradead.org>
> Cc: Michal Hocko <mhocko at suse.com>
> Cc: Peng Zhang <zhangpeng.00 at bytedance.com>
> Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> ---
> 
> v1: https://lore.kernel.org/all/20250123205849.793810-1-Liam.Howlett at oracle.com/
> 
> Changes since:
> v1
>  - Added check_stable_address_space() to uprobe code - Thanks Lorenzo
>  - Added Oleg & Masami to Cc list.
> 
>  kernel/events/uprobes.c |  4 ++++
>  kernel/fork.c           | 17 ++++++++++++++---
>  2 files changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index fa04b14a7d723..90ebcdbad05ca 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -28,6 +28,7 @@
>  #include <linux/rcupdate_trace.h>
>  #include <linux/workqueue.h>
>  #include <linux/srcu.h>
> +#include <linux/oom.h>          /* check_stable_address_space */
>  
>  #include <linux/uprobes.h>
>  
> @@ -1260,6 +1261,9 @@ register_for_each_vma(struct uprobe *uprobe, struct uprobe_consumer *new)
>  		 * returns NULL in find_active_uprobe_rcu().
>  		 */
>  		mmap_write_lock(mm);
> +		if (check_stable_address_space(mm))
> +			goto unlock;
> +
>  		vma = find_vma(mm, info->vaddr);
>  		if (!vma || !valid_vma(vma, is_register) ||
>  		    file_inode(vma->vm_file) != uprobe->inode)
> diff --git a/kernel/fork.c b/kernel/fork.c
> index ded49f18cd95c..20b2120f019ca 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -760,7 +760,8 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
>  		mt_set_in_rcu(vmi.mas.tree);
>  		ksm_fork(mm, oldmm);
>  		khugepaged_fork(mm, oldmm);
> -	} else if (mpnt) {
> +	} else {
> +
>  		/*
>  		 * The entire maple tree has already been duplicated. If the
>  		 * mmap duplication fails, mark the failure point with
> @@ -768,8 +769,18 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
>  		 * stop releasing VMAs that have not been duplicated after this
>  		 * point.
>  		 */
> -		mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
> -		mas_store(&vmi.mas, XA_ZERO_ENTRY);
> +		if (mpnt) {
> +			mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
> +			mas_store(&vmi.mas, XA_ZERO_ENTRY);
> +			/* Avoid OOM iterating a broken tree */
> +			set_bit(MMF_OOM_SKIP, &mm->flags);
> +		}
> +		/*
> +		 * The mm_struct is going to exit, but the locks will be dropped
> +		 * first.  Set the mm_struct as unstable is advisable as it is
> +		 * not fully initialised.
> +		 */
> +		set_bit(MMF_UNSTABLE, &mm->flags);
>  	}
>  out:
>  	mmap_write_unlock(mm);
> -- 
> 2.43.0
> 
> 
> -- 
> maple-tree mailing list
> maple-tree at lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/maple-tree


From lorenzo.stoakes at oracle.com  Mon Jan 27 09:37:52 2025
From: lorenzo.stoakes at oracle.com (Lorenzo Stoakes)
Date: Mon, 27 Jan 2025 17:37:52 +0000
Subject: [PATCH v2] kernel: Be more careful about dup_mmap() failures and
 uprobe registering
In-Reply-To: <20250127170221.1761366-1-Liam.Howlett@oracle.com>
References: <20250127170221.1761366-1-Liam.Howlett@oracle.com>
Message-ID: <c8314c29-e28e-4602-bd25-a6f13ee2fdc0@lucifer.local>

On Mon, Jan 27, 2025 at 12:02:21PM -0500, Liam R. Howlett wrote:
> From: "Liam R. Howlett" <Liam.Howlett at Oracle.com>
>
> In the even that there is a failure during dup_mmap(), the maple tree
> can be left in an unsafe state for other iterators besides the exit
> path.  All the locks are dropped before the exit_mmap() call (in
> mm/mmap.c), but the incomplete mm_struct can be reached through (at
> least) the rmap finding the vmas which have a pointer back to the
> mm_struct.
>
> Up to this point, there have been no issues with being able to find an
> mm_struct that was only partially initialised.  Syzbot was able to make
> the incomplete mm_struct fail with recent forking changes, so it has
> been proven unsafe to use the mm_struct that hasn't been initialised, as
> referenced in the link below.
>
> Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to
> invalid mm") fixed the uprobe access, it does not completely remove the
> race.
>
> This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on
> the oom side (even though this is extremely unlikely to be selected as
> an oom victim in the race window), and sets MMF_UNSTABLE to avoid other
> potential users from using a partially initialised mm_struct.
>
> When registering vmas for uprobe, skip the vmas in an mm that is marked
> unstable.  Modifying a vma in an unstable mm may cause issues if the mm
> isn't fully initialised.
>
> Link: https://lore.kernel.org/all/6756d273.050a0220.2477f.003d.GAE at google.com/
> Fixes: d240629148377 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()")
> Cc: Oleg Nesterov <oleg at redhat.com>
> Cc: Masami Hiramatsu <mhiramat at kernel.org>
> Cc: Jann Horn <jannh at google.com>
> Cc: Lorenzo Stoakes <lorenzo.stoakes at oracle.com>
> Cc: Peter Zijlstra <peterz at infradead.org>
> Cc: Michal Hocko <mhocko at suse.com>
> Cc: Peng Zhang <zhangpeng.00 at bytedance.com>
> Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>

Looks good to me!

Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes at oracle.com>

> ---
>
> v1: https://lore.kernel.org/all/20250123205849.793810-1-Liam.Howlett at oracle.com/
>
> Changes since:
> v1
>  - Added check_stable_address_space() to uprobe code - Thanks Lorenzo
>  - Added Oleg & Masami to Cc list.
>
>  kernel/events/uprobes.c |  4 ++++
>  kernel/fork.c           | 17 ++++++++++++++---
>  2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index fa04b14a7d723..90ebcdbad05ca 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -28,6 +28,7 @@
>  #include <linux/rcupdate_trace.h>
>  #include <linux/workqueue.h>
>  #include <linux/srcu.h>
> +#include <linux/oom.h>          /* check_stable_address_space */
>
>  #include <linux/uprobes.h>
>
> @@ -1260,6 +1261,9 @@ register_for_each_vma(struct uprobe *uprobe, struct uprobe_consumer *new)
>  		 * returns NULL in find_active_uprobe_rcu().
>  		 */
>  		mmap_write_lock(mm);
> +		if (check_stable_address_space(mm))
> +			goto unlock;
> +

Great thanks!

>  		vma = find_vma(mm, info->vaddr);
>  		if (!vma || !valid_vma(vma, is_register) ||
>  		    file_inode(vma->vm_file) != uprobe->inode)
> diff --git a/kernel/fork.c b/kernel/fork.c
> index ded49f18cd95c..20b2120f019ca 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -760,7 +760,8 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
>  		mt_set_in_rcu(vmi.mas.tree);
>  		ksm_fork(mm, oldmm);
>  		khugepaged_fork(mm, oldmm);
> -	} else if (mpnt) {
> +	} else {
> +
>  		/*
>  		 * The entire maple tree has already been duplicated. If the
>  		 * mmap duplication fails, mark the failure point with
> @@ -768,8 +769,18 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
>  		 * stop releasing VMAs that have not been duplicated after this
>  		 * point.
>  		 */
> -		mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
> -		mas_store(&vmi.mas, XA_ZERO_ENTRY);
> +		if (mpnt) {
> +			mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
> +			mas_store(&vmi.mas, XA_ZERO_ENTRY);
> +			/* Avoid OOM iterating a broken tree */
> +			set_bit(MMF_OOM_SKIP, &mm->flags);
> +		}
> +		/*
> +		 * The mm_struct is going to exit, but the locks will be dropped
> +		 * first.  Set the mm_struct as unstable is advisable as it is
> +		 * not fully initialised.
> +		 */
> +		set_bit(MMF_UNSTABLE, &mm->flags);
>  	}
>  out:
>  	mmap_write_unlock(mm);
> --
> 2.43.0
>


From Liam.Howlett at oracle.com  Mon Jan 27 09:54:18 2025
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Mon, 27 Jan 2025 12:54:18 -0500
Subject: [PATCH v2] kernel: Be more careful about dup_mmap() failures and
 uprobe registering
In-Reply-To: <Z5e9g3QUHVE-imrU@casper.infradead.org>
References: <20250127170221.1761366-1-Liam.Howlett@oracle.com>
 <Z5e9g3QUHVE-imrU@casper.infradead.org>
Message-ID: <3zg7e6dyu2mbugguwtzlobwavhtgjw2zk7jo7eqzbqhpqxjxnz@nxokogoh7dtm>

* Matthew Wilcox <willy at infradead.org> [250127 12:08]:
> On Mon, Jan 27, 2025 at 12:02:21PM -0500, Liam R. Howlett wrote:
> > From: "Liam R. Howlett" <Liam.Howlett at Oracle.com>
> > 
> > In the even that there is a failure during dup_mmap(), the maple tree
> 
> "event".  Although the writing is a little clumsy here.  You could just
> say "If there is a failure".

Thanks.


> But that begs the question of what kind of
> failure, and I think it's only a memory allocation failure?  So you
> could say
> 
> "If a memory allocation fails during dup_mmap(),"

The problem that syzbot found is an allocation failure, but I didn't
want to say that's the only possible failure that could cause the
duplication to fail.  Looking at the code, we could also hit this issue
with a fatal signal.

If the return isn't zero, the mm will be marked as unstable.

If we fail in the loop across the vmas, then we also set the OOM skip
bit as the oom iterator may not be safe.


> 
> > can be left in an unsafe state for other iterators besides the exit
> > path.  All the locks are dropped before the exit_mmap() call (in
> > mm/mmap.c), but the incomplete mm_struct can be reached through (at
> > least) the rmap finding the vmas which have a pointer back to the
> > mm_struct.
> > 
> > Up to this point, there have been no issues with being able to find an
> > mm_struct that was only partially initialised.  Syzbot was able to make
> > the incomplete mm_struct fail with recent forking changes, so it has
> > been proven unsafe to use the mm_struct that hasn't been initialised, as
> > referenced in the link below.
> > 
> > Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to
> > invalid mm") fixed the uprobe access, it does not completely remove the
> > race.
> > 
> > This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on
> > the oom side (even though this is extremely unlikely to be selected as
> > an oom victim in the race window), and sets MMF_UNSTABLE to avoid other
> > potential users from using a partially initialised mm_struct.
> > 
> > When registering vmas for uprobe, skip the vmas in an mm that is marked
> > unstable.  Modifying a vma in an unstable mm may cause issues if the mm
> > isn't fully initialised.
> > 
> > Link: https://lore.kernel.org/all/6756d273.050a0220.2477f.003d.GAE at google.com/
> > Fixes: d240629148377 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()")
> > Cc: Oleg Nesterov <oleg at redhat.com>
> > Cc: Masami Hiramatsu <mhiramat at kernel.org>
> > Cc: Jann Horn <jannh at google.com>
> > Cc: Lorenzo Stoakes <lorenzo.stoakes at oracle.com>
> > Cc: Peter Zijlstra <peterz at infradead.org>
> > Cc: Michal Hocko <mhocko at suse.com>
> > Cc: Peng Zhang <zhangpeng.00 at bytedance.com>
> > Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> > ---
> > 
> > v1: https://lore.kernel.org/all/20250123205849.793810-1-Liam.Howlett at oracle.com/
> > 
> > Changes since:
> > v1
> >  - Added check_stable_address_space() to uprobe code - Thanks Lorenzo
> >  - Added Oleg & Masami to Cc list.
> > 
> >  kernel/events/uprobes.c |  4 ++++
> >  kernel/fork.c           | 17 ++++++++++++++---
> >  2 files changed, 18 insertions(+), 3 deletions(-)
> > 
> > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> > index fa04b14a7d723..90ebcdbad05ca 100644
> > --- a/kernel/events/uprobes.c
> > +++ b/kernel/events/uprobes.c
> > @@ -28,6 +28,7 @@
> >  #include <linux/rcupdate_trace.h>
> >  #include <linux/workqueue.h>
> >  #include <linux/srcu.h>
> > +#include <linux/oom.h>          /* check_stable_address_space */
> >  
> >  #include <linux/uprobes.h>
> >  
> > @@ -1260,6 +1261,9 @@ register_for_each_vma(struct uprobe *uprobe, struct uprobe_consumer *new)
> >  		 * returns NULL in find_active_uprobe_rcu().
> >  		 */
> >  		mmap_write_lock(mm);
> > +		if (check_stable_address_space(mm))
> > +			goto unlock;
> > +
> >  		vma = find_vma(mm, info->vaddr);
> >  		if (!vma || !valid_vma(vma, is_register) ||
> >  		    file_inode(vma->vm_file) != uprobe->inode)
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index ded49f18cd95c..20b2120f019ca 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -760,7 +760,8 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
> >  		mt_set_in_rcu(vmi.mas.tree);
> >  		ksm_fork(mm, oldmm);
> >  		khugepaged_fork(mm, oldmm);
> > -	} else if (mpnt) {
> > +	} else {
> > +
> >  		/*
> >  		 * The entire maple tree has already been duplicated. If the
> >  		 * mmap duplication fails, mark the failure point with
> > @@ -768,8 +769,18 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
> >  		 * stop releasing VMAs that have not been duplicated after this
> >  		 * point.
> >  		 */
> > -		mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
> > -		mas_store(&vmi.mas, XA_ZERO_ENTRY);
> > +		if (mpnt) {
> > +			mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
> > +			mas_store(&vmi.mas, XA_ZERO_ENTRY);
> > +			/* Avoid OOM iterating a broken tree */
> > +			set_bit(MMF_OOM_SKIP, &mm->flags);
> > +		}
> > +		/*
> > +		 * The mm_struct is going to exit, but the locks will be dropped
> > +		 * first.  Set the mm_struct as unstable is advisable as it is
> > +		 * not fully initialised.
> > +		 */
> > +		set_bit(MMF_UNSTABLE, &mm->flags);
> >  	}
> >  out:
> >  	mmap_write_unlock(mm);
> > -- 
> > 2.43.0
> > 
> > 
> > -- 
> > maple-tree mailing list
> > maple-tree at lists.infradead.org
> > https://lists.infradead.org/mailman/listinfo/maple-tree
> 
> -- 
> maple-tree mailing list
> maple-tree at lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/maple-tree


From richard.weiyang at gmail.com  Mon Jan 27 17:36:11 2025
From: richard.weiyang at gmail.com (Wei Yang)
Date: Tue, 28 Jan 2025 01:36:11 +0000
Subject: [PATCH 0/7] spanning write related cleanup
In-Reply-To: <axz4cvmddhompm72cj6wga6hrqdkl56zcixol55gzisxf433wh@ycau3ttsbzg7>
References: <20241127012753.3393-1-richard.weiyang@gmail.com>
 <cqulekn3csbs5q6vo3uormpplgbn7vvqir4a4pnaavgvhcsd3b@js4s5ncaritj>
 <20250117054942.w6vgrllnaasjaww3@master>
 <acq3uafsy54fo6nwcrrrqjkpojw7dnfy5ubwrissrn2726p64d@4izyq742k5ym>
 <20250124013412.2vpf7davx63s377d@master>
 <axz4cvmddhompm72cj6wga6hrqdkl56zcixol55gzisxf433wh@ycau3ttsbzg7>
Message-ID: <20250128013611.2c27dcaa5dq2kcth@master>

On Mon, Jan 27, 2025 at 09:36:11AM -0500, Liam R. Howlett wrote:
>* Wei Yang <richard.weiyang at gmail.com> [250123 20:44]:
>> On Thu, Jan 23, 2025 at 12:52:40PM -0500, Liam R. Howlett wrote:
>> >* Wei Yang <richard.weiyang at gmail.com> [250117 00:49]:
>> >> On Wed, Nov 27, 2024 at 08:31:13AM -0500, Liam R. Howlett wrote:
>> >> >* Wei Yang <richard.weiyang at gmail.com> [241126 20:28]:
>> >> >> Here is some cleanup related to spanning write.
>> >> >
>> >> >None of these fix anything, but do fiddle with code that's pretty
>> >> >critical to the kernel.  Most of the changes will be immeasurable in
>> >> >change but carry risk to causing subtle changes.
>> >> >
>> >> >Some are simple removal of returns that aren't used while others change
>> >> >things because you think they are probably the equivalent.  This seems
>> >> >like unnecessary chrun at this point.  I'm all for efficient code but
>> >> >this is getting a bit much, some of these are just preference of what to
>> >> >use that will already exist in the cpu cache.
>> >> >
>> >> >I'll get back to you when I dig through them, as some need a deeper look
>> >> >for sure.
>> >> >
>> >> >Liam
>> >> >
>> >> 
>> >> Hi, Liam
>> >> 
>> >> Would you mind taking a look when you have time?
>> >
>> >Yes, I'll have a look soon.  I don't love changes that dive deep into
>> >complex code that results in no gains (performance or feature wise).
>> >
>> >It's also odd to have simple "this return isn't use" and things moving
>> >code blocks to be executed only in certain scenarios, as the difficulty
>> >to verify the latter is much higher.
>> >
>> >Can we please limit changes to areas where there is a performance change
>> >or coupled with a change that is needed?  ie: stop sending patches that
>> >change things unless it's with a feature or improvement (performance or
>> >otherwise).  I'm just not convinced some of these are worth the
>> >cost vs risk.
>> >
>> 
>> Ok.
>> 
>> So you would drop this patch set or still want to take a look?
>
>I was going to look at it, but after I send my reply, I received a
>report of an issue caused in a certain configuration that caused the
>stack frame to grow out of the configured 1024 limit, which was tracked
>to a patch you added to simplify a previous function.

Sorry for that. Would you mind letting me know what is the problem? or cc me
in case you will fix it?

>
>So, I think we should drop these patches since they don't make a
>measurable difference and are not without risk.
>
>Thanks,
>Liam

-- 
Wei Yang
Help you, Help me


From richard.weiyang at gmail.com  Mon Jan 27 18:11:35 2025
From: richard.weiyang at gmail.com (Wei Yang)
Date: Tue, 28 Jan 2025 02:11:35 +0000
Subject: [PATCH 0/7] spanning write related cleanup
In-Reply-To: <axz4cvmddhompm72cj6wga6hrqdkl56zcixol55gzisxf433wh@ycau3ttsbzg7>
References: <20241127012753.3393-1-richard.weiyang@gmail.com>
 <cqulekn3csbs5q6vo3uormpplgbn7vvqir4a4pnaavgvhcsd3b@js4s5ncaritj>
 <20250117054942.w6vgrllnaasjaww3@master>
 <acq3uafsy54fo6nwcrrrqjkpojw7dnfy5ubwrissrn2726p64d@4izyq742k5ym>
 <20250124013412.2vpf7davx63s377d@master>
 <axz4cvmddhompm72cj6wga6hrqdkl56zcixol55gzisxf433wh@ycau3ttsbzg7>
Message-ID: <20250128021135.fxfb2muboeug7jjb@master>

On Mon, Jan 27, 2025 at 09:36:11AM -0500, Liam R. Howlett wrote:
>* Wei Yang <richard.weiyang at gmail.com> [250123 20:44]:
>> On Thu, Jan 23, 2025 at 12:52:40PM -0500, Liam R. Howlett wrote:
>> >* Wei Yang <richard.weiyang at gmail.com> [250117 00:49]:
>> >> On Wed, Nov 27, 2024 at 08:31:13AM -0500, Liam R. Howlett wrote:
>> >> >* Wei Yang <richard.weiyang at gmail.com> [241126 20:28]:
>> >> >> Here is some cleanup related to spanning write.
>> >> >
>> >> >None of these fix anything, but do fiddle with code that's pretty
>> >> >critical to the kernel.  Most of the changes will be immeasurable in
>> >> >change but carry risk to causing subtle changes.
>> >> >
>> >> >Some are simple removal of returns that aren't used while others change
>> >> >things because you think they are probably the equivalent.  This seems
>> >> >like unnecessary chrun at this point.  I'm all for efficient code but
>> >> >this is getting a bit much, some of these are just preference of what to
>> >> >use that will already exist in the cpu cache.
>> >> >
>> >> >I'll get back to you when I dig through them, as some need a deeper look
>> >> >for sure.
>> >> >
>> >> >Liam
>> >> >
>> >> 
>> >> Hi, Liam
>> >> 
>> >> Would you mind taking a look when you have time?
>> >
>> >Yes, I'll have a look soon.  I don't love changes that dive deep into
>> >complex code that results in no gains (performance or feature wise).
>> >
>> >It's also odd to have simple "this return isn't use" and things moving
>> >code blocks to be executed only in certain scenarios, as the difficulty
>> >to verify the latter is much higher.
>> >
>> >Can we please limit changes to areas where there is a performance change
>> >or coupled with a change that is needed?  ie: stop sending patches that
>> >change things unless it's with a feature or improvement (performance or
>> >otherwise).  I'm just not convinced some of these are worth the
>> >cost vs risk.
>> >
>> 
>> Ok.
>> 
>> So you would drop this patch set or still want to take a look?
>
>I was going to look at it, but after I send my reply, I received a
>report of an issue caused in a certain configuration that caused the
>stack frame to grow out of the configured 1024 limit, which was tracked
>to a patch you added to simplify a previous function.
>
>So, I think we should drop these patches since they don't make a
>measurable difference and are not without risk.
>

Hi, Liam

Maybe I found one issue in current code that we miss to set the root node
dead. Before sending a fix, I want to check with you first.

Current behavior:

  mte_destroy_walk()
    mt_destroy_walk()
      if (mte_is_leaf())
        goto free_leaf;
      mte_destroy_descend()
        mte_set_node_dead()    <-- set node dead here

Usually we set all node dead in mte_destroy_descend(). But if the maple tree
has just one root node, it jump to free_leaf without set it dead.

It seems not correct to leave a non-dead node. Is my understanding correct?

>Thanks,
>Liam

-- 
Wei Yang
Help you, Help me


From willy at infradead.org  Thu Jan 30 07:19:45 2025
From: willy at infradead.org (Matthew Wilcox (Oracle))
Date: Thu, 30 Jan 2025 15:19:45 +0000
Subject: [PATCH] test suite: Use %zu to print size_t
Message-ID: <20250130151946.3218986-1-willy@infradead.org>

On 32-bit, we can't use %lu to print a size_t variable and gcc warns us
about it.  Shame it doesn't warn about it on 64-bit.

Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
Fixes: cc86e0c2f306 (radix tree test suite: add support for slab bulk APIs)
---
 tools/testing/shared/linux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/shared/linux.c b/tools/testing/shared/linux.c
index 66dbb362385f..0f97fb0d19e1 100644
--- a/tools/testing/shared/linux.c
+++ b/tools/testing/shared/linux.c
@@ -150,7 +150,7 @@ void kmem_cache_free(struct kmem_cache *cachep, void *objp)
 void kmem_cache_free_bulk(struct kmem_cache *cachep, size_t size, void **list)
 {
 	if (kmalloc_verbose)
-		pr_debug("Bulk free %p[0-%lu]\n", list, size - 1);
+		pr_debug("Bulk free %p[0-%zu]\n", list, size - 1);
 
 	pthread_mutex_lock(&cachep->lock);
 	for (int i = 0; i < size; i++)
@@ -168,7 +168,7 @@ int kmem_cache_alloc_bulk(struct kmem_cache *cachep, gfp_t gfp, size_t size,
 	size_t i;
 
 	if (kmalloc_verbose)
-		pr_debug("Bulk alloc %lu\n", size);
+		pr_debug("Bulk alloc %zu\n", size);
 
 	pthread_mutex_lock(&cachep->lock);
 	if (cachep->nr_objs >= size) {
-- 
2.47.2



From scall at prosemail.net  Thu Jan 30 07:46:10 2025
From: scall at prosemail.net (Scall)
Date: Thu, 30 Jan 2025 16:46:10 +0100
Subject: lib/maple_tree.c:4056:1: error: the frame size of 1144 bytes is
 larger than 1024 bytes
Message-ID: <60cee319-4914-4a98-b74d-32e06fb3cbd8@prosemail.net>

Trying to build Linux 6.12.11 with GCC 14.2.1 and KCFLAGS="-O3":

[...]
lib/maple_tree.c: In function 'mas_wr_bnode':
lib/maple_tree.c:4056:1: error: the frame size of 1144 bytes is larger 
than 1024 bytes [-Werror=frame-larger-than=]
   4056 | }
        | ^
[...]


From Liam.Howlett at oracle.com  Thu Jan 30 08:13:42 2025
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Thu, 30 Jan 2025 11:13:42 -0500
Subject: lib/maple_tree.c:4056:1: error: the frame size of 1144 bytes is
 larger than 1024 bytes
In-Reply-To: <60cee319-4914-4a98-b74d-32e06fb3cbd8@prosemail.net>
References: <60cee319-4914-4a98-b74d-32e06fb3cbd8@prosemail.net>
Message-ID: <hxxufpccovvtnoypt4bukrpt4qrhiydlena5tdxqdxpmlduiii@2wac57fy4mqj>

* Scall <scall at prosemail.net> [250130 10:53]:
> Trying to build Linux 6.12.11 with GCC 14.2.1 and KCFLAGS="-O3":

Thanks.  I received a report of a frame size issue directly (not over
email) from someone else.

Do you have KASAN or lock debugging on?


> 
> [...]
> lib/maple_tree.c: In function 'mas_wr_bnode':
> lib/maple_tree.c:4056:1: error: the frame size of 1144 bytes is larger than
> 1024 bytes [-Werror=frame-larger-than=]
>   4056 | }
>        | ^
> [...]

Does the issue go away when reverting 8c7904a8cd0df ("maple_tree: i is
always less than or equal to mas_end") ?

Thanks,
Liam



From Liam.Howlett at oracle.com  Thu Jan 30 08:26:35 2025
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Thu, 30 Jan 2025 11:26:35 -0500
Subject: [PATCH] test suite: Use %zu to print size_t
In-Reply-To: <20250130151946.3218986-1-willy@infradead.org>
References: <20250130151946.3218986-1-willy@infradead.org>
Message-ID: <jfs2niyda3gvcxeywgwrcdfyprwduido2jstoxt3ubmmyvdauv@u4apuqb7tg7m>

* Matthew Wilcox (Oracle) <willy at infradead.org> [250130 10:19]:
> On 32-bit, we can't use %lu to print a size_t variable and gcc warns us
> about it.  Shame it doesn't warn about it on 64-bit.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
> Fixes: cc86e0c2f306 (radix tree test suite: add support for slab bulk APIs)

Thanks.  I'll try to remember to do this in the future.

> ---
>  tools/testing/shared/linux.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/testing/shared/linux.c b/tools/testing/shared/linux.c
> index 66dbb362385f..0f97fb0d19e1 100644
> --- a/tools/testing/shared/linux.c
> +++ b/tools/testing/shared/linux.c
> @@ -150,7 +150,7 @@ void kmem_cache_free(struct kmem_cache *cachep, void *objp)
>  void kmem_cache_free_bulk(struct kmem_cache *cachep, size_t size, void **list)
>  {
>  	if (kmalloc_verbose)
> -		pr_debug("Bulk free %p[0-%lu]\n", list, size - 1);
> +		pr_debug("Bulk free %p[0-%zu]\n", list, size - 1);
>  
>  	pthread_mutex_lock(&cachep->lock);
>  	for (int i = 0; i < size; i++)
> @@ -168,7 +168,7 @@ int kmem_cache_alloc_bulk(struct kmem_cache *cachep, gfp_t gfp, size_t size,
>  	size_t i;
>  
>  	if (kmalloc_verbose)
> -		pr_debug("Bulk alloc %lu\n", size);
> +		pr_debug("Bulk alloc %zu\n", size);
>  
>  	pthread_mutex_lock(&cachep->lock);
>  	if (cachep->nr_objs >= size) {
> -- 
> 2.47.2
> 


From scall at prosemail.net  Thu Jan 30 14:31:50 2025
From: scall at prosemail.net (Scall)
Date: Thu, 30 Jan 2025 23:31:50 +0100
Subject: lib/maple_tree.c:4056:1: error: the frame size of 1144 bytes is
 larger than 1024 bytes
In-Reply-To: <hxxufpccovvtnoypt4bukrpt4qrhiydlena5tdxqdxpmlduiii@2wac57fy4mqj>
References: <60cee319-4914-4a98-b74d-32e06fb3cbd8@prosemail.net>
 <hxxufpccovvtnoypt4bukrpt4qrhiydlena5tdxqdxpmlduiii@2wac57fy4mqj>
Message-ID: <8415a24a-a19e-46f6-bb56-dfd529143dd9@prosemail.net>

On 1/30/25 5:13 PM, Liam R. Howlett wrote:
> Do you have KASAN or lock debugging on?

No, I don't.

> Does the issue go away when reverting 8c7904a8cd0df ("maple_tree: i is
> always less than or equal to mas_end") ?

That commit has not been backported to the kernel version I tried to 
build (6.12.11, currently the latest stable version).

Good news: I learned that the issue has already been solved in the 
mainline version with commit 5059aa6334fcf ("maple_tree: memset 
maple_big_node as a whole") and backporting it is the solution.


From richard.weiyang at gmail.com  Fri Jan 31 04:28:01 2025
From: richard.weiyang at gmail.com (Wei Yang)
Date: Fri, 31 Jan 2025 12:28:01 +0000
Subject: lib/maple_tree.c:4056:1: error: the frame size of 1144 bytes is
 larger than 1024 bytes
In-Reply-To: <8415a24a-a19e-46f6-bb56-dfd529143dd9@prosemail.net>
References: <60cee319-4914-4a98-b74d-32e06fb3cbd8@prosemail.net>
 <hxxufpccovvtnoypt4bukrpt4qrhiydlena5tdxqdxpmlduiii@2wac57fy4mqj>
 <8415a24a-a19e-46f6-bb56-dfd529143dd9@prosemail.net>
Message-ID: <20250131122801.rb3bid7peznbgxwg@master>

Hi, Scall

On Thu, Jan 30, 2025 at 11:31:50PM +0100, Scall wrote:
>On 1/30/25 5:13 PM, Liam R. Howlett wrote:
>> Do you have KASAN or lock debugging on?
>
>No, I don't.
>
>> Does the issue go away when reverting 8c7904a8cd0df ("maple_tree: i is
>> always less than or equal to mas_end") ?
>
>That commit has not been backported to the kernel version I tried to build
>(6.12.11, currently the latest stable version).

Is there a public git tree to get the code you do build?

>
>Good news: I learned that the issue has already been solved in the mainline
>version with commit 5059aa6334fcf ("maple_tree: memset maple_big_node as a
>whole") and backporting it is the solution.

Or, is it possible to list the last several commits of file lib/maple_tree.c
so that I can reproduce it on my side.

I guess maybe I can try to reproduce this with:

   * set CONFIG_FRAM_WARN to 1024
   * set KCFLAGS="-O3"

I would try to take a look first.

Is the GCC version matters? I don't have the exact version at hand. Have you
tried other version?

-- 
Wei Yang
Help you, Help me


From richard.weiyang at gmail.com  Fri Jan 31 05:37:35 2025
From: richard.weiyang at gmail.com (Wei Yang)
Date: Fri, 31 Jan 2025 13:37:35 +0000
Subject: lib/maple_tree.c:4056:1: error: the frame size of 1144 bytes is
 larger than 1024 bytes
In-Reply-To: <8415a24a-a19e-46f6-bb56-dfd529143dd9@prosemail.net>
References: <60cee319-4914-4a98-b74d-32e06fb3cbd8@prosemail.net>
 <hxxufpccovvtnoypt4bukrpt4qrhiydlena5tdxqdxpmlduiii@2wac57fy4mqj>
 <8415a24a-a19e-46f6-bb56-dfd529143dd9@prosemail.net>
Message-ID: <20250131133735.hq6kwncyb5uibe7j@master>

On Thu, Jan 30, 2025 at 11:31:50PM +0100, Scall wrote:
>On 1/30/25 5:13 PM, Liam R. Howlett wrote:
>> Do you have KASAN or lock debugging on?
>
>No, I don't.
>
>> Does the issue go away when reverting 8c7904a8cd0df ("maple_tree: i is
>> always less than or equal to mas_end") ?
>
>That commit has not been backported to the kernel version I tried to build
>(6.12.11, currently the latest stable version).
>
>Good news: I learned that the issue has already been solved in the mainline
>version with commit 5059aa6334fcf ("maple_tree: memset maple_big_node as a
>whole") and backporting it is the solution.

Hmm... I tried to reproduce this and found different gcc version may behave
differently. An old version doesn't report warning while a later version does.

With GCC 8.2.1, the latest master looks good. Even I use -O3.

    7004a2e46d16 2025-01-22 Merge tag 'linux_kselftest-nolibc-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest

But with GCC 11.4.0(I don't have the exact version as yours), the latest
master still get a warning. But the message is a little bit different from
yours:

  lib/maple_tree.c: In function ?mas_wr_spanning_store?:
  lib/maple_tree.c:3804:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
   3804 | }
        | ^
  lib/maple_tree.c: In function ?mas_wr_bnode?:
  lib/maple_tree.c:4065:1: warning: the frame size of 1048 bytes is larger than 1024 bytes [-Wframe-larger-than=]
   4065 | }
        | ^

Then I tried to bisect it. And found similar warning even at the first maple
tree commit 54a611b60590 ("Maple Tree: add new data structure"). Below is the
warning message:

  lib/maple_tree.c: In function ?mas_wr_spanning_store.isra?:
  lib/maple_tree.c:4047:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]
   4047 | }
        | ^
  lib/maple_tree.c: In function ?mas_wr_bnode?:
  lib/maple_tree.c:4325:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
   4325 | }
        | ^

Hi, Liam

Do you have some suggestion on what I can do to help?

-- 
Wei Yang
Help you, Help me


From Liam.Howlett at oracle.com  Fri Jan 31 07:08:00 2025
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Fri, 31 Jan 2025 10:08:00 -0500
Subject: lib/maple_tree.c:4056:1: error: the frame size of 1144 bytes is
 larger than 1024 bytes
In-Reply-To: <20250131133735.hq6kwncyb5uibe7j@master>
References: <60cee319-4914-4a98-b74d-32e06fb3cbd8@prosemail.net>
 <hxxufpccovvtnoypt4bukrpt4qrhiydlena5tdxqdxpmlduiii@2wac57fy4mqj>
 <8415a24a-a19e-46f6-bb56-dfd529143dd9@prosemail.net>
 <20250131133735.hq6kwncyb5uibe7j@master>
Message-ID: <troejyyno7oiokx4njv7cbahwhkvkovlopj2igwlsexxqmrmaj@f3cjalwkpvf6>

* Wei Yang <richard.weiyang at gmail.com> [250131 08:37]:
> On Thu, Jan 30, 2025 at 11:31:50PM +0100, Scall wrote:
> >On 1/30/25 5:13 PM, Liam R. Howlett wrote:
> >> Do you have KASAN or lock debugging on?
> >
> >No, I don't.
> >
> >> Does the issue go away when reverting 8c7904a8cd0df ("maple_tree: i is
> >> always less than or equal to mas_end") ?
> >
> >That commit has not been backported to the kernel version I tried to build
> >(6.12.11, currently the latest stable version).
> >
> >Good news: I learned that the issue has already been solved in the mainline
> >version with commit 5059aa6334fcf ("maple_tree: memset maple_big_node as a
> >whole") and backporting it is the solution.
> 
> Hmm... I tried to reproduce this and found different gcc version may behave
> differently. An old version doesn't report warning while a later version does.
> 
> With GCC 8.2.1, the latest master looks good. Even I use -O3.
> 
>     7004a2e46d16 2025-01-22 Merge tag 'linux_kselftest-nolibc-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
> 
> But with GCC 11.4.0(I don't have the exact version as yours), the latest
> master still get a warning. But the message is a little bit different from
> yours:
> 
>   lib/maple_tree.c: In function ?mas_wr_spanning_store?:
>   lib/maple_tree.c:3804:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>    3804 | }
>         | ^
>   lib/maple_tree.c: In function ?mas_wr_bnode?:
>   lib/maple_tree.c:4065:1: warning: the frame size of 1048 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>    4065 | }
>         | ^
> 
> Then I tried to bisect it. And found similar warning even at the first maple
> tree commit 54a611b60590 ("Maple Tree: add new data structure"). Below is the
> warning message:
> 
>   lib/maple_tree.c: In function ?mas_wr_spanning_store.isra?:
>   lib/maple_tree.c:4047:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>    4047 | }
>         | ^
>   lib/maple_tree.c: In function ?mas_wr_bnode?:
>   lib/maple_tree.c:4325:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>    4325 | }
>         | ^
> 
> Hi, Liam
> 
> Do you have some suggestion on what I can do to help?

No, this isn't worth chasing down.

The proper fix is to remove the big node, but that's really involved and
I'm working on it.

Thanks,
Liam



From richard.weiyang at gmail.com  Fri Jan 31 08:46:39 2025
From: richard.weiyang at gmail.com (Wei Yang)
Date: Fri, 31 Jan 2025 16:46:39 +0000
Subject: [PATCH 0/7] spanning write related cleanup
In-Reply-To: <axz4cvmddhompm72cj6wga6hrqdkl56zcixol55gzisxf433wh@ycau3ttsbzg7>
References: <20241127012753.3393-1-richard.weiyang@gmail.com>
 <cqulekn3csbs5q6vo3uormpplgbn7vvqir4a4pnaavgvhcsd3b@js4s5ncaritj>
 <20250117054942.w6vgrllnaasjaww3@master>
 <acq3uafsy54fo6nwcrrrqjkpojw7dnfy5ubwrissrn2726p64d@4izyq742k5ym>
 <20250124013412.2vpf7davx63s377d@master>
 <axz4cvmddhompm72cj6wga6hrqdkl56zcixol55gzisxf433wh@ycau3ttsbzg7>
Message-ID: <20250131164639.o2j7dmwymrcmufh6@master>

On Mon, Jan 27, 2025 at 09:36:11AM -0500, Liam R. Howlett wrote:
>* Wei Yang <richard.weiyang at gmail.com> [250123 20:44]:
[...]
>> >> Hi, Liam
>> >> 
>> >> Would you mind taking a look when you have time?
>> >
>> >Yes, I'll have a look soon.  I don't love changes that dive deep into
>> >complex code that results in no gains (performance or feature wise).
>> >
>> >It's also odd to have simple "this return isn't use" and things moving
>> >code blocks to be executed only in certain scenarios, as the difficulty
>> >to verify the latter is much higher.
>> >
>> >Can we please limit changes to areas where there is a performance change
>> >or coupled with a change that is needed?  ie: stop sending patches that
>> >change things unless it's with a feature or improvement (performance or
>> >otherwise).  I'm just not convinced some of these are worth the
>> >cost vs risk.
>> >
>> 
>> Ok.
>> 
>> So you would drop this patch set or still want to take a look?
>
>I was going to look at it, but after I send my reply, I received a
>report of an issue caused in a certain configuration that caused the
>stack frame to grow out of the configured 1024 limit, which was tracked
>to a patch you added to simplify a previous function.
>

Liam,

I tried to locate which of my patch introduce the problem, but not succeed.
This is the issue of -Wframe-larger-than=, right?

Would you mind letting me know which one did something bad? So that I can
avoid such thing later.

>So, I think we should drop these patches since they don't make a
>measurable difference and are not without risk.
>
>Thanks,
>Liam

-- 
Wei Yang
Help you, Help me


