[PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Yang Shi]

From: Yang Shi <yang@os.amperecomputing.com>

The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
boundaries") caused two issues [1] [2] reported on 32 bit system or compat
userspace.

It doesn't make too much sense to force huge page alignment on 32 bit
system due to the constrained virtual address space.

[1] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#mf211643a0427f8d6495b5b53f8132f453d60ab95
[2] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#me93dff2ccbd9902c3e395e1c022fb454e48ecb1d

Fixes: efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries")
Reported-by: Jiri Slaby <jirislaby@kernel.org>
Reported-by: Suren Baghdasaryan <surenb@google.com>
Tested-by: Jiri Slaby <jirislaby@kernel.org>
Tested-by: Suren Baghdasaryan <surenb@google.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Christopher Lameter <cl@linux.com>
Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
---
 mm/huge_memory.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 94ef5c02b459..e9fbaccbe0c0 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -37,6 +37,7 @@
 #include <linux/page_owner.h>
 #include <linux/sched/sysctl.h>
 #include <linux/memory-tiers.h>
+#include <linux/compat.h>
 
 #include <asm/tlb.h>
 #include <asm/pgalloc.h>
@@ -811,6 +812,14 @@ static unsigned long __thp_get_unmapped_area(struct file *filp,
 	loff_t off_align = round_up(off, size);
 	unsigned long len_pad, ret;
 
+	/*
+	 * It doesn't make too much sense to froce huge page alignment on
+	 * 32 bit system or compat userspace due to the contrained virtual
+	 * address space and address entropy.
+	 */
+	if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
+		return 0;
+
 	if (off_end <= off_align || (off_end - off_align) < size)
 		return 0;
 
-- 
2.41.0

[PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Yang Shi]

From: Yang Shi <yang@os.amperecomputing.com>

The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
boundaries") caused two issues [1] [2] reported on 32 bit system or compat
userspace.

It doesn't make too much sense to force huge page alignment on 32 bit
system due to the constrained virtual address space.

[1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/
[2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/

Fixes: efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries")
Reported-by: Jiri Slaby <jirislaby@kernel.org>
Reported-by: Suren Baghdasaryan <surenb@google.com>
Tested-by: Jiri Slaby <jirislaby@kernel.org>
Tested-by: Suren Baghdasaryan <surenb@google.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Christopher Lameter <cl@linux.com>
Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
---
 mm/huge_memory.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 94ef5c02b459..66adecdc509b 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -37,6 +37,7 @@
 #include <linux/page_owner.h>
 #include <linux/sched/sysctl.h>
 #include <linux/memory-tiers.h>
+#include <linux/compat.h>
 
 #include <asm/tlb.h>
 #include <asm/pgalloc.h>
@@ -811,6 +812,9 @@ static unsigned long __thp_get_unmapped_area(struct file *filp,
 	loff_t off_align = round_up(off, size);
 	unsigned long len_pad, ret;
 
+	if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
+		return 0;
+
 	if (off_end <= off_align || (off_end - off_align) < size)
 		return 0;
 
-- 
2.41.0

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Matthew Wilcox]

On Thu, Jan 18, 2024 at 05:35:04AM -0800, Yang Shi wrote:
> It doesn't make too much sense to force huge page alignment on 32 bit
> system due to the constrained virtual address space.
> 
> [1] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#mf211643a0427f8d6495b5b53f8132f453d60ab95
> [2] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#me93dff2ccbd9902c3e395e1c022fb454e48ecb1d

I feel sure there are shorter URLs for those messages ...

> @@ -811,6 +812,14 @@ static unsigned long __thp_get_unmapped_area(struct file *filp,
>  	loff_t off_align = round_up(off, size);
>  	unsigned long len_pad, ret;
>  
> +	/*
> +	 * It doesn't make too much sense to froce huge page alignment on
> +	 * 32 bit system or compat userspace due to the contrained virtual
> +	 * address space and address entropy.
> +	 */

I honestly wouldn't even comment this.  But if you must,

	/* Using THP alignment is not as important as address randomisation */

> +	if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
> +		return 0;
> +
>  	if (off_end <= off_align || (off_end - off_align) < size)
>  		return 0;
>  
> -- 
> 2.41.0
> 

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Yang Shi]

On Thu, Jan 18, 2024 at 12:14 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Thu, Jan 18, 2024 at 05:35:04AM -0800, Yang Shi wrote:
> > It doesn't make too much sense to force huge page alignment on 32 bit
> > system due to the constrained virtual address space.
> >
> > [1] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#mf211643a0427f8d6495b5b53f8132f453d60ab95
> > [2] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#me93dff2ccbd9902c3e395e1c022fb454e48ecb1d
>
> I feel sure there are shorter URLs for those messages ...

Oh, yeah, I just found.

[1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/
[2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/

>
> > @@ -811,6 +812,14 @@ static unsigned long __thp_get_unmapped_area(struct file *filp,
> >       loff_t off_align = round_up(off, size);
> >       unsigned long len_pad, ret;
> >
> > +     /*
> > +      * It doesn't make too much sense to froce huge page alignment on
> > +      * 32 bit system or compat userspace due to the contrained virtual
> > +      * address space and address entropy.
> > +      */
>
> I honestly wouldn't even comment this.  But if you must,
>
>         /* Using THP alignment is not as important as address randomisation */

It is not only about address randomization. Removing the comment is fine too.

>
> > +     if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
> > +             return 0;
> > +
> >       if (off_end <= off_align || (off_end - off_align) < size)
> >               return 0;
> >
> > --
> > 2.41.0
> >

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Matthew Wilcox]

On Thu, Jan 18, 2024 at 10:05:05AM -0800, Yang Shi wrote:
> From: Yang Shi <yang@os.amperecomputing.com>
> 
> The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
> boundaries") caused two issues [1] [2] reported on 32 bit system or compat
> userspace.
> 
> It doesn't make too much sense to force huge page alignment on 32 bit
> system due to the constrained virtual address space.
> 
> [1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/
> [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/
> 
> Fixes: efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries")
> Reported-by: Jiri Slaby <jirislaby@kernel.org>
> Reported-by: Suren Baghdasaryan <surenb@google.com>
> Tested-by: Jiri Slaby <jirislaby@kernel.org>
> Tested-by: Suren Baghdasaryan <surenb@google.com>
> Cc: Rik van Riel <riel@surriel.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Christopher Lameter <cl@linux.com>
> Signed-off-by: Yang Shi <yang@os.amperecomputing.com>

Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Rik van Riel]

On Thu, 2024-01-18 at 05:35 -0800, Yang Shi wrote:
> From: Yang Shi <yang@os.amperecomputing.com>
> 
> The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
> boundaries") caused two issues [1] [2] reported on 32 bit system or
> compat
> userspace.
> 
> It doesn't make too much sense to force huge page alignment on 32 bit
> system due to the constrained virtual address space.
> 

> +++ b/mm/huge_memory.c
> 
> @@ -811,6 +812,14 @@ static unsigned long
> __thp_get_unmapped_area(struct file *filp,
>         loff_t off_align = round_up(off, size);
>         unsigned long len_pad, ret;
>  
> +       /*
> +        * It doesn't make too much sense to froce huge page
> alignment on
> +        * 32 bit system or compat userspace due to the contrained
> virtual
> +        * address space and address entropy.
> +        */
> +       if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
> +               return 0;
> +
>         if (off_end <= off_align || (off_end - off_align) < size)
>                 return 0;
>  

Reviewed-by: Rik van Riel <riel@surriel.com>

-- 
All Rights Reversed.

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Michal Hocko]

On Thu 18-01-24 05:35:04, Yang Shi wrote:
> From: Yang Shi <yang@os.amperecomputing.com>
> 
> The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
> boundaries") caused two issues [1] [2] reported on 32 bit system or compat
> userspace.
> 
> It doesn't make too much sense to force huge page alignment on 32 bit
> system due to the constrained virtual address space.
> 
> [1] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#mf211643a0427f8d6495b5b53f8132f453d60ab95
> [2] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#me93dff2ccbd9902c3e395e1c022fb454e48ecb1d
> 
> Fixes: efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries")
> Reported-by: Jiri Slaby <jirislaby@kernel.org>
> Reported-by: Suren Baghdasaryan <surenb@google.com>
> Tested-by: Jiri Slaby <jirislaby@kernel.org>
> Tested-by: Suren Baghdasaryan <surenb@google.com>
> Cc: Rik van Riel <riel@surriel.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Christopher Lameter <cl@linux.com>
> Signed-off-by: Yang Shi <yang@os.amperecomputing.com>

Acked-by: Michal Hocko <mhocko@suse.com>

Thanks!

> ---
>  mm/huge_memory.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 94ef5c02b459..e9fbaccbe0c0 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -37,6 +37,7 @@
>  #include <linux/page_owner.h>
>  #include <linux/sched/sysctl.h>
>  #include <linux/memory-tiers.h>
> +#include <linux/compat.h>
>  
>  #include <asm/tlb.h>
>  #include <asm/pgalloc.h>
> @@ -811,6 +812,14 @@ static unsigned long __thp_get_unmapped_area(struct file *filp,
>  	loff_t off_align = round_up(off, size);
>  	unsigned long len_pad, ret;
>  
> +	/*
> +	 * It doesn't make too much sense to froce huge page alignment on
> +	 * 32 bit system or compat userspace due to the contrained virtual
> +	 * address space and address entropy.
> +	 */
> +	if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
> +		return 0;
> +
>  	if (off_end <= off_align || (off_end - off_align) < size)
>  		return 0;
>  
> -- 
> 2.41.0
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Jiri Slaby]

On 25. 01. 24, 9:53, Michal Hocko wrote:
> On Thu 18-01-24 05:35:04, Yang Shi wrote:
>> From: Yang Shi <yang@os.amperecomputing.com>
>>
>> The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
>> boundaries") caused two issues [1] [2] reported on 32 bit system or compat
>> userspace.
>>
>> It doesn't make too much sense to force huge page alignment on 32 bit
>> system due to the constrained virtual address space.
>>
>> [1] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#mf211643a0427f8d6495b5b53f8132f453d60ab95
>> [2] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#me93dff2ccbd9902c3e395e1c022fb454e48ecb1d
>>
>> Fixes: efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries")
>> Reported-by: Jiri Slaby <jirislaby@kernel.org>
>> Reported-by: Suren Baghdasaryan <surenb@google.com>
>> Tested-by: Jiri Slaby <jirislaby@kernel.org>
>> Tested-by: Suren Baghdasaryan <surenb@google.com>
>> Cc: Rik van Riel <riel@surriel.com>
>> Cc: Matthew Wilcox <willy@infradead.org>
>> Cc: Christopher Lameter <cl@linux.com>
>> Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
> 
> Acked-by: Michal Hocko <mhocko@suse.com>
> 
> Thanks!
> 
>> ---
>>   mm/huge_memory.c | 9 +++++++++
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index 94ef5c02b459..e9fbaccbe0c0 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -37,6 +37,7 @@
>>   #include <linux/page_owner.h>
>>   #include <linux/sched/sysctl.h>
>>   #include <linux/memory-tiers.h>
>> +#include <linux/compat.h>
>>   
>>   #include <asm/tlb.h>
>>   #include <asm/pgalloc.h>
>> @@ -811,6 +812,14 @@ static unsigned long __thp_get_unmapped_area(struct file *filp,
>>   	loff_t off_align = round_up(off, size);
>>   	unsigned long len_pad, ret;
>>   
>> +	/*
>> +	 * It doesn't make too much sense to froce huge page alignment on
>> +	 * 32 bit system or compat userspace due to the contrained virtual
>> +	 * address space and address entropy.
>> +	 */

FWIW,
Bernhard noticed that "froce" and "contrained", could you fix that 
before applying the patch?

thanks,
-- 
js
suse labs

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Jiri Slaby]

On 26. 01. 24, 10:36, Jiri Slaby wrote:
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -37,6 +37,7 @@
>>>   #include <linux/page_owner.h>
>>>   #include <linux/sched/sysctl.h>
>>>   #include <linux/memory-tiers.h>
>>> +#include <linux/compat.h>
>>>   #include <asm/tlb.h>
>>>   #include <asm/pgalloc.h>
>>> @@ -811,6 +812,14 @@ static unsigned long 
>>> __thp_get_unmapped_area(struct file *filp,
>>>       loff_t off_align = round_up(off, size);
>>>       unsigned long len_pad, ret;
>>> +    /*
>>> +     * It doesn't make too much sense to froce huge page alignment on
>>> +     * 32 bit system or compat userspace due to the contrained virtual
>>> +     * address space and address entropy.
>>> +     */
> 
> FWIW,
> Bernhard noticed that "froce" and "contrained", could you fix that 
> before applying the patch?

No, you can't:

1) it was merged to mm-stable already, and
2) the comment is not in that version at all [1]

[1] https://lore.kernel.org/all/20240126075612.87780C433F1@smtp.kernel.org/

> thanks,

-- 
js
suse labs

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Michal Hocko]

On Fri 26-01-24 10:41:49, Jiri Slaby wrote:
> On 26. 01. 24, 10:36, Jiri Slaby wrote:
> > > > --- a/mm/huge_memory.c
> > > > +++ b/mm/huge_memory.c
> > > > @@ -37,6 +37,7 @@
> > > >   #include <linux/page_owner.h>
> > > >   #include <linux/sched/sysctl.h>
> > > >   #include <linux/memory-tiers.h>
> > > > +#include <linux/compat.h>
> > > >   #include <asm/tlb.h>
> > > >   #include <asm/pgalloc.h>
> > > > @@ -811,6 +812,14 @@ static unsigned long
> > > > __thp_get_unmapped_area(struct file *filp,
> > > >       loff_t off_align = round_up(off, size);
> > > >       unsigned long len_pad, ret;
> > > > +    /*
> > > > +     * It doesn't make too much sense to froce huge page alignment on
> > > > +     * 32 bit system or compat userspace due to the contrained virtual
> > > > +     * address space and address entropy.
> > > > +     */
> > 
> > FWIW,
> > Bernhard noticed that "froce" and "contrained", could you fix that
> > before applying the patch?
> 
> No, you can't:
> 
> 1) it was merged to mm-stable already, and
> 2) the comment is not in that version at all [1]
> 
> [1] https://lore.kernel.org/all/20240126075612.87780C433F1@smtp.kernel.org/

Matthew has objected that the comment is not really necessary and I
think he is quite right. If anything the commend would be helpful to
explain why this doesn't make much sense (because that breaks ASLR
on default configuration and compat tasks). But that should be clear
from the changelog so I think we are good here.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Thorsten Leemhuis]

On 18.01.24 14:35, Yang Shi wrote:
> From: Yang Shi <yang@os.amperecomputing.com>
> 
> The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
> boundaries") caused two issues [1] [2] reported on 32 bit system or compat
> userspace.
> 
> It doesn't make too much sense to force huge page alignment on 32 bit
> system due to the constrained virtual address space.
> 
> [1] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#mf211643a0427f8d6495b5b53f8132f453d60ab95
> [2] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#me93dff2ccbd9902c3e395e1c022fb454e48ecb1d

[FWIW, this is now 4ef9ad19e17676 ("mm: huge_memory: don't force huge
page alignment on 32 bit") in mainline]

Quick question: it it okay to ask Greg to pick this up for linux-6.7.y
series?

I'm wondering because Jiri's report ([1] in above quote) sounded like
this is something that will affect and annoy quite a few people with the
linux-6.7.y.

Ciao, Thorsten

> Fixes: efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries")
> Reported-by: Jiri Slaby <jirislaby@kernel.org>
> Reported-by: Suren Baghdasaryan <surenb@google.com>
> Tested-by: Jiri Slaby <jirislaby@kernel.org>
> Tested-by: Suren Baghdasaryan <surenb@google.com>
> Cc: Rik van Riel <riel@surriel.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Christopher Lameter <cl@linux.com>
> Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
> ---
>  mm/huge_memory.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 94ef5c02b459..e9fbaccbe0c0 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -37,6 +37,7 @@
>  #include <linux/page_owner.h>
>  #include <linux/sched/sysctl.h>
>  #include <linux/memory-tiers.h>
> +#include <linux/compat.h>
>  
>  #include <asm/tlb.h>
>  #include <asm/pgalloc.h>
> @@ -811,6 +812,14 @@ static unsigned long __thp_get_unmapped_area(struct file *filp,
>  	loff_t off_align = round_up(off, size);
>  	unsigned long len_pad, ret;
>  
> +	/*
> +	 * It doesn't make too much sense to froce huge page alignment on
> +	 * 32 bit system or compat userspace due to the contrained virtual
> +	 * address space and address entropy.
> +	 */
> +	if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
> +		return 0;
> +
>  	if (off_end <= off_align || (off_end - off_align) < size)
>  		return 0;
>  

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Yang Shi]

On Sat, Feb 3, 2024 at 1:24 AM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> On 18.01.24 14:35, Yang Shi wrote:
> > From: Yang Shi <yang@os.amperecomputing.com>
> >
> > The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
> > boundaries") caused two issues [1] [2] reported on 32 bit system or compat
> > userspace.
> >
> > It doesn't make too much sense to force huge page alignment on 32 bit
> > system due to the constrained virtual address space.
> >
> > [1] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#mf211643a0427f8d6495b5b53f8132f453d60ab95
> > [2] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#me93dff2ccbd9902c3e395e1c022fb454e48ecb1d
>
> [FWIW, this is now 4ef9ad19e17676 ("mm: huge_memory: don't force huge
> page alignment on 32 bit") in mainline]
>
> Quick question: it it okay to ask Greg to pick this up for linux-6.7.y
> series?

Yes, definitely. Thanks for following up.

Yang

>
> I'm wondering because Jiri's report ([1] in above quote) sounded like
> this is something that will affect and annoy quite a few people with the
> linux-6.7.y.
>
> Ciao, Thorsten
>
> > Fixes: efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries")
> > Reported-by: Jiri Slaby <jirislaby@kernel.org>
> > Reported-by: Suren Baghdasaryan <surenb@google.com>
> > Tested-by: Jiri Slaby <jirislaby@kernel.org>
> > Tested-by: Suren Baghdasaryan <surenb@google.com>
> > Cc: Rik van Riel <riel@surriel.com>
> > Cc: Matthew Wilcox <willy@infradead.org>
> > Cc: Christopher Lameter <cl@linux.com>
> > Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
> > ---
> >  mm/huge_memory.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 94ef5c02b459..e9fbaccbe0c0 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -37,6 +37,7 @@
> >  #include <linux/page_owner.h>
> >  #include <linux/sched/sysctl.h>
> >  #include <linux/memory-tiers.h>
> > +#include <linux/compat.h>
> >
> >  #include <asm/tlb.h>
> >  #include <asm/pgalloc.h>
> > @@ -811,6 +812,14 @@ static unsigned long __thp_get_unmapped_area(struct file *filp,
> >       loff_t off_align = round_up(off, size);
> >       unsigned long len_pad, ret;
> >
> > +     /*
> > +      * It doesn't make too much sense to froce huge page alignment on
> > +      * 32 bit system or compat userspace due to the contrained virtual
> > +      * address space and address entropy.
> > +      */
> > +     if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
> > +             return 0;
> > +
> >       if (off_end <= off_align || (off_end - off_align) < size)
> >               return 0;
> >

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Linux regression tracking (Thorsten Leemhuis)]

[adding the stable team]

On 05.02.24 18:07, Yang Shi wrote:
> On Sat, Feb 3, 2024 at 1:24 AM Thorsten Leemhuis
> <regressions@leemhuis.info> wrote:
>> On 18.01.24 14:35, Yang Shi wrote:
>>>
>>> The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
>>> boundaries") caused two issues [1] [2] reported on 32 bit system or compat
>>> userspace.
>>>
>>> It doesn't make too much sense to force huge page alignment on 32 bit
>>> system due to the constrained virtual address space.
>>>
>>> [1] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#mf211643a0427f8d6495b5b53f8132f453d60ab95
>>> [2] https://lore.kernel.org/linux-mm/CAHbLzkqa1SCBA10yjWTtA2mKCsoK5+M1BthSDL8ROvUq2XxZMw@mail.gmail.com/T/#me93dff2ccbd9902c3e395e1c022fb454e48ecb1d
>>
>> [FWIW, this is now 4ef9ad19e17676 ("mm: huge_memory: don't force huge
>> page alignment on 32 bit") in mainline]
>>
>> Quick question: it it okay to ask Greg to pick this up for linux-6.7.y
>> series?
> 
> Yes, definitely. Thanks for following up.

In that case: Greg, could you please consider picking up 4ef9ad19e17676
("mm: huge_memory: don't force huge page alignment on 32 bit") for the
next linux-6.7 rc round? tia!

Ohh, and btw: you might also want to pick up c4608d1bf7c653 ("mm: mmap:
map MAP_STACK to VM_NOHUGEPAGE") if you haven't already done so: its
stable tag contains a typo, hence I guess your scripts might have missed
it (I only noticed that by chance).

Ciao, Thorsten

>> I'm wondering because Jiri's report ([1] in above quote) sounded like
>> this is something that will affect and annoy quite a few people with the
>> linux-6.7.y.
>>
>> Ciao, Thorsten
>>
>>> Fixes: efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries")
>>> Reported-by: Jiri Slaby <jirislaby@kernel.org>
>>> Reported-by: Suren Baghdasaryan <surenb@google.com>
>>> Tested-by: Jiri Slaby <jirislaby@kernel.org>
>>> Tested-by: Suren Baghdasaryan <surenb@google.com>
>>> Cc: Rik van Riel <riel@surriel.com>
>>> Cc: Matthew Wilcox <willy@infradead.org>
>>> Cc: Christopher Lameter <cl@linux.com>
>>> Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
>>> ---
>>>  mm/huge_memory.c | 9 +++++++++
>>>  1 file changed, 9 insertions(+)
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index 94ef5c02b459..e9fbaccbe0c0 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -37,6 +37,7 @@
>>>  #include <linux/page_owner.h>
>>>  #include <linux/sched/sysctl.h>
>>>  #include <linux/memory-tiers.h>
>>> +#include <linux/compat.h>
>>>
>>>  #include <asm/tlb.h>
>>>  #include <asm/pgalloc.h>
>>> @@ -811,6 +812,14 @@ static unsigned long __thp_get_unmapped_area(struct file *filp,
>>>       loff_t off_align = round_up(off, size);
>>>       unsigned long len_pad, ret;
>>>
>>> +     /*
>>> +      * It doesn't make too much sense to froce huge page alignment on
>>> +      * 32 bit system or compat userspace due to the contrained virtual
>>> +      * address space and address entropy.
>>> +      */
>>> +     if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
>>> +             return 0;
>>> +
>>>       if (off_end <= off_align || (off_end - off_align) < size)
>>>               return 0;
>>>
> 
> 

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Thorsten Leemhuis]

Hey Greg, is below mail still in your queue of linux-stable mails to
process? If so please apologize this interruption and just ignore this
mail. I just started to wonder if it might have fallen through the
cracks somehow, as I've seen you updating stable-queue.git for 6.7.y,
but it's still missing this patch (and the other one mentioned) --
that's why I decided to write this quick status inquiry.

Ciao, Thorsten

On 05.02.24 18:53, Linux regression tracking (Thorsten Leemhuis) wrote:
> [adding the stable team]
> 
> On 05.02.24 18:07, Yang Shi wrote:
>> On Sat, Feb 3, 2024 at 1:24 AM Thorsten Leemhuis
>> <regressions@leemhuis.info> wrote:
>>> On 18.01.24 14:35, Yang Shi wrote:
>>>>
>>>> The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
>>>> boundaries") caused two issues [1] [2] reported on 32 bit system or compat
>>>> userspace.
> [...]
>>> [FWIW, this is now 4ef9ad19e17676 ("mm: huge_memory: don't force huge
>>> page alignment on 32 bit") in mainline]
>>>
>>> Quick question: it it okay to ask Greg to pick this up for linux-6.7.y
>>> series?
>>
>> Yes, definitely. Thanks for following up.
> 
> In that case: Greg, could you please consider picking up 4ef9ad19e17676
> ("mm: huge_memory: don't force huge page alignment on 32 bit") for the
> next linux-6.7 rc round? tia!
> 
> Ohh, and btw: you might also want to pick up c4608d1bf7c653 ("mm: mmap:
> map MAP_STACK to VM_NOHUGEPAGE") if you haven't already done so: its
> stable tag contains a typo, hence I guess your scripts might have missed
> it (I only noticed that by chance).
> 
> Ciao, Thorsten

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Greg KH]

On Mon, Feb 12, 2024 at 02:45:04PM +0100, Thorsten Leemhuis wrote:
> Hey Greg, is below mail still in your queue of linux-stable mails to
> process? If so please apologize this interruption and just ignore this
> mail. I just started to wonder if it might have fallen through the
> cracks somehow, as I've seen you updating stable-queue.git for 6.7.y,
> but it's still missing this patch (and the other one mentioned) --
> that's why I decided to write this quick status inquiry.

Yes, my queue is quite large because of travel and the CNA/CVE work that
was happening, am catching up now.  I've queued these up now, thanks.

greg k-h

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Yves-Alexis Perez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, 2024-01-18 at 05:35 -0800, Yang Shi wrote:
> The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
> boundaries") caused two issues [1] [2] reported on 32 bit system or compat
> userspace.
> 
> It doesn't make too much sense to force huge page alignment on 32 bit
> system due to the constrained virtual address space.

Hi people,

sorry for beeing so late. I've looked at this following the OpenSSH issue
(CVE-2024-6387 [1]) and especially the impact on IA-32 installations where
ASLR is apparently broken.

There was a recent thread [2] on oss-security discussing the issue.

Looking at the commit log I think the intention was to fix this both for:
- - 32 bit process running on 64 bit kernels: in_compat_syscall()
- - all processes running on 32 bit kernels: IS_ENABLED(CONFIG_32BIT)

Unfortunately, as far as I can tell, CONFIG_32BIT is not enabled on 32bit x86
kernels. Maybe CONFIG_X86_32 would be the right one there?

[1] https://www.openwall.com/lists/oss-security/2024/07/01/3
[2] https://www.openwall.com/lists/oss-security/2024/07/08/3
- -- 
Yves-Alexis
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmaQPCQACgkQ3rYcyPpX
RFvSHQf/VE7td7scTTsrK7Cx0F3MmDLFgjUDbMDuyPq6lNQqnDbd2zc00JP1eeLs
/mW1uZNbR92bn6xq2sPJu7c6tB3MJuiQme+ZqnPfIgyoWc89i6V6WUXTZN077lIl
xJZxHLMei5KreHz66AYU66HdU89knMTcX362YyyI8dEZKXS3FlP0SLSoBM0UKY0G
HYM6+GetE+fINhfNSMpHgqkTQB825Vqdq5UBsBjHYMg5RJ92/fDgUo5RD7qm/HVz
SDDNSGwpVwYZ20RnnD+DOS9rsnyR4FcAP0m0dcTmQdM8GcY4SyjnEux5idvCicjy
a1jmvsSLxCMZ9mZsrsipIZoNhSHlDA==
=f0Lk
-----END PGP SIGNATURE-----

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Yang Shi]

On Thu, Jul 11, 2024 at 1:10 PM Yves-Alexis Perez <corsac@debian.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Thu, 2024-01-18 at 05:35 -0800, Yang Shi wrote:
> > The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
> > boundaries") caused two issues [1] [2] reported on 32 bit system or compat
> > userspace.
> >
> > It doesn't make too much sense to force huge page alignment on 32 bit
> > system due to the constrained virtual address space.
>
> Hi people,
>
> sorry for beeing so late. I've looked at this following the OpenSSH issue
> (CVE-2024-6387 [1]) and especially the impact on IA-32 installations where
> ASLR is apparently broken.
>
> There was a recent thread [2] on oss-security discussing the issue.
>
> Looking at the commit log I think the intention was to fix this both for:
> - - 32 bit process running on 64 bit kernels: in_compat_syscall()
> - - all processes running on 32 bit kernels: IS_ENABLED(CONFIG_32BIT)

Yes. It is supposed to cover all 32 bit machines.

>
> Unfortunately, as far as I can tell, CONFIG_32BIT is not enabled on 32bit x86
> kernels. Maybe CONFIG_X86_32 would be the right one there?

I have not been working on 32 bit machine for years. I'm a little bit
surprised CONFIG_32BIT is not enough for x86_32. Sorry for overlooking
this.

The below patch should fix your problem.

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 2120f7478e55..2944b3fc88a5 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -857,7 +857,8 @@ static unsigned long
__thp_get_unmapped_area(struct file *filp,
        loff_t off_align = round_up(off, size);
        unsigned long len_pad, ret, off_sub;

-       if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
+       if (IS_ENABLED(CONFIG_32BIT) || IS_ENABLED(CONFIG_X86_32) ||
+           in_compat_syscall())
                return 0;

        if (off_end <= off_align || (off_end - off_align) < size)

>
> [1] https://www.openwall.com/lists/oss-security/2024/07/01/3
> [2] https://www.openwall.com/lists/oss-security/2024/07/08/3
> - --
> Yves-Alexis
> -----BEGIN PGP SIGNATURE-----
>
> iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmaQPCQACgkQ3rYcyPpX
> RFvSHQf/VE7td7scTTsrK7Cx0F3MmDLFgjUDbMDuyPq6lNQqnDbd2zc00JP1eeLs
> /mW1uZNbR92bn6xq2sPJu7c6tB3MJuiQme+ZqnPfIgyoWc89i6V6WUXTZN077lIl
> xJZxHLMei5KreHz66AYU66HdU89knMTcX362YyyI8dEZKXS3FlP0SLSoBM0UKY0G
> HYM6+GetE+fINhfNSMpHgqkTQB825Vqdq5UBsBjHYMg5RJ92/fDgUo5RD7qm/HVz
> SDDNSGwpVwYZ20RnnD+DOS9rsnyR4FcAP0m0dcTmQdM8GcY4SyjnEux5idvCicjy
> a1jmvsSLxCMZ9mZsrsipIZoNhSHlDA==
> =f0Lk
> -----END PGP SIGNATURE-----

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Matthew Wilcox]

On Thu, Jul 11, 2024 at 01:47:00PM -0700, Yang Shi wrote:
> +++ b/mm/huge_memory.c
> @@ -857,7 +857,8 @@ static unsigned long
> __thp_get_unmapped_area(struct file *filp,
>         loff_t off_align = round_up(off, size);
>         unsigned long len_pad, ret, off_sub;
> 
> -       if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
> +       if (IS_ENABLED(CONFIG_32BIT) || IS_ENABLED(CONFIG_X86_32) ||
> +           in_compat_syscall())

Why not:

	if (!IS_ENABLED(CONFIG_64BIT) || in_compat_syscall())

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

On Thu, 2024-07-11 at 22:10 +0200, Yves-Alexis Perez wrote:
> On Thu, 2024-01-18 at 05:35 -0800, Yang Shi wrote:
> > The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
> > boundaries") caused two issues [1] [2] reported on 32 bit system or compat
> > userspace.
> > 
> > It doesn't make too much sense to force huge page alignment on 32 bit
> > system due to the constrained virtual address space.
> 
> Hi people,
> 
> sorry for beeing so late. I've looked at this following the OpenSSH issue
> (CVE-2024-6387 [1]) and especially the impact on IA-32 installations where
> ASLR is apparently broken.
> 
> There was a recent thread [2] on oss-security discussing the issue.
> 
> Looking at the commit log I think the intention was to fix this both for:
> - 32 bit process running on 64 bit kernels: in_compat_syscall()
> - all processes running on 32 bit kernels: IS_ENABLED(CONFIG_32BIT)
> 
> Unfortunately, as far as I can tell, CONFIG_32BIT is not enabled on 32bit x86
> kernels. Maybe CONFIG_X86_32 would be the right one there?

CONFIG_64BIT appears to be defined and enabled in all 64-bit
architectures, so I think !IS_ENABLED(CONFIG_64BIT) would work as a
generic check.

Ben.

> 
> [1] https://www.openwall.com/lists/oss-security/2024/07/01/3
> [2] https://www.openwall.com/lists/oss-security/2024/07/08/3

-- 
Ben Hutchings
Computers are not intelligent.	They only think they are.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Yang Shi]

On Thu, Jul 11, 2024 at 1:50 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Thu, Jul 11, 2024 at 01:47:00PM -0700, Yang Shi wrote:
> > +++ b/mm/huge_memory.c
> > @@ -857,7 +857,8 @@ static unsigned long
> > __thp_get_unmapped_area(struct file *filp,
> >         loff_t off_align = round_up(off, size);
> >         unsigned long len_pad, ret, off_sub;
> >
> > -       if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
> > +       if (IS_ENABLED(CONFIG_32BIT) || IS_ENABLED(CONFIG_X86_32) ||
> > +           in_compat_syscall())
>
> Why not:
>
>         if (!IS_ENABLED(CONFIG_64BIT) || in_compat_syscall())

Nothing specific, just didn't think of it, sigh...

Thanks for the suggestion. Definitely preferable way.

>

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Yves-Alexis Perez]

On Thu, Jul 11, 2024 at 01:53:04PM -0700, Yang Shi wrote:
> On Thu, Jul 11, 2024 at 1:50 PM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Thu, Jul 11, 2024 at 01:47:00PM -0700, Yang Shi wrote:
> > > +++ b/mm/huge_memory.c
> > > @@ -857,7 +857,8 @@ static unsigned long
> > > __thp_get_unmapped_area(struct file *filp,
> > >         loff_t off_align = round_up(off, size);
> > >         unsigned long len_pad, ret, off_sub;
> > >
> > > -       if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
> > > +       if (IS_ENABLED(CONFIG_32BIT) || IS_ENABLED(CONFIG_X86_32) ||
> > > +           in_compat_syscall())
> >
> > Why not:
> >
> >         if (!IS_ENABLED(CONFIG_64BIT) || in_compat_syscall())
> 
> Nothing specific, just didn't think of it, sigh...
> 
> Thanks for the suggestion. Definitely preferable way.
> 
And I just did a quick test rebuilding a kernel with
!IS_ENABLED(CONFIG_64BIT) and running on an i386 Debian sid
installation.

I can confirm it seems to work as intended:

Before:
root@testvm:~# uname -a
Linux testvm 6.9.8-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.9.8-1 (2024-07-07) i686 GNU/Linux
root@testvm:~# for i in {0..9}; do cat /proc/self/maps |grep libc.so |head -n1; done
b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6


After:

root@testvm:~# uname -a
Linux testvm 6.9.8+ #1 SMP PREEMPT_DYNAMIC Fri Jul 12 15:23:07 CEST 2024 i686 GNU/Linux
root@testvm:~# for i in {0..9}; do cat /proc/self/maps |grep libc.so |head -n1; done
b7cf3000-b7d15000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7d7a000-b7d9c000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7d8b000-b7dad000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7d4b000-b7d6d000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7d64000-b7d86000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7d15000-b7d37000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7c9e000-b7cc0000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7d68000-b7d8a000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7cf6000-b7d18000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
b7ce6000-b7d08000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6

So:
Tested-By: Yves-Alexis Perez <corsac@debian.org>

I didn't try on other 32b architectures though.

Regards,
-- 
Yves-Alexis Perez

Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32 bit

[Yang Shi]

On Fri, Jul 12, 2024 at 7:43 AM Yves-Alexis Perez <corsac@debian.org> wrote:
>
> On Thu, Jul 11, 2024 at 01:53:04PM -0700, Yang Shi wrote:
> > On Thu, Jul 11, 2024 at 1:50 PM Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > On Thu, Jul 11, 2024 at 01:47:00PM -0700, Yang Shi wrote:
> > > > +++ b/mm/huge_memory.c
> > > > @@ -857,7 +857,8 @@ static unsigned long
> > > > __thp_get_unmapped_area(struct file *filp,
> > > >         loff_t off_align = round_up(off, size);
> > > >         unsigned long len_pad, ret, off_sub;
> > > >
> > > > -       if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
> > > > +       if (IS_ENABLED(CONFIG_32BIT) || IS_ENABLED(CONFIG_X86_32) ||
> > > > +           in_compat_syscall())
> > >
> > > Why not:
> > >
> > >         if (!IS_ENABLED(CONFIG_64BIT) || in_compat_syscall())
> >
> > Nothing specific, just didn't think of it, sigh...
> >
> > Thanks for the suggestion. Definitely preferable way.
> >
> And I just did a quick test rebuilding a kernel with
> !IS_ENABLED(CONFIG_64BIT) and running on an i386 Debian sid
> installation.
>
> I can confirm it seems to work as intended:
>
> Before:
> root@testvm:~# uname -a
> Linux testvm 6.9.8-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.9.8-1 (2024-07-07) i686 GNU/Linux
> root@testvm:~# for i in {0..9}; do cat /proc/self/maps |grep libc.so |head -n1; done
> b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7c00000-b7c22000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
>
>
> After:
>
> root@testvm:~# uname -a
> Linux testvm 6.9.8+ #1 SMP PREEMPT_DYNAMIC Fri Jul 12 15:23:07 CEST 2024 i686 GNU/Linux
> root@testvm:~# for i in {0..9}; do cat /proc/self/maps |grep libc.so |head -n1; done
> b7cf3000-b7d15000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7d7a000-b7d9c000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7d8b000-b7dad000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7d4b000-b7d6d000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7d64000-b7d86000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7d15000-b7d37000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7c9e000-b7cc0000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7d68000-b7d8a000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7cf6000-b7d18000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
> b7ce6000-b7d08000 r--p 00000000 fe:00 933        /usr/lib/i386-linux-gnu/libc.so.6
>
> So:
> Tested-By: Yves-Alexis Perez <corsac@debian.org>

Thank you so much. Will submit the formal patch soon.

>
> I didn't try on other 32b architectures though.
>
> Regards,
> --
> Yves-Alexis Perez