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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sun, 25 Feb 2018 01:50:32 +0100
From:   Eugeniu Rosca <erosca@...adit-jv.com>
To:     Michal Hocko <mhocko@...nel.org>, <akpm@...ux-foundation.org>
CC:     Randy Dunlap <rdunlap@...radead.org>, <broonie@...nel.org>,
        <linux-fsdevel@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-mm@...ck.org>, <linux-next@...r.kernel.org>,
        <mm-commits@...r.kernel.org>, <sfr@...b.auug.org.au>,
        richard -rw- weinberger <richard.weinberger@...il.com>,
        Eugeniu Rosca <rosca.eugeniu@...il.com>,
        Eugeniu Rosca <erosca@...adit-jv.com>
Subject: Re: mmotm 2018-02-21-14-48 uploaded (mm/page_alloc.c on UML)

Hello Andrew, Michal,

On Thu, Feb 22, 2018 at 02:26:30PM +0100, Michal Hocko wrote:
> On Thu 22-02-18 14:08:14, Eugeniu Rosca wrote:
> > On Thu, Feb 22, 2018 at 01:59:55PM +0100, Michal Hocko wrote:
> > > On Thu 22-02-18 11:38:32, Eugeniu Rosca wrote:
> > > > Hi Michal,
> > > > 
> > > > Please, let me know if any action is expected from my end.
> > > 
> > > I do not thing anything is really needed right now. If you have a strong
> > > opinion about the solution (ifdef vs. noop stub) then speak up.
> > 
> > No different preference on my side. I was more thinking if you are going
> > to amend the patch or create a fix on top of it. Since it didn't reach
> > mainline, it makes sense to amend it. If you can do it without the
> > intervention of the author, that's also fine for me.
> 
> Andrew usually takes the incremental fix and then squash them when
> sending to Linus

This may sound like bikeshedding, but if commit [1] is squashed onto [2],
the resulted commit will pointlessly relocate the ifdef line, like seen
in [3]. Feel free to skip this comment/request, but imho applying [4] on
top of [1] would then result in a cleaner squashed commit. No functional
change is intended here. TIA.

[1] linux-next commit 5fd667a8c762 ("mm-page_alloc-skip-over-regions-of-invalid-pfns-on-uma-fix")
[2] linux-next commit 72a571e91476 ("mm: page_alloc: skip over regions of invalid pfns on UMA")

[3] Ugly and unneeded ifdef line relocation
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cb416723538f..a89b029985ef 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5355,12 +5355,12 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone,
                        goto not_early;

                if (!early_pfn_valid(pfn)) {
-#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
                        /*
                         * Skip to the pfn preceding the next valid one (or
                         * end_pfn), such that we hit a valid pfn (or end_pfn)
                         * on our next iteration of the loop.
                         */
+#ifdef CONFIG_HAVE_MEMBLOCK
                        pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
 #endif
                        continue;


[4] Patch to be applied on top of [1], for a cleaner squashed commit.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a89b029985ef..10cbf9f1fb35 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5355,12 +5355,12 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone,
                        goto not_early;

                if (!early_pfn_valid(pfn)) {
+#ifdef CONFIG_HAVE_MEMBLOCK
                        /*
                         * Skip to the pfn preceding the next valid one (or
                         * end_pfn), such that we hit a valid pfn (or end_pfn)
                         * on our next iteration of the loop.
                         */
-#ifdef CONFIG_HAVE_MEMBLOCK
                        pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
 #endif
                        continue;

Best regards,
Eugeniu.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ