| Message ID | 20240118133504.2910955-1-shy828301@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: huge_memory: don't force huge page alignment on 32 bit | expand |
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 >
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 > >
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>
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 >
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,
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,
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.
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; >
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; > >
[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; >>> > >
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
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
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;