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  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:   Fri, 1 May 2020 03:55:45 -0700
From:   Christoph Hellwig <>
To:     Joonsoo Kim <>
Cc:     Andrew Morton <>,
        Linux Memory Management List <>,
        LKML <>,
        Vlastimil Babka <>,
        Laura Abbott <>,
        "Aneesh Kumar K . V" <>,
        Mel Gorman <>,
        Michal Hocko <>,
        Johannes Weiner <>,
        Roman Gushchin <>, Minchan Kim <>,
        Rik van Riel <>,
        Christian Koenig <>,
        Huang Rui <>,
        Eric Biederman <>,
        "Rafael J . Wysocki" <>,
        Pavel Machek <>,,
        Christoph Hellwig <>,
        Joonsoo Kim <>
Subject: Re: [PATCH v2 00/10] change the implementation of the PageHighMem()

On Fri, May 01, 2020 at 07:52:35PM +0900, Joonsoo Kim wrote:
> > - New code will pop up which gets it wrong and nobody will notice for
> >   a long time.
> Hmm... I think that it's not that hard to decide correct macro. If we rename
> PageHighMem() with PageDirectMapped(), they, PageDirectMapped() and
> PageHighMemZone(), are self-explanation macro. There would be no
> confusion to use.

What confuses me is why we even need PageHighMemZone - mostly code
should not care about particular zones.  Maybe just open coding
PageHighMemZone makes more sense - it is a little more cumersome, but
at least it makes it explicit what we check for.  I already sent you
an incremental diff for one obvious place, but maybe we need to look
through the remaining ones if we can kill them or open code them in an
obvious way.

Powered by blists - more mailing lists