linux-kernel - Re: [PATCH v4 5/5] mm: Fix memory_failure() handling of dax-namespace metadata

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 14 Jan 2021 02:25:13 +0000
From:   HORIGUCHI NAOYA(堀口　直也) 
        <naoya.horiguchi@....com>
To:     Dan Williams <dan.j.williams@...el.com>
CC:     "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        David Hildenbrand <david@...hat.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 5/5] mm: Fix memory_failure() handling of dax-namespace
 metadata

On Wed, Jan 13, 2021 at 04:43:37PM -0800, Dan Williams wrote:
> Given 'struct dev_pagemap' spans both data pages and metadata pages be
> careful to consult the altmap if present to delineate metadata. In fact
> the pfn_first() helper already identifies the first valid data pfn, so
> export that helper for other code paths via pgmap_pfn_valid().
> 
> Other usage of get_dev_pagemap() are not a concern because those are
> operating on known data pfns having been looked up by get_user_pages().
> I.e. metadata pfns are never user mapped.
> 
> Fixes: 6100e34b2526 ("mm, memory_failure: Teach memory_failure() about dev_pagemap pages")
> Cc: Naoya Horiguchi <naoya.horiguchi@....com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Reported-by: David Hildenbrand <david@...hat.com>
> Reviewed-by: David Hildenbrand <david@...hat.com>
> Signed-off-by: Dan Williams <dan.j.williams@...el.com>

Looks fine to me.

Reviewed-by: Naoya Horiguchi <naoya.horiguchi@....com>