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] [day] [month] [year] [list]
Message-ID: <20160930063807.GB19118@dhcp22.suse.cz>
Date:   Fri, 30 Sep 2016 08:38:08 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Mike Kravetz <mike.kravetz@...cle.com>
Cc:     Gerald Schaefer <gerald.schaefer@...ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        "Aneesh Kumar K . V" <aneesh.kumar@...ux.vnet.ibm.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Rui Teng <rui.teng@...ux.vnet.ibm.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH v4 2/3] mm/hugetlb: check for reserved hugepages during
 memory offline

On Thu 29-09-16 10:09:37, Mike Kravetz wrote:
> On 09/29/2016 05:30 AM, Michal Hocko wrote:
> > On Mon 26-09-16 19:28:10, Gerald Schaefer wrote:
[...]
> >> Fix this by adding a return value to dissolve_free_huge_pages() and
> >> checking h->free_huge_pages vs. h->resv_huge_pages. Note that this may
> >> lead to the situation where dissolve_free_huge_page() returns an error
> >> and all free hugepages that were dissolved before that error are lost,
> >> while the memory block still cannot be set offline.
> > 
> > Hmm, OK offline failure is certainly a better option than an application
> > failure.
> 
> I agree.
> 
> However, if the reason for the offline is that a dimm within the huge page
> is starting to fail, then one could make an argument that forced offline of
> the huge page would be more desirable.  We really don't know the reason for
> the offline.  So, I think the approach of this patch is best.

I though that memory which was already reported to be faulty would be
marked HWPoison and removed from the allocator. But it's been quite some
time since I've looked in that area...
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ