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]
Date:   Thu, 28 Sep 2017 11:44:23 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     Minchan Kim <minchan@...nel.org>, Nitin Gupta <ngupta@...are.org>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Lutomirski <luto@...capital.net>,
        Cyrill Gorcunov <gorcunov@...nvz.org>,
        Borislav Petkov <bp@...e.de>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCHv7 02/19] mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS


* Kirill A. Shutemov <kirill@...temov.name> wrote:

> On Thu, Sep 28, 2017 at 10:10:34AM +0200, Ingo Molnar wrote:
> > 
> > * Kirill A. Shutemov <kirill.shutemov@...ux.intel.com> wrote:
> > 
> > > With boot-time switching between paging mode we will have variable
> > > MAX_PHYSMEM_BITS.
> > > 
> > > Let's use the maximum variable possible for CONFIG_X86_5LEVEL=y
> > > configuration to define zsmalloc data structures.
> > > 
> > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> > > Cc: Minchan Kim <minchan@...nel.org>
> > > Cc: Nitin Gupta <ngupta@...are.org>
> > > Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
> > > ---
> > >  mm/zsmalloc.c | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > > index 7c38e850a8fc..fe22661f2fe5 100644
> > > --- a/mm/zsmalloc.c
> > > +++ b/mm/zsmalloc.c
> > > @@ -93,7 +93,13 @@
> > >  #define MAX_PHYSMEM_BITS BITS_PER_LONG
> > >  #endif
> > >  #endif
> > > +
> > > +#ifdef CONFIG_X86_5LEVEL
> > > +/* MAX_PHYSMEM_BITS is variable, use maximum value here */
> > > +#define _PFN_BITS		(52 - PAGE_SHIFT)
> > > +#else
> > >  #define _PFN_BITS		(MAX_PHYSMEM_BITS - PAGE_SHIFT)
> > > +#endif
> > 
> > This is a totally ugly hack, polluting generic MM code with an x86-ism and an 
> > arbitrary hard-coded constant that would silently lose validity when x86 paging 
> > gets extended again ...
> 
> Well, yes it's ugly. And I would be glad to find better solution. But I
> don't see one.
> 
> And it won't break silently on x86 paging expanding as it won't use
> CONFIG_X86_5LEVEL, so we would fallback to MAX_PHYSMEM_BITS - PAGE_SHIFT.
>
> I worth noting that the code already has x86 hack. See PAE special case
> for MAX_PHYSMEM_BITS.

Old mistakes don't justify new ones.

It's possible to do better: for example if we provide a MAX_POSSIBLE_PHYSMEM_BITS 
define that is the higher value then code which needs this for sizing can use it?

That could eliminate the PAE dependency as well perhaps.

Thanks,

	Ingo

Powered by blists - more mailing lists