lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZbOOn0hrKQ_ojM2K@tiehlicka>
Date: Fri, 26 Jan 2024 11:51:11 +0100
From: Michal Hocko <mhocko@...e.com>
To: Jiri Slaby <jirislaby@...nel.org>
Cc: akpm@...ux-foundation.org, surenb@...gle.com, riel@...riel.com,
	willy@...radead.org, cl@...ux.com, yang@...amperecomputing.com,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	"Bernhard M. Wiedemann" <bwiedemann@...e.de>,
	Yang Shi <shy828301@...il.com>
Subject: Re: [PATCH] mm: huge_memory: don't force huge page alignment on 32
 bit

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ