linux-kernel - Re: [PATCH] mm: check pfn_valid first in zero_resv

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:   Fri, 1 Dec 2017 16:57:49 +0800
From:   Dave Young <dyoung@...hat.com>
To:     Pavel Tatashin <pasha.tatashin@...cle.com>
Cc:     linux-kernel@...r.kernel.org,
        Linux Memory Management List <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] mm: check pfn_valid first in zero_resv_unavail

On 11/30/17 at 12:25pm, Pavel Tatashin wrote:
> Hi Dave,
> 
> Because unavailable memory can be in the middle of a section, I think
> a proper fix would be to do pfn_valid() check only at the beginning of
> section. Otherwise, we might miss zeroing  a struct page is in the
> middle of a section but pfn_valid() could potentially return false as
> that page is indeed invalid.
> 
> So, I would do something like this:
> +                       if (!pfn_valid(ALIGN_DOWN(pfn, pageblock_nr_pages))
> +                               continue;
> 
> Could you please test if this fix works?

It works.

> 
> We should really look into this memory that is reserved by memblock
> but Linux is not aware of physical backing, so far I know that only
> x86 can have such scenarios, so we should really see if the problem
> can be addressed on x86 platform. It would be very nice if we could
> enforce inside memblock to reserve only memory that has real physical
> backing.

Will resend with your suggestion along with patch log changes.

> 
> Thank you,
> Pavel

Thanks
Dave