2019-05-29 14:12:37 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2009-09-16 09:50:15 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2008, 2009 Intel Corporation
|
|
|
|
* Authors: Andi Kleen, Fengguang Wu
|
|
|
|
*
|
|
|
|
* High level machine check handler. Handles pages reported by the
|
2010-09-27 21:09:51 +00:00
|
|
|
* hardware as being corrupted usually due to a multi-bit ECC memory or cache
|
2009-09-16 09:50:15 +00:00
|
|
|
* failure.
|
mm: ptep_get() conversion
Convert all instances of direct pte_t* dereferencing to instead use
ptep_get() helper. This means that by default, the accesses change from a
C dereference to a READ_ONCE(). This is technically the correct thing to
do since where pgtables are modified by HW (for access/dirty) they are
volatile and therefore we should always ensure READ_ONCE() semantics.
But more importantly, by always using the helper, it can be overridden by
the architecture to fully encapsulate the contents of the pte. Arch code
is deliberately not converted, as the arch code knows best. It is
intended that arch code (arm64) will override the default with its own
implementation that can (e.g.) hide certain bits from the core code, or
determine young/dirty status by mixing in state from another source.
Conversion was done using Coccinelle:
----
// $ make coccicheck \
// COCCI=ptepget.cocci \
// SPFLAGS="--include-headers" \
// MODE=patch
virtual patch
@ depends on patch @
pte_t *v;
@@
- *v
+ ptep_get(v)
----
Then reviewed and hand-edited to avoid multiple unnecessary calls to
ptep_get(), instead opting to store the result of a single call in a
variable, where it is correct to do so. This aims to negate any cost of
READ_ONCE() and will benefit arch-overrides that may be more complex.
Included is a fix for an issue in an earlier version of this patch that
was pointed out by kernel test robot. The issue arose because config
MMU=n elides definition of the ptep helper functions, including
ptep_get(). HUGETLB_PAGE=n configs still define a simple
huge_ptep_clear_flush() for linking purposes, which dereferences the ptep.
So when both configs are disabled, this caused a build error because
ptep_get() is not defined. Fix by continuing to do a direct dereference
when MMU=n. This is safe because for this config the arch code cannot be
trying to virtualize the ptes because none of the ptep helpers are
defined.
Link: https://lkml.kernel.org/r/20230612151545.3317766-4-ryan.roberts@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202305120142.yXsNEo6H-lkp@intel.com/
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport (IBM) <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: SeongJae Park <sj@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-12 15:15:45 +00:00
|
|
|
*
|
2010-09-27 21:09:51 +00:00
|
|
|
* In addition there is a "soft offline" entry point that allows stop using
|
|
|
|
* not-yet-corrupted-by-suspicious pages without killing anything.
|
2009-09-16 09:50:15 +00:00
|
|
|
*
|
|
|
|
* Handles page cache pages in various states. The tricky part
|
mm: ptep_get() conversion
Convert all instances of direct pte_t* dereferencing to instead use
ptep_get() helper. This means that by default, the accesses change from a
C dereference to a READ_ONCE(). This is technically the correct thing to
do since where pgtables are modified by HW (for access/dirty) they are
volatile and therefore we should always ensure READ_ONCE() semantics.
But more importantly, by always using the helper, it can be overridden by
the architecture to fully encapsulate the contents of the pte. Arch code
is deliberately not converted, as the arch code knows best. It is
intended that arch code (arm64) will override the default with its own
implementation that can (e.g.) hide certain bits from the core code, or
determine young/dirty status by mixing in state from another source.
Conversion was done using Coccinelle:
----
// $ make coccicheck \
// COCCI=ptepget.cocci \
// SPFLAGS="--include-headers" \
// MODE=patch
virtual patch
@ depends on patch @
pte_t *v;
@@
- *v
+ ptep_get(v)
----
Then reviewed and hand-edited to avoid multiple unnecessary calls to
ptep_get(), instead opting to store the result of a single call in a
variable, where it is correct to do so. This aims to negate any cost of
READ_ONCE() and will benefit arch-overrides that may be more complex.
Included is a fix for an issue in an earlier version of this patch that
was pointed out by kernel test robot. The issue arose because config
MMU=n elides definition of the ptep helper functions, including
ptep_get(). HUGETLB_PAGE=n configs still define a simple
huge_ptep_clear_flush() for linking purposes, which dereferences the ptep.
So when both configs are disabled, this caused a build error because
ptep_get() is not defined. Fix by continuing to do a direct dereference
when MMU=n. This is safe because for this config the arch code cannot be
trying to virtualize the ptes because none of the ptep helpers are
defined.
Link: https://lkml.kernel.org/r/20230612151545.3317766-4-ryan.roberts@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202305120142.yXsNEo6H-lkp@intel.com/
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport (IBM) <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: SeongJae Park <sj@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-12 15:15:45 +00:00
|
|
|
* here is that we can access any page asynchronously in respect to
|
|
|
|
* other VM users, because memory failures could happen anytime and
|
|
|
|
* anywhere. This could violate some of their assumptions. This is why
|
|
|
|
* this code has to be extremely careful. Generally it tries to use
|
|
|
|
* normal locking rules, as in get the standard locks, even if that means
|
2010-09-27 21:09:51 +00:00
|
|
|
* the error handling takes potentially a long time.
|
2015-06-24 23:56:02 +00:00
|
|
|
*
|
|
|
|
* It can be very tempting to add handling for obscure cases here.
|
|
|
|
* In general any code for handling new cases should only be added iff:
|
|
|
|
* - You know how to test it.
|
|
|
|
* - You have a test that can be added to mce-test
|
|
|
|
* https://git.kernel.org/cgit/utils/cpu/mce/mce-test.git/
|
|
|
|
* - The case actually shows up as a frequent (top 10) page state in
|
2023-01-03 18:07:52 +00:00
|
|
|
* tools/mm/page-types when running a real workload.
|
mm: ptep_get() conversion
Convert all instances of direct pte_t* dereferencing to instead use
ptep_get() helper. This means that by default, the accesses change from a
C dereference to a READ_ONCE(). This is technically the correct thing to
do since where pgtables are modified by HW (for access/dirty) they are
volatile and therefore we should always ensure READ_ONCE() semantics.
But more importantly, by always using the helper, it can be overridden by
the architecture to fully encapsulate the contents of the pte. Arch code
is deliberately not converted, as the arch code knows best. It is
intended that arch code (arm64) will override the default with its own
implementation that can (e.g.) hide certain bits from the core code, or
determine young/dirty status by mixing in state from another source.
Conversion was done using Coccinelle:
----
// $ make coccicheck \
// COCCI=ptepget.cocci \
// SPFLAGS="--include-headers" \
// MODE=patch
virtual patch
@ depends on patch @
pte_t *v;
@@
- *v
+ ptep_get(v)
----
Then reviewed and hand-edited to avoid multiple unnecessary calls to
ptep_get(), instead opting to store the result of a single call in a
variable, where it is correct to do so. This aims to negate any cost of
READ_ONCE() and will benefit arch-overrides that may be more complex.
Included is a fix for an issue in an earlier version of this patch that
was pointed out by kernel test robot. The issue arose because config
MMU=n elides definition of the ptep helper functions, including
ptep_get(). HUGETLB_PAGE=n configs still define a simple
huge_ptep_clear_flush() for linking purposes, which dereferences the ptep.
So when both configs are disabled, this caused a build error because
ptep_get() is not defined. Fix by continuing to do a direct dereference
when MMU=n. This is safe because for this config the arch code cannot be
trying to virtualize the ptes because none of the ptep helpers are
defined.
Link: https://lkml.kernel.org/r/20230612151545.3317766-4-ryan.roberts@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202305120142.yXsNEo6H-lkp@intel.com/
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport (IBM) <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: SeongJae Park <sj@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-12 15:15:45 +00:00
|
|
|
*
|
2010-09-27 21:09:51 +00:00
|
|
|
* There are several operations here with exponential complexity because
|
mm: ptep_get() conversion
Convert all instances of direct pte_t* dereferencing to instead use
ptep_get() helper. This means that by default, the accesses change from a
C dereference to a READ_ONCE(). This is technically the correct thing to
do since where pgtables are modified by HW (for access/dirty) they are
volatile and therefore we should always ensure READ_ONCE() semantics.
But more importantly, by always using the helper, it can be overridden by
the architecture to fully encapsulate the contents of the pte. Arch code
is deliberately not converted, as the arch code knows best. It is
intended that arch code (arm64) will override the default with its own
implementation that can (e.g.) hide certain bits from the core code, or
determine young/dirty status by mixing in state from another source.
Conversion was done using Coccinelle:
----
// $ make coccicheck \
// COCCI=ptepget.cocci \
// SPFLAGS="--include-headers" \
// MODE=patch
virtual patch
@ depends on patch @
pte_t *v;
@@
- *v
+ ptep_get(v)
----
Then reviewed and hand-edited to avoid multiple unnecessary calls to
ptep_get(), instead opting to store the result of a single call in a
variable, where it is correct to do so. This aims to negate any cost of
READ_ONCE() and will benefit arch-overrides that may be more complex.
Included is a fix for an issue in an earlier version of this patch that
was pointed out by kernel test robot. The issue arose because config
MMU=n elides definition of the ptep helper functions, including
ptep_get(). HUGETLB_PAGE=n configs still define a simple
huge_ptep_clear_flush() for linking purposes, which dereferences the ptep.
So when both configs are disabled, this caused a build error because
ptep_get() is not defined. Fix by continuing to do a direct dereference
when MMU=n. This is safe because for this config the arch code cannot be
trying to virtualize the ptes because none of the ptep helpers are
defined.
Link: https://lkml.kernel.org/r/20230612151545.3317766-4-ryan.roberts@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202305120142.yXsNEo6H-lkp@intel.com/
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport (IBM) <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: SeongJae Park <sj@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-12 15:15:45 +00:00
|
|
|
* of unsuitable VM data structures. For example the operation to map back
|
|
|
|
* from RMAP chains to processes has to walk the complete process list and
|
2010-09-27 21:09:51 +00:00
|
|
|
* has non linear complexity with the number. But since memory corruptions
|
mm: ptep_get() conversion
Convert all instances of direct pte_t* dereferencing to instead use
ptep_get() helper. This means that by default, the accesses change from a
C dereference to a READ_ONCE(). This is technically the correct thing to
do since where pgtables are modified by HW (for access/dirty) they are
volatile and therefore we should always ensure READ_ONCE() semantics.
But more importantly, by always using the helper, it can be overridden by
the architecture to fully encapsulate the contents of the pte. Arch code
is deliberately not converted, as the arch code knows best. It is
intended that arch code (arm64) will override the default with its own
implementation that can (e.g.) hide certain bits from the core code, or
determine young/dirty status by mixing in state from another source.
Conversion was done using Coccinelle:
----
// $ make coccicheck \
// COCCI=ptepget.cocci \
// SPFLAGS="--include-headers" \
// MODE=patch
virtual patch
@ depends on patch @
pte_t *v;
@@
- *v
+ ptep_get(v)
----
Then reviewed and hand-edited to avoid multiple unnecessary calls to
ptep_get(), instead opting to store the result of a single call in a
variable, where it is correct to do so. This aims to negate any cost of
READ_ONCE() and will benefit arch-overrides that may be more complex.
Included is a fix for an issue in an earlier version of this patch that
was pointed out by kernel test robot. The issue arose because config
MMU=n elides definition of the ptep helper functions, including
ptep_get(). HUGETLB_PAGE=n configs still define a simple
huge_ptep_clear_flush() for linking purposes, which dereferences the ptep.
So when both configs are disabled, this caused a build error because
ptep_get() is not defined. Fix by continuing to do a direct dereference
when MMU=n. This is safe because for this config the arch code cannot be
trying to virtualize the ptes because none of the ptep helpers are
defined.
Link: https://lkml.kernel.org/r/20230612151545.3317766-4-ryan.roberts@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202305120142.yXsNEo6H-lkp@intel.com/
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport (IBM) <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: SeongJae Park <sj@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-12 15:15:45 +00:00
|
|
|
* are rare we hope to get away with this. This avoids impacting the core
|
2010-09-27 21:09:51 +00:00
|
|
|
* VM.
|
2009-09-16 09:50:15 +00:00
|
|
|
*/
|
2022-07-26 08:10:46 +00:00
|
|
|
|
|
|
|
#define pr_fmt(fmt) "Memory failure: " fmt
|
|
|
|
|
2009-09-16 09:50:15 +00:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/page-flags.h>
|
2017-02-08 17:51:30 +00:00
|
|
|
#include <linux/sched/signal.h>
|
2017-02-08 17:51:36 +00:00
|
|
|
#include <linux/sched/task.h>
|
2021-11-05 20:35:30 +00:00
|
|
|
#include <linux/dax.h>
|
2009-10-13 14:02:11 +00:00
|
|
|
#include <linux/ksm.h>
|
2009-09-16 09:50:15 +00:00
|
|
|
#include <linux/rmap.h>
|
2011-05-26 20:00:52 +00:00
|
|
|
#include <linux/export.h>
|
2009-09-16 09:50:15 +00:00
|
|
|
#include <linux/pagemap.h>
|
|
|
|
#include <linux/swap.h>
|
|
|
|
#include <linux/backing-dev.h>
|
2009-12-16 11:20:00 +00:00
|
|
|
#include <linux/migrate.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 08:04:11 +00:00
|
|
|
#include <linux/slab.h>
|
2010-05-31 06:28:19 +00:00
|
|
|
#include <linux/swapops.h>
|
2010-05-28 00:29:17 +00:00
|
|
|
#include <linux/hugetlb.h>
|
2010-12-02 22:31:19 +00:00
|
|
|
#include <linux/memory_hotplug.h>
|
2011-06-15 22:08:48 +00:00
|
|
|
#include <linux/mm_inline.h>
|
2018-07-14 04:50:21 +00:00
|
|
|
#include <linux/memremap.h>
|
2011-07-13 05:14:27 +00:00
|
|
|
#include <linux/kfifo.h>
|
2015-11-06 02:47:26 +00:00
|
|
|
#include <linux/ratelimit.h>
|
2021-06-29 02:43:14 +00:00
|
|
|
#include <linux/pagewalk.h>
|
2022-01-14 22:05:19 +00:00
|
|
|
#include <linux/shmem_fs.h>
|
2023-03-20 07:40:10 +00:00
|
|
|
#include <linux/sysctl.h>
|
2022-05-10 01:20:47 +00:00
|
|
|
#include "swap.h"
|
2009-09-16 09:50:15 +00:00
|
|
|
#include "internal.h"
|
2015-06-24 23:57:36 +00:00
|
|
|
#include "ras/ras_event.h"
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2023-03-20 07:40:10 +00:00
|
|
|
static int sysctl_memory_failure_early_kill __read_mostly;
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2023-03-20 07:40:10 +00:00
|
|
|
static int sysctl_memory_failure_recovery __read_mostly = 1;
|
2009-09-16 09:50:15 +00:00
|
|
|
|
mm/memory-failure: userspace controls soft-offlining pages
Correctable memory errors are very common on servers with large amount of
memory, and are corrected by ECC. Soft offline is kernel's additional
recovery handling for memory pages having (excessive) corrected memory
errors. Impacted page is migrated to a healthy page if inuse; the
original page is discarded for any future use.
The actual policy on whether (and when) to soft offline should be
maintained by userspace, especially in case of an 1G HugeTLB page.
Soft-offline dissolves the HugeTLB page, either in-use or free, into
chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If
userspace has not acknowledged such behavior, it may be surprised when
later failed to mmap hugepages due to lack of hugepages. In case of a
transparent hugepage, it will be split into 4K pages as well; userspace
will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of
corrected memory errors sounds very costly and kernel better not doing
under the hood. But today there are at least 2 such cases doing so:
1. when GHES driver sees both GHES_SEV_CORRECTED and
CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
2. RAS Correctable Errors Collector counts correctable errors per
PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed
by kernel's memory failure recovery.
This commit gives userspace the control of softofflining any page: kernel
only soft offlines raw page / transparent hugepage / HugeTLB hugepage if
userspace has agreed to. The interface to userspace is a new sysctl at
/proc/sys/vm/enable_soft_offline. By default its value is set to 1 to
preserve existing behavior in kernel. When set to 0, soft-offline (e.g.
MADV_SOFT_OFFLINE) will fail with EOPNOTSUPP.
[jiaqiyan@google.com: v7]
Link: https://lkml.kernel.org/r/20240628205958.2845610-3-jiaqiyan@google.com
Link: https://lkml.kernel.org/r/20240626050818.2277273-3-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Lance Yang <ioworker0@gmail.com>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-26 05:08:16 +00:00
|
|
|
static int sysctl_enable_soft_offline __read_mostly = 1;
|
|
|
|
|
2013-02-23 00:34:02 +00:00
|
|
|
atomic_long_t num_poisoned_pages __read_mostly = ATOMIC_LONG_INIT(0);
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2022-06-15 09:32:09 +00:00
|
|
|
static bool hw_memory_failure __read_mostly = false;
|
|
|
|
|
2023-07-13 00:18:31 +00:00
|
|
|
static DEFINE_MUTEX(mf_mutex);
|
|
|
|
|
2023-06-26 11:43:43 +00:00
|
|
|
void num_poisoned_pages_inc(unsigned long pfn)
|
2022-10-24 06:20:10 +00:00
|
|
|
{
|
|
|
|
atomic_long_inc(&num_poisoned_pages);
|
2022-10-24 06:20:12 +00:00
|
|
|
memblk_nr_poison_inc(pfn);
|
2022-10-24 06:20:10 +00:00
|
|
|
}
|
|
|
|
|
2023-06-26 11:43:43 +00:00
|
|
|
void num_poisoned_pages_sub(unsigned long pfn, long i)
|
2022-10-24 06:20:10 +00:00
|
|
|
{
|
|
|
|
atomic_long_sub(i, &num_poisoned_pages);
|
2022-10-24 06:20:12 +00:00
|
|
|
if (pfn != -1UL)
|
|
|
|
memblk_nr_poison_sub(pfn, i);
|
2022-10-24 06:20:10 +00:00
|
|
|
}
|
|
|
|
|
mm: memory-failure: add memory failure stats to sysfs
Patch series "Introduce per NUMA node memory error statistics", v2.
Background
==========
In the RFC for Kernel Support of Memory Error Detection [1], one advantage
of software-based scanning over hardware patrol scrubber is the ability to
make statistics visible to system administrators. The statistics include
2 categories:
* Memory error statistics, for example, how many memory error are
encountered, how many of them are recovered by the kernel. Note these
memory errors are non-fatal to kernel: during the machine check
exception (MCE) handling kernel already classified MCE's severity to be
unnecessary to panic (but either action required or optional).
* Scanner statistics, for example how many times the scanner have fully
scanned a NUMA node, how many errors are first detected by the scanner.
The memory error statistics are useful to userspace and actually not
specific to scanner detected memory errors, and are the focus of this
patchset.
Motivation
==========
Memory error stats are important to userspace but insufficient in kernel
today. Datacenter administrators can better monitor a machine's memory
health with the visible stats. For example, while memory errors are
inevitable on servers with 10+ TB memory, starting server maintenance when
there are only 1~2 recovered memory errors could be overreacting; in cloud
production environment maintenance usually means live migrate all the
workload running on the server and this usually causes nontrivial
disruption to the customer. Providing insight into the scope of memory
errors on a system helps to determine the appropriate follow-up action.
In addition, the kernel's existing memory error stats need to be
standardized so that userspace can reliably count on their usefulness.
Today kernel provides following memory error info to userspace, but they
are not sufficient or have disadvantages:
* HardwareCorrupted in /proc/meminfo: number of bytes poisoned in total,
not per NUMA node stats though
* ras:memory_failure_event: only available after explicitly enabled
* /dev/mcelog provides many useful info about the MCEs, but doesn't
capture how memory_failure recovered memory MCEs
* kernel logs: userspace needs to process log text
Exposing memory error stats is also a good start for the in-kernel memory
error detector. Today the data source of memory error stats are either
direct memory error consumption, or hardware patrol scrubber detection
(either signaled as UCNA or SRAO). Once in-kernel memory scanner is
implemented, it will be the main source as it is usually configured to
scan memory DIMMs constantly and faster than hardware patrol scrubber.
How Implemented
===============
As Naoya pointed out [2], exposing memory error statistics to userspace is
useful independent of software or hardware scanner. Therefore we
implement the memory error statistics independent of the in-kernel memory
error detector. It exposes the following per NUMA node memory error
counters:
/sys/devices/system/node/node${X}/memory_failure/total
/sys/devices/system/node/node${X}/memory_failure/recovered
/sys/devices/system/node/node${X}/memory_failure/ignored
/sys/devices/system/node/node${X}/memory_failure/failed
/sys/devices/system/node/node${X}/memory_failure/delayed
These counters describe how many raw pages are poisoned and after the
attempted recoveries by the kernel, their resolutions: how many are
recovered, ignored, failed, or delayed respectively. This approach can be
easier to extend for future use cases than /proc/meminfo, trace event, and
log. The following math holds for the statistics:
* total = recovered + ignored + failed + delayed
These memory error stats are reset during machine boot.
The 1st commit introduces these sysfs entries. The 2nd commit populates
memory error stats every time memory_failure attempts memory error
recovery. The 3rd commit adds documentations for introduced stats.
[1] https://lore.kernel.org/linux-mm/7E670362-C29E-4626-B546-26530D54F937@gmail.com/T/#mc22959244f5388891c523882e61163c6e4d703af
[2] https://lore.kernel.org/linux-mm/7E670362-C29E-4626-B546-26530D54F937@gmail.com/T/#m52d8d7a333d8536bd7ce74253298858b1c0c0ac6
This patch (of 3):
Today kernel provides following memory error info to userspace, but each
has its own disadvantage
* HardwareCorrupted in /proc/meminfo: number of bytes poisoned in total,
not per NUMA node stats though
* ras:memory_failure_event: only available after explicitly enabled
* /dev/mcelog provides many useful info about the MCEs, but
doesn't capture how memory_failure recovered memory MCEs
* kernel logs: userspace needs to process log text
Exposes per NUMA node memory error stats as sysfs entries:
/sys/devices/system/node/node${X}/memory_failure/total
/sys/devices/system/node/node${X}/memory_failure/recovered
/sys/devices/system/node/node${X}/memory_failure/ignored
/sys/devices/system/node/node${X}/memory_failure/failed
/sys/devices/system/node/node${X}/memory_failure/delayed
These counters describe how many raw pages are poisoned and after the
attempted recoveries by the kernel, their resolutions: how many are
recovered, ignored, failed, or delayed respectively. The following math
holds for the statistics:
* total = recovered + ignored + failed + delayed
Link: https://lkml.kernel.org/r/20230120034622.2698268-1-jiaqiyan@google.com
Link: https://lkml.kernel.org/r/20230120034622.2698268-2-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-01-20 03:46:20 +00:00
|
|
|
/**
|
|
|
|
* MF_ATTR_RO - Create sysfs entry for each memory failure statistics.
|
|
|
|
* @_name: name of the file in the per NUMA sysfs directory.
|
|
|
|
*/
|
|
|
|
#define MF_ATTR_RO(_name) \
|
|
|
|
static ssize_t _name##_show(struct device *dev, \
|
|
|
|
struct device_attribute *attr, \
|
|
|
|
char *buf) \
|
|
|
|
{ \
|
|
|
|
struct memory_failure_stats *mf_stats = \
|
|
|
|
&NODE_DATA(dev->id)->mf_stats; \
|
|
|
|
return sprintf(buf, "%lu\n", mf_stats->_name); \
|
|
|
|
} \
|
|
|
|
static DEVICE_ATTR_RO(_name)
|
|
|
|
|
|
|
|
MF_ATTR_RO(total);
|
|
|
|
MF_ATTR_RO(ignored);
|
|
|
|
MF_ATTR_RO(failed);
|
|
|
|
MF_ATTR_RO(delayed);
|
|
|
|
MF_ATTR_RO(recovered);
|
|
|
|
|
|
|
|
static struct attribute *memory_failure_attr[] = {
|
|
|
|
&dev_attr_total.attr,
|
|
|
|
&dev_attr_ignored.attr,
|
|
|
|
&dev_attr_failed.attr,
|
|
|
|
&dev_attr_delayed.attr,
|
|
|
|
&dev_attr_recovered.attr,
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
const struct attribute_group memory_failure_attr_group = {
|
|
|
|
.name = "memory_failure",
|
|
|
|
.attrs = memory_failure_attr,
|
|
|
|
};
|
|
|
|
|
2023-03-20 07:40:10 +00:00
|
|
|
static struct ctl_table memory_failure_table[] = {
|
|
|
|
{
|
|
|
|
.procname = "memory_failure_early_kill",
|
|
|
|
.data = &sysctl_memory_failure_early_kill,
|
|
|
|
.maxlen = sizeof(sysctl_memory_failure_early_kill),
|
|
|
|
.mode = 0644,
|
|
|
|
.proc_handler = proc_dointvec_minmax,
|
|
|
|
.extra1 = SYSCTL_ZERO,
|
|
|
|
.extra2 = SYSCTL_ONE,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.procname = "memory_failure_recovery",
|
|
|
|
.data = &sysctl_memory_failure_recovery,
|
|
|
|
.maxlen = sizeof(sysctl_memory_failure_recovery),
|
|
|
|
.mode = 0644,
|
|
|
|
.proc_handler = proc_dointvec_minmax,
|
|
|
|
.extra1 = SYSCTL_ZERO,
|
|
|
|
.extra2 = SYSCTL_ONE,
|
|
|
|
},
|
mm/memory-failure: userspace controls soft-offlining pages
Correctable memory errors are very common on servers with large amount of
memory, and are corrected by ECC. Soft offline is kernel's additional
recovery handling for memory pages having (excessive) corrected memory
errors. Impacted page is migrated to a healthy page if inuse; the
original page is discarded for any future use.
The actual policy on whether (and when) to soft offline should be
maintained by userspace, especially in case of an 1G HugeTLB page.
Soft-offline dissolves the HugeTLB page, either in-use or free, into
chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If
userspace has not acknowledged such behavior, it may be surprised when
later failed to mmap hugepages due to lack of hugepages. In case of a
transparent hugepage, it will be split into 4K pages as well; userspace
will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of
corrected memory errors sounds very costly and kernel better not doing
under the hood. But today there are at least 2 such cases doing so:
1. when GHES driver sees both GHES_SEV_CORRECTED and
CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
2. RAS Correctable Errors Collector counts correctable errors per
PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed
by kernel's memory failure recovery.
This commit gives userspace the control of softofflining any page: kernel
only soft offlines raw page / transparent hugepage / HugeTLB hugepage if
userspace has agreed to. The interface to userspace is a new sysctl at
/proc/sys/vm/enable_soft_offline. By default its value is set to 1 to
preserve existing behavior in kernel. When set to 0, soft-offline (e.g.
MADV_SOFT_OFFLINE) will fail with EOPNOTSUPP.
[jiaqiyan@google.com: v7]
Link: https://lkml.kernel.org/r/20240628205958.2845610-3-jiaqiyan@google.com
Link: https://lkml.kernel.org/r/20240626050818.2277273-3-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Lance Yang <ioworker0@gmail.com>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-26 05:08:16 +00:00
|
|
|
{
|
|
|
|
.procname = "enable_soft_offline",
|
|
|
|
.data = &sysctl_enable_soft_offline,
|
|
|
|
.maxlen = sizeof(sysctl_enable_soft_offline),
|
|
|
|
.mode = 0644,
|
|
|
|
.proc_handler = proc_dointvec_minmax,
|
|
|
|
.extra1 = SYSCTL_ZERO,
|
|
|
|
.extra2 = SYSCTL_ONE,
|
|
|
|
}
|
2023-03-20 07:40:10 +00:00
|
|
|
};
|
|
|
|
|
2022-07-14 04:24:18 +00:00
|
|
|
/*
|
|
|
|
* Return values:
|
|
|
|
* 1: the page is dissolved (if needed) and taken off from buddy,
|
|
|
|
* 0: the page is dissolved (if needed) and not taken off from buddy,
|
|
|
|
* < 0: failed to dissolve.
|
|
|
|
*/
|
|
|
|
static int __page_handle_poison(struct page *page)
|
2021-07-01 01:48:38 +00:00
|
|
|
{
|
2021-09-02 21:58:40 +00:00
|
|
|
int ret;
|
2021-07-01 01:48:38 +00:00
|
|
|
|
mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled
When I did hard offline test with hugetlb pages, below deadlock occurs:
======================================================
WARNING: possible circular locking dependency detected
6.8.0-11409-gf6cef5f8c37f #1 Not tainted
------------------------------------------------------
bash/46904 is trying to acquire lock:
ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60
but task is already holding lock:
ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (pcp_batch_high_lock){+.+.}-{3:3}:
__mutex_lock+0x6c/0x770
page_alloc_cpu_online+0x3c/0x70
cpuhp_invoke_callback+0x397/0x5f0
__cpuhp_invoke_callback_range+0x71/0xe0
_cpu_up+0xeb/0x210
cpu_up+0x91/0xe0
cpuhp_bringup_mask+0x49/0xb0
bringup_nonboot_cpus+0xb7/0xe0
smp_init+0x25/0xa0
kernel_init_freeable+0x15f/0x3e0
kernel_init+0x15/0x1b0
ret_from_fork+0x2f/0x50
ret_from_fork_asm+0x1a/0x30
-> #0 (cpu_hotplug_lock){++++}-{0:0}:
__lock_acquire+0x1298/0x1cd0
lock_acquire+0xc0/0x2b0
cpus_read_lock+0x2a/0xc0
static_key_slow_dec+0x16/0x60
__hugetlb_vmemmap_restore_folio+0x1b9/0x200
dissolve_free_huge_page+0x211/0x260
__page_handle_poison+0x45/0xc0
memory_failure+0x65e/0xc70
hard_offline_page_store+0x55/0xa0
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x387/0x550
ksys_write+0x64/0xe0
do_syscall_64+0xca/0x1e0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(pcp_batch_high_lock);
lock(cpu_hotplug_lock);
lock(pcp_batch_high_lock);
rlock(cpu_hotplug_lock);
*** DEADLOCK ***
5 locks held by bash/46904:
#0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0
#1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0
#2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0
#3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70
#4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
stack backtrace:
CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x68/0xa0
check_noncircular+0x129/0x140
__lock_acquire+0x1298/0x1cd0
lock_acquire+0xc0/0x2b0
cpus_read_lock+0x2a/0xc0
static_key_slow_dec+0x16/0x60
__hugetlb_vmemmap_restore_folio+0x1b9/0x200
dissolve_free_huge_page+0x211/0x260
__page_handle_poison+0x45/0xc0
memory_failure+0x65e/0xc70
hard_offline_page_store+0x55/0xa0
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x387/0x550
ksys_write+0x64/0xe0
do_syscall_64+0xca/0x1e0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7fc862314887
Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
RSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887
RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001
RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c
R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00
In short, below scene breaks the lock dependency chain:
memory_failure
__page_handle_poison
zone_pcp_disable -- lock(pcp_batch_high_lock)
dissolve_free_huge_page
__hugetlb_vmemmap_restore_folio
static_key_slow_dec
cpus_read_lock -- rlock(cpu_hotplug_lock)
Fix this by calling drain_all_pages() instead.
This issue won't occur until commit a6b40850c442 ("mm: hugetlb: replace
hugetlb_free_vmemmap_enabled with a static_key"). As it introduced
rlock(cpu_hotplug_lock) in dissolve_free_huge_page() code path while
lock(pcp_batch_high_lock) is already in the __page_handle_poison().
[linmiaohe@huawei.com: extend comment per Oscar]
[akpm@linux-foundation.org: reflow block comment]
Link: https://lkml.kernel.org/r/20240407085456.2798193-1-linmiaohe@huawei.com
Fixes: a6b40850c442 ("mm: hugetlb: replace hugetlb_free_vmemmap_enabled with a static_key")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Acked-by: Oscar Salvador <osalvador@suse.de>
Reviewed-by: Jane Chu <jane.chu@oracle.com>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-04-07 08:54:56 +00:00
|
|
|
/*
|
|
|
|
* zone_pcp_disable() can't be used here. It will
|
2024-04-11 16:47:56 +00:00
|
|
|
* hold pcp_batch_high_lock and dissolve_free_hugetlb_folio() might hold
|
mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled
When I did hard offline test with hugetlb pages, below deadlock occurs:
======================================================
WARNING: possible circular locking dependency detected
6.8.0-11409-gf6cef5f8c37f #1 Not tainted
------------------------------------------------------
bash/46904 is trying to acquire lock:
ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60
but task is already holding lock:
ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (pcp_batch_high_lock){+.+.}-{3:3}:
__mutex_lock+0x6c/0x770
page_alloc_cpu_online+0x3c/0x70
cpuhp_invoke_callback+0x397/0x5f0
__cpuhp_invoke_callback_range+0x71/0xe0
_cpu_up+0xeb/0x210
cpu_up+0x91/0xe0
cpuhp_bringup_mask+0x49/0xb0
bringup_nonboot_cpus+0xb7/0xe0
smp_init+0x25/0xa0
kernel_init_freeable+0x15f/0x3e0
kernel_init+0x15/0x1b0
ret_from_fork+0x2f/0x50
ret_from_fork_asm+0x1a/0x30
-> #0 (cpu_hotplug_lock){++++}-{0:0}:
__lock_acquire+0x1298/0x1cd0
lock_acquire+0xc0/0x2b0
cpus_read_lock+0x2a/0xc0
static_key_slow_dec+0x16/0x60
__hugetlb_vmemmap_restore_folio+0x1b9/0x200
dissolve_free_huge_page+0x211/0x260
__page_handle_poison+0x45/0xc0
memory_failure+0x65e/0xc70
hard_offline_page_store+0x55/0xa0
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x387/0x550
ksys_write+0x64/0xe0
do_syscall_64+0xca/0x1e0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(pcp_batch_high_lock);
lock(cpu_hotplug_lock);
lock(pcp_batch_high_lock);
rlock(cpu_hotplug_lock);
*** DEADLOCK ***
5 locks held by bash/46904:
#0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0
#1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0
#2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0
#3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70
#4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
stack backtrace:
CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x68/0xa0
check_noncircular+0x129/0x140
__lock_acquire+0x1298/0x1cd0
lock_acquire+0xc0/0x2b0
cpus_read_lock+0x2a/0xc0
static_key_slow_dec+0x16/0x60
__hugetlb_vmemmap_restore_folio+0x1b9/0x200
dissolve_free_huge_page+0x211/0x260
__page_handle_poison+0x45/0xc0
memory_failure+0x65e/0xc70
hard_offline_page_store+0x55/0xa0
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x387/0x550
ksys_write+0x64/0xe0
do_syscall_64+0xca/0x1e0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7fc862314887
Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
RSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887
RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001
RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c
R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00
In short, below scene breaks the lock dependency chain:
memory_failure
__page_handle_poison
zone_pcp_disable -- lock(pcp_batch_high_lock)
dissolve_free_huge_page
__hugetlb_vmemmap_restore_folio
static_key_slow_dec
cpus_read_lock -- rlock(cpu_hotplug_lock)
Fix this by calling drain_all_pages() instead.
This issue won't occur until commit a6b40850c442 ("mm: hugetlb: replace
hugetlb_free_vmemmap_enabled with a static_key"). As it introduced
rlock(cpu_hotplug_lock) in dissolve_free_huge_page() code path while
lock(pcp_batch_high_lock) is already in the __page_handle_poison().
[linmiaohe@huawei.com: extend comment per Oscar]
[akpm@linux-foundation.org: reflow block comment]
Link: https://lkml.kernel.org/r/20240407085456.2798193-1-linmiaohe@huawei.com
Fixes: a6b40850c442 ("mm: hugetlb: replace hugetlb_free_vmemmap_enabled with a static_key")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Acked-by: Oscar Salvador <osalvador@suse.de>
Reviewed-by: Jane Chu <jane.chu@oracle.com>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-04-07 08:54:56 +00:00
|
|
|
* cpu_hotplug_lock via static_key_slow_dec() when hugetlb vmemmap
|
|
|
|
* optimization is enabled. This will break current lock dependency
|
|
|
|
* chain and leads to deadlock.
|
|
|
|
* Disabling pcp before dissolving the page was a deterministic
|
|
|
|
* approach because we made sure that those pages cannot end up in any
|
|
|
|
* PCP list. Draining PCP lists expels those pages to the buddy system,
|
|
|
|
* but nothing guarantees that those pages do not get back to a PCP
|
|
|
|
* queue if we need to refill those.
|
|
|
|
*/
|
2024-04-11 16:47:56 +00:00
|
|
|
ret = dissolve_free_hugetlb_folio(page_folio(page));
|
mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled
When I did hard offline test with hugetlb pages, below deadlock occurs:
======================================================
WARNING: possible circular locking dependency detected
6.8.0-11409-gf6cef5f8c37f #1 Not tainted
------------------------------------------------------
bash/46904 is trying to acquire lock:
ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60
but task is already holding lock:
ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (pcp_batch_high_lock){+.+.}-{3:3}:
__mutex_lock+0x6c/0x770
page_alloc_cpu_online+0x3c/0x70
cpuhp_invoke_callback+0x397/0x5f0
__cpuhp_invoke_callback_range+0x71/0xe0
_cpu_up+0xeb/0x210
cpu_up+0x91/0xe0
cpuhp_bringup_mask+0x49/0xb0
bringup_nonboot_cpus+0xb7/0xe0
smp_init+0x25/0xa0
kernel_init_freeable+0x15f/0x3e0
kernel_init+0x15/0x1b0
ret_from_fork+0x2f/0x50
ret_from_fork_asm+0x1a/0x30
-> #0 (cpu_hotplug_lock){++++}-{0:0}:
__lock_acquire+0x1298/0x1cd0
lock_acquire+0xc0/0x2b0
cpus_read_lock+0x2a/0xc0
static_key_slow_dec+0x16/0x60
__hugetlb_vmemmap_restore_folio+0x1b9/0x200
dissolve_free_huge_page+0x211/0x260
__page_handle_poison+0x45/0xc0
memory_failure+0x65e/0xc70
hard_offline_page_store+0x55/0xa0
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x387/0x550
ksys_write+0x64/0xe0
do_syscall_64+0xca/0x1e0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(pcp_batch_high_lock);
lock(cpu_hotplug_lock);
lock(pcp_batch_high_lock);
rlock(cpu_hotplug_lock);
*** DEADLOCK ***
5 locks held by bash/46904:
#0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0
#1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0
#2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0
#3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70
#4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
stack backtrace:
CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x68/0xa0
check_noncircular+0x129/0x140
__lock_acquire+0x1298/0x1cd0
lock_acquire+0xc0/0x2b0
cpus_read_lock+0x2a/0xc0
static_key_slow_dec+0x16/0x60
__hugetlb_vmemmap_restore_folio+0x1b9/0x200
dissolve_free_huge_page+0x211/0x260
__page_handle_poison+0x45/0xc0
memory_failure+0x65e/0xc70
hard_offline_page_store+0x55/0xa0
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x387/0x550
ksys_write+0x64/0xe0
do_syscall_64+0xca/0x1e0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7fc862314887
Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
RSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887
RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001
RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c
R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00
In short, below scene breaks the lock dependency chain:
memory_failure
__page_handle_poison
zone_pcp_disable -- lock(pcp_batch_high_lock)
dissolve_free_huge_page
__hugetlb_vmemmap_restore_folio
static_key_slow_dec
cpus_read_lock -- rlock(cpu_hotplug_lock)
Fix this by calling drain_all_pages() instead.
This issue won't occur until commit a6b40850c442 ("mm: hugetlb: replace
hugetlb_free_vmemmap_enabled with a static_key"). As it introduced
rlock(cpu_hotplug_lock) in dissolve_free_huge_page() code path while
lock(pcp_batch_high_lock) is already in the __page_handle_poison().
[linmiaohe@huawei.com: extend comment per Oscar]
[akpm@linux-foundation.org: reflow block comment]
Link: https://lkml.kernel.org/r/20240407085456.2798193-1-linmiaohe@huawei.com
Fixes: a6b40850c442 ("mm: hugetlb: replace hugetlb_free_vmemmap_enabled with a static_key")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Acked-by: Oscar Salvador <osalvador@suse.de>
Reviewed-by: Jane Chu <jane.chu@oracle.com>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-04-07 08:54:56 +00:00
|
|
|
if (!ret) {
|
|
|
|
drain_all_pages(page_zone(page));
|
2021-07-01 01:48:38 +00:00
|
|
|
ret = take_page_off_buddy(page);
|
mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled
When I did hard offline test with hugetlb pages, below deadlock occurs:
======================================================
WARNING: possible circular locking dependency detected
6.8.0-11409-gf6cef5f8c37f #1 Not tainted
------------------------------------------------------
bash/46904 is trying to acquire lock:
ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60
but task is already holding lock:
ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (pcp_batch_high_lock){+.+.}-{3:3}:
__mutex_lock+0x6c/0x770
page_alloc_cpu_online+0x3c/0x70
cpuhp_invoke_callback+0x397/0x5f0
__cpuhp_invoke_callback_range+0x71/0xe0
_cpu_up+0xeb/0x210
cpu_up+0x91/0xe0
cpuhp_bringup_mask+0x49/0xb0
bringup_nonboot_cpus+0xb7/0xe0
smp_init+0x25/0xa0
kernel_init_freeable+0x15f/0x3e0
kernel_init+0x15/0x1b0
ret_from_fork+0x2f/0x50
ret_from_fork_asm+0x1a/0x30
-> #0 (cpu_hotplug_lock){++++}-{0:0}:
__lock_acquire+0x1298/0x1cd0
lock_acquire+0xc0/0x2b0
cpus_read_lock+0x2a/0xc0
static_key_slow_dec+0x16/0x60
__hugetlb_vmemmap_restore_folio+0x1b9/0x200
dissolve_free_huge_page+0x211/0x260
__page_handle_poison+0x45/0xc0
memory_failure+0x65e/0xc70
hard_offline_page_store+0x55/0xa0
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x387/0x550
ksys_write+0x64/0xe0
do_syscall_64+0xca/0x1e0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(pcp_batch_high_lock);
lock(cpu_hotplug_lock);
lock(pcp_batch_high_lock);
rlock(cpu_hotplug_lock);
*** DEADLOCK ***
5 locks held by bash/46904:
#0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0
#1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0
#2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0
#3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70
#4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
stack backtrace:
CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x68/0xa0
check_noncircular+0x129/0x140
__lock_acquire+0x1298/0x1cd0
lock_acquire+0xc0/0x2b0
cpus_read_lock+0x2a/0xc0
static_key_slow_dec+0x16/0x60
__hugetlb_vmemmap_restore_folio+0x1b9/0x200
dissolve_free_huge_page+0x211/0x260
__page_handle_poison+0x45/0xc0
memory_failure+0x65e/0xc70
hard_offline_page_store+0x55/0xa0
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x387/0x550
ksys_write+0x64/0xe0
do_syscall_64+0xca/0x1e0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7fc862314887
Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
RSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887
RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001
RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c
R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00
In short, below scene breaks the lock dependency chain:
memory_failure
__page_handle_poison
zone_pcp_disable -- lock(pcp_batch_high_lock)
dissolve_free_huge_page
__hugetlb_vmemmap_restore_folio
static_key_slow_dec
cpus_read_lock -- rlock(cpu_hotplug_lock)
Fix this by calling drain_all_pages() instead.
This issue won't occur until commit a6b40850c442 ("mm: hugetlb: replace
hugetlb_free_vmemmap_enabled with a static_key"). As it introduced
rlock(cpu_hotplug_lock) in dissolve_free_huge_page() code path while
lock(pcp_batch_high_lock) is already in the __page_handle_poison().
[linmiaohe@huawei.com: extend comment per Oscar]
[akpm@linux-foundation.org: reflow block comment]
Link: https://lkml.kernel.org/r/20240407085456.2798193-1-linmiaohe@huawei.com
Fixes: a6b40850c442 ("mm: hugetlb: replace hugetlb_free_vmemmap_enabled with a static_key")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Acked-by: Oscar Salvador <osalvador@suse.de>
Reviewed-by: Jane Chu <jane.chu@oracle.com>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-04-07 08:54:56 +00:00
|
|
|
}
|
2021-07-01 01:48:38 +00:00
|
|
|
|
2022-07-14 04:24:18 +00:00
|
|
|
return ret;
|
2021-07-01 01:48:38 +00:00
|
|
|
}
|
|
|
|
|
2020-10-16 03:07:13 +00:00
|
|
|
static bool page_handle_poison(struct page *page, bool hugepage_or_freepage, bool release)
|
2020-10-16 03:07:05 +00:00
|
|
|
{
|
2020-10-16 03:07:13 +00:00
|
|
|
if (hugepage_or_freepage) {
|
|
|
|
/*
|
2024-04-11 16:47:56 +00:00
|
|
|
* Doing this check for free pages is also fine since
|
|
|
|
* dissolve_free_hugetlb_folio() returns 0 for non-hugetlb folios as well.
|
2020-10-16 03:07:13 +00:00
|
|
|
*/
|
2022-07-14 04:24:18 +00:00
|
|
|
if (__page_handle_poison(page) <= 0)
|
2020-10-16 03:07:13 +00:00
|
|
|
/*
|
|
|
|
* We could fail to take off the target page from buddy
|
2021-05-07 01:06:47 +00:00
|
|
|
* for example due to racy page allocation, but that's
|
2020-10-16 03:07:13 +00:00
|
|
|
* acceptable because soft-offlined page is not broken
|
|
|
|
* and if someone really want to use it, they should
|
|
|
|
* take it.
|
|
|
|
*/
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2020-10-16 03:07:05 +00:00
|
|
|
SetPageHWPoison(page);
|
mm,hwpoison: rework soft offline for in-use pages
This patch changes the way we set and handle in-use poisoned pages. Until
now, poisoned pages were released to the buddy allocator, trusting that
the checks that take place at allocation time would act as a safe net and
would skip that page.
This has proved to be wrong, as we got some pfn walkers out there, like
compaction, that all they care is the page to be in a buddy freelist.
Although this might not be the only user, having poisoned pages in the
buddy allocator seems a bad idea as we should only have free pages that
are ready and meant to be used as such.
Before explaining the taken approach, let us break down the kind of pages
we can soft offline.
- Anonymous THP (after the split, they end up being 4K pages)
- Hugetlb
- Order-0 pages (that can be either migrated or invalited)
* Normal pages (order-0 and anon-THP)
- If they are clean and unmapped page cache pages, we invalidate
then by means of invalidate_inode_page().
- If they are mapped/dirty, we do the isolate-and-migrate dance.
Either way, do not call put_page directly from those paths. Instead, we
keep the page and send it to page_handle_poison to perform the right
handling.
page_handle_poison sets the HWPoison flag and does the last put_page.
Down the chain, we placed a check for HWPoison page in
free_pages_prepare, that just skips any poisoned page, so those pages
do not end up in any pcplist/freelist.
After that, we set the refcount on the page to 1 and we increment
the poisoned pages counter.
If we see that the check in free_pages_prepare creates trouble, we can
always do what we do for free pages:
- wait until the page hits buddy's freelists
- take it off, and flag it
The downside of the above approach is that we could race with an
allocation, so by the time we want to take the page off the buddy, the
page has been already allocated so we cannot soft offline it.
But the user could always retry it.
* Hugetlb pages
- We isolate-and-migrate them
After the migration has been successful, we call dissolve_free_huge_page,
and we set HWPoison on the page if we succeed.
Hugetlb has a slightly different handling though.
While for non-hugetlb pages we cared about closing the race with an
allocation, doing so for hugetlb pages requires quite some additional
and intrusive code (we would need to hook in free_huge_page and some other
places).
So I decided to not make the code overly complicated and just fail
normally if the page we allocated in the meantime.
We can always build on top of this.
As a bonus, because of the way we handle now in-use pages, we no longer
need the put-as-isolation-migratetype dance, that was guarding for poisoned
pages to end up in pcplists.
Signed-off-by: Oscar Salvador <osalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Aristeu Rozanski <aris@ruivo.org>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Dmitry Yakunin <zeil@yandex-team.ru>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Oscar Salvador <osalvador@suse.com>
Cc: Qian Cai <cai@lca.pw>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20200922135650.1634-10-osalvador@suse.de
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-16 03:07:09 +00:00
|
|
|
if (release)
|
|
|
|
put_page(page);
|
2020-10-16 03:07:05 +00:00
|
|
|
page_ref_inc(page);
|
2022-10-24 06:20:11 +00:00
|
|
|
num_poisoned_pages_inc(page_to_pfn(page));
|
2020-10-16 03:07:13 +00:00
|
|
|
|
|
|
|
return true;
|
2020-10-16 03:07:05 +00:00
|
|
|
}
|
|
|
|
|
2023-03-13 05:39:29 +00:00
|
|
|
#if IS_ENABLED(CONFIG_HWPOISON_INJECT)
|
2009-12-21 18:56:42 +00:00
|
|
|
|
2009-12-16 11:19:59 +00:00
|
|
|
u32 hwpoison_filter_enable = 0;
|
2009-12-16 11:19:59 +00:00
|
|
|
u32 hwpoison_filter_dev_major = ~0U;
|
|
|
|
u32 hwpoison_filter_dev_minor = ~0U;
|
2009-12-16 11:19:59 +00:00
|
|
|
u64 hwpoison_filter_flags_mask;
|
|
|
|
u64 hwpoison_filter_flags_value;
|
2009-12-16 11:19:59 +00:00
|
|
|
EXPORT_SYMBOL_GPL(hwpoison_filter_enable);
|
2009-12-16 11:19:59 +00:00
|
|
|
EXPORT_SYMBOL_GPL(hwpoison_filter_dev_major);
|
|
|
|
EXPORT_SYMBOL_GPL(hwpoison_filter_dev_minor);
|
2009-12-16 11:19:59 +00:00
|
|
|
EXPORT_SYMBOL_GPL(hwpoison_filter_flags_mask);
|
|
|
|
EXPORT_SYMBOL_GPL(hwpoison_filter_flags_value);
|
2009-12-16 11:19:59 +00:00
|
|
|
|
|
|
|
static int hwpoison_filter_dev(struct page *p)
|
|
|
|
{
|
2024-04-23 22:55:34 +00:00
|
|
|
struct folio *folio = page_folio(p);
|
2009-12-16 11:19:59 +00:00
|
|
|
struct address_space *mapping;
|
|
|
|
dev_t dev;
|
|
|
|
|
|
|
|
if (hwpoison_filter_dev_major == ~0U &&
|
|
|
|
hwpoison_filter_dev_minor == ~0U)
|
|
|
|
return 0;
|
|
|
|
|
2024-04-23 22:55:34 +00:00
|
|
|
mapping = folio_mapping(folio);
|
2009-12-16 11:19:59 +00:00
|
|
|
if (mapping == NULL || mapping->host == NULL)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
dev = mapping->host->i_sb->s_dev;
|
|
|
|
if (hwpoison_filter_dev_major != ~0U &&
|
|
|
|
hwpoison_filter_dev_major != MAJOR(dev))
|
|
|
|
return -EINVAL;
|
|
|
|
if (hwpoison_filter_dev_minor != ~0U &&
|
|
|
|
hwpoison_filter_dev_minor != MINOR(dev))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-12-16 11:19:59 +00:00
|
|
|
static int hwpoison_filter_flags(struct page *p)
|
|
|
|
{
|
|
|
|
if (!hwpoison_filter_flags_mask)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if ((stable_page_flags(p) & hwpoison_filter_flags_mask) ==
|
|
|
|
hwpoison_filter_flags_value)
|
|
|
|
return 0;
|
|
|
|
else
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2009-12-16 11:19:59 +00:00
|
|
|
/*
|
|
|
|
* This allows stress tests to limit test scope to a collection of tasks
|
|
|
|
* by putting them under some memcg. This prevents killing unrelated/important
|
|
|
|
* processes such as /sbin/init. Note that the target task may share clean
|
|
|
|
* pages with init (eg. libc text), which is harmless. If the target task
|
|
|
|
* share _dirty_ pages with another task B, the test scheme must make sure B
|
|
|
|
* is also included in the memcg. At last, due to race conditions this filter
|
|
|
|
* can only guarantee that the page either belongs to the memcg tasks, or is
|
|
|
|
* a freed page.
|
|
|
|
*/
|
2015-09-09 22:35:31 +00:00
|
|
|
#ifdef CONFIG_MEMCG
|
2009-12-16 11:19:59 +00:00
|
|
|
u64 hwpoison_filter_memcg;
|
|
|
|
EXPORT_SYMBOL_GPL(hwpoison_filter_memcg);
|
|
|
|
static int hwpoison_filter_task(struct page *p)
|
|
|
|
{
|
|
|
|
if (!hwpoison_filter_memcg)
|
|
|
|
return 0;
|
|
|
|
|
2015-09-09 22:35:31 +00:00
|
|
|
if (page_cgroup_ino(p) != hwpoison_filter_memcg)
|
2009-12-16 11:19:59 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static int hwpoison_filter_task(struct page *p) { return 0; }
|
|
|
|
#endif
|
|
|
|
|
2009-12-16 11:19:59 +00:00
|
|
|
int hwpoison_filter(struct page *p)
|
|
|
|
{
|
2009-12-16 11:19:59 +00:00
|
|
|
if (!hwpoison_filter_enable)
|
|
|
|
return 0;
|
|
|
|
|
2009-12-16 11:19:59 +00:00
|
|
|
if (hwpoison_filter_dev(p))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2009-12-16 11:19:59 +00:00
|
|
|
if (hwpoison_filter_flags(p))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2009-12-16 11:19:59 +00:00
|
|
|
if (hwpoison_filter_task(p))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2009-12-16 11:19:59 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2024-06-12 07:18:29 +00:00
|
|
|
EXPORT_SYMBOL_GPL(hwpoison_filter);
|
2009-12-21 18:56:42 +00:00
|
|
|
#else
|
|
|
|
int hwpoison_filter(struct page *p)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2018-07-14 04:50:11 +00:00
|
|
|
/*
|
|
|
|
* Kill all processes that have a poisoned page mapped and then isolate
|
|
|
|
* the page.
|
|
|
|
*
|
|
|
|
* General strategy:
|
|
|
|
* Find all processes having the page mapped and kill them.
|
|
|
|
* But we keep a page reference around so that the page is not
|
|
|
|
* actually freed yet.
|
|
|
|
* Then stash the page away
|
|
|
|
*
|
|
|
|
* There's no convenient way to get back to mapped processes
|
|
|
|
* from the VMAs. So do a brute-force search over all
|
|
|
|
* running processes.
|
|
|
|
*
|
|
|
|
* Remember that machine checks are not common (or rather
|
|
|
|
* if they are common you have other problems), so this shouldn't
|
|
|
|
* be a performance issue.
|
|
|
|
*
|
|
|
|
* Also there are some races possible while we get from the
|
|
|
|
* error detection to actually handle it.
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct to_kill {
|
|
|
|
struct list_head nd;
|
|
|
|
struct task_struct *tsk;
|
|
|
|
unsigned long addr;
|
|
|
|
short size_shift;
|
|
|
|
};
|
|
|
|
|
2009-09-16 09:50:15 +00:00
|
|
|
/*
|
2011-12-13 17:27:58 +00:00
|
|
|
* Send all the processes who have the page mapped a signal.
|
|
|
|
* ``action optional'' if they are not immediately affected by the error
|
|
|
|
* ``action required'' if error happened in current execution context
|
2009-09-16 09:50:15 +00:00
|
|
|
*/
|
2018-07-14 04:50:11 +00:00
|
|
|
static int kill_proc(struct to_kill *tk, unsigned long pfn, int flags)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
2018-07-14 04:50:11 +00:00
|
|
|
struct task_struct *t = tk->tsk;
|
|
|
|
short addr_lsb = tk->size_shift;
|
2020-06-02 04:50:11 +00:00
|
|
|
int ret = 0;
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_err("%#lx: Sending SIGBUS to %s:%d due to hardware memory corruption\n",
|
2024-06-12 07:18:30 +00:00
|
|
|
pfn, t->comm, task_pid_nr(t));
|
2011-12-13 17:27:58 +00:00
|
|
|
|
2022-03-22 21:44:18 +00:00
|
|
|
if ((flags & MF_ACTION_REQUIRED) && (t == current))
|
|
|
|
ret = force_sig_mceerr(BUS_MCEERR_AR,
|
|
|
|
(void __user *)tk->addr, addr_lsb);
|
|
|
|
else
|
2011-12-13 17:27:58 +00:00
|
|
|
/*
|
2022-03-22 21:44:18 +00:00
|
|
|
* Signal other processes sharing the page if they have
|
|
|
|
* PF_MCE_EARLY set.
|
2011-12-13 17:27:58 +00:00
|
|
|
* Don't use force here, it's convenient if the signal
|
|
|
|
* can be temporarily blocked.
|
|
|
|
*/
|
2018-07-14 04:50:11 +00:00
|
|
|
ret = send_sig_mceerr(BUS_MCEERR_AO, (void __user *)tk->addr,
|
2022-08-30 12:36:04 +00:00
|
|
|
addr_lsb, t);
|
2009-09-16 09:50:15 +00:00
|
|
|
if (ret < 0)
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_info("Error sending signal to %s:%d: %d\n",
|
2024-06-12 07:18:30 +00:00
|
|
|
t->comm, task_pid_nr(t), ret);
|
2009-09-16 09:50:15 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2009-12-16 11:19:57 +00:00
|
|
|
/*
|
2020-12-15 03:11:45 +00:00
|
|
|
* Unknown page type encountered. Try to check whether it can turn PageLRU by
|
mm: hwpoison: don't drop slab caches for offlining non-LRU page
In the current implementation of soft offline, if non-LRU page is met,
all the slab caches will be dropped to free the page then offline. But
if the page is not slab page all the effort is wasted in vain. Even
though it is a slab page, it is not guaranteed the page could be freed
at all.
However the side effect and cost is quite high. It does not only drop
the slab caches, but also may drop a significant amount of page caches
which are associated with inode caches. It could make the most
workingset gone in order to just offline a page. And the offline is not
guaranteed to succeed at all, actually I really doubt the success rate
for real life workload.
Furthermore the worse consequence is the system may be locked up and
unusable since the page cache release may incur huge amount of works
queued for memcg release.
Actually we ran into such unpleasant case in our production environment.
Firstly, the workqueue of memory_failure_work_func is locked up as
below:
BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 53s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=14/256 refcnt=15
in-flight: 409271:memory_failure_work_func
pending: kfree_rcu_work, kfree_rcu_monitor, kfree_rcu_work, rht_deferred_worker, rht_deferred_worker, rht_deferred_worker, rht_deferred_worker, kfree_rcu_work, kfree_rcu_work, kfree_rcu_work, kfree_rcu_work, drain_local_stock, kfree_rcu_work
workqueue mm_percpu_wq: flags=0x8
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
pending: vmstat_update
workqueue cgroup_destroy: flags=0x0
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/1 refcnt=12072
pending: css_release_work_fn
There were over 12K css_release_work_fn queued, and this caused a few
lockups due to the contention of worker pool lock with IRQ disabled, for
example:
NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
Modules linked in: amd64_edac_mod edac_mce_amd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xt_DSCP iptable_mangle kvm_amd bpfilter vfat fat acpi_ipmi i2c_piix4 usb_storage ipmi_si k10temp i2c_core ipmi_devintf ipmi_msghandler acpi_cpufreq sch_fq_codel xfs libcrc32c crc32c_intel mlx5_core mlxfw nvme xhci_pci ptp nvme_core pps_core xhci_hcd
CPU: 1 PID: 205500 Comm: kworker/1:0 Tainted: G L 5.10.32-t1.el7.twitter.x86_64 #1
Hardware name: TYAN F5AMT /z /S8026GM2NRE-CGN, BIOS V8.030 03/30/2021
Workqueue: events memory_failure_work_func
RIP: 0010:queued_spin_lock_slowpath+0x41/0x1a0
Code: 41 f0 0f ba 2f 08 0f 92 c0 0f b6 c0 c1 e0 08 89 c2 8b 07 30 e4 09 d0 a9 00 01 ff ff 75 1b 85 c0 74 0e 8b 07 84 c0 74 08 f3 90 <8b> 07 84 c0 75 f8 b8 01 00 00 00 66 89 07 c3 f6 c4 01 75 04 c6 47
RSP: 0018:ffff9b2ac278f900 EFLAGS: 00000002
RAX: 0000000000480101 RBX: ffff8ce98ce71800 RCX: 0000000000000084
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8ce98ce6a140
RBP: 00000000000284c8 R08: ffffd7248dcb6808 R09: 0000000000000000
R10: 0000000000000003 R11: ffff9b2ac278f9b0 R12: 0000000000000001
R13: ffff8cb44dab9c00 R14: ffffffffbd1ce6a0 R15: ffff8cacaa37f068
FS: 0000000000000000(0000) GS:ffff8ce98ce40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fcf6e8cb000 CR3: 0000000a0c60a000 CR4: 0000000000350ee0
Call Trace:
__queue_work+0xd6/0x3c0
queue_work_on+0x1c/0x30
uncharge_batch+0x10e/0x110
mem_cgroup_uncharge_list+0x6d/0x80
release_pages+0x37f/0x3f0
__pagevec_release+0x1c/0x50
__invalidate_mapping_pages+0x348/0x380
inode_lru_isolate+0x10a/0x160
__list_lru_walk_one+0x7b/0x170
list_lru_walk_one+0x4a/0x60
prune_icache_sb+0x37/0x50
super_cache_scan+0x123/0x1a0
do_shrink_slab+0x10c/0x2c0
shrink_slab+0x1f1/0x290
drop_slab_node+0x4d/0x70
soft_offline_page+0x1ac/0x5b0
memory_failure_work_func+0x6a/0x90
process_one_work+0x19e/0x340
worker_thread+0x30/0x360
kthread+0x116/0x130
The lockup made the machine is quite unusable. And it also made the
most workingset gone, the reclaimabled slab caches were reduced from 12G
to 300MB, the page caches were decreased from 17G to 4G.
But the most disappointing thing is all the effort doesn't make the page
offline, it just returns:
soft_offline: 0x1469f2: unknown non LRU page type 5ffff0000000000 ()
It seems the aggressive behavior for non-LRU page didn't pay back, so it
doesn't make too much sense to keep it considering the terrible side
effect.
Link: https://lkml.kernel.org/r/20210819054116.266126-1-shy828301@gmail.com
Signed-off-by: Yang Shi <shy828301@gmail.com>
Reported-by: David Mackey <tdmackey@twitter.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-02 21:58:31 +00:00
|
|
|
* lru_add_drain_all.
|
2009-12-16 11:19:57 +00:00
|
|
|
*/
|
2024-04-12 19:35:02 +00:00
|
|
|
void shake_folio(struct folio *folio)
|
2009-12-16 11:19:57 +00:00
|
|
|
{
|
2024-04-12 19:35:02 +00:00
|
|
|
if (folio_test_hugetlb(folio))
|
2017-05-03 21:56:19 +00:00
|
|
|
return;
|
2009-12-16 11:19:57 +00:00
|
|
|
/*
|
mm: hwpoison: don't drop slab caches for offlining non-LRU page
In the current implementation of soft offline, if non-LRU page is met,
all the slab caches will be dropped to free the page then offline. But
if the page is not slab page all the effort is wasted in vain. Even
though it is a slab page, it is not guaranteed the page could be freed
at all.
However the side effect and cost is quite high. It does not only drop
the slab caches, but also may drop a significant amount of page caches
which are associated with inode caches. It could make the most
workingset gone in order to just offline a page. And the offline is not
guaranteed to succeed at all, actually I really doubt the success rate
for real life workload.
Furthermore the worse consequence is the system may be locked up and
unusable since the page cache release may incur huge amount of works
queued for memcg release.
Actually we ran into such unpleasant case in our production environment.
Firstly, the workqueue of memory_failure_work_func is locked up as
below:
BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 53s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=14/256 refcnt=15
in-flight: 409271:memory_failure_work_func
pending: kfree_rcu_work, kfree_rcu_monitor, kfree_rcu_work, rht_deferred_worker, rht_deferred_worker, rht_deferred_worker, rht_deferred_worker, kfree_rcu_work, kfree_rcu_work, kfree_rcu_work, kfree_rcu_work, drain_local_stock, kfree_rcu_work
workqueue mm_percpu_wq: flags=0x8
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
pending: vmstat_update
workqueue cgroup_destroy: flags=0x0
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/1 refcnt=12072
pending: css_release_work_fn
There were over 12K css_release_work_fn queued, and this caused a few
lockups due to the contention of worker pool lock with IRQ disabled, for
example:
NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
Modules linked in: amd64_edac_mod edac_mce_amd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xt_DSCP iptable_mangle kvm_amd bpfilter vfat fat acpi_ipmi i2c_piix4 usb_storage ipmi_si k10temp i2c_core ipmi_devintf ipmi_msghandler acpi_cpufreq sch_fq_codel xfs libcrc32c crc32c_intel mlx5_core mlxfw nvme xhci_pci ptp nvme_core pps_core xhci_hcd
CPU: 1 PID: 205500 Comm: kworker/1:0 Tainted: G L 5.10.32-t1.el7.twitter.x86_64 #1
Hardware name: TYAN F5AMT /z /S8026GM2NRE-CGN, BIOS V8.030 03/30/2021
Workqueue: events memory_failure_work_func
RIP: 0010:queued_spin_lock_slowpath+0x41/0x1a0
Code: 41 f0 0f ba 2f 08 0f 92 c0 0f b6 c0 c1 e0 08 89 c2 8b 07 30 e4 09 d0 a9 00 01 ff ff 75 1b 85 c0 74 0e 8b 07 84 c0 74 08 f3 90 <8b> 07 84 c0 75 f8 b8 01 00 00 00 66 89 07 c3 f6 c4 01 75 04 c6 47
RSP: 0018:ffff9b2ac278f900 EFLAGS: 00000002
RAX: 0000000000480101 RBX: ffff8ce98ce71800 RCX: 0000000000000084
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8ce98ce6a140
RBP: 00000000000284c8 R08: ffffd7248dcb6808 R09: 0000000000000000
R10: 0000000000000003 R11: ffff9b2ac278f9b0 R12: 0000000000000001
R13: ffff8cb44dab9c00 R14: ffffffffbd1ce6a0 R15: ffff8cacaa37f068
FS: 0000000000000000(0000) GS:ffff8ce98ce40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fcf6e8cb000 CR3: 0000000a0c60a000 CR4: 0000000000350ee0
Call Trace:
__queue_work+0xd6/0x3c0
queue_work_on+0x1c/0x30
uncharge_batch+0x10e/0x110
mem_cgroup_uncharge_list+0x6d/0x80
release_pages+0x37f/0x3f0
__pagevec_release+0x1c/0x50
__invalidate_mapping_pages+0x348/0x380
inode_lru_isolate+0x10a/0x160
__list_lru_walk_one+0x7b/0x170
list_lru_walk_one+0x4a/0x60
prune_icache_sb+0x37/0x50
super_cache_scan+0x123/0x1a0
do_shrink_slab+0x10c/0x2c0
shrink_slab+0x1f1/0x290
drop_slab_node+0x4d/0x70
soft_offline_page+0x1ac/0x5b0
memory_failure_work_func+0x6a/0x90
process_one_work+0x19e/0x340
worker_thread+0x30/0x360
kthread+0x116/0x130
The lockup made the machine is quite unusable. And it also made the
most workingset gone, the reclaimabled slab caches were reduced from 12G
to 300MB, the page caches were decreased from 17G to 4G.
But the most disappointing thing is all the effort doesn't make the page
offline, it just returns:
soft_offline: 0x1469f2: unknown non LRU page type 5ffff0000000000 ()
It seems the aggressive behavior for non-LRU page didn't pay back, so it
doesn't make too much sense to keep it considering the terrible side
effect.
Link: https://lkml.kernel.org/r/20210819054116.266126-1-shy828301@gmail.com
Signed-off-by: Yang Shi <shy828301@gmail.com>
Reported-by: David Mackey <tdmackey@twitter.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-02 21:58:31 +00:00
|
|
|
* TODO: Could shrink slab caches here if a lightweight range-based
|
|
|
|
* shrinker will be available.
|
2009-12-16 11:19:57 +00:00
|
|
|
*/
|
2024-04-12 19:35:02 +00:00
|
|
|
if (folio_test_slab(folio))
|
2023-06-28 01:49:29 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
lru_add_drain_all();
|
2009-12-16 11:19:57 +00:00
|
|
|
}
|
2024-04-12 19:35:02 +00:00
|
|
|
EXPORT_SYMBOL_GPL(shake_folio);
|
|
|
|
|
|
|
|
static void shake_page(struct page *page)
|
|
|
|
{
|
|
|
|
shake_folio(page_folio(page));
|
|
|
|
}
|
2009-12-16 11:19:57 +00:00
|
|
|
|
2022-06-03 05:37:29 +00:00
|
|
|
static unsigned long dev_pagemap_mapping_shift(struct vm_area_struct *vma,
|
|
|
|
unsigned long address)
|
2018-07-14 04:50:21 +00:00
|
|
|
{
|
2021-09-24 22:44:03 +00:00
|
|
|
unsigned long ret = 0;
|
2018-07-14 04:50:21 +00:00
|
|
|
pgd_t *pgd;
|
|
|
|
p4d_t *p4d;
|
|
|
|
pud_t *pud;
|
|
|
|
pmd_t *pmd;
|
|
|
|
pte_t *pte;
|
mm: ptep_get() conversion
Convert all instances of direct pte_t* dereferencing to instead use
ptep_get() helper. This means that by default, the accesses change from a
C dereference to a READ_ONCE(). This is technically the correct thing to
do since where pgtables are modified by HW (for access/dirty) they are
volatile and therefore we should always ensure READ_ONCE() semantics.
But more importantly, by always using the helper, it can be overridden by
the architecture to fully encapsulate the contents of the pte. Arch code
is deliberately not converted, as the arch code knows best. It is
intended that arch code (arm64) will override the default with its own
implementation that can (e.g.) hide certain bits from the core code, or
determine young/dirty status by mixing in state from another source.
Conversion was done using Coccinelle:
----
// $ make coccicheck \
// COCCI=ptepget.cocci \
// SPFLAGS="--include-headers" \
// MODE=patch
virtual patch
@ depends on patch @
pte_t *v;
@@
- *v
+ ptep_get(v)
----
Then reviewed and hand-edited to avoid multiple unnecessary calls to
ptep_get(), instead opting to store the result of a single call in a
variable, where it is correct to do so. This aims to negate any cost of
READ_ONCE() and will benefit arch-overrides that may be more complex.
Included is a fix for an issue in an earlier version of this patch that
was pointed out by kernel test robot. The issue arose because config
MMU=n elides definition of the ptep helper functions, including
ptep_get(). HUGETLB_PAGE=n configs still define a simple
huge_ptep_clear_flush() for linking purposes, which dereferences the ptep.
So when both configs are disabled, this caused a build error because
ptep_get() is not defined. Fix by continuing to do a direct dereference
when MMU=n. This is safe because for this config the arch code cannot be
trying to virtualize the ptes because none of the ptep helpers are
defined.
Link: https://lkml.kernel.org/r/20230612151545.3317766-4-ryan.roberts@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202305120142.yXsNEo6H-lkp@intel.com/
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport (IBM) <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: SeongJae Park <sj@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-12 15:15:45 +00:00
|
|
|
pte_t ptent;
|
2018-07-14 04:50:21 +00:00
|
|
|
|
2022-03-22 21:44:15 +00:00
|
|
|
VM_BUG_ON_VMA(address == -EFAULT, vma);
|
2018-07-14 04:50:21 +00:00
|
|
|
pgd = pgd_offset(vma->vm_mm, address);
|
|
|
|
if (!pgd_present(*pgd))
|
|
|
|
return 0;
|
|
|
|
p4d = p4d_offset(pgd, address);
|
|
|
|
if (!p4d_present(*p4d))
|
|
|
|
return 0;
|
|
|
|
pud = pud_offset(p4d, address);
|
|
|
|
if (!pud_present(*pud))
|
|
|
|
return 0;
|
|
|
|
if (pud_devmap(*pud))
|
|
|
|
return PUD_SHIFT;
|
|
|
|
pmd = pmd_offset(pud, address);
|
|
|
|
if (!pmd_present(*pmd))
|
|
|
|
return 0;
|
|
|
|
if (pmd_devmap(*pmd))
|
|
|
|
return PMD_SHIFT;
|
|
|
|
pte = pte_offset_map(pmd, address);
|
2023-06-09 01:29:22 +00:00
|
|
|
if (!pte)
|
|
|
|
return 0;
|
mm: ptep_get() conversion
Convert all instances of direct pte_t* dereferencing to instead use
ptep_get() helper. This means that by default, the accesses change from a
C dereference to a READ_ONCE(). This is technically the correct thing to
do since where pgtables are modified by HW (for access/dirty) they are
volatile and therefore we should always ensure READ_ONCE() semantics.
But more importantly, by always using the helper, it can be overridden by
the architecture to fully encapsulate the contents of the pte. Arch code
is deliberately not converted, as the arch code knows best. It is
intended that arch code (arm64) will override the default with its own
implementation that can (e.g.) hide certain bits from the core code, or
determine young/dirty status by mixing in state from another source.
Conversion was done using Coccinelle:
----
// $ make coccicheck \
// COCCI=ptepget.cocci \
// SPFLAGS="--include-headers" \
// MODE=patch
virtual patch
@ depends on patch @
pte_t *v;
@@
- *v
+ ptep_get(v)
----
Then reviewed and hand-edited to avoid multiple unnecessary calls to
ptep_get(), instead opting to store the result of a single call in a
variable, where it is correct to do so. This aims to negate any cost of
READ_ONCE() and will benefit arch-overrides that may be more complex.
Included is a fix for an issue in an earlier version of this patch that
was pointed out by kernel test robot. The issue arose because config
MMU=n elides definition of the ptep helper functions, including
ptep_get(). HUGETLB_PAGE=n configs still define a simple
huge_ptep_clear_flush() for linking purposes, which dereferences the ptep.
So when both configs are disabled, this caused a build error because
ptep_get() is not defined. Fix by continuing to do a direct dereference
when MMU=n. This is safe because for this config the arch code cannot be
trying to virtualize the ptes because none of the ptep helpers are
defined.
Link: https://lkml.kernel.org/r/20230612151545.3317766-4-ryan.roberts@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202305120142.yXsNEo6H-lkp@intel.com/
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport (IBM) <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: SeongJae Park <sj@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-12 15:15:45 +00:00
|
|
|
ptent = ptep_get(pte);
|
|
|
|
if (pte_present(ptent) && pte_devmap(ptent))
|
2021-09-24 22:44:03 +00:00
|
|
|
ret = PAGE_SHIFT;
|
|
|
|
pte_unmap(pte);
|
|
|
|
return ret;
|
2018-07-14 04:50:21 +00:00
|
|
|
}
|
2009-09-16 09:50:15 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Failure handling: if we can't find or can't kill a process there's
|
|
|
|
* not much we can do. We just print a message and ignore otherwise.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Schedule a process for later kill.
|
|
|
|
* Uses GFP_ATOMIC allocations to avoid potential recursions in the VM.
|
|
|
|
*/
|
mm: memory-failure: refactor add_to_kill()
Patch series "mm: ksm: support hwpoison for ksm page", v2.
Currently, ksm does not support hwpoison. As ksm is being used more
widely for deduplication at the system level, container level, and process
level, supporting hwpoison for ksm has become increasingly important.
However, ksm pages were not processed by hwpoison in 2009 [1].
The main method of implementation:
1. Refactor add_to_kill() and add new add_to_kill_*() to better
accommodate the handling of different types of pages.
2. Add collect_procs_ksm() to collect processes when the error hit an
ksm page.
3. Add task_in_to_kill_list() to avoid duplicate addition of tsk to
the to_kill list.
4. Try_to_unmap ksm page (already supported).
5. Handle related processes such as sending SIGBUS.
Tested with poisoning to ksm page from
1) different process
2) one process
and with/without memory_failure_early_kill set, the processes are killed
as expected with the patchset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?h=01e00f880ca700376e1845cf7a2524ebe68e47d6
This patch (of 2):
The page_address_in_vma() is used to find the user virtual address of page
in add_to_kill(), but it doesn't support ksm due to the ksm page->index
unusable, add an ksm_addr as parameter to add_to_kill(), let's the caller
to pass it, also rename the function to __add_to_kill(), and adding
add_to_kill_anon_file() for handling anonymous pages and file pages,
adding add_to_kill_fsdax() for handling fsdax pages.
Link: https://lkml.kernel.org/r/20230414021741.2597273-1-xialonglong1@huawei.com
Link: https://lkml.kernel.org/r/20230414021741.2597273-2-xialonglong1@huawei.com
Signed-off-by: Longlong Xia <xialonglong1@huawei.com>
Tested-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Nanyong Sun <sunnanyong@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-04-14 02:17:40 +00:00
|
|
|
static void __add_to_kill(struct task_struct *tsk, struct page *p,
|
|
|
|
struct vm_area_struct *vma, struct list_head *to_kill,
|
2024-04-12 19:34:58 +00:00
|
|
|
unsigned long addr)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
|
|
|
struct to_kill *tk;
|
|
|
|
|
2019-12-01 01:53:35 +00:00
|
|
|
tk = kmalloc(sizeof(struct to_kill), GFP_ATOMIC);
|
|
|
|
if (!tk) {
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_err("Out of memory while machine check handling\n");
|
2019-12-01 01:53:35 +00:00
|
|
|
return;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
2019-12-01 01:53:35 +00:00
|
|
|
|
2024-04-12 19:34:59 +00:00
|
|
|
tk->addr = addr;
|
2024-04-12 19:34:58 +00:00
|
|
|
if (is_zone_device_page(p))
|
2022-06-03 05:37:29 +00:00
|
|
|
tk->size_shift = dev_pagemap_mapping_shift(vma, tk->addr);
|
2024-04-12 19:34:58 +00:00
|
|
|
else
|
2019-12-01 01:53:41 +00:00
|
|
|
tk->size_shift = page_shift(compound_head(p));
|
2009-09-16 09:50:15 +00:00
|
|
|
|
|
|
|
/*
|
2019-10-14 21:12:29 +00:00
|
|
|
* Send SIGKILL if "tk->addr == -EFAULT". Also, as
|
|
|
|
* "tk->size_shift" is always non-zero for !is_zone_device_page(),
|
|
|
|
* so "tk->size_shift == 0" effectively checks no mapping on
|
|
|
|
* ZONE_DEVICE. Indeed, when a devdax page is mmapped N times
|
|
|
|
* to a process' address space, it's possible not all N VMAs
|
|
|
|
* contain mappings for the page, but at least one VMA does.
|
|
|
|
* Only deliver SIGBUS with payload derived from the VMA that
|
|
|
|
* has a mapping for the page.
|
2009-09-16 09:50:15 +00:00
|
|
|
*/
|
2019-10-14 21:12:29 +00:00
|
|
|
if (tk->addr == -EFAULT) {
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_info("Unable to find user space address %lx in %s\n",
|
2009-09-16 09:50:15 +00:00
|
|
|
page_to_pfn(p), tsk->comm);
|
2019-10-14 21:12:29 +00:00
|
|
|
} else if (tk->size_shift == 0) {
|
|
|
|
kfree(tk);
|
|
|
|
return;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
2019-12-01 01:53:35 +00:00
|
|
|
|
2009-09-16 09:50:15 +00:00
|
|
|
get_task_struct(tsk);
|
|
|
|
tk->tsk = tsk;
|
|
|
|
list_add_tail(&tk->nd, to_kill);
|
|
|
|
}
|
|
|
|
|
mm: memory-failure: refactor add_to_kill()
Patch series "mm: ksm: support hwpoison for ksm page", v2.
Currently, ksm does not support hwpoison. As ksm is being used more
widely for deduplication at the system level, container level, and process
level, supporting hwpoison for ksm has become increasingly important.
However, ksm pages were not processed by hwpoison in 2009 [1].
The main method of implementation:
1. Refactor add_to_kill() and add new add_to_kill_*() to better
accommodate the handling of different types of pages.
2. Add collect_procs_ksm() to collect processes when the error hit an
ksm page.
3. Add task_in_to_kill_list() to avoid duplicate addition of tsk to
the to_kill list.
4. Try_to_unmap ksm page (already supported).
5. Handle related processes such as sending SIGBUS.
Tested with poisoning to ksm page from
1) different process
2) one process
and with/without memory_failure_early_kill set, the processes are killed
as expected with the patchset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?h=01e00f880ca700376e1845cf7a2524ebe68e47d6
This patch (of 2):
The page_address_in_vma() is used to find the user virtual address of page
in add_to_kill(), but it doesn't support ksm due to the ksm page->index
unusable, add an ksm_addr as parameter to add_to_kill(), let's the caller
to pass it, also rename the function to __add_to_kill(), and adding
add_to_kill_anon_file() for handling anonymous pages and file pages,
adding add_to_kill_fsdax() for handling fsdax pages.
Link: https://lkml.kernel.org/r/20230414021741.2597273-1-xialonglong1@huawei.com
Link: https://lkml.kernel.org/r/20230414021741.2597273-2-xialonglong1@huawei.com
Signed-off-by: Longlong Xia <xialonglong1@huawei.com>
Tested-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Nanyong Sun <sunnanyong@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-04-14 02:17:40 +00:00
|
|
|
static void add_to_kill_anon_file(struct task_struct *tsk, struct page *p,
|
2024-04-12 19:35:00 +00:00
|
|
|
struct vm_area_struct *vma, struct list_head *to_kill,
|
|
|
|
unsigned long addr)
|
mm: memory-failure: refactor add_to_kill()
Patch series "mm: ksm: support hwpoison for ksm page", v2.
Currently, ksm does not support hwpoison. As ksm is being used more
widely for deduplication at the system level, container level, and process
level, supporting hwpoison for ksm has become increasingly important.
However, ksm pages were not processed by hwpoison in 2009 [1].
The main method of implementation:
1. Refactor add_to_kill() and add new add_to_kill_*() to better
accommodate the handling of different types of pages.
2. Add collect_procs_ksm() to collect processes when the error hit an
ksm page.
3. Add task_in_to_kill_list() to avoid duplicate addition of tsk to
the to_kill list.
4. Try_to_unmap ksm page (already supported).
5. Handle related processes such as sending SIGBUS.
Tested with poisoning to ksm page from
1) different process
2) one process
and with/without memory_failure_early_kill set, the processes are killed
as expected with the patchset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?h=01e00f880ca700376e1845cf7a2524ebe68e47d6
This patch (of 2):
The page_address_in_vma() is used to find the user virtual address of page
in add_to_kill(), but it doesn't support ksm due to the ksm page->index
unusable, add an ksm_addr as parameter to add_to_kill(), let's the caller
to pass it, also rename the function to __add_to_kill(), and adding
add_to_kill_anon_file() for handling anonymous pages and file pages,
adding add_to_kill_fsdax() for handling fsdax pages.
Link: https://lkml.kernel.org/r/20230414021741.2597273-1-xialonglong1@huawei.com
Link: https://lkml.kernel.org/r/20230414021741.2597273-2-xialonglong1@huawei.com
Signed-off-by: Longlong Xia <xialonglong1@huawei.com>
Tested-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Nanyong Sun <sunnanyong@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-04-14 02:17:40 +00:00
|
|
|
{
|
2024-04-12 19:35:00 +00:00
|
|
|
if (addr == -EFAULT)
|
|
|
|
return;
|
2024-04-12 19:34:59 +00:00
|
|
|
__add_to_kill(tsk, p, vma, to_kill, addr);
|
mm: memory-failure: refactor add_to_kill()
Patch series "mm: ksm: support hwpoison for ksm page", v2.
Currently, ksm does not support hwpoison. As ksm is being used more
widely for deduplication at the system level, container level, and process
level, supporting hwpoison for ksm has become increasingly important.
However, ksm pages were not processed by hwpoison in 2009 [1].
The main method of implementation:
1. Refactor add_to_kill() and add new add_to_kill_*() to better
accommodate the handling of different types of pages.
2. Add collect_procs_ksm() to collect processes when the error hit an
ksm page.
3. Add task_in_to_kill_list() to avoid duplicate addition of tsk to
the to_kill list.
4. Try_to_unmap ksm page (already supported).
5. Handle related processes such as sending SIGBUS.
Tested with poisoning to ksm page from
1) different process
2) one process
and with/without memory_failure_early_kill set, the processes are killed
as expected with the patchset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?h=01e00f880ca700376e1845cf7a2524ebe68e47d6
This patch (of 2):
The page_address_in_vma() is used to find the user virtual address of page
in add_to_kill(), but it doesn't support ksm due to the ksm page->index
unusable, add an ksm_addr as parameter to add_to_kill(), let's the caller
to pass it, also rename the function to __add_to_kill(), and adding
add_to_kill_anon_file() for handling anonymous pages and file pages,
adding add_to_kill_fsdax() for handling fsdax pages.
Link: https://lkml.kernel.org/r/20230414021741.2597273-1-xialonglong1@huawei.com
Link: https://lkml.kernel.org/r/20230414021741.2597273-2-xialonglong1@huawei.com
Signed-off-by: Longlong Xia <xialonglong1@huawei.com>
Tested-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Nanyong Sun <sunnanyong@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-04-14 02:17:40 +00:00
|
|
|
}
|
|
|
|
|
2023-04-14 02:17:41 +00:00
|
|
|
#ifdef CONFIG_KSM
|
|
|
|
static bool task_in_to_kill_list(struct list_head *to_kill,
|
|
|
|
struct task_struct *tsk)
|
|
|
|
{
|
|
|
|
struct to_kill *tk, *next;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(tk, next, to_kill, nd) {
|
|
|
|
if (tk->tsk == tsk)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
2024-04-12 19:34:59 +00:00
|
|
|
|
2023-04-14 02:17:41 +00:00
|
|
|
void add_to_kill_ksm(struct task_struct *tsk, struct page *p,
|
|
|
|
struct vm_area_struct *vma, struct list_head *to_kill,
|
2024-04-12 19:34:58 +00:00
|
|
|
unsigned long addr)
|
2023-04-14 02:17:41 +00:00
|
|
|
{
|
|
|
|
if (!task_in_to_kill_list(to_kill, tsk))
|
2024-04-12 19:34:58 +00:00
|
|
|
__add_to_kill(tsk, p, vma, to_kill, addr);
|
2023-04-14 02:17:41 +00:00
|
|
|
}
|
|
|
|
#endif
|
2009-09-16 09:50:15 +00:00
|
|
|
/*
|
|
|
|
* Kill the processes that have been collected earlier.
|
|
|
|
*
|
2021-09-02 21:58:28 +00:00
|
|
|
* Only do anything when FORCEKILL is set, otherwise just free the
|
|
|
|
* list (this is used for clean pages which do not need killing)
|
2009-09-16 09:50:15 +00:00
|
|
|
*/
|
mm/memory-failure: try to send SIGBUS even if unmap failed
Patch series "Enhance soft hwpoison handling and injection", v4.
This series is aimed at the following enhancements:
- Let one hwpoison injector, that is, madvise(MADV_HWPOISON) to behave
more like as if a real UE occurred. Because the other two injectors
such as hwpoison-inject and the 'einj' on x86 can't, and it seems to me
we need a better simulation to real UE scenario.
- For years, if the kernel is unable to unmap a hwpoisoned page, it send
a SIGKILL instead of SIGBUS to prevent user process from potentially
accessing the page again. But in doing so, the user process also lose
important information: vaddr, for recovery. Fortunately, the kernel
already has code to kill process re-accessing a hwpoisoned page, so
remove the '!unmap_success' check.
- Right now, if a thp page under GUP longterm pin is hwpoisoned, and
kernel cannot split the thp page, memory-failure simply ignores the UE
and returns. That's not ideal, it could deliver a SIGBUS with useful
information for userspace recovery.
This patch (of 5):
For years when it comes down to kill a process due to hwpoison, a SIGBUS
is delivered only if unmap has been successful. Otherwise, a SIGKILL is
delivered. And the reason for that is to prevent the involved process
from accessing the hwpoisoned page again.
Since then a lot has changed, a hwpoisoned page is marked and upon being
re-accessed, the memory-failure handler invokes kill_accessing_process()
to kill the process immediately. So let's take out the '!unmap_success'
factor and try to deliver SIGBUS if possible.
Link: https://lkml.kernel.org/r/20240524215306.2705454-1-jane.chu@oracle.com
Link: https://lkml.kernel.org/r/20240524215306.2705454-2-jane.chu@oracle.com
Signed-off-by: Jane Chu <jane.chu@oracle.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <oalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-24 21:53:02 +00:00
|
|
|
static void kill_procs(struct list_head *to_kill, int forcekill,
|
2018-07-14 04:50:11 +00:00
|
|
|
unsigned long pfn, int flags)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
|
|
|
struct to_kill *tk, *next;
|
|
|
|
|
2022-08-23 03:23:44 +00:00
|
|
|
list_for_each_entry_safe(tk, next, to_kill, nd) {
|
2012-07-11 17:20:47 +00:00
|
|
|
if (forcekill) {
|
mm/memory-failure: try to send SIGBUS even if unmap failed
Patch series "Enhance soft hwpoison handling and injection", v4.
This series is aimed at the following enhancements:
- Let one hwpoison injector, that is, madvise(MADV_HWPOISON) to behave
more like as if a real UE occurred. Because the other two injectors
such as hwpoison-inject and the 'einj' on x86 can't, and it seems to me
we need a better simulation to real UE scenario.
- For years, if the kernel is unable to unmap a hwpoisoned page, it send
a SIGKILL instead of SIGBUS to prevent user process from potentially
accessing the page again. But in doing so, the user process also lose
important information: vaddr, for recovery. Fortunately, the kernel
already has code to kill process re-accessing a hwpoisoned page, so
remove the '!unmap_success' check.
- Right now, if a thp page under GUP longterm pin is hwpoisoned, and
kernel cannot split the thp page, memory-failure simply ignores the UE
and returns. That's not ideal, it could deliver a SIGBUS with useful
information for userspace recovery.
This patch (of 5):
For years when it comes down to kill a process due to hwpoison, a SIGBUS
is delivered only if unmap has been successful. Otherwise, a SIGKILL is
delivered. And the reason for that is to prevent the involved process
from accessing the hwpoisoned page again.
Since then a lot has changed, a hwpoisoned page is marked and upon being
re-accessed, the memory-failure handler invokes kill_accessing_process()
to kill the process immediately. So let's take out the '!unmap_success'
factor and try to deliver SIGBUS if possible.
Link: https://lkml.kernel.org/r/20240524215306.2705454-1-jane.chu@oracle.com
Link: https://lkml.kernel.org/r/20240524215306.2705454-2-jane.chu@oracle.com
Signed-off-by: Jane Chu <jane.chu@oracle.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <oalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-24 21:53:02 +00:00
|
|
|
if (tk->addr == -EFAULT) {
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_err("%#lx: forcibly killing %s:%d because of failure to unmap corrupted page\n",
|
2024-06-12 07:18:30 +00:00
|
|
|
pfn, tk->tsk->comm, task_pid_nr(tk->tsk));
|
2019-02-01 22:21:08 +00:00
|
|
|
do_send_sig_info(SIGKILL, SEND_SIG_PRIV,
|
|
|
|
tk->tsk, PIDTYPE_PID);
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In theory the process could have mapped
|
|
|
|
* something else on the address in-between. We could
|
|
|
|
* check for that, but we need to tell the
|
|
|
|
* process anyways.
|
|
|
|
*/
|
2018-07-14 04:50:11 +00:00
|
|
|
else if (kill_proc(tk, pfn, flags) < 0)
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_err("%#lx: Cannot send advisory machine check signal to %s:%d\n",
|
2024-06-12 07:18:30 +00:00
|
|
|
pfn, tk->tsk->comm, task_pid_nr(tk->tsk));
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
2022-08-23 03:23:44 +00:00
|
|
|
list_del(&tk->nd);
|
2009-09-16 09:50:15 +00:00
|
|
|
put_task_struct(tk->tsk);
|
|
|
|
kfree(tk);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-06-04 23:11:02 +00:00
|
|
|
/*
|
|
|
|
* Find a dedicated thread which is supposed to handle SIGBUS(BUS_MCEERR_AO)
|
|
|
|
* on behalf of the thread group. Return task_struct of the (first found)
|
|
|
|
* dedicated thread if found, and return NULL otherwise.
|
|
|
|
*
|
mm: memory-failure: use rcu lock instead of tasklist_lock when collect_procs()
We found a softlock issue in our test, analyzed the logs, and found that
the relevant CPU call trace as follows:
CPU0:
_do_fork
-> copy_process()
-> write_lock_irq(&tasklist_lock) //Disable irq,waiting for
//tasklist_lock
CPU1:
wp_page_copy()
->pte_offset_map_lock()
-> spin_lock(&page->ptl); //Hold page->ptl
-> ptep_clear_flush()
-> flush_tlb_others() ...
-> smp_call_function_many()
-> arch_send_call_function_ipi_mask()
-> csd_lock_wait() //Waiting for other CPUs respond
//IPI
CPU2:
collect_procs_anon()
-> read_lock(&tasklist_lock) //Hold tasklist_lock
->for_each_process(tsk)
-> page_mapped_in_vma()
-> page_vma_mapped_walk()
-> map_pte()
->spin_lock(&page->ptl) //Waiting for page->ptl
We can see that CPU1 waiting for CPU0 respond IPI,CPU0 waiting for CPU2
unlock tasklist_lock, CPU2 waiting for CPU1 unlock page->ptl. As a result,
softlockup is triggered.
For collect_procs_anon(), what we're doing is task list iteration, during
the iteration, with the help of call_rcu(), the task_struct object is freed
only after one or more grace periods elapse. the logic as follows:
release_task()
-> __exit_signal()
-> __unhash_process()
-> list_del_rcu()
-> put_task_struct_rcu_user()
-> call_rcu(&task->rcu, delayed_put_task_struct)
delayed_put_task_struct()
-> put_task_struct()
-> if (refcount_sub_and_test())
__put_task_struct()
-> free_task()
Therefore, under the protection of the rcu lock, we can safely use
get_task_struct() to ensure a safe reference to task_struct during the
iteration.
By removing the use of tasklist_lock in task list iteration, we can break
the softlock chain above.
The same logic can also be applied to:
- collect_procs_file()
- collect_procs_fsdax()
- collect_procs_ksm()
Link: https://lkml.kernel.org/r/20230828022527.241693-1-tongtiangen@huawei.com
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-08-28 02:25:27 +00:00
|
|
|
* We already hold rcu lock in the caller, so we don't have to call
|
|
|
|
* rcu_read_lock/unlock() in this function.
|
2014-06-04 23:11:02 +00:00
|
|
|
*/
|
|
|
|
static struct task_struct *find_early_kill_thread(struct task_struct *tsk)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
2014-06-04 23:11:02 +00:00
|
|
|
struct task_struct *t;
|
|
|
|
|
2020-06-12 00:34:45 +00:00
|
|
|
for_each_thread(tsk, t) {
|
|
|
|
if (t->flags & PF_MCE_PROCESS) {
|
|
|
|
if (t->flags & PF_MCE_EARLY)
|
|
|
|
return t;
|
|
|
|
} else {
|
|
|
|
if (sysctl_memory_failure_early_kill)
|
|
|
|
return t;
|
|
|
|
}
|
|
|
|
}
|
2014-06-04 23:11:02 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Determine whether a given process is "early kill" process which expects
|
|
|
|
* to be signaled when some page under the process is hwpoisoned.
|
|
|
|
* Return task_struct of the dedicated thread (main thread unless explicitly
|
2021-02-24 20:06:39 +00:00
|
|
|
* specified) if the process is "early kill" and otherwise returns NULL.
|
2020-06-12 00:34:48 +00:00
|
|
|
*
|
2021-02-24 20:06:39 +00:00
|
|
|
* Note that the above is true for Action Optional case. For Action Required
|
|
|
|
* case, it's only meaningful to the current thread which need to be signaled
|
|
|
|
* with SIGBUS, this error is Action Optional for other non current
|
|
|
|
* processes sharing the same error page,if the process is "early kill", the
|
|
|
|
* task_struct of the dedicated thread will also be returned.
|
2014-06-04 23:11:02 +00:00
|
|
|
*/
|
2023-04-14 02:17:41 +00:00
|
|
|
struct task_struct *task_early_kill(struct task_struct *tsk, int force_early)
|
2014-06-04 23:11:02 +00:00
|
|
|
{
|
2009-09-16 09:50:15 +00:00
|
|
|
if (!tsk->mm)
|
2014-06-04 23:11:02 +00:00
|
|
|
return NULL;
|
2021-02-24 20:06:39 +00:00
|
|
|
/*
|
|
|
|
* Comparing ->mm here because current task might represent
|
|
|
|
* a subthread, while tsk always points to the main thread.
|
|
|
|
*/
|
|
|
|
if (force_early && tsk->mm == current->mm)
|
|
|
|
return current;
|
|
|
|
|
2020-06-12 00:34:45 +00:00
|
|
|
return find_early_kill_thread(tsk);
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Collect processes when the error hit an anonymous page.
|
|
|
|
*/
|
2023-12-18 13:58:35 +00:00
|
|
|
static void collect_procs_anon(struct folio *folio, struct page *page,
|
|
|
|
struct list_head *to_kill, int force_early)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
|
|
|
struct task_struct *tsk;
|
|
|
|
struct anon_vma *av;
|
mm anon rmap: replace same_anon_vma linked list with an interval tree.
When a large VMA (anon or private file mapping) is first touched, which
will populate its anon_vma field, and then split into many regions through
the use of mprotect(), the original anon_vma ends up linking all of the
vmas on a linked list. This can cause rmap to become inefficient, as we
have to walk potentially thousands of irrelevent vmas before finding the
one a given anon page might fall into.
By replacing the same_anon_vma linked list with an interval tree (where
each avc's interval is determined by its vma's start and last pgoffs), we
can make rmap efficient for this use case again.
While the change is large, all of its pieces are fairly simple.
Most places that were walking the same_anon_vma list were looking for a
known pgoff, so they can just use the anon_vma_interval_tree_foreach()
interval tree iterator instead. The exception here is ksm, where the
page's index is not known. It would probably be possible to rework ksm so
that the index would be known, but for now I have decided to keep things
simple and just walk the entirety of the interval tree there.
When updating vma's that already have an anon_vma assigned, we must take
care to re-index the corresponding avc's on their interval tree. This is
done through the use of anon_vma_interval_tree_pre_update_vma() and
anon_vma_interval_tree_post_update_vma(), which remove the avc's from
their interval tree before the update and re-insert them after the update.
The anon_vma stays locked during the update, so there is no chance that
rmap would miss the vmas that are being updated.
Signed-off-by: Michel Lespinasse <walken@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Daniel Santos <daniel.santos@pobox.com>
Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-08 23:31:39 +00:00
|
|
|
pgoff_t pgoff;
|
2009-09-16 09:50:15 +00:00
|
|
|
|
mm: don't be stuck to rmap lock on reclaim path
The rmap locks(i_mmap_rwsem and anon_vma->root->rwsem) could be contended
under memory pressure if processes keep working on their vmas(e.g., fork,
mmap, munmap). It makes reclaim path stuck. In our real workload traces,
we see kswapd is waiting the lock for 300ms+(worst case, a sec) and it
makes other processes entering direct reclaim, which were also stuck on
the lock.
This patch makes lru aging path try_lock mode like shink_page_list so the
reclaim context will keep working with next lru pages without being stuck.
if it found the rmap lock contended, it rotates the page back to head of
lru in both active/inactive lrus to make them consistent behavior, which
is basic starting point rather than adding more heristic.
Since this patch introduces a new "contended" field as out-param along
with try_lock in-param in rmap_walk_control, it's not immutable any longer
if the try_lock is set so remove const keywords on rmap related functions.
Since rmap walking is already expensive operation, I doubt the const
would help sizable benefit( And we didn't have it until 5.17).
In a heavy app workload in Android, trace shows following statistics. It
almost removes rmap lock contention from reclaim path.
Martin Liu reported:
Before:
max_dur(ms) min_dur(ms) max-min(dur)ms avg_dur(ms) sum_dur(ms) count blocked_function
1632 0 1631 151.542173 31672 209 page_lock_anon_vma_read
601 0 601 145.544681 28817 198 rmap_walk_file
After:
max_dur(ms) min_dur(ms) max-min(dur)ms avg_dur(ms) sum_dur(ms) count blocked_function
NaN NaN NaN NaN NaN 0.0 NaN
0 0 0 0.127645 1 12 rmap_walk_file
[minchan@kernel.org: add comment, per Matthew]
Link: https://lkml.kernel.org/r/YnNqeB5tUf6LZ57b@google.com
Link: https://lkml.kernel.org/r/20220510215423.164547-1-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: John Dias <joaodias@google.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Martin Liu <liumartin@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-05-19 21:08:54 +00:00
|
|
|
av = folio_lock_anon_vma_read(folio, NULL);
|
2009-09-16 09:50:15 +00:00
|
|
|
if (av == NULL) /* Not actually mapped anymore */
|
2011-06-27 23:18:09 +00:00
|
|
|
return;
|
|
|
|
|
2014-07-23 21:00:01 +00:00
|
|
|
pgoff = page_to_pgoff(page);
|
mm: memory-failure: use rcu lock instead of tasklist_lock when collect_procs()
We found a softlock issue in our test, analyzed the logs, and found that
the relevant CPU call trace as follows:
CPU0:
_do_fork
-> copy_process()
-> write_lock_irq(&tasklist_lock) //Disable irq,waiting for
//tasklist_lock
CPU1:
wp_page_copy()
->pte_offset_map_lock()
-> spin_lock(&page->ptl); //Hold page->ptl
-> ptep_clear_flush()
-> flush_tlb_others() ...
-> smp_call_function_many()
-> arch_send_call_function_ipi_mask()
-> csd_lock_wait() //Waiting for other CPUs respond
//IPI
CPU2:
collect_procs_anon()
-> read_lock(&tasklist_lock) //Hold tasklist_lock
->for_each_process(tsk)
-> page_mapped_in_vma()
-> page_vma_mapped_walk()
-> map_pte()
->spin_lock(&page->ptl) //Waiting for page->ptl
We can see that CPU1 waiting for CPU0 respond IPI,CPU0 waiting for CPU2
unlock tasklist_lock, CPU2 waiting for CPU1 unlock page->ptl. As a result,
softlockup is triggered.
For collect_procs_anon(), what we're doing is task list iteration, during
the iteration, with the help of call_rcu(), the task_struct object is freed
only after one or more grace periods elapse. the logic as follows:
release_task()
-> __exit_signal()
-> __unhash_process()
-> list_del_rcu()
-> put_task_struct_rcu_user()
-> call_rcu(&task->rcu, delayed_put_task_struct)
delayed_put_task_struct()
-> put_task_struct()
-> if (refcount_sub_and_test())
__put_task_struct()
-> free_task()
Therefore, under the protection of the rcu lock, we can safely use
get_task_struct() to ensure a safe reference to task_struct during the
iteration.
By removing the use of tasklist_lock in task list iteration, we can break
the softlock chain above.
The same logic can also be applied to:
- collect_procs_file()
- collect_procs_fsdax()
- collect_procs_ksm()
Link: https://lkml.kernel.org/r/20230828022527.241693-1-tongtiangen@huawei.com
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-08-28 02:25:27 +00:00
|
|
|
rcu_read_lock();
|
2023-07-11 05:50:14 +00:00
|
|
|
for_each_process(tsk) {
|
2024-04-12 19:35:00 +00:00
|
|
|
struct vm_area_struct *vma;
|
mm: change anon_vma linking to fix multi-process server scalability issue
The old anon_vma code can lead to scalability issues with heavily forking
workloads. Specifically, each anon_vma will be shared between the parent
process and all its child processes.
In a workload with 1000 child processes and a VMA with 1000 anonymous
pages per process that get COWed, this leads to a system with a million
anonymous pages in the same anon_vma, each of which is mapped in just one
of the 1000 processes. However, the current rmap code needs to walk them
all, leading to O(N) scanning complexity for each page.
This can result in systems where one CPU is walking the page tables of
1000 processes in page_referenced_one, while all other CPUs are stuck on
the anon_vma lock. This leads to catastrophic failure for a benchmark
like AIM7, where the total number of processes can reach in the tens of
thousands. Real workloads are still a factor 10 less process intensive
than AIM7, but they are catching up.
This patch changes the way anon_vmas and VMAs are linked, which allows us
to associate multiple anon_vmas with a VMA. At fork time, each child
process gets its own anon_vmas, in which its COWed pages will be
instantiated. The parents' anon_vma is also linked to the VMA, because
non-COWed pages could be present in any of the children.
This reduces rmap scanning complexity to O(1) for the pages of the 1000
child processes, with O(N) complexity for at most 1/N pages in the system.
This reduces the average scanning cost in heavily forking workloads from
O(N) to 2.
The only real complexity in this patch stems from the fact that linking a
VMA to anon_vmas now involves memory allocations. This means vma_adjust
can fail, if it needs to attach a VMA to anon_vma structures. This in
turn means error handling needs to be added to the calling functions.
A second source of complexity is that, because there can be multiple
anon_vmas, the anon_vma linking in vma_adjust can no longer be done under
"the" anon_vma lock. To prevent the rmap code from walking up an
incomplete VMA, this patch introduces the VM_LOCK_RMAP VMA flag. This bit
flag uses the same slot as the NOMMU VM_MAPPED_COPY, with an ifdef in mm.h
to make sure it is impossible to compile a kernel that needs both symbolic
values for the same bitflag.
Some test results:
Without the anon_vma changes, when AIM7 hits around 9.7k users (on a test
box with 16GB RAM and not quite enough IO), the system ends up running
>99% in system time, with every CPU on the same anon_vma lock in the
pageout code.
With these changes, AIM7 hits the cross-over point around 29.7k users.
This happens with ~99% IO wait time, there never seems to be any spike in
system time. The anon_vma lock contention appears to be resolved.
[akpm@linux-foundation.org: cleanups]
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Larry Woodman <lwoodman@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-03-05 21:42:07 +00:00
|
|
|
struct anon_vma_chain *vmac;
|
2014-06-04 23:11:02 +00:00
|
|
|
struct task_struct *t = task_early_kill(tsk, force_early);
|
2024-04-12 19:35:00 +00:00
|
|
|
unsigned long addr;
|
mm: change anon_vma linking to fix multi-process server scalability issue
The old anon_vma code can lead to scalability issues with heavily forking
workloads. Specifically, each anon_vma will be shared between the parent
process and all its child processes.
In a workload with 1000 child processes and a VMA with 1000 anonymous
pages per process that get COWed, this leads to a system with a million
anonymous pages in the same anon_vma, each of which is mapped in just one
of the 1000 processes. However, the current rmap code needs to walk them
all, leading to O(N) scanning complexity for each page.
This can result in systems where one CPU is walking the page tables of
1000 processes in page_referenced_one, while all other CPUs are stuck on
the anon_vma lock. This leads to catastrophic failure for a benchmark
like AIM7, where the total number of processes can reach in the tens of
thousands. Real workloads are still a factor 10 less process intensive
than AIM7, but they are catching up.
This patch changes the way anon_vmas and VMAs are linked, which allows us
to associate multiple anon_vmas with a VMA. At fork time, each child
process gets its own anon_vmas, in which its COWed pages will be
instantiated. The parents' anon_vma is also linked to the VMA, because
non-COWed pages could be present in any of the children.
This reduces rmap scanning complexity to O(1) for the pages of the 1000
child processes, with O(N) complexity for at most 1/N pages in the system.
This reduces the average scanning cost in heavily forking workloads from
O(N) to 2.
The only real complexity in this patch stems from the fact that linking a
VMA to anon_vmas now involves memory allocations. This means vma_adjust
can fail, if it needs to attach a VMA to anon_vma structures. This in
turn means error handling needs to be added to the calling functions.
A second source of complexity is that, because there can be multiple
anon_vmas, the anon_vma linking in vma_adjust can no longer be done under
"the" anon_vma lock. To prevent the rmap code from walking up an
incomplete VMA, this patch introduces the VM_LOCK_RMAP VMA flag. This bit
flag uses the same slot as the NOMMU VM_MAPPED_COPY, with an ifdef in mm.h
to make sure it is impossible to compile a kernel that needs both symbolic
values for the same bitflag.
Some test results:
Without the anon_vma changes, when AIM7 hits around 9.7k users (on a test
box with 16GB RAM and not quite enough IO), the system ends up running
>99% in system time, with every CPU on the same anon_vma lock in the
pageout code.
With these changes, AIM7 hits the cross-over point around 29.7k users.
This happens with ~99% IO wait time, there never seems to be any spike in
system time. The anon_vma lock contention appears to be resolved.
[akpm@linux-foundation.org: cleanups]
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Larry Woodman <lwoodman@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-03-05 21:42:07 +00:00
|
|
|
|
2014-06-04 23:11:02 +00:00
|
|
|
if (!t)
|
2009-09-16 09:50:15 +00:00
|
|
|
continue;
|
mm anon rmap: replace same_anon_vma linked list with an interval tree.
When a large VMA (anon or private file mapping) is first touched, which
will populate its anon_vma field, and then split into many regions through
the use of mprotect(), the original anon_vma ends up linking all of the
vmas on a linked list. This can cause rmap to become inefficient, as we
have to walk potentially thousands of irrelevent vmas before finding the
one a given anon page might fall into.
By replacing the same_anon_vma linked list with an interval tree (where
each avc's interval is determined by its vma's start and last pgoffs), we
can make rmap efficient for this use case again.
While the change is large, all of its pieces are fairly simple.
Most places that were walking the same_anon_vma list were looking for a
known pgoff, so they can just use the anon_vma_interval_tree_foreach()
interval tree iterator instead. The exception here is ksm, where the
page's index is not known. It would probably be possible to rework ksm so
that the index would be known, but for now I have decided to keep things
simple and just walk the entirety of the interval tree there.
When updating vma's that already have an anon_vma assigned, we must take
care to re-index the corresponding avc's on their interval tree. This is
done through the use of anon_vma_interval_tree_pre_update_vma() and
anon_vma_interval_tree_post_update_vma(), which remove the avc's from
their interval tree before the update and re-insert them after the update.
The anon_vma stays locked during the update, so there is no chance that
rmap would miss the vmas that are being updated.
Signed-off-by: Michel Lespinasse <walken@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Daniel Santos <daniel.santos@pobox.com>
Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-08 23:31:39 +00:00
|
|
|
anon_vma_interval_tree_foreach(vmac, &av->rb_root,
|
|
|
|
pgoff, pgoff) {
|
mm: change anon_vma linking to fix multi-process server scalability issue
The old anon_vma code can lead to scalability issues with heavily forking
workloads. Specifically, each anon_vma will be shared between the parent
process and all its child processes.
In a workload with 1000 child processes and a VMA with 1000 anonymous
pages per process that get COWed, this leads to a system with a million
anonymous pages in the same anon_vma, each of which is mapped in just one
of the 1000 processes. However, the current rmap code needs to walk them
all, leading to O(N) scanning complexity for each page.
This can result in systems where one CPU is walking the page tables of
1000 processes in page_referenced_one, while all other CPUs are stuck on
the anon_vma lock. This leads to catastrophic failure for a benchmark
like AIM7, where the total number of processes can reach in the tens of
thousands. Real workloads are still a factor 10 less process intensive
than AIM7, but they are catching up.
This patch changes the way anon_vmas and VMAs are linked, which allows us
to associate multiple anon_vmas with a VMA. At fork time, each child
process gets its own anon_vmas, in which its COWed pages will be
instantiated. The parents' anon_vma is also linked to the VMA, because
non-COWed pages could be present in any of the children.
This reduces rmap scanning complexity to O(1) for the pages of the 1000
child processes, with O(N) complexity for at most 1/N pages in the system.
This reduces the average scanning cost in heavily forking workloads from
O(N) to 2.
The only real complexity in this patch stems from the fact that linking a
VMA to anon_vmas now involves memory allocations. This means vma_adjust
can fail, if it needs to attach a VMA to anon_vma structures. This in
turn means error handling needs to be added to the calling functions.
A second source of complexity is that, because there can be multiple
anon_vmas, the anon_vma linking in vma_adjust can no longer be done under
"the" anon_vma lock. To prevent the rmap code from walking up an
incomplete VMA, this patch introduces the VM_LOCK_RMAP VMA flag. This bit
flag uses the same slot as the NOMMU VM_MAPPED_COPY, with an ifdef in mm.h
to make sure it is impossible to compile a kernel that needs both symbolic
values for the same bitflag.
Some test results:
Without the anon_vma changes, when AIM7 hits around 9.7k users (on a test
box with 16GB RAM and not quite enough IO), the system ends up running
>99% in system time, with every CPU on the same anon_vma lock in the
pageout code.
With these changes, AIM7 hits the cross-over point around 29.7k users.
This happens with ~99% IO wait time, there never seems to be any spike in
system time. The anon_vma lock contention appears to be resolved.
[akpm@linux-foundation.org: cleanups]
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Larry Woodman <lwoodman@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-03-05 21:42:07 +00:00
|
|
|
vma = vmac->vma;
|
2022-08-30 12:36:02 +00:00
|
|
|
if (vma->vm_mm != t->mm)
|
|
|
|
continue;
|
2024-04-12 19:35:00 +00:00
|
|
|
addr = page_mapped_in_vma(page, vma);
|
|
|
|
add_to_kill_anon_file(t, page, vma, to_kill, addr);
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
}
|
mm: memory-failure: use rcu lock instead of tasklist_lock when collect_procs()
We found a softlock issue in our test, analyzed the logs, and found that
the relevant CPU call trace as follows:
CPU0:
_do_fork
-> copy_process()
-> write_lock_irq(&tasklist_lock) //Disable irq,waiting for
//tasklist_lock
CPU1:
wp_page_copy()
->pte_offset_map_lock()
-> spin_lock(&page->ptl); //Hold page->ptl
-> ptep_clear_flush()
-> flush_tlb_others() ...
-> smp_call_function_many()
-> arch_send_call_function_ipi_mask()
-> csd_lock_wait() //Waiting for other CPUs respond
//IPI
CPU2:
collect_procs_anon()
-> read_lock(&tasklist_lock) //Hold tasklist_lock
->for_each_process(tsk)
-> page_mapped_in_vma()
-> page_vma_mapped_walk()
-> map_pte()
->spin_lock(&page->ptl) //Waiting for page->ptl
We can see that CPU1 waiting for CPU0 respond IPI,CPU0 waiting for CPU2
unlock tasklist_lock, CPU2 waiting for CPU1 unlock page->ptl. As a result,
softlockup is triggered.
For collect_procs_anon(), what we're doing is task list iteration, during
the iteration, with the help of call_rcu(), the task_struct object is freed
only after one or more grace periods elapse. the logic as follows:
release_task()
-> __exit_signal()
-> __unhash_process()
-> list_del_rcu()
-> put_task_struct_rcu_user()
-> call_rcu(&task->rcu, delayed_put_task_struct)
delayed_put_task_struct()
-> put_task_struct()
-> if (refcount_sub_and_test())
__put_task_struct()
-> free_task()
Therefore, under the protection of the rcu lock, we can safely use
get_task_struct() to ensure a safe reference to task_struct during the
iteration.
By removing the use of tasklist_lock in task list iteration, we can break
the softlock chain above.
The same logic can also be applied to:
- collect_procs_file()
- collect_procs_fsdax()
- collect_procs_ksm()
Link: https://lkml.kernel.org/r/20230828022527.241693-1-tongtiangen@huawei.com
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-08-28 02:25:27 +00:00
|
|
|
rcu_read_unlock();
|
2022-09-02 19:46:51 +00:00
|
|
|
anon_vma_unlock_read(av);
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Collect processes when the error hit a file mapped page.
|
|
|
|
*/
|
2023-12-18 13:58:35 +00:00
|
|
|
static void collect_procs_file(struct folio *folio, struct page *page,
|
|
|
|
struct list_head *to_kill, int force_early)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
|
|
|
struct vm_area_struct *vma;
|
|
|
|
struct task_struct *tsk;
|
2023-12-18 13:58:35 +00:00
|
|
|
struct address_space *mapping = folio->mapping;
|
2020-10-13 23:54:42 +00:00
|
|
|
pgoff_t pgoff;
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2014-12-13 00:54:36 +00:00
|
|
|
i_mmap_lock_read(mapping);
|
mm: memory-failure: use rcu lock instead of tasklist_lock when collect_procs()
We found a softlock issue in our test, analyzed the logs, and found that
the relevant CPU call trace as follows:
CPU0:
_do_fork
-> copy_process()
-> write_lock_irq(&tasklist_lock) //Disable irq,waiting for
//tasklist_lock
CPU1:
wp_page_copy()
->pte_offset_map_lock()
-> spin_lock(&page->ptl); //Hold page->ptl
-> ptep_clear_flush()
-> flush_tlb_others() ...
-> smp_call_function_many()
-> arch_send_call_function_ipi_mask()
-> csd_lock_wait() //Waiting for other CPUs respond
//IPI
CPU2:
collect_procs_anon()
-> read_lock(&tasklist_lock) //Hold tasklist_lock
->for_each_process(tsk)
-> page_mapped_in_vma()
-> page_vma_mapped_walk()
-> map_pte()
->spin_lock(&page->ptl) //Waiting for page->ptl
We can see that CPU1 waiting for CPU0 respond IPI,CPU0 waiting for CPU2
unlock tasklist_lock, CPU2 waiting for CPU1 unlock page->ptl. As a result,
softlockup is triggered.
For collect_procs_anon(), what we're doing is task list iteration, during
the iteration, with the help of call_rcu(), the task_struct object is freed
only after one or more grace periods elapse. the logic as follows:
release_task()
-> __exit_signal()
-> __unhash_process()
-> list_del_rcu()
-> put_task_struct_rcu_user()
-> call_rcu(&task->rcu, delayed_put_task_struct)
delayed_put_task_struct()
-> put_task_struct()
-> if (refcount_sub_and_test())
__put_task_struct()
-> free_task()
Therefore, under the protection of the rcu lock, we can safely use
get_task_struct() to ensure a safe reference to task_struct during the
iteration.
By removing the use of tasklist_lock in task list iteration, we can break
the softlock chain above.
The same logic can also be applied to:
- collect_procs_file()
- collect_procs_fsdax()
- collect_procs_ksm()
Link: https://lkml.kernel.org/r/20230828022527.241693-1-tongtiangen@huawei.com
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-08-28 02:25:27 +00:00
|
|
|
rcu_read_lock();
|
2020-10-13 23:54:42 +00:00
|
|
|
pgoff = page_to_pgoff(page);
|
2009-09-16 09:50:15 +00:00
|
|
|
for_each_process(tsk) {
|
2014-06-04 23:11:02 +00:00
|
|
|
struct task_struct *t = task_early_kill(tsk, force_early);
|
2024-04-12 19:35:00 +00:00
|
|
|
unsigned long addr;
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2014-06-04 23:11:02 +00:00
|
|
|
if (!t)
|
2009-09-16 09:50:15 +00:00
|
|
|
continue;
|
2012-10-08 23:31:25 +00:00
|
|
|
vma_interval_tree_foreach(vma, &mapping->i_mmap, pgoff,
|
2009-09-16 09:50:15 +00:00
|
|
|
pgoff) {
|
|
|
|
/*
|
|
|
|
* Send early kill signal to tasks where a vma covers
|
|
|
|
* the page but the corrupted page is not necessarily
|
2023-07-11 05:50:14 +00:00
|
|
|
* mapped in its pte.
|
2009-09-16 09:50:15 +00:00
|
|
|
* Assume applications who requested early kill want
|
|
|
|
* to be informed of all such data corruptions.
|
|
|
|
*/
|
2024-04-12 19:35:00 +00:00
|
|
|
if (vma->vm_mm != t->mm)
|
|
|
|
continue;
|
|
|
|
addr = page_address_in_vma(page, vma);
|
|
|
|
add_to_kill_anon_file(t, page, vma, to_kill, addr);
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
}
|
mm: memory-failure: use rcu lock instead of tasklist_lock when collect_procs()
We found a softlock issue in our test, analyzed the logs, and found that
the relevant CPU call trace as follows:
CPU0:
_do_fork
-> copy_process()
-> write_lock_irq(&tasklist_lock) //Disable irq,waiting for
//tasklist_lock
CPU1:
wp_page_copy()
->pte_offset_map_lock()
-> spin_lock(&page->ptl); //Hold page->ptl
-> ptep_clear_flush()
-> flush_tlb_others() ...
-> smp_call_function_many()
-> arch_send_call_function_ipi_mask()
-> csd_lock_wait() //Waiting for other CPUs respond
//IPI
CPU2:
collect_procs_anon()
-> read_lock(&tasklist_lock) //Hold tasklist_lock
->for_each_process(tsk)
-> page_mapped_in_vma()
-> page_vma_mapped_walk()
-> map_pte()
->spin_lock(&page->ptl) //Waiting for page->ptl
We can see that CPU1 waiting for CPU0 respond IPI,CPU0 waiting for CPU2
unlock tasklist_lock, CPU2 waiting for CPU1 unlock page->ptl. As a result,
softlockup is triggered.
For collect_procs_anon(), what we're doing is task list iteration, during
the iteration, with the help of call_rcu(), the task_struct object is freed
only after one or more grace periods elapse. the logic as follows:
release_task()
-> __exit_signal()
-> __unhash_process()
-> list_del_rcu()
-> put_task_struct_rcu_user()
-> call_rcu(&task->rcu, delayed_put_task_struct)
delayed_put_task_struct()
-> put_task_struct()
-> if (refcount_sub_and_test())
__put_task_struct()
-> free_task()
Therefore, under the protection of the rcu lock, we can safely use
get_task_struct() to ensure a safe reference to task_struct during the
iteration.
By removing the use of tasklist_lock in task list iteration, we can break
the softlock chain above.
The same logic can also be applied to:
- collect_procs_file()
- collect_procs_fsdax()
- collect_procs_ksm()
Link: https://lkml.kernel.org/r/20230828022527.241693-1-tongtiangen@huawei.com
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-08-28 02:25:27 +00:00
|
|
|
rcu_read_unlock();
|
2014-12-13 00:54:36 +00:00
|
|
|
i_mmap_unlock_read(mapping);
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
2022-06-03 05:37:29 +00:00
|
|
|
#ifdef CONFIG_FS_DAX
|
mm: memory-failure: refactor add_to_kill()
Patch series "mm: ksm: support hwpoison for ksm page", v2.
Currently, ksm does not support hwpoison. As ksm is being used more
widely for deduplication at the system level, container level, and process
level, supporting hwpoison for ksm has become increasingly important.
However, ksm pages were not processed by hwpoison in 2009 [1].
The main method of implementation:
1. Refactor add_to_kill() and add new add_to_kill_*() to better
accommodate the handling of different types of pages.
2. Add collect_procs_ksm() to collect processes when the error hit an
ksm page.
3. Add task_in_to_kill_list() to avoid duplicate addition of tsk to
the to_kill list.
4. Try_to_unmap ksm page (already supported).
5. Handle related processes such as sending SIGBUS.
Tested with poisoning to ksm page from
1) different process
2) one process
and with/without memory_failure_early_kill set, the processes are killed
as expected with the patchset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?h=01e00f880ca700376e1845cf7a2524ebe68e47d6
This patch (of 2):
The page_address_in_vma() is used to find the user virtual address of page
in add_to_kill(), but it doesn't support ksm due to the ksm page->index
unusable, add an ksm_addr as parameter to add_to_kill(), let's the caller
to pass it, also rename the function to __add_to_kill(), and adding
add_to_kill_anon_file() for handling anonymous pages and file pages,
adding add_to_kill_fsdax() for handling fsdax pages.
Link: https://lkml.kernel.org/r/20230414021741.2597273-1-xialonglong1@huawei.com
Link: https://lkml.kernel.org/r/20230414021741.2597273-2-xialonglong1@huawei.com
Signed-off-by: Longlong Xia <xialonglong1@huawei.com>
Tested-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Nanyong Sun <sunnanyong@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-04-14 02:17:40 +00:00
|
|
|
static void add_to_kill_fsdax(struct task_struct *tsk, struct page *p,
|
|
|
|
struct vm_area_struct *vma,
|
|
|
|
struct list_head *to_kill, pgoff_t pgoff)
|
|
|
|
{
|
2024-04-12 19:34:58 +00:00
|
|
|
unsigned long addr = vma_address(vma, pgoff, 1);
|
|
|
|
__add_to_kill(tsk, p, vma, to_kill, addr);
|
mm: memory-failure: refactor add_to_kill()
Patch series "mm: ksm: support hwpoison for ksm page", v2.
Currently, ksm does not support hwpoison. As ksm is being used more
widely for deduplication at the system level, container level, and process
level, supporting hwpoison for ksm has become increasingly important.
However, ksm pages were not processed by hwpoison in 2009 [1].
The main method of implementation:
1. Refactor add_to_kill() and add new add_to_kill_*() to better
accommodate the handling of different types of pages.
2. Add collect_procs_ksm() to collect processes when the error hit an
ksm page.
3. Add task_in_to_kill_list() to avoid duplicate addition of tsk to
the to_kill list.
4. Try_to_unmap ksm page (already supported).
5. Handle related processes such as sending SIGBUS.
Tested with poisoning to ksm page from
1) different process
2) one process
and with/without memory_failure_early_kill set, the processes are killed
as expected with the patchset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?h=01e00f880ca700376e1845cf7a2524ebe68e47d6
This patch (of 2):
The page_address_in_vma() is used to find the user virtual address of page
in add_to_kill(), but it doesn't support ksm due to the ksm page->index
unusable, add an ksm_addr as parameter to add_to_kill(), let's the caller
to pass it, also rename the function to __add_to_kill(), and adding
add_to_kill_anon_file() for handling anonymous pages and file pages,
adding add_to_kill_fsdax() for handling fsdax pages.
Link: https://lkml.kernel.org/r/20230414021741.2597273-1-xialonglong1@huawei.com
Link: https://lkml.kernel.org/r/20230414021741.2597273-2-xialonglong1@huawei.com
Signed-off-by: Longlong Xia <xialonglong1@huawei.com>
Tested-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Nanyong Sun <sunnanyong@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-04-14 02:17:40 +00:00
|
|
|
}
|
|
|
|
|
2022-06-03 05:37:29 +00:00
|
|
|
/*
|
|
|
|
* Collect processes when the error hit a fsdax page.
|
|
|
|
*/
|
|
|
|
static void collect_procs_fsdax(struct page *page,
|
|
|
|
struct address_space *mapping, pgoff_t pgoff,
|
mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for unbind
Now, if we suddenly remove a PMEM device(by calling unbind) which
contains FSDAX while programs are still accessing data in this device,
e.g.:
```
$FSSTRESS_PROG -d $SCRATCH_MNT -n 99999 -p 4 &
# $FSX_PROG -N 1000000 -o 8192 -l 500000 $SCRATCH_MNT/t001 &
echo "pfn1.1" > /sys/bus/nd/drivers/nd_pmem/unbind
```
it could come into an unacceptable state:
1. device has gone but mount point still exists, and umount will fail
with "target is busy"
2. programs will hang and cannot be killed
3. may crash with NULL pointer dereference
To fix this, we introduce a MF_MEM_PRE_REMOVE flag to let it know that we
are going to remove the whole device, and make sure all related processes
could be notified so that they could end up gracefully.
This patch is inspired by Dan's "mm, dax, pmem: Introduce
dev_pagemap_failure()"[1]. With the help of dax_holder and
->notify_failure() mechanism, the pmem driver is able to ask filesystem
on it to unmap all files in use, and notify processes who are using
those files.
Call trace:
trigger unbind
-> unbind_store()
-> ... (skip)
-> devres_release_all()
-> kill_dax()
-> dax_holder_notify_failure(dax_dev, 0, U64_MAX, MF_MEM_PRE_REMOVE)
-> xfs_dax_notify_failure()
`-> freeze_super() // freeze (kernel call)
`-> do xfs rmap
` -> mf_dax_kill_procs()
` -> collect_procs_fsdax() // all associated processes
` -> unmap_and_kill()
` -> invalidate_inode_pages2_range() // drop file's cache
`-> thaw_super() // thaw (both kernel & user call)
Introduce MF_MEM_PRE_REMOVE to let filesystem know this is a remove
event. Use the exclusive freeze/thaw[2] to lock the filesystem to prevent
new dax mapping from being created. Do not shutdown filesystem directly
if configuration is not supported, or if failure range includes metadata
area. Make sure all files and processes(not only the current progress)
are handled correctly. Also drop the cache of associated files before
pmem is removed.
[1]: https://lore.kernel.org/linux-mm/161604050314.1463742.14151665140035795571.stgit@dwillia2-desk3.amr.corp.intel.com/
[2]: https://lore.kernel.org/linux-xfs/169116275623.3187159.16862410128731457358.stg-ugh@frogsfrogsfrogs/
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
2023-10-23 07:20:46 +00:00
|
|
|
struct list_head *to_kill, bool pre_remove)
|
2022-06-03 05:37:29 +00:00
|
|
|
{
|
|
|
|
struct vm_area_struct *vma;
|
|
|
|
struct task_struct *tsk;
|
|
|
|
|
|
|
|
i_mmap_lock_read(mapping);
|
mm: memory-failure: use rcu lock instead of tasklist_lock when collect_procs()
We found a softlock issue in our test, analyzed the logs, and found that
the relevant CPU call trace as follows:
CPU0:
_do_fork
-> copy_process()
-> write_lock_irq(&tasklist_lock) //Disable irq,waiting for
//tasklist_lock
CPU1:
wp_page_copy()
->pte_offset_map_lock()
-> spin_lock(&page->ptl); //Hold page->ptl
-> ptep_clear_flush()
-> flush_tlb_others() ...
-> smp_call_function_many()
-> arch_send_call_function_ipi_mask()
-> csd_lock_wait() //Waiting for other CPUs respond
//IPI
CPU2:
collect_procs_anon()
-> read_lock(&tasklist_lock) //Hold tasklist_lock
->for_each_process(tsk)
-> page_mapped_in_vma()
-> page_vma_mapped_walk()
-> map_pte()
->spin_lock(&page->ptl) //Waiting for page->ptl
We can see that CPU1 waiting for CPU0 respond IPI,CPU0 waiting for CPU2
unlock tasklist_lock, CPU2 waiting for CPU1 unlock page->ptl. As a result,
softlockup is triggered.
For collect_procs_anon(), what we're doing is task list iteration, during
the iteration, with the help of call_rcu(), the task_struct object is freed
only after one or more grace periods elapse. the logic as follows:
release_task()
-> __exit_signal()
-> __unhash_process()
-> list_del_rcu()
-> put_task_struct_rcu_user()
-> call_rcu(&task->rcu, delayed_put_task_struct)
delayed_put_task_struct()
-> put_task_struct()
-> if (refcount_sub_and_test())
__put_task_struct()
-> free_task()
Therefore, under the protection of the rcu lock, we can safely use
get_task_struct() to ensure a safe reference to task_struct during the
iteration.
By removing the use of tasklist_lock in task list iteration, we can break
the softlock chain above.
The same logic can also be applied to:
- collect_procs_file()
- collect_procs_fsdax()
- collect_procs_ksm()
Link: https://lkml.kernel.org/r/20230828022527.241693-1-tongtiangen@huawei.com
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-08-28 02:25:27 +00:00
|
|
|
rcu_read_lock();
|
2022-06-03 05:37:29 +00:00
|
|
|
for_each_process(tsk) {
|
mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for unbind
Now, if we suddenly remove a PMEM device(by calling unbind) which
contains FSDAX while programs are still accessing data in this device,
e.g.:
```
$FSSTRESS_PROG -d $SCRATCH_MNT -n 99999 -p 4 &
# $FSX_PROG -N 1000000 -o 8192 -l 500000 $SCRATCH_MNT/t001 &
echo "pfn1.1" > /sys/bus/nd/drivers/nd_pmem/unbind
```
it could come into an unacceptable state:
1. device has gone but mount point still exists, and umount will fail
with "target is busy"
2. programs will hang and cannot be killed
3. may crash with NULL pointer dereference
To fix this, we introduce a MF_MEM_PRE_REMOVE flag to let it know that we
are going to remove the whole device, and make sure all related processes
could be notified so that they could end up gracefully.
This patch is inspired by Dan's "mm, dax, pmem: Introduce
dev_pagemap_failure()"[1]. With the help of dax_holder and
->notify_failure() mechanism, the pmem driver is able to ask filesystem
on it to unmap all files in use, and notify processes who are using
those files.
Call trace:
trigger unbind
-> unbind_store()
-> ... (skip)
-> devres_release_all()
-> kill_dax()
-> dax_holder_notify_failure(dax_dev, 0, U64_MAX, MF_MEM_PRE_REMOVE)
-> xfs_dax_notify_failure()
`-> freeze_super() // freeze (kernel call)
`-> do xfs rmap
` -> mf_dax_kill_procs()
` -> collect_procs_fsdax() // all associated processes
` -> unmap_and_kill()
` -> invalidate_inode_pages2_range() // drop file's cache
`-> thaw_super() // thaw (both kernel & user call)
Introduce MF_MEM_PRE_REMOVE to let filesystem know this is a remove
event. Use the exclusive freeze/thaw[2] to lock the filesystem to prevent
new dax mapping from being created. Do not shutdown filesystem directly
if configuration is not supported, or if failure range includes metadata
area. Make sure all files and processes(not only the current progress)
are handled correctly. Also drop the cache of associated files before
pmem is removed.
[1]: https://lore.kernel.org/linux-mm/161604050314.1463742.14151665140035795571.stgit@dwillia2-desk3.amr.corp.intel.com/
[2]: https://lore.kernel.org/linux-xfs/169116275623.3187159.16862410128731457358.stg-ugh@frogsfrogsfrogs/
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
2023-10-23 07:20:46 +00:00
|
|
|
struct task_struct *t = tsk;
|
2022-06-03 05:37:29 +00:00
|
|
|
|
mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for unbind
Now, if we suddenly remove a PMEM device(by calling unbind) which
contains FSDAX while programs are still accessing data in this device,
e.g.:
```
$FSSTRESS_PROG -d $SCRATCH_MNT -n 99999 -p 4 &
# $FSX_PROG -N 1000000 -o 8192 -l 500000 $SCRATCH_MNT/t001 &
echo "pfn1.1" > /sys/bus/nd/drivers/nd_pmem/unbind
```
it could come into an unacceptable state:
1. device has gone but mount point still exists, and umount will fail
with "target is busy"
2. programs will hang and cannot be killed
3. may crash with NULL pointer dereference
To fix this, we introduce a MF_MEM_PRE_REMOVE flag to let it know that we
are going to remove the whole device, and make sure all related processes
could be notified so that they could end up gracefully.
This patch is inspired by Dan's "mm, dax, pmem: Introduce
dev_pagemap_failure()"[1]. With the help of dax_holder and
->notify_failure() mechanism, the pmem driver is able to ask filesystem
on it to unmap all files in use, and notify processes who are using
those files.
Call trace:
trigger unbind
-> unbind_store()
-> ... (skip)
-> devres_release_all()
-> kill_dax()
-> dax_holder_notify_failure(dax_dev, 0, U64_MAX, MF_MEM_PRE_REMOVE)
-> xfs_dax_notify_failure()
`-> freeze_super() // freeze (kernel call)
`-> do xfs rmap
` -> mf_dax_kill_procs()
` -> collect_procs_fsdax() // all associated processes
` -> unmap_and_kill()
` -> invalidate_inode_pages2_range() // drop file's cache
`-> thaw_super() // thaw (both kernel & user call)
Introduce MF_MEM_PRE_REMOVE to let filesystem know this is a remove
event. Use the exclusive freeze/thaw[2] to lock the filesystem to prevent
new dax mapping from being created. Do not shutdown filesystem directly
if configuration is not supported, or if failure range includes metadata
area. Make sure all files and processes(not only the current progress)
are handled correctly. Also drop the cache of associated files before
pmem is removed.
[1]: https://lore.kernel.org/linux-mm/161604050314.1463742.14151665140035795571.stgit@dwillia2-desk3.amr.corp.intel.com/
[2]: https://lore.kernel.org/linux-xfs/169116275623.3187159.16862410128731457358.stg-ugh@frogsfrogsfrogs/
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
2023-10-23 07:20:46 +00:00
|
|
|
/*
|
|
|
|
* Search for all tasks while MF_MEM_PRE_REMOVE is set, because
|
|
|
|
* the current may not be the one accessing the fsdax page.
|
|
|
|
* Otherwise, search for the current task.
|
|
|
|
*/
|
|
|
|
if (!pre_remove)
|
|
|
|
t = task_early_kill(tsk, true);
|
2022-06-03 05:37:29 +00:00
|
|
|
if (!t)
|
|
|
|
continue;
|
|
|
|
vma_interval_tree_foreach(vma, &mapping->i_mmap, pgoff, pgoff) {
|
|
|
|
if (vma->vm_mm == t->mm)
|
mm: memory-failure: refactor add_to_kill()
Patch series "mm: ksm: support hwpoison for ksm page", v2.
Currently, ksm does not support hwpoison. As ksm is being used more
widely for deduplication at the system level, container level, and process
level, supporting hwpoison for ksm has become increasingly important.
However, ksm pages were not processed by hwpoison in 2009 [1].
The main method of implementation:
1. Refactor add_to_kill() and add new add_to_kill_*() to better
accommodate the handling of different types of pages.
2. Add collect_procs_ksm() to collect processes when the error hit an
ksm page.
3. Add task_in_to_kill_list() to avoid duplicate addition of tsk to
the to_kill list.
4. Try_to_unmap ksm page (already supported).
5. Handle related processes such as sending SIGBUS.
Tested with poisoning to ksm page from
1) different process
2) one process
and with/without memory_failure_early_kill set, the processes are killed
as expected with the patchset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?h=01e00f880ca700376e1845cf7a2524ebe68e47d6
This patch (of 2):
The page_address_in_vma() is used to find the user virtual address of page
in add_to_kill(), but it doesn't support ksm due to the ksm page->index
unusable, add an ksm_addr as parameter to add_to_kill(), let's the caller
to pass it, also rename the function to __add_to_kill(), and adding
add_to_kill_anon_file() for handling anonymous pages and file pages,
adding add_to_kill_fsdax() for handling fsdax pages.
Link: https://lkml.kernel.org/r/20230414021741.2597273-1-xialonglong1@huawei.com
Link: https://lkml.kernel.org/r/20230414021741.2597273-2-xialonglong1@huawei.com
Signed-off-by: Longlong Xia <xialonglong1@huawei.com>
Tested-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Nanyong Sun <sunnanyong@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-04-14 02:17:40 +00:00
|
|
|
add_to_kill_fsdax(t, page, vma, to_kill, pgoff);
|
2022-06-03 05:37:29 +00:00
|
|
|
}
|
|
|
|
}
|
mm: memory-failure: use rcu lock instead of tasklist_lock when collect_procs()
We found a softlock issue in our test, analyzed the logs, and found that
the relevant CPU call trace as follows:
CPU0:
_do_fork
-> copy_process()
-> write_lock_irq(&tasklist_lock) //Disable irq,waiting for
//tasklist_lock
CPU1:
wp_page_copy()
->pte_offset_map_lock()
-> spin_lock(&page->ptl); //Hold page->ptl
-> ptep_clear_flush()
-> flush_tlb_others() ...
-> smp_call_function_many()
-> arch_send_call_function_ipi_mask()
-> csd_lock_wait() //Waiting for other CPUs respond
//IPI
CPU2:
collect_procs_anon()
-> read_lock(&tasklist_lock) //Hold tasklist_lock
->for_each_process(tsk)
-> page_mapped_in_vma()
-> page_vma_mapped_walk()
-> map_pte()
->spin_lock(&page->ptl) //Waiting for page->ptl
We can see that CPU1 waiting for CPU0 respond IPI,CPU0 waiting for CPU2
unlock tasklist_lock, CPU2 waiting for CPU1 unlock page->ptl. As a result,
softlockup is triggered.
For collect_procs_anon(), what we're doing is task list iteration, during
the iteration, with the help of call_rcu(), the task_struct object is freed
only after one or more grace periods elapse. the logic as follows:
release_task()
-> __exit_signal()
-> __unhash_process()
-> list_del_rcu()
-> put_task_struct_rcu_user()
-> call_rcu(&task->rcu, delayed_put_task_struct)
delayed_put_task_struct()
-> put_task_struct()
-> if (refcount_sub_and_test())
__put_task_struct()
-> free_task()
Therefore, under the protection of the rcu lock, we can safely use
get_task_struct() to ensure a safe reference to task_struct during the
iteration.
By removing the use of tasklist_lock in task list iteration, we can break
the softlock chain above.
The same logic can also be applied to:
- collect_procs_file()
- collect_procs_fsdax()
- collect_procs_ksm()
Link: https://lkml.kernel.org/r/20230828022527.241693-1-tongtiangen@huawei.com
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-08-28 02:25:27 +00:00
|
|
|
rcu_read_unlock();
|
2022-06-03 05:37:29 +00:00
|
|
|
i_mmap_unlock_read(mapping);
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_FS_DAX */
|
|
|
|
|
2009-09-16 09:50:15 +00:00
|
|
|
/*
|
|
|
|
* Collect the processes who have the corrupted page mapped to kill.
|
|
|
|
*/
|
2023-12-18 13:58:35 +00:00
|
|
|
static void collect_procs(struct folio *folio, struct page *page,
|
|
|
|
struct list_head *tokill, int force_early)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
2023-12-18 13:58:35 +00:00
|
|
|
if (!folio->mapping)
|
2009-09-16 09:50:15 +00:00
|
|
|
return;
|
2024-04-12 19:35:07 +00:00
|
|
|
if (unlikely(folio_test_ksm(folio)))
|
2024-04-12 19:35:08 +00:00
|
|
|
collect_procs_ksm(folio, page, tokill, force_early);
|
2024-04-12 19:35:07 +00:00
|
|
|
else if (folio_test_anon(folio))
|
2023-12-18 13:58:35 +00:00
|
|
|
collect_procs_anon(folio, page, tokill, force_early);
|
2009-09-16 09:50:15 +00:00
|
|
|
else
|
2023-12-18 13:58:35 +00:00
|
|
|
collect_procs_file(folio, page, tokill, force_early);
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
mm/hwpoison: rename hwp_walk* to hwpoison_walk*
In the discussion of "Improve hugetlbfs read on HWPOISON hugepages" [1],
Matthew Wilcox suggests hwp is a bad abbreviation of hwpoison, as hwp is
already used as "an acronym by acpi, intel_pstate, some clock drivers, an
ethernet driver, and a scsi driver"[1].
So rename hwp_walk and hwp_walk_ops to hwpoison_walk and
hwpoison_walk_ops respectively.
raw_hwp_(page|list), *_raw_hwp, and raw_hwp_unreliable flag are other
major appearances of "hwp". However, given the "raw" hint in the name, it
is easy to differentiate them from other "hwp" acronyms. Since renaming
them is not as straightforward as renaming hwp_walk*, they are not covered
by this commit.
[1] https://lore.kernel.org/lkml/20230707201904.953262-5-jiaqiyan@google.com/T/#me6fecb8ce1ad4d5769199c9e162a44bc88f7bdec
Link: https://lkml.kernel.org/r/20230713235553.4121855-1-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-07-13 23:55:53 +00:00
|
|
|
struct hwpoison_walk {
|
2021-06-29 02:43:14 +00:00
|
|
|
struct to_kill tk;
|
|
|
|
unsigned long pfn;
|
|
|
|
int flags;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void set_to_kill(struct to_kill *tk, unsigned long addr, short shift)
|
|
|
|
{
|
|
|
|
tk->addr = addr;
|
|
|
|
tk->size_shift = shift;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int check_hwpoisoned_entry(pte_t pte, unsigned long addr, short shift,
|
|
|
|
unsigned long poisoned_pfn, struct to_kill *tk)
|
|
|
|
{
|
|
|
|
unsigned long pfn = 0;
|
|
|
|
|
|
|
|
if (pte_present(pte)) {
|
|
|
|
pfn = pte_pfn(pte);
|
|
|
|
} else {
|
|
|
|
swp_entry_t swp = pte_to_swp_entry(pte);
|
|
|
|
|
|
|
|
if (is_hwpoison_entry(swp))
|
mm/swap: add swp_offset_pfn() to fetch PFN from swap entry
We've got a bunch of special swap entries that stores PFN inside the swap
offset fields. To fetch the PFN, normally the user just calls
swp_offset() assuming that'll be the PFN.
Add a helper swp_offset_pfn() to fetch the PFN instead, fetching only the
max possible length of a PFN on the host, meanwhile doing proper check
with MAX_PHYSMEM_BITS to make sure the swap offsets can actually store the
PFNs properly always using the BUILD_BUG_ON() in is_pfn_swap_entry().
One reason to do so is we never tried to sanitize whether swap offset can
really fit for storing PFN. At the meantime, this patch also prepares us
with the future possibility to store more information inside the swp
offset field, so assuming "swp_offset(entry)" to be the PFN will not stand
any more very soon.
Replace many of the swp_offset() callers to use swp_offset_pfn() where
proper. Note that many of the existing users are not candidates for the
replacement, e.g.:
(1) When the swap entry is not a pfn swap entry at all, or,
(2) when we wanna keep the whole swp_offset but only change the swp type.
For the latter, it can happen when fork() triggered on a write-migration
swap entry pte, we may want to only change the migration type from
write->read but keep the rest, so it's not "fetching PFN" but "changing
swap type only". They're left aside so that when there're more
information within the swp offset they'll be carried over naturally in
those cases.
Since at it, dropping hwpoison_entry_to_pfn() because that's exactly what
the new swp_offset_pfn() is about.
Link: https://lkml.kernel.org/r/20220811161331.37055-4-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: "Huang, Ying" <ying.huang@intel.com>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Andi Kleen <andi.kleen@intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: "Kirill A . Shutemov" <kirill@shutemov.name>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-08-11 16:13:27 +00:00
|
|
|
pfn = swp_offset_pfn(swp);
|
2021-06-29 02:43:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!pfn || pfn != poisoned_pfn)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
set_to_kill(tk, addr, shift);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
|
|
|
|
static int check_hwpoisoned_pmd_entry(pmd_t *pmdp, unsigned long addr,
|
mm/hwpoison: rename hwp_walk* to hwpoison_walk*
In the discussion of "Improve hugetlbfs read on HWPOISON hugepages" [1],
Matthew Wilcox suggests hwp is a bad abbreviation of hwpoison, as hwp is
already used as "an acronym by acpi, intel_pstate, some clock drivers, an
ethernet driver, and a scsi driver"[1].
So rename hwp_walk and hwp_walk_ops to hwpoison_walk and
hwpoison_walk_ops respectively.
raw_hwp_(page|list), *_raw_hwp, and raw_hwp_unreliable flag are other
major appearances of "hwp". However, given the "raw" hint in the name, it
is easy to differentiate them from other "hwp" acronyms. Since renaming
them is not as straightforward as renaming hwp_walk*, they are not covered
by this commit.
[1] https://lore.kernel.org/lkml/20230707201904.953262-5-jiaqiyan@google.com/T/#me6fecb8ce1ad4d5769199c9e162a44bc88f7bdec
Link: https://lkml.kernel.org/r/20230713235553.4121855-1-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-07-13 23:55:53 +00:00
|
|
|
struct hwpoison_walk *hwp)
|
2021-06-29 02:43:14 +00:00
|
|
|
{
|
|
|
|
pmd_t pmd = *pmdp;
|
|
|
|
unsigned long pfn;
|
|
|
|
unsigned long hwpoison_vaddr;
|
|
|
|
|
|
|
|
if (!pmd_present(pmd))
|
|
|
|
return 0;
|
|
|
|
pfn = pmd_pfn(pmd);
|
|
|
|
if (pfn <= hwp->pfn && hwp->pfn < pfn + HPAGE_PMD_NR) {
|
|
|
|
hwpoison_vaddr = addr + ((hwp->pfn - pfn) << PAGE_SHIFT);
|
|
|
|
set_to_kill(&hwp->tk, hwpoison_vaddr, PAGE_SHIFT);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static int check_hwpoisoned_pmd_entry(pmd_t *pmdp, unsigned long addr,
|
mm/hwpoison: rename hwp_walk* to hwpoison_walk*
In the discussion of "Improve hugetlbfs read on HWPOISON hugepages" [1],
Matthew Wilcox suggests hwp is a bad abbreviation of hwpoison, as hwp is
already used as "an acronym by acpi, intel_pstate, some clock drivers, an
ethernet driver, and a scsi driver"[1].
So rename hwp_walk and hwp_walk_ops to hwpoison_walk and
hwpoison_walk_ops respectively.
raw_hwp_(page|list), *_raw_hwp, and raw_hwp_unreliable flag are other
major appearances of "hwp". However, given the "raw" hint in the name, it
is easy to differentiate them from other "hwp" acronyms. Since renaming
them is not as straightforward as renaming hwp_walk*, they are not covered
by this commit.
[1] https://lore.kernel.org/lkml/20230707201904.953262-5-jiaqiyan@google.com/T/#me6fecb8ce1ad4d5769199c9e162a44bc88f7bdec
Link: https://lkml.kernel.org/r/20230713235553.4121855-1-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-07-13 23:55:53 +00:00
|
|
|
struct hwpoison_walk *hwp)
|
2021-06-29 02:43:14 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static int hwpoison_pte_range(pmd_t *pmdp, unsigned long addr,
|
|
|
|
unsigned long end, struct mm_walk *walk)
|
|
|
|
{
|
mm/hwpoison: rename hwp_walk* to hwpoison_walk*
In the discussion of "Improve hugetlbfs read on HWPOISON hugepages" [1],
Matthew Wilcox suggests hwp is a bad abbreviation of hwpoison, as hwp is
already used as "an acronym by acpi, intel_pstate, some clock drivers, an
ethernet driver, and a scsi driver"[1].
So rename hwp_walk and hwp_walk_ops to hwpoison_walk and
hwpoison_walk_ops respectively.
raw_hwp_(page|list), *_raw_hwp, and raw_hwp_unreliable flag are other
major appearances of "hwp". However, given the "raw" hint in the name, it
is easy to differentiate them from other "hwp" acronyms. Since renaming
them is not as straightforward as renaming hwp_walk*, they are not covered
by this commit.
[1] https://lore.kernel.org/lkml/20230707201904.953262-5-jiaqiyan@google.com/T/#me6fecb8ce1ad4d5769199c9e162a44bc88f7bdec
Link: https://lkml.kernel.org/r/20230713235553.4121855-1-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-07-13 23:55:53 +00:00
|
|
|
struct hwpoison_walk *hwp = walk->private;
|
2021-06-29 02:43:14 +00:00
|
|
|
int ret = 0;
|
2021-09-02 21:58:22 +00:00
|
|
|
pte_t *ptep, *mapped_pte;
|
2021-06-29 02:43:14 +00:00
|
|
|
spinlock_t *ptl;
|
|
|
|
|
|
|
|
ptl = pmd_trans_huge_lock(pmdp, walk->vma);
|
|
|
|
if (ptl) {
|
|
|
|
ret = check_hwpoisoned_pmd_entry(pmdp, addr, hwp);
|
|
|
|
spin_unlock(ptl);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2021-09-02 21:58:22 +00:00
|
|
|
mapped_pte = ptep = pte_offset_map_lock(walk->vma->vm_mm, pmdp,
|
|
|
|
addr, &ptl);
|
2023-06-09 01:29:22 +00:00
|
|
|
if (!ptep)
|
|
|
|
goto out;
|
|
|
|
|
2021-06-29 02:43:14 +00:00
|
|
|
for (; addr != end; ptep++, addr += PAGE_SIZE) {
|
mm: ptep_get() conversion
Convert all instances of direct pte_t* dereferencing to instead use
ptep_get() helper. This means that by default, the accesses change from a
C dereference to a READ_ONCE(). This is technically the correct thing to
do since where pgtables are modified by HW (for access/dirty) they are
volatile and therefore we should always ensure READ_ONCE() semantics.
But more importantly, by always using the helper, it can be overridden by
the architecture to fully encapsulate the contents of the pte. Arch code
is deliberately not converted, as the arch code knows best. It is
intended that arch code (arm64) will override the default with its own
implementation that can (e.g.) hide certain bits from the core code, or
determine young/dirty status by mixing in state from another source.
Conversion was done using Coccinelle:
----
// $ make coccicheck \
// COCCI=ptepget.cocci \
// SPFLAGS="--include-headers" \
// MODE=patch
virtual patch
@ depends on patch @
pte_t *v;
@@
- *v
+ ptep_get(v)
----
Then reviewed and hand-edited to avoid multiple unnecessary calls to
ptep_get(), instead opting to store the result of a single call in a
variable, where it is correct to do so. This aims to negate any cost of
READ_ONCE() and will benefit arch-overrides that may be more complex.
Included is a fix for an issue in an earlier version of this patch that
was pointed out by kernel test robot. The issue arose because config
MMU=n elides definition of the ptep helper functions, including
ptep_get(). HUGETLB_PAGE=n configs still define a simple
huge_ptep_clear_flush() for linking purposes, which dereferences the ptep.
So when both configs are disabled, this caused a build error because
ptep_get() is not defined. Fix by continuing to do a direct dereference
when MMU=n. This is safe because for this config the arch code cannot be
trying to virtualize the ptes because none of the ptep helpers are
defined.
Link: https://lkml.kernel.org/r/20230612151545.3317766-4-ryan.roberts@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202305120142.yXsNEo6H-lkp@intel.com/
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport (IBM) <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: SeongJae Park <sj@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-12 15:15:45 +00:00
|
|
|
ret = check_hwpoisoned_entry(ptep_get(ptep), addr, PAGE_SHIFT,
|
2021-06-29 02:43:14 +00:00
|
|
|
hwp->pfn, &hwp->tk);
|
|
|
|
if (ret == 1)
|
|
|
|
break;
|
|
|
|
}
|
2021-09-02 21:58:22 +00:00
|
|
|
pte_unmap_unlock(mapped_pte, ptl);
|
2021-06-29 02:43:14 +00:00
|
|
|
out:
|
|
|
|
cond_resched();
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_HUGETLB_PAGE
|
|
|
|
static int hwpoison_hugetlb_range(pte_t *ptep, unsigned long hmask,
|
|
|
|
unsigned long addr, unsigned long end,
|
|
|
|
struct mm_walk *walk)
|
|
|
|
{
|
mm/hwpoison: rename hwp_walk* to hwpoison_walk*
In the discussion of "Improve hugetlbfs read on HWPOISON hugepages" [1],
Matthew Wilcox suggests hwp is a bad abbreviation of hwpoison, as hwp is
already used as "an acronym by acpi, intel_pstate, some clock drivers, an
ethernet driver, and a scsi driver"[1].
So rename hwp_walk and hwp_walk_ops to hwpoison_walk and
hwpoison_walk_ops respectively.
raw_hwp_(page|list), *_raw_hwp, and raw_hwp_unreliable flag are other
major appearances of "hwp". However, given the "raw" hint in the name, it
is easy to differentiate them from other "hwp" acronyms. Since renaming
them is not as straightforward as renaming hwp_walk*, they are not covered
by this commit.
[1] https://lore.kernel.org/lkml/20230707201904.953262-5-jiaqiyan@google.com/T/#me6fecb8ce1ad4d5769199c9e162a44bc88f7bdec
Link: https://lkml.kernel.org/r/20230713235553.4121855-1-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-07-13 23:55:53 +00:00
|
|
|
struct hwpoison_walk *hwp = walk->private;
|
2024-07-02 13:51:20 +00:00
|
|
|
pte_t pte = huge_ptep_get(walk->mm, addr, ptep);
|
2021-06-29 02:43:14 +00:00
|
|
|
struct hstate *h = hstate_vma(walk->vma);
|
|
|
|
|
|
|
|
return check_hwpoisoned_entry(pte, addr, huge_page_shift(h),
|
|
|
|
hwp->pfn, &hwp->tk);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
#define hwpoison_hugetlb_range NULL
|
|
|
|
#endif
|
|
|
|
|
mm/hwpoison: rename hwp_walk* to hwpoison_walk*
In the discussion of "Improve hugetlbfs read on HWPOISON hugepages" [1],
Matthew Wilcox suggests hwp is a bad abbreviation of hwpoison, as hwp is
already used as "an acronym by acpi, intel_pstate, some clock drivers, an
ethernet driver, and a scsi driver"[1].
So rename hwp_walk and hwp_walk_ops to hwpoison_walk and
hwpoison_walk_ops respectively.
raw_hwp_(page|list), *_raw_hwp, and raw_hwp_unreliable flag are other
major appearances of "hwp". However, given the "raw" hint in the name, it
is easy to differentiate them from other "hwp" acronyms. Since renaming
them is not as straightforward as renaming hwp_walk*, they are not covered
by this commit.
[1] https://lore.kernel.org/lkml/20230707201904.953262-5-jiaqiyan@google.com/T/#me6fecb8ce1ad4d5769199c9e162a44bc88f7bdec
Link: https://lkml.kernel.org/r/20230713235553.4121855-1-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-07-13 23:55:53 +00:00
|
|
|
static const struct mm_walk_ops hwpoison_walk_ops = {
|
2021-06-29 02:43:14 +00:00
|
|
|
.pmd_entry = hwpoison_pte_range,
|
|
|
|
.hugetlb_entry = hwpoison_hugetlb_range,
|
2023-08-04 15:27:19 +00:00
|
|
|
.walk_lock = PGWALK_RDLOCK,
|
2021-06-29 02:43:14 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Sends SIGBUS to the current process with error info.
|
|
|
|
*
|
|
|
|
* This function is intended to handle "Action Required" MCEs on already
|
|
|
|
* hardware poisoned pages. They could happen, for example, when
|
|
|
|
* memory_failure() failed to unmap the error page at the first call, or
|
|
|
|
* when multiple local machine checks happened on different CPUs.
|
|
|
|
*
|
|
|
|
* MCE handler currently has no easy access to the error virtual address,
|
|
|
|
* so this function walks page table to find it. The returned virtual address
|
|
|
|
* is proper in most cases, but it could be wrong when the application
|
|
|
|
* process has multiple entries mapping the error page.
|
|
|
|
*/
|
|
|
|
static int kill_accessing_process(struct task_struct *p, unsigned long pfn,
|
|
|
|
int flags)
|
|
|
|
{
|
|
|
|
int ret;
|
mm/hwpoison: rename hwp_walk* to hwpoison_walk*
In the discussion of "Improve hugetlbfs read on HWPOISON hugepages" [1],
Matthew Wilcox suggests hwp is a bad abbreviation of hwpoison, as hwp is
already used as "an acronym by acpi, intel_pstate, some clock drivers, an
ethernet driver, and a scsi driver"[1].
So rename hwp_walk and hwp_walk_ops to hwpoison_walk and
hwpoison_walk_ops respectively.
raw_hwp_(page|list), *_raw_hwp, and raw_hwp_unreliable flag are other
major appearances of "hwp". However, given the "raw" hint in the name, it
is easy to differentiate them from other "hwp" acronyms. Since renaming
them is not as straightforward as renaming hwp_walk*, they are not covered
by this commit.
[1] https://lore.kernel.org/lkml/20230707201904.953262-5-jiaqiyan@google.com/T/#me6fecb8ce1ad4d5769199c9e162a44bc88f7bdec
Link: https://lkml.kernel.org/r/20230713235553.4121855-1-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-07-13 23:55:53 +00:00
|
|
|
struct hwpoison_walk priv = {
|
2021-06-29 02:43:14 +00:00
|
|
|
.pfn = pfn,
|
|
|
|
};
|
|
|
|
priv.tk.tsk = p;
|
|
|
|
|
2022-09-14 06:49:35 +00:00
|
|
|
if (!p->mm)
|
|
|
|
return -EFAULT;
|
|
|
|
|
2021-06-29 02:43:14 +00:00
|
|
|
mmap_read_lock(p->mm);
|
mm/hwpoison: rename hwp_walk* to hwpoison_walk*
In the discussion of "Improve hugetlbfs read on HWPOISON hugepages" [1],
Matthew Wilcox suggests hwp is a bad abbreviation of hwpoison, as hwp is
already used as "an acronym by acpi, intel_pstate, some clock drivers, an
ethernet driver, and a scsi driver"[1].
So rename hwp_walk and hwp_walk_ops to hwpoison_walk and
hwpoison_walk_ops respectively.
raw_hwp_(page|list), *_raw_hwp, and raw_hwp_unreliable flag are other
major appearances of "hwp". However, given the "raw" hint in the name, it
is easy to differentiate them from other "hwp" acronyms. Since renaming
them is not as straightforward as renaming hwp_walk*, they are not covered
by this commit.
[1] https://lore.kernel.org/lkml/20230707201904.953262-5-jiaqiyan@google.com/T/#me6fecb8ce1ad4d5769199c9e162a44bc88f7bdec
Link: https://lkml.kernel.org/r/20230713235553.4121855-1-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-07-13 23:55:53 +00:00
|
|
|
ret = walk_page_range(p->mm, 0, TASK_SIZE, &hwpoison_walk_ops,
|
2021-06-29 02:43:14 +00:00
|
|
|
(void *)&priv);
|
|
|
|
if (ret == 1 && priv.tk.addr)
|
|
|
|
kill_proc(&priv.tk, pfn, flags);
|
2022-03-22 21:44:06 +00:00
|
|
|
else
|
|
|
|
ret = 0;
|
2021-06-29 02:43:14 +00:00
|
|
|
mmap_read_unlock(p->mm);
|
2022-03-22 21:44:06 +00:00
|
|
|
return ret > 0 ? -EHWPOISON : -EFAULT;
|
2021-06-29 02:43:14 +00:00
|
|
|
}
|
|
|
|
|
2024-05-24 21:53:04 +00:00
|
|
|
/*
|
|
|
|
* MF_IGNORED - The m-f() handler marks the page as PG_hwpoisoned'ed.
|
|
|
|
* But it could not do more to isolate the page from being accessed again,
|
|
|
|
* nor does it kill the process. This is extremely rare and one of the
|
|
|
|
* potential causes is that the page state has been changed due to
|
|
|
|
* underlying race condition. This is the most severe outcomes.
|
|
|
|
*
|
|
|
|
* MF_FAILED - The m-f() handler marks the page as PG_hwpoisoned'ed.
|
|
|
|
* It should have killed the process, but it can't isolate the page,
|
|
|
|
* due to conditions such as extra pin, unmap failure, etc. Accessing
|
|
|
|
* the page again may trigger another MCE and the process will be killed
|
|
|
|
* by the m-f() handler immediately.
|
|
|
|
*
|
|
|
|
* MF_DELAYED - The m-f() handler marks the page as PG_hwpoisoned'ed.
|
|
|
|
* The page is unmapped, and is removed from the LRU or file mapping.
|
|
|
|
* An attempt to access the page again will trigger page fault and the
|
|
|
|
* PF handler will kill the process.
|
|
|
|
*
|
|
|
|
* MF_RECOVERED - The m-f() handler marks the page as PG_hwpoisoned'ed.
|
|
|
|
* The page has been completely isolated, that is, unmapped, taken out of
|
|
|
|
* the buddy system, or hole-punnched out of the file mapping.
|
|
|
|
*/
|
2009-09-16 09:50:15 +00:00
|
|
|
static const char *action_name[] = {
|
2015-06-24 23:57:30 +00:00
|
|
|
[MF_IGNORED] = "Ignored",
|
|
|
|
[MF_FAILED] = "Failed",
|
|
|
|
[MF_DELAYED] = "Delayed",
|
|
|
|
[MF_RECOVERED] = "Recovered",
|
2015-04-15 23:13:05 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const char * const action_page_types[] = {
|
2015-06-24 23:57:30 +00:00
|
|
|
[MF_MSG_KERNEL] = "reserved kernel page",
|
|
|
|
[MF_MSG_KERNEL_HIGH_ORDER] = "high-order kernel page",
|
|
|
|
[MF_MSG_DIFFERENT_COMPOUND] = "different compound page after locking",
|
|
|
|
[MF_MSG_HUGE] = "huge page",
|
|
|
|
[MF_MSG_FREE_HUGE] = "free huge page",
|
2024-05-24 21:53:04 +00:00
|
|
|
[MF_MSG_GET_HWPOISON] = "get hwpoison page",
|
2015-06-24 23:57:30 +00:00
|
|
|
[MF_MSG_UNMAP_FAILED] = "unmapping failed page",
|
|
|
|
[MF_MSG_DIRTY_SWAPCACHE] = "dirty swapcache page",
|
|
|
|
[MF_MSG_CLEAN_SWAPCACHE] = "clean swapcache page",
|
|
|
|
[MF_MSG_DIRTY_MLOCKED_LRU] = "dirty mlocked LRU page",
|
|
|
|
[MF_MSG_CLEAN_MLOCKED_LRU] = "clean mlocked LRU page",
|
|
|
|
[MF_MSG_DIRTY_UNEVICTABLE_LRU] = "dirty unevictable LRU page",
|
|
|
|
[MF_MSG_CLEAN_UNEVICTABLE_LRU] = "clean unevictable LRU page",
|
|
|
|
[MF_MSG_DIRTY_LRU] = "dirty LRU page",
|
|
|
|
[MF_MSG_CLEAN_LRU] = "clean LRU page",
|
|
|
|
[MF_MSG_TRUNCATED_LRU] = "already truncated LRU page",
|
|
|
|
[MF_MSG_BUDDY] = "free buddy page",
|
2018-07-14 04:50:21 +00:00
|
|
|
[MF_MSG_DAX] = "dax page",
|
2020-10-16 03:07:21 +00:00
|
|
|
[MF_MSG_UNSPLIT_THP] = "unsplit thp",
|
2024-05-24 21:53:04 +00:00
|
|
|
[MF_MSG_ALREADY_POISONED] = "already poisoned",
|
2015-06-24 23:57:30 +00:00
|
|
|
[MF_MSG_UNKNOWN] = "unknown page",
|
2015-04-15 23:13:05 +00:00
|
|
|
};
|
|
|
|
|
2009-12-16 11:19:58 +00:00
|
|
|
/*
|
|
|
|
* XXX: It is possible that a page is isolated from LRU cache,
|
|
|
|
* and then kept in swap cache or failed to remove from page cache.
|
|
|
|
* The page count will stop it from being freed by unpoison.
|
|
|
|
* Stress tests should be aware of this memory leak problem.
|
|
|
|
*/
|
2023-11-17 16:14:44 +00:00
|
|
|
static int delete_from_lru_cache(struct folio *folio)
|
2009-12-16 11:19:58 +00:00
|
|
|
{
|
2023-11-17 16:14:44 +00:00
|
|
|
if (folio_isolate_lru(folio)) {
|
2009-12-16 11:19:58 +00:00
|
|
|
/*
|
|
|
|
* Clear sensible page flags, so that the buddy system won't
|
2023-11-17 16:14:44 +00:00
|
|
|
* complain when the folio is unpoison-and-freed.
|
2009-12-16 11:19:58 +00:00
|
|
|
*/
|
2023-11-17 16:14:44 +00:00
|
|
|
folio_clear_active(folio);
|
|
|
|
folio_clear_unevictable(folio);
|
2017-05-12 22:46:26 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Poisoned page might never drop its ref count to 0 so we have
|
|
|
|
* to uncharge it manually from its memcg.
|
|
|
|
*/
|
2023-11-17 16:14:44 +00:00
|
|
|
mem_cgroup_uncharge(folio);
|
2017-05-12 22:46:26 +00:00
|
|
|
|
2009-12-16 11:19:58 +00:00
|
|
|
/*
|
2023-11-17 16:14:44 +00:00
|
|
|
* drop the refcount elevated by folio_isolate_lru()
|
2009-12-16 11:19:58 +00:00
|
|
|
*/
|
2023-11-17 16:14:44 +00:00
|
|
|
folio_put(folio);
|
2009-12-16 11:19:58 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
2023-11-17 16:14:47 +00:00
|
|
|
static int truncate_error_folio(struct folio *folio, unsigned long pfn,
|
2017-07-10 22:47:50 +00:00
|
|
|
struct address_space *mapping)
|
|
|
|
{
|
|
|
|
int ret = MF_FAILED;
|
|
|
|
|
2023-11-17 16:14:47 +00:00
|
|
|
if (mapping->a_ops->error_remove_folio) {
|
|
|
|
int err = mapping->a_ops->error_remove_folio(mapping, folio);
|
2017-07-10 22:47:50 +00:00
|
|
|
|
mm: merge folio_has_private()/filemap_release_folio() call pairs
Patch series "mm, netfs, fscache: Stop read optimisation when folio
removed from pagecache", v7.
This fixes an optimisation in fscache whereby we don't read from the cache
for a particular file until we know that there's data there that we don't
have in the pagecache. The problem is that I'm no longer using PG_fscache
(aka PG_private_2) to indicate that the page is cached and so I don't get
a notification when a cached page is dropped from the pagecache.
The first patch merges some folio_has_private() and
filemap_release_folio() pairs and introduces a helper,
folio_needs_release(), to indicate if a release is required.
The second patch is the actual fix. Following Willy's suggestions[1], it
adds an AS_RELEASE_ALWAYS flag to an address_space that will make
filemap_release_folio() always call ->release_folio(), even if
PG_private/PG_private_2 aren't set. folio_needs_release() is altered to
add a check for this.
This patch (of 2):
Make filemap_release_folio() check folio_has_private(). Then, in most
cases, where a call to folio_has_private() is immediately followed by a
call to filemap_release_folio(), we can get rid of the test in the pair.
There are a couple of sites in mm/vscan.c that this can't so easily be
done. In shrink_folio_list(), there are actually three cases (something
different is done for incompletely invalidated buffers), but
filemap_release_folio() elides two of them.
In shrink_active_list(), we don't have have the folio lock yet, so the
check allows us to avoid locking the page unnecessarily.
A wrapper function to check if a folio needs release is provided for those
places that still need to do it in the mm/ directory. This will acquire
additional parts to the condition in a future patch.
After this, the only remaining caller of folio_has_private() outside of
mm/ is a check in fuse.
Link: https://lkml.kernel.org/r/20230628104852.3391651-1-dhowells@redhat.com
Link: https://lkml.kernel.org/r/20230628104852.3391651-2-dhowells@redhat.com
Reported-by: Rohith Surabattula <rohiths.msft@gmail.com>
Suggested-by: Matthew Wilcox <willy@infradead.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steve French <sfrench@samba.org>
Cc: Shyam Prasad N <nspmangalore@gmail.com>
Cc: Rohith Surabattula <rohiths.msft@gmail.com>
Cc: Dave Wysochanski <dwysocha@redhat.com>
Cc: Dominique Martinet <asmadeus@codewreck.org>
Cc: Ilya Dryomov <idryomov@gmail.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Xiubo Li <xiubli@redhat.com>
Cc: Jingbo Xu <jefflexu@linux.alibaba.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-28 10:48:51 +00:00
|
|
|
if (err != 0)
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_info("%#lx: Failed to punch page: %d\n", pfn, err);
|
mm: merge folio_has_private()/filemap_release_folio() call pairs
Patch series "mm, netfs, fscache: Stop read optimisation when folio
removed from pagecache", v7.
This fixes an optimisation in fscache whereby we don't read from the cache
for a particular file until we know that there's data there that we don't
have in the pagecache. The problem is that I'm no longer using PG_fscache
(aka PG_private_2) to indicate that the page is cached and so I don't get
a notification when a cached page is dropped from the pagecache.
The first patch merges some folio_has_private() and
filemap_release_folio() pairs and introduces a helper,
folio_needs_release(), to indicate if a release is required.
The second patch is the actual fix. Following Willy's suggestions[1], it
adds an AS_RELEASE_ALWAYS flag to an address_space that will make
filemap_release_folio() always call ->release_folio(), even if
PG_private/PG_private_2 aren't set. folio_needs_release() is altered to
add a check for this.
This patch (of 2):
Make filemap_release_folio() check folio_has_private(). Then, in most
cases, where a call to folio_has_private() is immediately followed by a
call to filemap_release_folio(), we can get rid of the test in the pair.
There are a couple of sites in mm/vscan.c that this can't so easily be
done. In shrink_folio_list(), there are actually three cases (something
different is done for incompletely invalidated buffers), but
filemap_release_folio() elides two of them.
In shrink_active_list(), we don't have have the folio lock yet, so the
check allows us to avoid locking the page unnecessarily.
A wrapper function to check if a folio needs release is provided for those
places that still need to do it in the mm/ directory. This will acquire
additional parts to the condition in a future patch.
After this, the only remaining caller of folio_has_private() outside of
mm/ is a check in fuse.
Link: https://lkml.kernel.org/r/20230628104852.3391651-1-dhowells@redhat.com
Link: https://lkml.kernel.org/r/20230628104852.3391651-2-dhowells@redhat.com
Reported-by: Rohith Surabattula <rohiths.msft@gmail.com>
Suggested-by: Matthew Wilcox <willy@infradead.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steve French <sfrench@samba.org>
Cc: Shyam Prasad N <nspmangalore@gmail.com>
Cc: Rohith Surabattula <rohiths.msft@gmail.com>
Cc: Dave Wysochanski <dwysocha@redhat.com>
Cc: Dominique Martinet <asmadeus@codewreck.org>
Cc: Ilya Dryomov <idryomov@gmail.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Xiubo Li <xiubli@redhat.com>
Cc: Jingbo Xu <jefflexu@linux.alibaba.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-28 10:48:51 +00:00
|
|
|
else if (!filemap_release_folio(folio, GFP_NOIO))
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_info("%#lx: failed to release buffers\n", pfn);
|
mm: merge folio_has_private()/filemap_release_folio() call pairs
Patch series "mm, netfs, fscache: Stop read optimisation when folio
removed from pagecache", v7.
This fixes an optimisation in fscache whereby we don't read from the cache
for a particular file until we know that there's data there that we don't
have in the pagecache. The problem is that I'm no longer using PG_fscache
(aka PG_private_2) to indicate that the page is cached and so I don't get
a notification when a cached page is dropped from the pagecache.
The first patch merges some folio_has_private() and
filemap_release_folio() pairs and introduces a helper,
folio_needs_release(), to indicate if a release is required.
The second patch is the actual fix. Following Willy's suggestions[1], it
adds an AS_RELEASE_ALWAYS flag to an address_space that will make
filemap_release_folio() always call ->release_folio(), even if
PG_private/PG_private_2 aren't set. folio_needs_release() is altered to
add a check for this.
This patch (of 2):
Make filemap_release_folio() check folio_has_private(). Then, in most
cases, where a call to folio_has_private() is immediately followed by a
call to filemap_release_folio(), we can get rid of the test in the pair.
There are a couple of sites in mm/vscan.c that this can't so easily be
done. In shrink_folio_list(), there are actually three cases (something
different is done for incompletely invalidated buffers), but
filemap_release_folio() elides two of them.
In shrink_active_list(), we don't have have the folio lock yet, so the
check allows us to avoid locking the page unnecessarily.
A wrapper function to check if a folio needs release is provided for those
places that still need to do it in the mm/ directory. This will acquire
additional parts to the condition in a future patch.
After this, the only remaining caller of folio_has_private() outside of
mm/ is a check in fuse.
Link: https://lkml.kernel.org/r/20230628104852.3391651-1-dhowells@redhat.com
Link: https://lkml.kernel.org/r/20230628104852.3391651-2-dhowells@redhat.com
Reported-by: Rohith Surabattula <rohiths.msft@gmail.com>
Suggested-by: Matthew Wilcox <willy@infradead.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steve French <sfrench@samba.org>
Cc: Shyam Prasad N <nspmangalore@gmail.com>
Cc: Rohith Surabattula <rohiths.msft@gmail.com>
Cc: Dave Wysochanski <dwysocha@redhat.com>
Cc: Dominique Martinet <asmadeus@codewreck.org>
Cc: Ilya Dryomov <idryomov@gmail.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Xiubo Li <xiubli@redhat.com>
Cc: Jingbo Xu <jefflexu@linux.alibaba.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-28 10:48:51 +00:00
|
|
|
else
|
2017-07-10 22:47:50 +00:00
|
|
|
ret = MF_RECOVERED;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* If the file system doesn't support it just invalidate
|
|
|
|
* This fails on dirty or anything with private pages
|
|
|
|
*/
|
2023-11-08 18:28:06 +00:00
|
|
|
if (mapping_evict_folio(mapping, folio))
|
2017-07-10 22:47:50 +00:00
|
|
|
ret = MF_RECOVERED;
|
|
|
|
else
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_info("%#lx: Failed to invalidate\n", pfn);
|
2017-07-10 22:47:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2021-11-05 20:41:07 +00:00
|
|
|
struct page_state {
|
|
|
|
unsigned long mask;
|
|
|
|
unsigned long res;
|
|
|
|
enum mf_action_page_type type;
|
|
|
|
|
|
|
|
/* Callback ->action() has to unlock the relevant page inside it. */
|
|
|
|
int (*action)(struct page_state *ps, struct page *p);
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return true if page is still referenced by others, otherwise return
|
|
|
|
* false.
|
|
|
|
*
|
|
|
|
* The extra_pins is true when one extra refcount is expected.
|
|
|
|
*/
|
|
|
|
static bool has_extra_refcount(struct page_state *ps, struct page *p,
|
|
|
|
bool extra_pins)
|
|
|
|
{
|
|
|
|
int count = page_count(p) - 1;
|
|
|
|
|
|
|
|
if (extra_pins)
|
2024-01-12 18:08:40 +00:00
|
|
|
count -= folio_nr_pages(page_folio(p));
|
2021-11-05 20:41:07 +00:00
|
|
|
|
|
|
|
if (count > 0) {
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_err("%#lx: %s still referenced by %d users\n",
|
2021-11-05 20:41:07 +00:00
|
|
|
page_to_pfn(p), action_page_types[ps->type], count);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2009-09-16 09:50:15 +00:00
|
|
|
/*
|
|
|
|
* Error hit kernel page.
|
|
|
|
* Do nothing, try to be lucky and not touch this instead. For a few cases we
|
|
|
|
* could be more sophisticated.
|
|
|
|
*/
|
2021-11-05 20:41:07 +00:00
|
|
|
static int me_kernel(struct page_state *ps, struct page *p)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
2021-06-25 01:40:01 +00:00
|
|
|
unlock_page(p);
|
2015-06-24 23:57:30 +00:00
|
|
|
return MF_IGNORED;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Page in unknown state. Do nothing.
|
2024-05-24 21:53:04 +00:00
|
|
|
* This is a catch-all in case we fail to make sense of the page state.
|
2009-09-16 09:50:15 +00:00
|
|
|
*/
|
2021-11-05 20:41:07 +00:00
|
|
|
static int me_unknown(struct page_state *ps, struct page *p)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_err("%#lx: Unknown page state\n", page_to_pfn(p));
|
2021-06-25 01:40:01 +00:00
|
|
|
unlock_page(p);
|
2024-05-24 21:53:04 +00:00
|
|
|
return MF_IGNORED;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Clean (or cleaned) page cache page.
|
|
|
|
*/
|
2021-11-05 20:41:07 +00:00
|
|
|
static int me_pagecache_clean(struct page_state *ps, struct page *p)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
2023-11-17 16:14:42 +00:00
|
|
|
struct folio *folio = page_folio(p);
|
2021-06-25 01:40:01 +00:00
|
|
|
int ret;
|
2009-09-16 09:50:15 +00:00
|
|
|
struct address_space *mapping;
|
2022-01-14 22:05:19 +00:00
|
|
|
bool extra_pins;
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2023-11-17 16:14:44 +00:00
|
|
|
delete_from_lru_cache(folio);
|
2009-12-16 11:19:58 +00:00
|
|
|
|
2009-09-16 09:50:15 +00:00
|
|
|
/*
|
2023-11-17 16:14:42 +00:00
|
|
|
* For anonymous folios the only reference left
|
2009-09-16 09:50:15 +00:00
|
|
|
* should be the one m_f() holds.
|
|
|
|
*/
|
2023-11-17 16:14:42 +00:00
|
|
|
if (folio_test_anon(folio)) {
|
2021-06-25 01:40:01 +00:00
|
|
|
ret = MF_RECOVERED;
|
|
|
|
goto out;
|
|
|
|
}
|
2009-09-16 09:50:15 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now truncate the page in the page cache. This is really
|
|
|
|
* more like a "temporary hole punch"
|
|
|
|
* Don't do this for block devices when someone else
|
|
|
|
* has a reference, because it could be file system metadata
|
|
|
|
* and that's not safe to truncate.
|
|
|
|
*/
|
2023-11-17 16:14:42 +00:00
|
|
|
mapping = folio_mapping(folio);
|
2009-09-16 09:50:15 +00:00
|
|
|
if (!mapping) {
|
2023-11-17 16:14:42 +00:00
|
|
|
/* Folio has been torn down in the meantime */
|
2021-06-25 01:40:01 +00:00
|
|
|
ret = MF_FAILED;
|
|
|
|
goto out;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
2022-01-14 22:05:19 +00:00
|
|
|
/*
|
|
|
|
* The shmem page is kept in page cache instead of truncating
|
|
|
|
* so is expected to have an extra refcount after error-handling.
|
|
|
|
*/
|
|
|
|
extra_pins = shmem_mapping(mapping);
|
|
|
|
|
2009-09-16 09:50:15 +00:00
|
|
|
/*
|
|
|
|
* Truncation is a bit tricky. Enable it per file system for now.
|
|
|
|
*
|
2021-04-12 13:50:21 +00:00
|
|
|
* Open: to take i_rwsem or not for this? Right now we don't.
|
2009-09-16 09:50:15 +00:00
|
|
|
*/
|
2023-11-17 16:14:47 +00:00
|
|
|
ret = truncate_error_folio(folio, page_to_pfn(p), mapping);
|
2022-01-14 22:05:19 +00:00
|
|
|
if (has_extra_refcount(ps, p, extra_pins))
|
|
|
|
ret = MF_FAILED;
|
|
|
|
|
2021-06-25 01:40:01 +00:00
|
|
|
out:
|
2023-11-17 16:14:42 +00:00
|
|
|
folio_unlock(folio);
|
2021-11-05 20:41:07 +00:00
|
|
|
|
2021-06-25 01:40:01 +00:00
|
|
|
return ret;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2014-01-21 23:49:08 +00:00
|
|
|
* Dirty pagecache page
|
2009-09-16 09:50:15 +00:00
|
|
|
* Issues: when the error hit a hole page the error is not properly
|
|
|
|
* propagated.
|
|
|
|
*/
|
2021-11-05 20:41:07 +00:00
|
|
|
static int me_pagecache_dirty(struct page_state *ps, struct page *p)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
2024-04-23 22:55:34 +00:00
|
|
|
struct folio *folio = page_folio(p);
|
|
|
|
struct address_space *mapping = folio_mapping(folio);
|
2009-09-16 09:50:15 +00:00
|
|
|
|
|
|
|
/* TBD: print more information about the file. */
|
|
|
|
if (mapping) {
|
|
|
|
/*
|
|
|
|
* IO error will be reported by write(), fsync(), etc.
|
|
|
|
* who check the mapping.
|
|
|
|
* This way the application knows that something went
|
|
|
|
* wrong with its dirty file data.
|
|
|
|
*/
|
2017-07-06 11:02:19 +00:00
|
|
|
mapping_set_error(mapping, -EIO);
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
2021-11-05 20:41:07 +00:00
|
|
|
return me_pagecache_clean(ps, p);
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Clean and dirty swap cache.
|
|
|
|
*
|
|
|
|
* Dirty swap cache page is tricky to handle. The page could live both in page
|
2024-06-12 07:18:35 +00:00
|
|
|
* table and swap cache(ie. page is freshly swapped in). So it could be
|
2009-09-16 09:50:15 +00:00
|
|
|
* referenced concurrently by 2 types of PTEs:
|
|
|
|
* normal PTEs and swap PTEs. We try to handle them consistently by calling
|
2023-02-21 08:59:05 +00:00
|
|
|
* try_to_unmap(!TTU_HWPOISON) to convert the normal PTEs to swap PTEs,
|
2009-09-16 09:50:15 +00:00
|
|
|
* and then
|
|
|
|
* - clear dirty bit to prevent IO
|
|
|
|
* - remove from LRU
|
|
|
|
* - but keep in the swap cache, so that when we return to it on
|
|
|
|
* a later page fault, we know the application is accessing
|
|
|
|
* corrupted data and shall be killed (we installed simple
|
|
|
|
* interception code in do_swap_page to catch it).
|
|
|
|
*
|
|
|
|
* Clean swap cache pages can be directly isolated. A later page fault will
|
|
|
|
* bring in the known good data from disk.
|
|
|
|
*/
|
2021-11-05 20:41:07 +00:00
|
|
|
static int me_swapcache_dirty(struct page_state *ps, struct page *p)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
2023-11-17 16:14:43 +00:00
|
|
|
struct folio *folio = page_folio(p);
|
2021-06-25 01:40:01 +00:00
|
|
|
int ret;
|
2021-11-05 20:41:07 +00:00
|
|
|
bool extra_pins = false;
|
2021-06-25 01:40:01 +00:00
|
|
|
|
2023-11-17 16:14:43 +00:00
|
|
|
folio_clear_dirty(folio);
|
2009-09-16 09:50:15 +00:00
|
|
|
/* Trigger EIO in shmem: */
|
2023-11-17 16:14:43 +00:00
|
|
|
folio_clear_uptodate(folio);
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2023-11-17 16:14:44 +00:00
|
|
|
ret = delete_from_lru_cache(folio) ? MF_FAILED : MF_DELAYED;
|
2023-11-17 16:14:43 +00:00
|
|
|
folio_unlock(folio);
|
2021-11-05 20:41:07 +00:00
|
|
|
|
|
|
|
if (ret == MF_DELAYED)
|
|
|
|
extra_pins = true;
|
|
|
|
|
|
|
|
if (has_extra_refcount(ps, p, extra_pins))
|
|
|
|
ret = MF_FAILED;
|
|
|
|
|
2021-06-25 01:40:01 +00:00
|
|
|
return ret;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
2021-11-05 20:41:07 +00:00
|
|
|
static int me_swapcache_clean(struct page_state *ps, struct page *p)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
2022-06-17 17:50:19 +00:00
|
|
|
struct folio *folio = page_folio(p);
|
2021-06-25 01:40:01 +00:00
|
|
|
int ret;
|
|
|
|
|
2022-06-17 17:50:19 +00:00
|
|
|
delete_from_swap_cache(folio);
|
2009-09-29 05:16:20 +00:00
|
|
|
|
2023-11-17 16:14:44 +00:00
|
|
|
ret = delete_from_lru_cache(folio) ? MF_FAILED : MF_RECOVERED;
|
2022-06-17 17:50:19 +00:00
|
|
|
folio_unlock(folio);
|
2021-11-05 20:41:07 +00:00
|
|
|
|
|
|
|
if (has_extra_refcount(ps, p, false))
|
|
|
|
ret = MF_FAILED;
|
|
|
|
|
2021-06-25 01:40:01 +00:00
|
|
|
return ret;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Huge pages. Needs work.
|
|
|
|
* Issues:
|
2010-05-28 00:29:20 +00:00
|
|
|
* - Error on hugepage is contained in hugepage unit (not in raw page unit.)
|
|
|
|
* To narrow down kill region to one page, we need to break up pmd.
|
2009-09-16 09:50:15 +00:00
|
|
|
*/
|
2021-11-05 20:41:07 +00:00
|
|
|
static int me_huge_page(struct page_state *ps, struct page *p)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
2023-11-17 16:14:45 +00:00
|
|
|
struct folio *folio = page_folio(p);
|
mm,hwpoison: take free pages off the buddy freelists
The crux of the matter is that historically we left poisoned pages in the
buddy system because we have some checks in place when allocating a page
that are gatekeeper for poisoned pages. Unfortunately, we do have other
users (e.g: compaction [1]) that scan buddy freelists and try to get a
page from there without checking whether the page is HWPoison.
As I stated already, I think it is fundamentally wrong to keep HWPoison
pages within the buddy systems, checks in place or not.
Let us fix this the same way we did for soft_offline [2], taking the page
off the buddy freelist so it is completely unreachable.
Note that this is fairly simple to trigger, as we only need to poison free
buddy pages (madvise MADV_HWPOISON) and then run some sort of memory
stress system.
Just for a matter of reference, I put a dump_page() in compaction_alloc()
to trigger for HWPoison patches:
page:0000000012b2982b refcount:1 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x1d5db
flags: 0xfffffc0800000(hwpoison)
raw: 000fffffc0800000 ffffea00007573c8 ffffc90000857de0 0000000000000000
raw: 0000000000000001 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: compaction_alloc
CPU: 4 PID: 123 Comm: kcompactd0 Tainted: G E 5.9.0-rc2-mm1-1-default+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
Call Trace:
dump_stack+0x6d/0x8b
compaction_alloc+0xb2/0xc0
migrate_pages+0x2a6/0x12a0
compact_zone+0x5eb/0x11c0
proactive_compact_node+0x89/0xf0
kcompactd+0x2d0/0x3a0
kthread+0x118/0x130
ret_from_fork+0x22/0x30
After that, if e.g: a process faults in the page, it will get killed
unexpectedly.
Fix it by containing the page immediatelly.
Besides that, two more changes can be noticed:
* MF_DELAYED no longer suits as we are fixing the issue by containing
the page immediately, so it does no longer rely on the allocation-time
checks to stop HWPoison to be handed over.
gain unless it is unpoisoned, so we fixed the situation.
Because of that, let us use MF_RECOVERED from now on.
* The second block that handles PageBuddy pages is no longer needed:
We call shake_page and then check whether the page is Buddy
because shake_page calls drain_all_pages, which sends pcp-pages back to
the buddy freelists, so we could have a chance to handle free pages.
Currently, get_hwpoison_page already calls drain_all_pages, and we call
get_hwpoison_page right before coming here, so we should be on the safe
side.
[1] https://lore.kernel.org/linux-mm/20190826104144.GA7849@linux/T/#u
[2] https://patchwork.kernel.org/cover/11792607/
[osalvador@suse.de: take the poisoned subpage off the buddy frelists]
Link: https://lkml.kernel.org/r/20201013144447.6706-4-osalvador@suse.de
Link: https://lkml.kernel.org/r/20201013144447.6706-3-osalvador@suse.de
Signed-off-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-12-15 03:11:32 +00:00
|
|
|
int res;
|
2017-07-10 22:47:50 +00:00
|
|
|
struct address_space *mapping;
|
2022-10-18 20:01:25 +00:00
|
|
|
bool extra_pins = false;
|
2015-06-24 23:56:53 +00:00
|
|
|
|
2023-11-17 16:14:45 +00:00
|
|
|
mapping = folio_mapping(folio);
|
2017-07-10 22:47:50 +00:00
|
|
|
if (mapping) {
|
2023-11-17 16:14:47 +00:00
|
|
|
res = truncate_error_folio(folio, page_to_pfn(p), mapping);
|
2022-10-18 20:01:25 +00:00
|
|
|
/* The page is kept in page cache. */
|
|
|
|
extra_pins = true;
|
2023-11-17 16:14:45 +00:00
|
|
|
folio_unlock(folio);
|
2017-07-10 22:47:50 +00:00
|
|
|
} else {
|
2023-11-17 16:14:45 +00:00
|
|
|
folio_unlock(folio);
|
2017-07-10 22:47:50 +00:00
|
|
|
/*
|
2022-04-29 06:16:02 +00:00
|
|
|
* migration entry prevents later access on error hugepage,
|
|
|
|
* so we can free and dissolve it into buddy to save healthy
|
|
|
|
* subpages.
|
2017-07-10 22:47:50 +00:00
|
|
|
*/
|
2023-11-17 16:14:45 +00:00
|
|
|
folio_put(folio);
|
2024-05-23 07:12:17 +00:00
|
|
|
if (__page_handle_poison(p) > 0) {
|
mm,hwpoison: take free pages off the buddy freelists
The crux of the matter is that historically we left poisoned pages in the
buddy system because we have some checks in place when allocating a page
that are gatekeeper for poisoned pages. Unfortunately, we do have other
users (e.g: compaction [1]) that scan buddy freelists and try to get a
page from there without checking whether the page is HWPoison.
As I stated already, I think it is fundamentally wrong to keep HWPoison
pages within the buddy systems, checks in place or not.
Let us fix this the same way we did for soft_offline [2], taking the page
off the buddy freelist so it is completely unreachable.
Note that this is fairly simple to trigger, as we only need to poison free
buddy pages (madvise MADV_HWPOISON) and then run some sort of memory
stress system.
Just for a matter of reference, I put a dump_page() in compaction_alloc()
to trigger for HWPoison patches:
page:0000000012b2982b refcount:1 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x1d5db
flags: 0xfffffc0800000(hwpoison)
raw: 000fffffc0800000 ffffea00007573c8 ffffc90000857de0 0000000000000000
raw: 0000000000000001 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: compaction_alloc
CPU: 4 PID: 123 Comm: kcompactd0 Tainted: G E 5.9.0-rc2-mm1-1-default+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
Call Trace:
dump_stack+0x6d/0x8b
compaction_alloc+0xb2/0xc0
migrate_pages+0x2a6/0x12a0
compact_zone+0x5eb/0x11c0
proactive_compact_node+0x89/0xf0
kcompactd+0x2d0/0x3a0
kthread+0x118/0x130
ret_from_fork+0x22/0x30
After that, if e.g: a process faults in the page, it will get killed
unexpectedly.
Fix it by containing the page immediatelly.
Besides that, two more changes can be noticed:
* MF_DELAYED no longer suits as we are fixing the issue by containing
the page immediately, so it does no longer rely on the allocation-time
checks to stop HWPoison to be handed over.
gain unless it is unpoisoned, so we fixed the situation.
Because of that, let us use MF_RECOVERED from now on.
* The second block that handles PageBuddy pages is no longer needed:
We call shake_page and then check whether the page is Buddy
because shake_page calls drain_all_pages, which sends pcp-pages back to
the buddy freelists, so we could have a chance to handle free pages.
Currently, get_hwpoison_page already calls drain_all_pages, and we call
get_hwpoison_page right before coming here, so we should be on the safe
side.
[1] https://lore.kernel.org/linux-mm/20190826104144.GA7849@linux/T/#u
[2] https://patchwork.kernel.org/cover/11792607/
[osalvador@suse.de: take the poisoned subpage off the buddy frelists]
Link: https://lkml.kernel.org/r/20201013144447.6706-4-osalvador@suse.de
Link: https://lkml.kernel.org/r/20201013144447.6706-3-osalvador@suse.de
Signed-off-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-12-15 03:11:32 +00:00
|
|
|
page_ref_inc(p);
|
|
|
|
res = MF_RECOVERED;
|
2022-07-14 04:24:19 +00:00
|
|
|
} else {
|
|
|
|
res = MF_FAILED;
|
mm,hwpoison: take free pages off the buddy freelists
The crux of the matter is that historically we left poisoned pages in the
buddy system because we have some checks in place when allocating a page
that are gatekeeper for poisoned pages. Unfortunately, we do have other
users (e.g: compaction [1]) that scan buddy freelists and try to get a
page from there without checking whether the page is HWPoison.
As I stated already, I think it is fundamentally wrong to keep HWPoison
pages within the buddy systems, checks in place or not.
Let us fix this the same way we did for soft_offline [2], taking the page
off the buddy freelist so it is completely unreachable.
Note that this is fairly simple to trigger, as we only need to poison free
buddy pages (madvise MADV_HWPOISON) and then run some sort of memory
stress system.
Just for a matter of reference, I put a dump_page() in compaction_alloc()
to trigger for HWPoison patches:
page:0000000012b2982b refcount:1 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x1d5db
flags: 0xfffffc0800000(hwpoison)
raw: 000fffffc0800000 ffffea00007573c8 ffffc90000857de0 0000000000000000
raw: 0000000000000001 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: compaction_alloc
CPU: 4 PID: 123 Comm: kcompactd0 Tainted: G E 5.9.0-rc2-mm1-1-default+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
Call Trace:
dump_stack+0x6d/0x8b
compaction_alloc+0xb2/0xc0
migrate_pages+0x2a6/0x12a0
compact_zone+0x5eb/0x11c0
proactive_compact_node+0x89/0xf0
kcompactd+0x2d0/0x3a0
kthread+0x118/0x130
ret_from_fork+0x22/0x30
After that, if e.g: a process faults in the page, it will get killed
unexpectedly.
Fix it by containing the page immediatelly.
Besides that, two more changes can be noticed:
* MF_DELAYED no longer suits as we are fixing the issue by containing
the page immediately, so it does no longer rely on the allocation-time
checks to stop HWPoison to be handed over.
gain unless it is unpoisoned, so we fixed the situation.
Because of that, let us use MF_RECOVERED from now on.
* The second block that handles PageBuddy pages is no longer needed:
We call shake_page and then check whether the page is Buddy
because shake_page calls drain_all_pages, which sends pcp-pages back to
the buddy freelists, so we could have a chance to handle free pages.
Currently, get_hwpoison_page already calls drain_all_pages, and we call
get_hwpoison_page right before coming here, so we should be on the safe
side.
[1] https://lore.kernel.org/linux-mm/20190826104144.GA7849@linux/T/#u
[2] https://patchwork.kernel.org/cover/11792607/
[osalvador@suse.de: take the poisoned subpage off the buddy frelists]
Link: https://lkml.kernel.org/r/20201013144447.6706-4-osalvador@suse.de
Link: https://lkml.kernel.org/r/20201013144447.6706-3-osalvador@suse.de
Signed-off-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-12-15 03:11:32 +00:00
|
|
|
}
|
2010-05-28 00:29:20 +00:00
|
|
|
}
|
2017-07-10 22:47:50 +00:00
|
|
|
|
2022-10-18 20:01:25 +00:00
|
|
|
if (has_extra_refcount(ps, p, extra_pins))
|
2021-11-05 20:41:07 +00:00
|
|
|
res = MF_FAILED;
|
|
|
|
|
2017-07-10 22:47:50 +00:00
|
|
|
return res;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Various page states we can handle.
|
|
|
|
*
|
|
|
|
* A page state is defined by its current page->flags bits.
|
|
|
|
* The table matches them in order and calls the right handler.
|
|
|
|
*
|
|
|
|
* This is quite tricky because we can access page at any time
|
2011-03-31 01:57:33 +00:00
|
|
|
* in its live cycle, so all accesses have to be extremely careful.
|
2009-09-16 09:50:15 +00:00
|
|
|
*
|
|
|
|
* This is not complete. More states could be added.
|
|
|
|
* For any missing state don't attempt recovery.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define dirty (1UL << PG_dirty)
|
2016-12-25 03:00:29 +00:00
|
|
|
#define sc ((1UL << PG_swapcache) | (1UL << PG_swapbacked))
|
2009-09-16 09:50:15 +00:00
|
|
|
#define unevict (1UL << PG_unevictable)
|
|
|
|
#define mlock (1UL << PG_mlocked)
|
|
|
|
#define lru (1UL << PG_lru)
|
|
|
|
#define head (1UL << PG_head)
|
|
|
|
#define reserved (1UL << PG_reserved)
|
|
|
|
|
2021-11-05 20:41:07 +00:00
|
|
|
static struct page_state error_states[] = {
|
2015-06-24 23:57:30 +00:00
|
|
|
{ reserved, reserved, MF_MSG_KERNEL, me_kernel },
|
2009-12-16 11:19:58 +00:00
|
|
|
/*
|
|
|
|
* free pages are specially detected outside this table:
|
|
|
|
* PG_buddy pages only make a small fraction of all free pages.
|
|
|
|
*/
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2015-06-24 23:57:30 +00:00
|
|
|
{ head, head, MF_MSG_HUGE, me_huge_page },
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2015-06-24 23:57:30 +00:00
|
|
|
{ sc|dirty, sc|dirty, MF_MSG_DIRTY_SWAPCACHE, me_swapcache_dirty },
|
|
|
|
{ sc|dirty, sc, MF_MSG_CLEAN_SWAPCACHE, me_swapcache_clean },
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2015-06-24 23:57:30 +00:00
|
|
|
{ mlock|dirty, mlock|dirty, MF_MSG_DIRTY_MLOCKED_LRU, me_pagecache_dirty },
|
|
|
|
{ mlock|dirty, mlock, MF_MSG_CLEAN_MLOCKED_LRU, me_pagecache_clean },
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2015-06-24 23:57:30 +00:00
|
|
|
{ unevict|dirty, unevict|dirty, MF_MSG_DIRTY_UNEVICTABLE_LRU, me_pagecache_dirty },
|
|
|
|
{ unevict|dirty, unevict, MF_MSG_CLEAN_UNEVICTABLE_LRU, me_pagecache_clean },
|
2013-02-23 00:35:53 +00:00
|
|
|
|
2015-06-24 23:57:30 +00:00
|
|
|
{ lru|dirty, lru|dirty, MF_MSG_DIRTY_LRU, me_pagecache_dirty },
|
|
|
|
{ lru|dirty, lru, MF_MSG_CLEAN_LRU, me_pagecache_clean },
|
2009-09-16 09:50:15 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Catchall entry: must be at end.
|
|
|
|
*/
|
2015-06-24 23:57:30 +00:00
|
|
|
{ 0, 0, MF_MSG_UNKNOWN, me_unknown },
|
2009-09-16 09:50:15 +00:00
|
|
|
};
|
|
|
|
|
2009-12-16 11:20:00 +00:00
|
|
|
#undef dirty
|
|
|
|
#undef sc
|
|
|
|
#undef unevict
|
|
|
|
#undef mlock
|
|
|
|
#undef lru
|
|
|
|
#undef head
|
|
|
|
#undef reserved
|
|
|
|
|
2023-01-20 03:46:21 +00:00
|
|
|
static void update_per_node_mf_stats(unsigned long pfn,
|
|
|
|
enum mf_result result)
|
|
|
|
{
|
|
|
|
int nid = MAX_NUMNODES;
|
|
|
|
struct memory_failure_stats *mf_stats = NULL;
|
|
|
|
|
|
|
|
nid = pfn_to_nid(pfn);
|
|
|
|
if (unlikely(nid < 0 || nid >= MAX_NUMNODES)) {
|
|
|
|
WARN_ONCE(1, "Memory failure: pfn=%#lx, invalid nid=%d", pfn, nid);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
mf_stats = &NODE_DATA(nid)->mf_stats;
|
|
|
|
switch (result) {
|
|
|
|
case MF_IGNORED:
|
|
|
|
++mf_stats->ignored;
|
|
|
|
break;
|
|
|
|
case MF_FAILED:
|
|
|
|
++mf_stats->failed;
|
|
|
|
break;
|
|
|
|
case MF_DELAYED:
|
|
|
|
++mf_stats->delayed;
|
|
|
|
break;
|
|
|
|
case MF_RECOVERED:
|
|
|
|
++mf_stats->recovered;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
WARN_ONCE(1, "Memory failure: mf_result=%d is not properly handled", result);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
++mf_stats->total;
|
|
|
|
}
|
|
|
|
|
2012-12-12 00:01:32 +00:00
|
|
|
/*
|
|
|
|
* "Dirty/Clean" indication is not 100% accurate due to the possibility of
|
|
|
|
* setting PG_dirty outside page lock. See also comment above set_page_dirty().
|
|
|
|
*/
|
2022-10-21 08:46:11 +00:00
|
|
|
static int action_result(unsigned long pfn, enum mf_action_page_type type,
|
|
|
|
enum mf_result result)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
2015-06-24 23:57:36 +00:00
|
|
|
trace_memory_failure_event(pfn, type, result);
|
|
|
|
|
2022-10-24 06:20:11 +00:00
|
|
|
num_poisoned_pages_inc(pfn);
|
2023-01-20 03:46:21 +00:00
|
|
|
|
|
|
|
update_per_node_mf_stats(pfn, result);
|
|
|
|
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_err("%#lx: recovery action for %s: %s\n",
|
2015-04-15 23:13:05 +00:00
|
|
|
pfn, action_page_types[type], action_name[result]);
|
2022-10-21 08:46:11 +00:00
|
|
|
|
|
|
|
return (result == MF_RECOVERED || result == MF_DELAYED) ? 0 : -EBUSY;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int page_action(struct page_state *ps, struct page *p,
|
2009-12-16 11:19:57 +00:00
|
|
|
unsigned long pfn)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
|
|
|
int result;
|
|
|
|
|
2021-06-25 01:40:01 +00:00
|
|
|
/* page p should be unlocked after returning from ps->action(). */
|
2021-11-05 20:41:07 +00:00
|
|
|
result = ps->action(ps, p);
|
2009-10-19 06:15:01 +00:00
|
|
|
|
2009-09-16 09:50:15 +00:00
|
|
|
/* Could do more checks here if page looks ok */
|
|
|
|
/*
|
|
|
|
* Could adjust zone counters here to correct for the missing page.
|
|
|
|
*/
|
|
|
|
|
2022-10-21 08:46:11 +00:00
|
|
|
return action_result(pfn, ps->type, result);
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
mm/hwpoison: fix unpoison_memory()
After recent soft-offline rework, error pages can be taken off from
buddy allocator, but the existing unpoison_memory() does not properly
undo the operation. Moreover, due to the recent change on
__get_hwpoison_page(), get_page_unless_zero() is hardly called for
hwpoisoned pages. So __get_hwpoison_page() highly likely returns -EBUSY
(meaning to fail to grab page refcount) and unpoison just clears
PG_hwpoison without releasing a refcount. That does not lead to a
critical issue like kernel panic, but unpoisoned pages never get back to
buddy (leaked permanently), which is not good.
To (partially) fix this, we need to identify "taken off" pages from
other types of hwpoisoned pages. We can't use refcount or page flags
for this purpose, so a pseudo flag is defined by hacking ->private
field. Someone might think that put_page() is enough to cancel
taken-off pages, but the normal free path contains some operations not
suitable for the current purpose, and can fire VM_BUG_ON().
Note that unpoison_memory() is now supposed to be cancel hwpoison events
injected only by madvise() or
/sys/devices/system/memory/{hard,soft}_offline_page, not by MCE
injection, so please don't try to use unpoison when testing with MCE
injection.
[lkp@intel.com: report build failure for ARCH=i386]
Link: https://lkml.kernel.org/r/20211115084006.3728254-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Ding Hui <dinghui@sangfor.com.cn>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-14 22:09:09 +00:00
|
|
|
static inline bool PageHWPoisonTakenOff(struct page *page)
|
|
|
|
{
|
|
|
|
return PageHWPoison(page) && page_private(page) == MAGIC_HWPOISON;
|
|
|
|
}
|
|
|
|
|
|
|
|
void SetPageHWPoisonTakenOff(struct page *page)
|
|
|
|
{
|
|
|
|
set_page_private(page, MAGIC_HWPOISON);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ClearPageHWPoisonTakenOff(struct page *page)
|
|
|
|
{
|
|
|
|
if (PageHWPoison(page))
|
|
|
|
set_page_private(page, 0);
|
|
|
|
}
|
|
|
|
|
2021-06-16 01:23:13 +00:00
|
|
|
/*
|
|
|
|
* Return true if a page type of a given page is supported by hwpoison
|
|
|
|
* mechanism (while handling could fail), otherwise false. This function
|
|
|
|
* does not return true for hugetlb or device memory pages, so it's assumed
|
|
|
|
* to be called only in the context where we never have such pages.
|
|
|
|
*/
|
2022-03-22 21:44:50 +00:00
|
|
|
static inline bool HWPoisonHandlable(struct page *page, unsigned long flags)
|
2021-06-16 01:23:13 +00:00
|
|
|
{
|
2024-01-24 08:40:14 +00:00
|
|
|
if (PageSlab(page))
|
|
|
|
return false;
|
|
|
|
|
2022-04-29 06:16:02 +00:00
|
|
|
/* Soft offline could migrate non-LRU movable pages */
|
2022-03-22 21:44:50 +00:00
|
|
|
if ((flags & MF_SOFT_OFFLINE) && __PageMovable(page))
|
2022-04-29 06:16:02 +00:00
|
|
|
return true;
|
2022-03-22 21:44:50 +00:00
|
|
|
|
2022-04-29 06:16:02 +00:00
|
|
|
return PageLRU(page) || is_free_buddy_page(page);
|
2021-06-16 01:23:13 +00:00
|
|
|
}
|
|
|
|
|
2022-03-22 21:44:50 +00:00
|
|
|
static int __get_hwpoison_page(struct page *page, unsigned long flags)
|
2015-06-24 23:56:48 +00:00
|
|
|
{
|
2023-01-18 17:40:39 +00:00
|
|
|
struct folio *folio = page_folio(page);
|
2021-06-16 01:23:13 +00:00
|
|
|
int ret = 0;
|
|
|
|
bool hugetlb = false;
|
|
|
|
|
2023-01-18 17:40:39 +00:00
|
|
|
ret = get_hwpoison_hugetlb_folio(folio, &hugetlb, false);
|
2023-07-11 05:50:16 +00:00
|
|
|
if (hugetlb) {
|
|
|
|
/* Make sure hugetlb demotion did not happen from under us. */
|
|
|
|
if (folio == page_folio(page))
|
|
|
|
return ret;
|
|
|
|
if (ret > 0) {
|
|
|
|
folio_put(folio);
|
|
|
|
folio = page_folio(page);
|
|
|
|
}
|
|
|
|
}
|
2021-06-16 01:23:13 +00:00
|
|
|
|
|
|
|
/*
|
2023-01-18 17:40:39 +00:00
|
|
|
* This check prevents from calling folio_try_get() for any
|
|
|
|
* unsupported type of folio in order to reduce the risk of unexpected
|
|
|
|
* races caused by taking a folio refcount.
|
2021-06-16 01:23:13 +00:00
|
|
|
*/
|
2023-01-18 17:40:39 +00:00
|
|
|
if (!HWPoisonHandlable(&folio->page, flags))
|
2021-08-20 02:04:24 +00:00
|
|
|
return -EBUSY;
|
2015-06-24 23:56:48 +00:00
|
|
|
|
2023-01-18 17:40:39 +00:00
|
|
|
if (folio_try_get(folio)) {
|
|
|
|
if (folio == page_folio(page))
|
2016-04-28 23:19:03 +00:00
|
|
|
return 1;
|
|
|
|
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_info("%#lx cannot catch tail\n", page_to_pfn(page));
|
2023-01-18 17:40:39 +00:00
|
|
|
folio_put(folio);
|
2016-04-28 23:19:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2015-06-24 23:56:48 +00:00
|
|
|
}
|
|
|
|
|
2024-06-12 07:18:25 +00:00
|
|
|
#define GET_PAGE_MAX_RETRY_NUM 3
|
|
|
|
|
2020-12-15 03:11:41 +00:00
|
|
|
static int get_any_page(struct page *p, unsigned long flags)
|
2020-12-15 03:11:28 +00:00
|
|
|
{
|
2020-12-15 03:11:41 +00:00
|
|
|
int ret = 0, pass = 0;
|
|
|
|
bool count_increased = false;
|
2020-12-15 03:11:28 +00:00
|
|
|
|
2020-12-15 03:11:41 +00:00
|
|
|
if (flags & MF_COUNT_INCREASED)
|
|
|
|
count_increased = true;
|
|
|
|
|
|
|
|
try_again:
|
2021-06-29 02:43:17 +00:00
|
|
|
if (!count_increased) {
|
2022-03-22 21:44:50 +00:00
|
|
|
ret = __get_hwpoison_page(p, flags);
|
2021-06-29 02:43:17 +00:00
|
|
|
if (!ret) {
|
|
|
|
if (page_count(p)) {
|
|
|
|
/* We raced with an allocation, retry. */
|
2024-06-12 07:18:25 +00:00
|
|
|
if (pass++ < GET_PAGE_MAX_RETRY_NUM)
|
2021-06-29 02:43:17 +00:00
|
|
|
goto try_again;
|
|
|
|
ret = -EBUSY;
|
|
|
|
} else if (!PageHuge(p) && !is_free_buddy_page(p)) {
|
|
|
|
/* We raced with put_page, retry. */
|
2024-06-12 07:18:25 +00:00
|
|
|
if (pass++ < GET_PAGE_MAX_RETRY_NUM)
|
2021-06-29 02:43:17 +00:00
|
|
|
goto try_again;
|
|
|
|
ret = -EIO;
|
|
|
|
}
|
|
|
|
goto out;
|
|
|
|
} else if (ret == -EBUSY) {
|
2021-08-20 02:04:24 +00:00
|
|
|
/*
|
|
|
|
* We raced with (possibly temporary) unhandlable
|
|
|
|
* page, retry.
|
|
|
|
*/
|
|
|
|
if (pass++ < 3) {
|
mm: hwpoison: don't drop slab caches for offlining non-LRU page
In the current implementation of soft offline, if non-LRU page is met,
all the slab caches will be dropped to free the page then offline. But
if the page is not slab page all the effort is wasted in vain. Even
though it is a slab page, it is not guaranteed the page could be freed
at all.
However the side effect and cost is quite high. It does not only drop
the slab caches, but also may drop a significant amount of page caches
which are associated with inode caches. It could make the most
workingset gone in order to just offline a page. And the offline is not
guaranteed to succeed at all, actually I really doubt the success rate
for real life workload.
Furthermore the worse consequence is the system may be locked up and
unusable since the page cache release may incur huge amount of works
queued for memcg release.
Actually we ran into such unpleasant case in our production environment.
Firstly, the workqueue of memory_failure_work_func is locked up as
below:
BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 53s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=14/256 refcnt=15
in-flight: 409271:memory_failure_work_func
pending: kfree_rcu_work, kfree_rcu_monitor, kfree_rcu_work, rht_deferred_worker, rht_deferred_worker, rht_deferred_worker, rht_deferred_worker, kfree_rcu_work, kfree_rcu_work, kfree_rcu_work, kfree_rcu_work, drain_local_stock, kfree_rcu_work
workqueue mm_percpu_wq: flags=0x8
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
pending: vmstat_update
workqueue cgroup_destroy: flags=0x0
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/1 refcnt=12072
pending: css_release_work_fn
There were over 12K css_release_work_fn queued, and this caused a few
lockups due to the contention of worker pool lock with IRQ disabled, for
example:
NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
Modules linked in: amd64_edac_mod edac_mce_amd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xt_DSCP iptable_mangle kvm_amd bpfilter vfat fat acpi_ipmi i2c_piix4 usb_storage ipmi_si k10temp i2c_core ipmi_devintf ipmi_msghandler acpi_cpufreq sch_fq_codel xfs libcrc32c crc32c_intel mlx5_core mlxfw nvme xhci_pci ptp nvme_core pps_core xhci_hcd
CPU: 1 PID: 205500 Comm: kworker/1:0 Tainted: G L 5.10.32-t1.el7.twitter.x86_64 #1
Hardware name: TYAN F5AMT /z /S8026GM2NRE-CGN, BIOS V8.030 03/30/2021
Workqueue: events memory_failure_work_func
RIP: 0010:queued_spin_lock_slowpath+0x41/0x1a0
Code: 41 f0 0f ba 2f 08 0f 92 c0 0f b6 c0 c1 e0 08 89 c2 8b 07 30 e4 09 d0 a9 00 01 ff ff 75 1b 85 c0 74 0e 8b 07 84 c0 74 08 f3 90 <8b> 07 84 c0 75 f8 b8 01 00 00 00 66 89 07 c3 f6 c4 01 75 04 c6 47
RSP: 0018:ffff9b2ac278f900 EFLAGS: 00000002
RAX: 0000000000480101 RBX: ffff8ce98ce71800 RCX: 0000000000000084
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8ce98ce6a140
RBP: 00000000000284c8 R08: ffffd7248dcb6808 R09: 0000000000000000
R10: 0000000000000003 R11: ffff9b2ac278f9b0 R12: 0000000000000001
R13: ffff8cb44dab9c00 R14: ffffffffbd1ce6a0 R15: ffff8cacaa37f068
FS: 0000000000000000(0000) GS:ffff8ce98ce40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fcf6e8cb000 CR3: 0000000a0c60a000 CR4: 0000000000350ee0
Call Trace:
__queue_work+0xd6/0x3c0
queue_work_on+0x1c/0x30
uncharge_batch+0x10e/0x110
mem_cgroup_uncharge_list+0x6d/0x80
release_pages+0x37f/0x3f0
__pagevec_release+0x1c/0x50
__invalidate_mapping_pages+0x348/0x380
inode_lru_isolate+0x10a/0x160
__list_lru_walk_one+0x7b/0x170
list_lru_walk_one+0x4a/0x60
prune_icache_sb+0x37/0x50
super_cache_scan+0x123/0x1a0
do_shrink_slab+0x10c/0x2c0
shrink_slab+0x1f1/0x290
drop_slab_node+0x4d/0x70
soft_offline_page+0x1ac/0x5b0
memory_failure_work_func+0x6a/0x90
process_one_work+0x19e/0x340
worker_thread+0x30/0x360
kthread+0x116/0x130
The lockup made the machine is quite unusable. And it also made the
most workingset gone, the reclaimabled slab caches were reduced from 12G
to 300MB, the page caches were decreased from 17G to 4G.
But the most disappointing thing is all the effort doesn't make the page
offline, it just returns:
soft_offline: 0x1469f2: unknown non LRU page type 5ffff0000000000 ()
It seems the aggressive behavior for non-LRU page didn't pay back, so it
doesn't make too much sense to keep it considering the terrible side
effect.
Link: https://lkml.kernel.org/r/20210819054116.266126-1-shy828301@gmail.com
Signed-off-by: Yang Shi <shy828301@gmail.com>
Reported-by: David Mackey <tdmackey@twitter.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-02 21:58:31 +00:00
|
|
|
shake_page(p);
|
2020-12-15 03:11:41 +00:00
|
|
|
goto try_again;
|
2021-08-20 02:04:24 +00:00
|
|
|
}
|
|
|
|
ret = -EIO;
|
2021-06-29 02:43:17 +00:00
|
|
|
goto out;
|
2020-12-15 03:11:41 +00:00
|
|
|
}
|
2021-06-29 02:43:17 +00:00
|
|
|
}
|
|
|
|
|
2022-03-22 21:44:50 +00:00
|
|
|
if (PageHuge(p) || HWPoisonHandlable(p, flags)) {
|
2021-06-29 02:43:17 +00:00
|
|
|
ret = 1;
|
2020-12-15 03:11:41 +00:00
|
|
|
} else {
|
2021-06-29 02:43:17 +00:00
|
|
|
/*
|
|
|
|
* A page we cannot handle. Check whether we can turn
|
|
|
|
* it into something we can handle.
|
|
|
|
*/
|
2024-06-12 07:18:25 +00:00
|
|
|
if (pass++ < GET_PAGE_MAX_RETRY_NUM) {
|
2020-12-15 03:11:41 +00:00
|
|
|
put_page(p);
|
mm: hwpoison: don't drop slab caches for offlining non-LRU page
In the current implementation of soft offline, if non-LRU page is met,
all the slab caches will be dropped to free the page then offline. But
if the page is not slab page all the effort is wasted in vain. Even
though it is a slab page, it is not guaranteed the page could be freed
at all.
However the side effect and cost is quite high. It does not only drop
the slab caches, but also may drop a significant amount of page caches
which are associated with inode caches. It could make the most
workingset gone in order to just offline a page. And the offline is not
guaranteed to succeed at all, actually I really doubt the success rate
for real life workload.
Furthermore the worse consequence is the system may be locked up and
unusable since the page cache release may incur huge amount of works
queued for memcg release.
Actually we ran into such unpleasant case in our production environment.
Firstly, the workqueue of memory_failure_work_func is locked up as
below:
BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 53s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=14/256 refcnt=15
in-flight: 409271:memory_failure_work_func
pending: kfree_rcu_work, kfree_rcu_monitor, kfree_rcu_work, rht_deferred_worker, rht_deferred_worker, rht_deferred_worker, rht_deferred_worker, kfree_rcu_work, kfree_rcu_work, kfree_rcu_work, kfree_rcu_work, drain_local_stock, kfree_rcu_work
workqueue mm_percpu_wq: flags=0x8
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
pending: vmstat_update
workqueue cgroup_destroy: flags=0x0
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/1 refcnt=12072
pending: css_release_work_fn
There were over 12K css_release_work_fn queued, and this caused a few
lockups due to the contention of worker pool lock with IRQ disabled, for
example:
NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
Modules linked in: amd64_edac_mod edac_mce_amd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xt_DSCP iptable_mangle kvm_amd bpfilter vfat fat acpi_ipmi i2c_piix4 usb_storage ipmi_si k10temp i2c_core ipmi_devintf ipmi_msghandler acpi_cpufreq sch_fq_codel xfs libcrc32c crc32c_intel mlx5_core mlxfw nvme xhci_pci ptp nvme_core pps_core xhci_hcd
CPU: 1 PID: 205500 Comm: kworker/1:0 Tainted: G L 5.10.32-t1.el7.twitter.x86_64 #1
Hardware name: TYAN F5AMT /z /S8026GM2NRE-CGN, BIOS V8.030 03/30/2021
Workqueue: events memory_failure_work_func
RIP: 0010:queued_spin_lock_slowpath+0x41/0x1a0
Code: 41 f0 0f ba 2f 08 0f 92 c0 0f b6 c0 c1 e0 08 89 c2 8b 07 30 e4 09 d0 a9 00 01 ff ff 75 1b 85 c0 74 0e 8b 07 84 c0 74 08 f3 90 <8b> 07 84 c0 75 f8 b8 01 00 00 00 66 89 07 c3 f6 c4 01 75 04 c6 47
RSP: 0018:ffff9b2ac278f900 EFLAGS: 00000002
RAX: 0000000000480101 RBX: ffff8ce98ce71800 RCX: 0000000000000084
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8ce98ce6a140
RBP: 00000000000284c8 R08: ffffd7248dcb6808 R09: 0000000000000000
R10: 0000000000000003 R11: ffff9b2ac278f9b0 R12: 0000000000000001
R13: ffff8cb44dab9c00 R14: ffffffffbd1ce6a0 R15: ffff8cacaa37f068
FS: 0000000000000000(0000) GS:ffff8ce98ce40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fcf6e8cb000 CR3: 0000000a0c60a000 CR4: 0000000000350ee0
Call Trace:
__queue_work+0xd6/0x3c0
queue_work_on+0x1c/0x30
uncharge_batch+0x10e/0x110
mem_cgroup_uncharge_list+0x6d/0x80
release_pages+0x37f/0x3f0
__pagevec_release+0x1c/0x50
__invalidate_mapping_pages+0x348/0x380
inode_lru_isolate+0x10a/0x160
__list_lru_walk_one+0x7b/0x170
list_lru_walk_one+0x4a/0x60
prune_icache_sb+0x37/0x50
super_cache_scan+0x123/0x1a0
do_shrink_slab+0x10c/0x2c0
shrink_slab+0x1f1/0x290
drop_slab_node+0x4d/0x70
soft_offline_page+0x1ac/0x5b0
memory_failure_work_func+0x6a/0x90
process_one_work+0x19e/0x340
worker_thread+0x30/0x360
kthread+0x116/0x130
The lockup made the machine is quite unusable. And it also made the
most workingset gone, the reclaimabled slab caches were reduced from 12G
to 300MB, the page caches were decreased from 17G to 4G.
But the most disappointing thing is all the effort doesn't make the page
offline, it just returns:
soft_offline: 0x1469f2: unknown non LRU page type 5ffff0000000000 ()
It seems the aggressive behavior for non-LRU page didn't pay back, so it
doesn't make too much sense to keep it considering the terrible side
effect.
Link: https://lkml.kernel.org/r/20210819054116.266126-1-shy828301@gmail.com
Signed-off-by: Yang Shi <shy828301@gmail.com>
Reported-by: David Mackey <tdmackey@twitter.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-02 21:58:31 +00:00
|
|
|
shake_page(p);
|
2021-06-29 02:43:17 +00:00
|
|
|
count_increased = false;
|
|
|
|
goto try_again;
|
2020-12-15 03:11:41 +00:00
|
|
|
}
|
2021-06-29 02:43:17 +00:00
|
|
|
put_page(p);
|
|
|
|
ret = -EIO;
|
2020-12-15 03:11:28 +00:00
|
|
|
}
|
2021-06-29 02:43:17 +00:00
|
|
|
out:
|
2021-09-02 21:58:37 +00:00
|
|
|
if (ret == -EIO)
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_err("%#lx: unhandlable page.\n", page_to_pfn(p));
|
2021-09-02 21:58:37 +00:00
|
|
|
|
2020-12-15 03:11:28 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
mm/hwpoison: fix unpoison_memory()
After recent soft-offline rework, error pages can be taken off from
buddy allocator, but the existing unpoison_memory() does not properly
undo the operation. Moreover, due to the recent change on
__get_hwpoison_page(), get_page_unless_zero() is hardly called for
hwpoisoned pages. So __get_hwpoison_page() highly likely returns -EBUSY
(meaning to fail to grab page refcount) and unpoison just clears
PG_hwpoison without releasing a refcount. That does not lead to a
critical issue like kernel panic, but unpoisoned pages never get back to
buddy (leaked permanently), which is not good.
To (partially) fix this, we need to identify "taken off" pages from
other types of hwpoisoned pages. We can't use refcount or page flags
for this purpose, so a pseudo flag is defined by hacking ->private
field. Someone might think that put_page() is enough to cancel
taken-off pages, but the normal free path contains some operations not
suitable for the current purpose, and can fire VM_BUG_ON().
Note that unpoison_memory() is now supposed to be cancel hwpoison events
injected only by madvise() or
/sys/devices/system/memory/{hard,soft}_offline_page, not by MCE
injection, so please don't try to use unpoison when testing with MCE
injection.
[lkp@intel.com: report build failure for ARCH=i386]
Link: https://lkml.kernel.org/r/20211115084006.3728254-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Ding Hui <dinghui@sangfor.com.cn>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-14 22:09:09 +00:00
|
|
|
static int __get_unpoison_page(struct page *page)
|
|
|
|
{
|
2023-01-18 17:40:39 +00:00
|
|
|
struct folio *folio = page_folio(page);
|
mm/hwpoison: fix unpoison_memory()
After recent soft-offline rework, error pages can be taken off from
buddy allocator, but the existing unpoison_memory() does not properly
undo the operation. Moreover, due to the recent change on
__get_hwpoison_page(), get_page_unless_zero() is hardly called for
hwpoisoned pages. So __get_hwpoison_page() highly likely returns -EBUSY
(meaning to fail to grab page refcount) and unpoison just clears
PG_hwpoison without releasing a refcount. That does not lead to a
critical issue like kernel panic, but unpoisoned pages never get back to
buddy (leaked permanently), which is not good.
To (partially) fix this, we need to identify "taken off" pages from
other types of hwpoisoned pages. We can't use refcount or page flags
for this purpose, so a pseudo flag is defined by hacking ->private
field. Someone might think that put_page() is enough to cancel
taken-off pages, but the normal free path contains some operations not
suitable for the current purpose, and can fire VM_BUG_ON().
Note that unpoison_memory() is now supposed to be cancel hwpoison events
injected only by madvise() or
/sys/devices/system/memory/{hard,soft}_offline_page, not by MCE
injection, so please don't try to use unpoison when testing with MCE
injection.
[lkp@intel.com: report build failure for ARCH=i386]
Link: https://lkml.kernel.org/r/20211115084006.3728254-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Ding Hui <dinghui@sangfor.com.cn>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-14 22:09:09 +00:00
|
|
|
int ret = 0;
|
|
|
|
bool hugetlb = false;
|
|
|
|
|
2023-01-18 17:40:39 +00:00
|
|
|
ret = get_hwpoison_hugetlb_folio(folio, &hugetlb, true);
|
2023-07-11 05:50:16 +00:00
|
|
|
if (hugetlb) {
|
|
|
|
/* Make sure hugetlb demotion did not happen from under us. */
|
|
|
|
if (folio == page_folio(page))
|
|
|
|
return ret;
|
|
|
|
if (ret > 0)
|
|
|
|
folio_put(folio);
|
|
|
|
}
|
mm/hwpoison: fix unpoison_memory()
After recent soft-offline rework, error pages can be taken off from
buddy allocator, but the existing unpoison_memory() does not properly
undo the operation. Moreover, due to the recent change on
__get_hwpoison_page(), get_page_unless_zero() is hardly called for
hwpoisoned pages. So __get_hwpoison_page() highly likely returns -EBUSY
(meaning to fail to grab page refcount) and unpoison just clears
PG_hwpoison without releasing a refcount. That does not lead to a
critical issue like kernel panic, but unpoisoned pages never get back to
buddy (leaked permanently), which is not good.
To (partially) fix this, we need to identify "taken off" pages from
other types of hwpoisoned pages. We can't use refcount or page flags
for this purpose, so a pseudo flag is defined by hacking ->private
field. Someone might think that put_page() is enough to cancel
taken-off pages, but the normal free path contains some operations not
suitable for the current purpose, and can fire VM_BUG_ON().
Note that unpoison_memory() is now supposed to be cancel hwpoison events
injected only by madvise() or
/sys/devices/system/memory/{hard,soft}_offline_page, not by MCE
injection, so please don't try to use unpoison when testing with MCE
injection.
[lkp@intel.com: report build failure for ARCH=i386]
Link: https://lkml.kernel.org/r/20211115084006.3728254-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Ding Hui <dinghui@sangfor.com.cn>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-14 22:09:09 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* PageHWPoisonTakenOff pages are not only marked as PG_hwpoison,
|
|
|
|
* but also isolated from buddy freelist, so need to identify the
|
|
|
|
* state and have to cancel both operations to unpoison.
|
|
|
|
*/
|
|
|
|
if (PageHWPoisonTakenOff(page))
|
|
|
|
return -EHWPOISON;
|
|
|
|
|
|
|
|
return get_page_unless_zero(page) ? 1 : 0;
|
|
|
|
}
|
|
|
|
|
2021-06-29 02:43:17 +00:00
|
|
|
/**
|
|
|
|
* get_hwpoison_page() - Get refcount for memory error handling
|
|
|
|
* @p: Raw error page (hit by memory error)
|
|
|
|
* @flags: Flags controlling behavior of error handling
|
|
|
|
*
|
|
|
|
* get_hwpoison_page() takes a page refcount of an error page to handle memory
|
|
|
|
* error on it, after checking that the error page is in a well-defined state
|
2022-01-14 22:09:25 +00:00
|
|
|
* (defined as a page-type we can successfully handle the memory error on it,
|
2021-06-29 02:43:17 +00:00
|
|
|
* such as LRU page and hugetlb page).
|
|
|
|
*
|
|
|
|
* Memory error handling could be triggered at any time on any type of page,
|
|
|
|
* so it's prone to race with typical memory management lifecycle (like
|
|
|
|
* allocation and free). So to avoid such races, get_hwpoison_page() takes
|
|
|
|
* extra care for the error page's state (as done in __get_hwpoison_page()),
|
|
|
|
* and has some retry logic in get_any_page().
|
|
|
|
*
|
mm/hwpoison: fix unpoison_memory()
After recent soft-offline rework, error pages can be taken off from
buddy allocator, but the existing unpoison_memory() does not properly
undo the operation. Moreover, due to the recent change on
__get_hwpoison_page(), get_page_unless_zero() is hardly called for
hwpoisoned pages. So __get_hwpoison_page() highly likely returns -EBUSY
(meaning to fail to grab page refcount) and unpoison just clears
PG_hwpoison without releasing a refcount. That does not lead to a
critical issue like kernel panic, but unpoisoned pages never get back to
buddy (leaked permanently), which is not good.
To (partially) fix this, we need to identify "taken off" pages from
other types of hwpoisoned pages. We can't use refcount or page flags
for this purpose, so a pseudo flag is defined by hacking ->private
field. Someone might think that put_page() is enough to cancel
taken-off pages, but the normal free path contains some operations not
suitable for the current purpose, and can fire VM_BUG_ON().
Note that unpoison_memory() is now supposed to be cancel hwpoison events
injected only by madvise() or
/sys/devices/system/memory/{hard,soft}_offline_page, not by MCE
injection, so please don't try to use unpoison when testing with MCE
injection.
[lkp@intel.com: report build failure for ARCH=i386]
Link: https://lkml.kernel.org/r/20211115084006.3728254-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Ding Hui <dinghui@sangfor.com.cn>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-14 22:09:09 +00:00
|
|
|
* When called from unpoison_memory(), the caller should already ensure that
|
|
|
|
* the given page has PG_hwpoison. So it's never reused for other page
|
|
|
|
* allocations, and __get_unpoison_page() never races with them.
|
|
|
|
*
|
2024-06-12 07:18:33 +00:00
|
|
|
* Return: 0 on failure or free buddy (hugetlb) page,
|
2021-06-29 02:43:17 +00:00
|
|
|
* 1 on success for in-use pages in a well-defined state,
|
|
|
|
* -EIO for pages on which we can not handle memory errors,
|
|
|
|
* -EBUSY when get_hwpoison_page() has raced with page lifecycle
|
mm/hwpoison: fix unpoison_memory()
After recent soft-offline rework, error pages can be taken off from
buddy allocator, but the existing unpoison_memory() does not properly
undo the operation. Moreover, due to the recent change on
__get_hwpoison_page(), get_page_unless_zero() is hardly called for
hwpoisoned pages. So __get_hwpoison_page() highly likely returns -EBUSY
(meaning to fail to grab page refcount) and unpoison just clears
PG_hwpoison without releasing a refcount. That does not lead to a
critical issue like kernel panic, but unpoisoned pages never get back to
buddy (leaked permanently), which is not good.
To (partially) fix this, we need to identify "taken off" pages from
other types of hwpoisoned pages. We can't use refcount or page flags
for this purpose, so a pseudo flag is defined by hacking ->private
field. Someone might think that put_page() is enough to cancel
taken-off pages, but the normal free path contains some operations not
suitable for the current purpose, and can fire VM_BUG_ON().
Note that unpoison_memory() is now supposed to be cancel hwpoison events
injected only by madvise() or
/sys/devices/system/memory/{hard,soft}_offline_page, not by MCE
injection, so please don't try to use unpoison when testing with MCE
injection.
[lkp@intel.com: report build failure for ARCH=i386]
Link: https://lkml.kernel.org/r/20211115084006.3728254-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Ding Hui <dinghui@sangfor.com.cn>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-14 22:09:09 +00:00
|
|
|
* operations like allocation and free,
|
|
|
|
* -EHWPOISON when the page is hwpoisoned and taken off from buddy.
|
2021-06-29 02:43:17 +00:00
|
|
|
*/
|
|
|
|
static int get_hwpoison_page(struct page *p, unsigned long flags)
|
2020-12-15 03:11:41 +00:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
zone_pcp_disable(page_zone(p));
|
mm/hwpoison: fix unpoison_memory()
After recent soft-offline rework, error pages can be taken off from
buddy allocator, but the existing unpoison_memory() does not properly
undo the operation. Moreover, due to the recent change on
__get_hwpoison_page(), get_page_unless_zero() is hardly called for
hwpoisoned pages. So __get_hwpoison_page() highly likely returns -EBUSY
(meaning to fail to grab page refcount) and unpoison just clears
PG_hwpoison without releasing a refcount. That does not lead to a
critical issue like kernel panic, but unpoisoned pages never get back to
buddy (leaked permanently), which is not good.
To (partially) fix this, we need to identify "taken off" pages from
other types of hwpoisoned pages. We can't use refcount or page flags
for this purpose, so a pseudo flag is defined by hacking ->private
field. Someone might think that put_page() is enough to cancel
taken-off pages, but the normal free path contains some operations not
suitable for the current purpose, and can fire VM_BUG_ON().
Note that unpoison_memory() is now supposed to be cancel hwpoison events
injected only by madvise() or
/sys/devices/system/memory/{hard,soft}_offline_page, not by MCE
injection, so please don't try to use unpoison when testing with MCE
injection.
[lkp@intel.com: report build failure for ARCH=i386]
Link: https://lkml.kernel.org/r/20211115084006.3728254-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Ding Hui <dinghui@sangfor.com.cn>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-14 22:09:09 +00:00
|
|
|
if (flags & MF_UNPOISON)
|
|
|
|
ret = __get_unpoison_page(p);
|
|
|
|
else
|
|
|
|
ret = get_any_page(p, flags);
|
2020-12-15 03:11:41 +00:00
|
|
|
zone_pcp_enable(page_zone(p));
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2009-09-16 09:50:15 +00:00
|
|
|
/*
|
|
|
|
* Do all that is necessary to remove user space mappings. Unmap
|
|
|
|
* the pages and send SIGBUS to the processes if the data was dirty.
|
|
|
|
*/
|
2024-04-12 19:35:05 +00:00
|
|
|
static bool hwpoison_user_mappings(struct folio *folio, struct page *p,
|
|
|
|
unsigned long pfn, int flags)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
2023-02-21 08:59:05 +00:00
|
|
|
enum ttu_flags ttu = TTU_IGNORE_MLOCK | TTU_SYNC | TTU_HWPOISON;
|
2009-09-16 09:50:15 +00:00
|
|
|
struct address_space *mapping;
|
|
|
|
LIST_HEAD(tokill);
|
2021-07-01 01:52:01 +00:00
|
|
|
bool unmap_success;
|
2022-08-18 13:00:15 +00:00
|
|
|
int forcekill;
|
2024-04-12 19:35:05 +00:00
|
|
|
bool mlocked = folio_test_mlocked(folio);
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2014-07-30 23:08:28 +00:00
|
|
|
/*
|
|
|
|
* Here we are interested only in user-mapped pages, so skip any
|
|
|
|
* other types of pages.
|
|
|
|
*/
|
2024-04-12 19:35:05 +00:00
|
|
|
if (folio_test_reserved(folio) || folio_test_slab(folio) ||
|
|
|
|
folio_test_pgtable(folio) || folio_test_offline(folio))
|
2017-05-03 21:54:20 +00:00
|
|
|
return true;
|
2024-04-12 19:35:05 +00:00
|
|
|
if (!(folio_test_lru(folio) || folio_test_hugetlb(folio)))
|
2017-05-03 21:54:20 +00:00
|
|
|
return true;
|
2009-09-16 09:50:15 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This check implies we don't kill processes if their pages
|
|
|
|
* are in the swap cache early. Those are always late kills.
|
|
|
|
*/
|
2024-06-12 07:18:26 +00:00
|
|
|
if (!folio_mapped(folio))
|
2017-05-03 21:54:20 +00:00
|
|
|
return true;
|
2009-12-16 11:19:58 +00:00
|
|
|
|
2024-04-12 19:35:05 +00:00
|
|
|
if (folio_test_swapcache(folio)) {
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_err("%#lx: keeping poisoned page in swap cache\n", pfn);
|
2023-02-21 08:59:05 +00:00
|
|
|
ttu &= ~TTU_HWPOISON;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Propagate the dirty bit from PTEs to struct page first, because we
|
|
|
|
* need this to decide if we should kill or just drop the page.
|
2009-12-16 11:19:58 +00:00
|
|
|
* XXX: the dirty test could be racy: set_page_dirty() may not always
|
|
|
|
* be called inside page lock (it's recommended but not enforced).
|
2009-09-16 09:50:15 +00:00
|
|
|
*/
|
2024-04-12 19:35:05 +00:00
|
|
|
mapping = folio_mapping(folio);
|
|
|
|
if (!(flags & MF_MUST_KILL) && !folio_test_dirty(folio) && mapping &&
|
2020-09-24 06:51:40 +00:00
|
|
|
mapping_can_writeback(mapping)) {
|
2024-04-12 19:35:05 +00:00
|
|
|
if (folio_mkclean(folio)) {
|
|
|
|
folio_set_dirty(folio);
|
2009-09-16 09:50:15 +00:00
|
|
|
} else {
|
2023-02-21 08:59:05 +00:00
|
|
|
ttu &= ~TTU_HWPOISON;
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_info("%#lx: corrupted page was clean: dropped without side effects\n",
|
2009-09-16 09:50:15 +00:00
|
|
|
pfn);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* First collect all the processes that have the page
|
|
|
|
* mapped in dirty form. This has to be done before try_to_unmap,
|
|
|
|
* because ttu takes the rmap data structures down.
|
|
|
|
*/
|
2023-12-18 13:58:35 +00:00
|
|
|
collect_procs(folio, p, &tokill, flags & MF_ACTION_REQUIRED);
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2024-04-12 19:35:05 +00:00
|
|
|
if (folio_test_hugetlb(folio) && !folio_test_anon(folio)) {
|
2022-03-22 21:44:27 +00:00
|
|
|
/*
|
|
|
|
* For hugetlb pages in shared mappings, try_to_unmap
|
|
|
|
* could potentially call huge_pmd_unshare. Because of
|
|
|
|
* this, take semaphore in write mode here and set
|
|
|
|
* TTU_RMAP_LOCKED to indicate we have taken the lock
|
|
|
|
* at this higher level.
|
|
|
|
*/
|
2024-04-12 19:35:03 +00:00
|
|
|
mapping = hugetlb_folio_mapping_lock_write(folio);
|
2022-03-22 21:44:27 +00:00
|
|
|
if (mapping) {
|
2022-03-23 00:03:12 +00:00
|
|
|
try_to_unmap(folio, ttu|TTU_RMAP_LOCKED);
|
2022-03-22 21:44:27 +00:00
|
|
|
i_mmap_unlock_write(mapping);
|
|
|
|
} else
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_info("%#lx: could not lock mapping for mapped huge page\n", pfn);
|
hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization
Patch series "hugetlbfs: use i_mmap_rwsem for more synchronization", v2.
While discussing the issue with huge_pte_offset [1], I remembered that
there were more outstanding hugetlb races. These issues are:
1) For shared pmds, huge PTE pointers returned by huge_pte_alloc can become
invalid via a call to huge_pmd_unshare by another thread.
2) hugetlbfs page faults can race with truncation causing invalid global
reserve counts and state.
A previous attempt was made to use i_mmap_rwsem in this manner as
described at [2]. However, those patches were reverted starting with [3]
due to locking issues.
To effectively use i_mmap_rwsem to address the above issues it needs to be
held (in read mode) during page fault processing. However, during fault
processing we need to lock the page we will be adding. Lock ordering
requires we take page lock before i_mmap_rwsem. Waiting until after
taking the page lock is too late in the fault process for the
synchronization we want to do.
To address this lock ordering issue, the following patches change the lock
ordering for hugetlb pages. This is not too invasive as hugetlbfs
processing is done separate from core mm in many places. However, I don't
really like this idea. Much ugliness is contained in the new routine
hugetlb_page_mapping_lock_write() of patch 1.
The only other way I can think of to address these issues is by catching
all the races. After catching a race, cleanup, backout, retry ... etc,
as needed. This can get really ugly, especially for huge page
reservations. At one time, I started writing some of the reservation
backout code for page faults and it got so ugly and complicated I went
down the path of adding synchronization to avoid the races. Any other
suggestions would be welcome.
[1] https://lore.kernel.org/linux-mm/1582342427-230392-1-git-send-email-longpeng2@huawei.com/
[2] https://lore.kernel.org/linux-mm/20181222223013.22193-1-mike.kravetz@oracle.com/
[3] https://lore.kernel.org/linux-mm/20190103235452.29335-1-mike.kravetz@oracle.com
[4] https://lore.kernel.org/linux-mm/1584028670.7365.182.camel@lca.pw/
[5] https://lore.kernel.org/lkml/20200312183142.108df9ac@canb.auug.org.au/
This patch (of 2):
While looking at BUGs associated with invalid huge page map counts, it was
discovered and observed that a huge pte pointer could become 'invalid' and
point to another task's page table. Consider the following:
A task takes a page fault on a shared hugetlbfs file and calls
huge_pte_alloc to get a ptep. Suppose the returned ptep points to a
shared pmd.
Now, another task truncates the hugetlbfs file. As part of truncation, it
unmaps everyone who has the file mapped. If the range being truncated is
covered by a shared pmd, huge_pmd_unshare will be called. For all but the
last user of the shared pmd, huge_pmd_unshare will clear the pud pointing
to the pmd. If the task in the middle of the page fault is not the last
user, the ptep returned by huge_pte_alloc now points to another task's
page table or worse. This leads to bad things such as incorrect page
map/reference counts or invalid memory references.
To fix, expand the use of i_mmap_rwsem as follows:
- i_mmap_rwsem is held in read mode whenever huge_pmd_share is called.
huge_pmd_share is only called via huge_pte_alloc, so callers of
huge_pte_alloc take i_mmap_rwsem before calling. In addition, callers
of huge_pte_alloc continue to hold the semaphore until finished with
the ptep.
- i_mmap_rwsem is held in write mode whenever huge_pmd_unshare is called.
One problem with this scheme is that it requires taking i_mmap_rwsem
before taking the page lock during page faults. This is not the order
specified in the rest of mm code. Handling of hugetlbfs pages is mostly
isolated today. Therefore, we use this alternative locking order for
PageHuge() pages.
mapping->i_mmap_rwsem
hugetlb_fault_mutex (hugetlbfs specific page fault mutex)
page->flags PG_locked (lock_page)
To help with lock ordering issues, hugetlb_page_mapping_lock_write() is
introduced to write lock the i_mmap_rwsem associated with a page.
In most cases it is easy to get address_space via vma->vm_file->f_mapping.
However, in the case of migration or memory errors for anon pages we do
not have an associated vma. A new routine _get_hugetlb_page_mapping()
will use anon_vma to get address_space in these cases.
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Prakash Sangappa <prakash.sangappa@oracle.com>
Link: http://lkml.kernel.org/r/20200316205756.146666-2-mike.kravetz@oracle.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-02 04:11:05 +00:00
|
|
|
} else {
|
2022-03-23 00:03:12 +00:00
|
|
|
try_to_unmap(folio, ttu);
|
hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization
Patch series "hugetlbfs: use i_mmap_rwsem for more synchronization", v2.
While discussing the issue with huge_pte_offset [1], I remembered that
there were more outstanding hugetlb races. These issues are:
1) For shared pmds, huge PTE pointers returned by huge_pte_alloc can become
invalid via a call to huge_pmd_unshare by another thread.
2) hugetlbfs page faults can race with truncation causing invalid global
reserve counts and state.
A previous attempt was made to use i_mmap_rwsem in this manner as
described at [2]. However, those patches were reverted starting with [3]
due to locking issues.
To effectively use i_mmap_rwsem to address the above issues it needs to be
held (in read mode) during page fault processing. However, during fault
processing we need to lock the page we will be adding. Lock ordering
requires we take page lock before i_mmap_rwsem. Waiting until after
taking the page lock is too late in the fault process for the
synchronization we want to do.
To address this lock ordering issue, the following patches change the lock
ordering for hugetlb pages. This is not too invasive as hugetlbfs
processing is done separate from core mm in many places. However, I don't
really like this idea. Much ugliness is contained in the new routine
hugetlb_page_mapping_lock_write() of patch 1.
The only other way I can think of to address these issues is by catching
all the races. After catching a race, cleanup, backout, retry ... etc,
as needed. This can get really ugly, especially for huge page
reservations. At one time, I started writing some of the reservation
backout code for page faults and it got so ugly and complicated I went
down the path of adding synchronization to avoid the races. Any other
suggestions would be welcome.
[1] https://lore.kernel.org/linux-mm/1582342427-230392-1-git-send-email-longpeng2@huawei.com/
[2] https://lore.kernel.org/linux-mm/20181222223013.22193-1-mike.kravetz@oracle.com/
[3] https://lore.kernel.org/linux-mm/20190103235452.29335-1-mike.kravetz@oracle.com
[4] https://lore.kernel.org/linux-mm/1584028670.7365.182.camel@lca.pw/
[5] https://lore.kernel.org/lkml/20200312183142.108df9ac@canb.auug.org.au/
This patch (of 2):
While looking at BUGs associated with invalid huge page map counts, it was
discovered and observed that a huge pte pointer could become 'invalid' and
point to another task's page table. Consider the following:
A task takes a page fault on a shared hugetlbfs file and calls
huge_pte_alloc to get a ptep. Suppose the returned ptep points to a
shared pmd.
Now, another task truncates the hugetlbfs file. As part of truncation, it
unmaps everyone who has the file mapped. If the range being truncated is
covered by a shared pmd, huge_pmd_unshare will be called. For all but the
last user of the shared pmd, huge_pmd_unshare will clear the pud pointing
to the pmd. If the task in the middle of the page fault is not the last
user, the ptep returned by huge_pte_alloc now points to another task's
page table or worse. This leads to bad things such as incorrect page
map/reference counts or invalid memory references.
To fix, expand the use of i_mmap_rwsem as follows:
- i_mmap_rwsem is held in read mode whenever huge_pmd_share is called.
huge_pmd_share is only called via huge_pte_alloc, so callers of
huge_pte_alloc take i_mmap_rwsem before calling. In addition, callers
of huge_pte_alloc continue to hold the semaphore until finished with
the ptep.
- i_mmap_rwsem is held in write mode whenever huge_pmd_unshare is called.
One problem with this scheme is that it requires taking i_mmap_rwsem
before taking the page lock during page faults. This is not the order
specified in the rest of mm code. Handling of hugetlbfs pages is mostly
isolated today. Therefore, we use this alternative locking order for
PageHuge() pages.
mapping->i_mmap_rwsem
hugetlb_fault_mutex (hugetlbfs specific page fault mutex)
page->flags PG_locked (lock_page)
To help with lock ordering issues, hugetlb_page_mapping_lock_write() is
introduced to write lock the i_mmap_rwsem associated with a page.
In most cases it is easy to get address_space via vma->vm_file->f_mapping.
However, in the case of migration or memory errors for anon pages we do
not have an associated vma. A new routine _get_hugetlb_page_mapping()
will use anon_vma to get address_space in these cases.
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Prakash Sangappa <prakash.sangappa@oracle.com>
Link: http://lkml.kernel.org/r/20200316205756.146666-2-mike.kravetz@oracle.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-02 04:11:05 +00:00
|
|
|
}
|
2021-07-01 01:52:01 +00:00
|
|
|
|
2024-06-12 07:18:26 +00:00
|
|
|
unmap_success = !folio_mapped(folio);
|
2017-05-03 21:54:20 +00:00
|
|
|
if (!unmap_success)
|
2024-04-09 19:22:52 +00:00
|
|
|
pr_err("%#lx: failed to unmap page (folio mapcount=%d)\n",
|
2024-06-12 07:18:26 +00:00
|
|
|
pfn, folio_mapcount(folio));
|
2011-02-01 23:52:40 +00:00
|
|
|
|
2017-05-03 21:56:22 +00:00
|
|
|
/*
|
|
|
|
* try_to_unmap() might put mlocked page in lru cache, so call
|
|
|
|
* shake_page() again to ensure that it's flushed.
|
|
|
|
*/
|
|
|
|
if (mlocked)
|
2024-04-12 19:35:02 +00:00
|
|
|
shake_folio(folio);
|
2017-05-03 21:56:22 +00:00
|
|
|
|
2009-09-16 09:50:15 +00:00
|
|
|
/*
|
|
|
|
* Now that the dirty bit has been propagated to the
|
|
|
|
* struct page and all unmaps done we can decide if
|
|
|
|
* killing is needed or not. Only kill when the page
|
2012-07-11 17:20:47 +00:00
|
|
|
* was dirty or the process is not restartable,
|
|
|
|
* otherwise the tokill list is merely
|
2009-09-16 09:50:15 +00:00
|
|
|
* freed. When there was a problem unmapping earlier
|
|
|
|
* use a more force-full uncatchable kill to prevent
|
|
|
|
* any accesses to the poisoned memory.
|
|
|
|
*/
|
2024-04-12 19:35:05 +00:00
|
|
|
forcekill = folio_test_dirty(folio) || (flags & MF_MUST_KILL) ||
|
2022-08-18 13:00:15 +00:00
|
|
|
!unmap_success;
|
mm/memory-failure: try to send SIGBUS even if unmap failed
Patch series "Enhance soft hwpoison handling and injection", v4.
This series is aimed at the following enhancements:
- Let one hwpoison injector, that is, madvise(MADV_HWPOISON) to behave
more like as if a real UE occurred. Because the other two injectors
such as hwpoison-inject and the 'einj' on x86 can't, and it seems to me
we need a better simulation to real UE scenario.
- For years, if the kernel is unable to unmap a hwpoisoned page, it send
a SIGKILL instead of SIGBUS to prevent user process from potentially
accessing the page again. But in doing so, the user process also lose
important information: vaddr, for recovery. Fortunately, the kernel
already has code to kill process re-accessing a hwpoisoned page, so
remove the '!unmap_success' check.
- Right now, if a thp page under GUP longterm pin is hwpoisoned, and
kernel cannot split the thp page, memory-failure simply ignores the UE
and returns. That's not ideal, it could deliver a SIGBUS with useful
information for userspace recovery.
This patch (of 5):
For years when it comes down to kill a process due to hwpoison, a SIGBUS
is delivered only if unmap has been successful. Otherwise, a SIGKILL is
delivered. And the reason for that is to prevent the involved process
from accessing the hwpoisoned page again.
Since then a lot has changed, a hwpoisoned page is marked and upon being
re-accessed, the memory-failure handler invokes kill_accessing_process()
to kill the process immediately. So let's take out the '!unmap_success'
factor and try to deliver SIGBUS if possible.
Link: https://lkml.kernel.org/r/20240524215306.2705454-1-jane.chu@oracle.com
Link: https://lkml.kernel.org/r/20240524215306.2705454-2-jane.chu@oracle.com
Signed-off-by: Jane Chu <jane.chu@oracle.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <oalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-24 21:53:02 +00:00
|
|
|
kill_procs(&tokill, forcekill, pfn, flags);
|
2009-12-16 11:19:58 +00:00
|
|
|
|
2017-05-03 21:54:20 +00:00
|
|
|
return unmap_success;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
2017-07-10 22:47:56 +00:00
|
|
|
static int identify_page_state(unsigned long pfn, struct page *p,
|
|
|
|
unsigned long page_flags)
|
2017-07-10 22:47:47 +00:00
|
|
|
{
|
|
|
|
struct page_state *ps;
|
2017-07-10 22:47:56 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The first check uses the current page flags which may not have any
|
|
|
|
* relevant information. The second check with the saved page flags is
|
|
|
|
* carried out only if the first check can't determine the page status.
|
|
|
|
*/
|
|
|
|
for (ps = error_states;; ps++)
|
|
|
|
if ((p->flags & ps->mask) == ps->res)
|
|
|
|
break;
|
|
|
|
|
|
|
|
page_flags |= (p->flags & (1UL << PG_dirty));
|
|
|
|
|
|
|
|
if (!ps->mask)
|
|
|
|
for (ps = error_states;; ps++)
|
|
|
|
if ((page_flags & ps->mask) == ps->res)
|
|
|
|
break;
|
|
|
|
return page_action(ps, p, pfn);
|
|
|
|
}
|
|
|
|
|
2024-05-24 21:53:06 +00:00
|
|
|
/*
|
|
|
|
* When 'release' is 'false', it means that if thp split has failed,
|
|
|
|
* there is still more to do, hence the page refcount we took earlier
|
|
|
|
* is still needed.
|
|
|
|
*/
|
|
|
|
static int try_to_split_thp_page(struct page *page, bool release)
|
2020-10-16 03:07:01 +00:00
|
|
|
{
|
2022-08-09 11:18:13 +00:00
|
|
|
int ret;
|
|
|
|
|
2020-10-16 03:07:01 +00:00
|
|
|
lock_page(page);
|
2022-08-09 11:18:13 +00:00
|
|
|
ret = split_huge_page(page);
|
|
|
|
unlock_page(page);
|
2020-10-16 03:07:01 +00:00
|
|
|
|
2024-05-24 21:53:06 +00:00
|
|
|
if (ret && release)
|
2020-10-16 03:07:01 +00:00
|
|
|
put_page(page);
|
|
|
|
|
2022-08-09 11:18:13 +00:00
|
|
|
return ret;
|
2020-10-16 03:07:01 +00:00
|
|
|
}
|
|
|
|
|
2022-06-03 05:37:26 +00:00
|
|
|
static void unmap_and_kill(struct list_head *to_kill, unsigned long pfn,
|
|
|
|
struct address_space *mapping, pgoff_t index, int flags)
|
|
|
|
{
|
|
|
|
struct to_kill *tk;
|
|
|
|
unsigned long size = 0;
|
|
|
|
|
|
|
|
list_for_each_entry(tk, to_kill, nd)
|
|
|
|
if (tk->size_shift)
|
|
|
|
size = max(size, 1UL << tk->size_shift);
|
|
|
|
|
|
|
|
if (size) {
|
|
|
|
/*
|
|
|
|
* Unmap the largest mapping to avoid breaking up device-dax
|
|
|
|
* mappings which are constant size. The actual size of the
|
|
|
|
* mapping being torn down is communicated in siginfo, see
|
|
|
|
* kill_proc()
|
|
|
|
*/
|
2023-12-18 13:58:37 +00:00
|
|
|
loff_t start = ((loff_t)index << PAGE_SHIFT) & ~(size - 1);
|
2022-06-03 05:37:26 +00:00
|
|
|
|
|
|
|
unmap_mapping_range(mapping, start, size, 0);
|
|
|
|
}
|
|
|
|
|
mm/memory-failure: try to send SIGBUS even if unmap failed
Patch series "Enhance soft hwpoison handling and injection", v4.
This series is aimed at the following enhancements:
- Let one hwpoison injector, that is, madvise(MADV_HWPOISON) to behave
more like as if a real UE occurred. Because the other two injectors
such as hwpoison-inject and the 'einj' on x86 can't, and it seems to me
we need a better simulation to real UE scenario.
- For years, if the kernel is unable to unmap a hwpoisoned page, it send
a SIGKILL instead of SIGBUS to prevent user process from potentially
accessing the page again. But in doing so, the user process also lose
important information: vaddr, for recovery. Fortunately, the kernel
already has code to kill process re-accessing a hwpoisoned page, so
remove the '!unmap_success' check.
- Right now, if a thp page under GUP longterm pin is hwpoisoned, and
kernel cannot split the thp page, memory-failure simply ignores the UE
and returns. That's not ideal, it could deliver a SIGBUS with useful
information for userspace recovery.
This patch (of 5):
For years when it comes down to kill a process due to hwpoison, a SIGBUS
is delivered only if unmap has been successful. Otherwise, a SIGKILL is
delivered. And the reason for that is to prevent the involved process
from accessing the hwpoisoned page again.
Since then a lot has changed, a hwpoisoned page is marked and upon being
re-accessed, the memory-failure handler invokes kill_accessing_process()
to kill the process immediately. So let's take out the '!unmap_success'
factor and try to deliver SIGBUS if possible.
Link: https://lkml.kernel.org/r/20240524215306.2705454-1-jane.chu@oracle.com
Link: https://lkml.kernel.org/r/20240524215306.2705454-2-jane.chu@oracle.com
Signed-off-by: Jane Chu <jane.chu@oracle.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <oalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-24 21:53:02 +00:00
|
|
|
kill_procs(to_kill, flags & MF_MUST_KILL, pfn, flags);
|
2022-06-03 05:37:26 +00:00
|
|
|
}
|
|
|
|
|
2023-08-22 23:13:14 +00:00
|
|
|
/*
|
|
|
|
* Only dev_pagemap pages get here, such as fsdax when the filesystem
|
|
|
|
* either do not claim or fails to claim a hwpoison event, or devdax.
|
|
|
|
* The fsdax pages are initialized per base page, and the devdax pages
|
|
|
|
* could be initialized either as base pages, or as compound pages with
|
|
|
|
* vmemmap optimization enabled. Devdax is simplistic in its dealing with
|
|
|
|
* hwpoison, such that, if a subpage of a compound page is poisoned,
|
|
|
|
* simply mark the compound head page is by far sufficient.
|
|
|
|
*/
|
2022-06-03 05:37:26 +00:00
|
|
|
static int mf_generic_kill_procs(unsigned long long pfn, int flags,
|
|
|
|
struct dev_pagemap *pgmap)
|
|
|
|
{
|
2023-08-22 23:13:14 +00:00
|
|
|
struct folio *folio = pfn_folio(pfn);
|
2022-06-03 05:37:26 +00:00
|
|
|
LIST_HEAD(to_kill);
|
|
|
|
dax_entry_t cookie;
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prevent the inode from being freed while we are interrogating
|
|
|
|
* the address_space, typically this would be handled by
|
|
|
|
* lock_page(), but dax pages do not use the page lock. This
|
|
|
|
* also prevents changes to the mapping of this pfn until
|
|
|
|
* poison signaling is complete.
|
|
|
|
*/
|
2023-08-22 23:13:14 +00:00
|
|
|
cookie = dax_lock_folio(folio);
|
2022-06-03 05:37:26 +00:00
|
|
|
if (!cookie)
|
|
|
|
return -EBUSY;
|
|
|
|
|
2023-08-22 23:13:14 +00:00
|
|
|
if (hwpoison_filter(&folio->page)) {
|
2022-06-03 05:37:26 +00:00
|
|
|
rc = -EOPNOTSUPP;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (pgmap->type) {
|
|
|
|
case MEMORY_DEVICE_PRIVATE:
|
|
|
|
case MEMORY_DEVICE_COHERENT:
|
|
|
|
/*
|
|
|
|
* TODO: Handle device pages which may need coordination
|
|
|
|
* with device-side memory.
|
|
|
|
*/
|
|
|
|
rc = -ENXIO;
|
|
|
|
goto unlock;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Use this flag as an indication that the dax page has been
|
|
|
|
* remapped UC to prevent speculative consumption of poison.
|
|
|
|
*/
|
2023-08-22 23:13:14 +00:00
|
|
|
SetPageHWPoison(&folio->page);
|
2022-06-03 05:37:26 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Unlike System-RAM there is no possibility to swap in a
|
|
|
|
* different physical page at a given virtual address, so all
|
|
|
|
* userspace consumption of ZONE_DEVICE memory necessitates
|
|
|
|
* SIGBUS (i.e. MF_MUST_KILL)
|
|
|
|
*/
|
|
|
|
flags |= MF_ACTION_REQUIRED | MF_MUST_KILL;
|
2023-12-18 13:58:35 +00:00
|
|
|
collect_procs(folio, &folio->page, &to_kill, true);
|
2022-06-03 05:37:26 +00:00
|
|
|
|
2023-08-22 23:13:14 +00:00
|
|
|
unmap_and_kill(&to_kill, pfn, folio->mapping, folio->index, flags);
|
2022-06-03 05:37:26 +00:00
|
|
|
unlock:
|
2023-08-22 23:13:14 +00:00
|
|
|
dax_unlock_folio(folio, cookie);
|
2022-06-03 05:37:26 +00:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2022-06-03 05:37:29 +00:00
|
|
|
#ifdef CONFIG_FS_DAX
|
|
|
|
/**
|
|
|
|
* mf_dax_kill_procs - Collect and kill processes who are using this file range
|
|
|
|
* @mapping: address_space of the file in use
|
|
|
|
* @index: start pgoff of the range within the file
|
|
|
|
* @count: length of the range, in unit of PAGE_SIZE
|
|
|
|
* @mf_flags: memory failure flags
|
|
|
|
*/
|
|
|
|
int mf_dax_kill_procs(struct address_space *mapping, pgoff_t index,
|
|
|
|
unsigned long count, int mf_flags)
|
|
|
|
{
|
|
|
|
LIST_HEAD(to_kill);
|
|
|
|
dax_entry_t cookie;
|
|
|
|
struct page *page;
|
|
|
|
size_t end = index + count;
|
mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for unbind
Now, if we suddenly remove a PMEM device(by calling unbind) which
contains FSDAX while programs are still accessing data in this device,
e.g.:
```
$FSSTRESS_PROG -d $SCRATCH_MNT -n 99999 -p 4 &
# $FSX_PROG -N 1000000 -o 8192 -l 500000 $SCRATCH_MNT/t001 &
echo "pfn1.1" > /sys/bus/nd/drivers/nd_pmem/unbind
```
it could come into an unacceptable state:
1. device has gone but mount point still exists, and umount will fail
with "target is busy"
2. programs will hang and cannot be killed
3. may crash with NULL pointer dereference
To fix this, we introduce a MF_MEM_PRE_REMOVE flag to let it know that we
are going to remove the whole device, and make sure all related processes
could be notified so that they could end up gracefully.
This patch is inspired by Dan's "mm, dax, pmem: Introduce
dev_pagemap_failure()"[1]. With the help of dax_holder and
->notify_failure() mechanism, the pmem driver is able to ask filesystem
on it to unmap all files in use, and notify processes who are using
those files.
Call trace:
trigger unbind
-> unbind_store()
-> ... (skip)
-> devres_release_all()
-> kill_dax()
-> dax_holder_notify_failure(dax_dev, 0, U64_MAX, MF_MEM_PRE_REMOVE)
-> xfs_dax_notify_failure()
`-> freeze_super() // freeze (kernel call)
`-> do xfs rmap
` -> mf_dax_kill_procs()
` -> collect_procs_fsdax() // all associated processes
` -> unmap_and_kill()
` -> invalidate_inode_pages2_range() // drop file's cache
`-> thaw_super() // thaw (both kernel & user call)
Introduce MF_MEM_PRE_REMOVE to let filesystem know this is a remove
event. Use the exclusive freeze/thaw[2] to lock the filesystem to prevent
new dax mapping from being created. Do not shutdown filesystem directly
if configuration is not supported, or if failure range includes metadata
area. Make sure all files and processes(not only the current progress)
are handled correctly. Also drop the cache of associated files before
pmem is removed.
[1]: https://lore.kernel.org/linux-mm/161604050314.1463742.14151665140035795571.stgit@dwillia2-desk3.amr.corp.intel.com/
[2]: https://lore.kernel.org/linux-xfs/169116275623.3187159.16862410128731457358.stg-ugh@frogsfrogsfrogs/
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
2023-10-23 07:20:46 +00:00
|
|
|
bool pre_remove = mf_flags & MF_MEM_PRE_REMOVE;
|
2022-06-03 05:37:29 +00:00
|
|
|
|
|
|
|
mf_flags |= MF_ACTION_REQUIRED | MF_MUST_KILL;
|
|
|
|
|
|
|
|
for (; index < end; index++) {
|
|
|
|
page = NULL;
|
|
|
|
cookie = dax_lock_mapping_entry(mapping, index, &page);
|
|
|
|
if (!cookie)
|
|
|
|
return -EBUSY;
|
|
|
|
if (!page)
|
|
|
|
goto unlock;
|
|
|
|
|
mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for unbind
Now, if we suddenly remove a PMEM device(by calling unbind) which
contains FSDAX while programs are still accessing data in this device,
e.g.:
```
$FSSTRESS_PROG -d $SCRATCH_MNT -n 99999 -p 4 &
# $FSX_PROG -N 1000000 -o 8192 -l 500000 $SCRATCH_MNT/t001 &
echo "pfn1.1" > /sys/bus/nd/drivers/nd_pmem/unbind
```
it could come into an unacceptable state:
1. device has gone but mount point still exists, and umount will fail
with "target is busy"
2. programs will hang and cannot be killed
3. may crash with NULL pointer dereference
To fix this, we introduce a MF_MEM_PRE_REMOVE flag to let it know that we
are going to remove the whole device, and make sure all related processes
could be notified so that they could end up gracefully.
This patch is inspired by Dan's "mm, dax, pmem: Introduce
dev_pagemap_failure()"[1]. With the help of dax_holder and
->notify_failure() mechanism, the pmem driver is able to ask filesystem
on it to unmap all files in use, and notify processes who are using
those files.
Call trace:
trigger unbind
-> unbind_store()
-> ... (skip)
-> devres_release_all()
-> kill_dax()
-> dax_holder_notify_failure(dax_dev, 0, U64_MAX, MF_MEM_PRE_REMOVE)
-> xfs_dax_notify_failure()
`-> freeze_super() // freeze (kernel call)
`-> do xfs rmap
` -> mf_dax_kill_procs()
` -> collect_procs_fsdax() // all associated processes
` -> unmap_and_kill()
` -> invalidate_inode_pages2_range() // drop file's cache
`-> thaw_super() // thaw (both kernel & user call)
Introduce MF_MEM_PRE_REMOVE to let filesystem know this is a remove
event. Use the exclusive freeze/thaw[2] to lock the filesystem to prevent
new dax mapping from being created. Do not shutdown filesystem directly
if configuration is not supported, or if failure range includes metadata
area. Make sure all files and processes(not only the current progress)
are handled correctly. Also drop the cache of associated files before
pmem is removed.
[1]: https://lore.kernel.org/linux-mm/161604050314.1463742.14151665140035795571.stgit@dwillia2-desk3.amr.corp.intel.com/
[2]: https://lore.kernel.org/linux-xfs/169116275623.3187159.16862410128731457358.stg-ugh@frogsfrogsfrogs/
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
2023-10-23 07:20:46 +00:00
|
|
|
if (!pre_remove)
|
|
|
|
SetPageHWPoison(page);
|
2022-06-03 05:37:29 +00:00
|
|
|
|
mm, pmem, xfs: Introduce MF_MEM_PRE_REMOVE for unbind
Now, if we suddenly remove a PMEM device(by calling unbind) which
contains FSDAX while programs are still accessing data in this device,
e.g.:
```
$FSSTRESS_PROG -d $SCRATCH_MNT -n 99999 -p 4 &
# $FSX_PROG -N 1000000 -o 8192 -l 500000 $SCRATCH_MNT/t001 &
echo "pfn1.1" > /sys/bus/nd/drivers/nd_pmem/unbind
```
it could come into an unacceptable state:
1. device has gone but mount point still exists, and umount will fail
with "target is busy"
2. programs will hang and cannot be killed
3. may crash with NULL pointer dereference
To fix this, we introduce a MF_MEM_PRE_REMOVE flag to let it know that we
are going to remove the whole device, and make sure all related processes
could be notified so that they could end up gracefully.
This patch is inspired by Dan's "mm, dax, pmem: Introduce
dev_pagemap_failure()"[1]. With the help of dax_holder and
->notify_failure() mechanism, the pmem driver is able to ask filesystem
on it to unmap all files in use, and notify processes who are using
those files.
Call trace:
trigger unbind
-> unbind_store()
-> ... (skip)
-> devres_release_all()
-> kill_dax()
-> dax_holder_notify_failure(dax_dev, 0, U64_MAX, MF_MEM_PRE_REMOVE)
-> xfs_dax_notify_failure()
`-> freeze_super() // freeze (kernel call)
`-> do xfs rmap
` -> mf_dax_kill_procs()
` -> collect_procs_fsdax() // all associated processes
` -> unmap_and_kill()
` -> invalidate_inode_pages2_range() // drop file's cache
`-> thaw_super() // thaw (both kernel & user call)
Introduce MF_MEM_PRE_REMOVE to let filesystem know this is a remove
event. Use the exclusive freeze/thaw[2] to lock the filesystem to prevent
new dax mapping from being created. Do not shutdown filesystem directly
if configuration is not supported, or if failure range includes metadata
area. Make sure all files and processes(not only the current progress)
are handled correctly. Also drop the cache of associated files before
pmem is removed.
[1]: https://lore.kernel.org/linux-mm/161604050314.1463742.14151665140035795571.stgit@dwillia2-desk3.amr.corp.intel.com/
[2]: https://lore.kernel.org/linux-xfs/169116275623.3187159.16862410128731457358.stg-ugh@frogsfrogsfrogs/
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
2023-10-23 07:20:46 +00:00
|
|
|
/*
|
|
|
|
* The pre_remove case is revoking access, the memory is still
|
|
|
|
* good and could theoretically be put back into service.
|
|
|
|
*/
|
|
|
|
collect_procs_fsdax(page, mapping, index, &to_kill, pre_remove);
|
2022-06-03 05:37:29 +00:00
|
|
|
unmap_and_kill(&to_kill, page_to_pfn(page), mapping,
|
|
|
|
index, mf_flags);
|
|
|
|
unlock:
|
|
|
|
dax_unlock_mapping_entry(mapping, index, cookie);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mf_dax_kill_procs);
|
|
|
|
#endif /* CONFIG_FS_DAX */
|
|
|
|
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
#ifdef CONFIG_HUGETLB_PAGE
|
2023-07-13 00:18:31 +00:00
|
|
|
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
/*
|
|
|
|
* Struct raw_hwp_page represents information about "raw error page",
|
mm,hugetlb: use folio fields in second tail page
Patch series "mm,huge,rmap: unify and speed up compound mapcounts".
This patch (of 3):
We want to declare one more int in the first tail of a compound page: that
first tail page being valuable property, since every compound page has a
first tail, but perhaps no more than that.
No problem on 64-bit: there is already space for it. No problem with
32-bit THPs: 5.18 commit 5232c63f46fd ("mm: Make compound_pincount always
available") kindly cleared the space for it, apparently not realizing that
only 64-bit architectures enable CONFIG_THP_SWAP (whose use of tail
page->private might conflict) - but make sure of that in its Kconfig.
But hugetlb pages use tail page->private of the first tail page for a
subpool pointer, which will conflict; and they also use page->private of
the 2nd, 3rd and 4th tails.
Undo "mm: add private field of first tail to struct page and struct
folio"'s recent addition of private_1 to the folio tail: instead add
hugetlb_subpool, hugetlb_cgroup, hugetlb_cgroup_rsvd, hugetlb_hwpoison to
a second tail page of the folio: THP has long been using several fields of
that tail, so make better use of it for hugetlb too. This is not how a
generic folio should be declared in future, but it is an effective
transitional way to make use of it.
Delete the SUBPAGE_INDEX stuff, but keep __NR_USED_SUBPAGE: now 3.
[hughd@google.com: prefix folio's page_1 and page_2 with double underscore,
give folio's _flags_2 and _head_2 a line documentation each]
Link: https://lkml.kernel.org/r/9e2cb6b-5b58-d3f2-b5ee-5f8a14e8f10@google.com
Link: https://lkml.kernel.org/r/5f52de70-975-e94f-f141-543765736181@google.com
Link: https://lkml.kernel.org/r/3818cc9a-9999-d064-d778-9c94c5911e6@google.com
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: James Houghton <jthoughton@google.com>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mina Almasry <almasrymina@google.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Naoya Horiguchi <naoya.horiguchi@linux.dev>
Cc: Peter Xu <peterx@redhat.com>
Cc: Sidhartha Kumar <sidhartha.kumar@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Zach O'Keefe <zokeefe@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-11-03 01:48:45 +00:00
|
|
|
* constructing singly linked list from ->_hugetlb_hwpoison field of folio.
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
*/
|
|
|
|
struct raw_hwp_page {
|
|
|
|
struct llist_node node;
|
|
|
|
struct page *page;
|
|
|
|
};
|
|
|
|
|
2023-01-12 20:46:05 +00:00
|
|
|
static inline struct llist_head *raw_hwp_list_head(struct folio *folio)
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
{
|
2023-01-12 20:46:05 +00:00
|
|
|
return (struct llist_head *)&folio->_hugetlb_hwpoison;
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
}
|
|
|
|
|
2023-07-13 00:18:31 +00:00
|
|
|
bool is_raw_hwpoison_page_in_hugepage(struct page *page)
|
|
|
|
{
|
|
|
|
struct llist_head *raw_hwp_head;
|
|
|
|
struct raw_hwp_page *p;
|
|
|
|
struct folio *folio = page_folio(page);
|
|
|
|
bool ret = false;
|
|
|
|
|
|
|
|
if (!folio_test_hwpoison(folio))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!folio_test_hugetlb(folio))
|
|
|
|
return PageHWPoison(page);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When RawHwpUnreliable is set, kernel lost track of which subpages
|
|
|
|
* are HWPOISON. So return as if ALL subpages are HWPOISONed.
|
|
|
|
*/
|
|
|
|
if (folio_test_hugetlb_raw_hwp_unreliable(folio))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
mutex_lock(&mf_mutex);
|
|
|
|
|
|
|
|
raw_hwp_head = raw_hwp_list_head(folio);
|
|
|
|
llist_for_each_entry(p, raw_hwp_head->first, node) {
|
|
|
|
if (page == p->page) {
|
|
|
|
ret = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&mf_mutex);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2023-01-12 20:46:06 +00:00
|
|
|
static unsigned long __folio_free_raw_hwp(struct folio *folio, bool move_flag)
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
{
|
2023-08-07 11:41:25 +00:00
|
|
|
struct llist_node *head;
|
|
|
|
struct raw_hwp_page *p, *next;
|
2022-07-14 04:24:16 +00:00
|
|
|
unsigned long count = 0;
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
|
mm/hwpoison: delete all entries before traversal in __folio_free_raw_hwp
Patch series "Improve hugetlbfs read on HWPOISON hugepages", v4.
Today when hardware memory is corrupted in a hugetlb hugepage, kernel
leaves the hugepage in pagecache [1]; otherwise future mmap or read will
suject to silent data corruption. This is implemented by returning -EIO
from hugetlb_read_iter immediately if the hugepage has HWPOISON flag set.
Since memory_failure already tracks the raw HWPOISON subpages in a
hugepage, a natural improvement is possible: if userspace only asks for
healthy subpages in the pagecache, kernel can return these data.
This patchset implements this improvement. It consist of three parts.
The 1st commit exports the functionality to tell if a subpage inside a
hugetlb hugepage is a raw HWPOISON page. The 2nd commit teaches
hugetlbfs_read_iter to return as many healthy bytes as possible. The 3rd
commit properly tests this new feature.
[1] commit 8625147cafaa ("hugetlbfs: don't delete error page from pagecache")
This patch (of 4):
Traversal on llist (e.g. llist_for_each_safe) is only safe AFTER entries
are deleted from the llist. Correct the way __folio_free_raw_hwp deletes
and frees raw_hwp_page entries in raw_hwp_list: first llist_del_all, then
kfree within llist_for_each_safe.
As of today, concurrent adding, deleting, and traversal on raw_hwp_list
from hugetlb.c and/or memory-failure.c are fine with each other. Note
this is guaranteed partly by the lock-free nature of llist, and partly by
holding hugetlb_lock and/or mf_mutex. For example, as llist_del_all is
lock-free with itself, folio_clear_hugetlb_hwpoison()s from
__update_and_free_hugetlb_folio and memory_failure won't need explicit
locking when freeing the raw_hwp_list. New code that manipulates
raw_hwp_list must be careful to ensure the concurrency correctness.
Link: https://lkml.kernel.org/r/20230713001833.3778937-1-jiaqiyan@google.com
Link: https://lkml.kernel.org/r/20230713001833.3778937-2-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Acked-by: Mike Kravetz <mike.kravetz@oracle.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: James Houghton <jthoughton@google.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-07-13 00:18:30 +00:00
|
|
|
head = llist_del_all(raw_hwp_list_head(folio));
|
2023-08-07 11:41:25 +00:00
|
|
|
llist_for_each_entry_safe(p, next, head, node) {
|
2022-07-14 04:24:16 +00:00
|
|
|
if (move_flag)
|
|
|
|
SetPageHWPoison(p->page);
|
2022-10-24 06:20:12 +00:00
|
|
|
else
|
|
|
|
num_poisoned_pages_sub(page_to_pfn(p->page), 1);
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
kfree(p);
|
2022-07-14 04:24:16 +00:00
|
|
|
count++;
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
}
|
2022-07-14 04:24:16 +00:00
|
|
|
return count;
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
}
|
|
|
|
|
2023-01-12 20:46:07 +00:00
|
|
|
static int folio_set_hugetlb_hwpoison(struct folio *folio, struct page *page)
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
{
|
|
|
|
struct llist_head *head;
|
|
|
|
struct raw_hwp_page *raw_hwp;
|
2024-05-13 07:58:30 +00:00
|
|
|
struct raw_hwp_page *p;
|
2023-01-12 20:46:07 +00:00
|
|
|
int ret = folio_test_set_hwpoison(folio) ? -EHWPOISON : 0;
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Once the hwpoison hugepage has lost reliable raw error info,
|
|
|
|
* there is little meaning to keep additional error info precisely,
|
|
|
|
* so skip to add additional raw error info.
|
|
|
|
*/
|
2023-01-12 20:46:05 +00:00
|
|
|
if (folio_test_hugetlb_raw_hwp_unreliable(folio))
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
return -EHWPOISON;
|
2023-01-12 20:46:05 +00:00
|
|
|
head = raw_hwp_list_head(folio);
|
2024-05-13 07:58:30 +00:00
|
|
|
llist_for_each_entry(p, head->first, node) {
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
if (p->page == page)
|
|
|
|
return -EHWPOISON;
|
|
|
|
}
|
|
|
|
|
|
|
|
raw_hwp = kmalloc(sizeof(struct raw_hwp_page), GFP_ATOMIC);
|
|
|
|
if (raw_hwp) {
|
|
|
|
raw_hwp->page = page;
|
|
|
|
llist_add(&raw_hwp->node, head);
|
|
|
|
/* the first error event will be counted in action_result(). */
|
|
|
|
if (ret)
|
2022-10-24 06:20:11 +00:00
|
|
|
num_poisoned_pages_inc(page_to_pfn(page));
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Failed to save raw error info. We no longer trace all
|
|
|
|
* hwpoisoned subpages, and we need refuse to free/dissolve
|
|
|
|
* this hwpoisoned hugepage.
|
|
|
|
*/
|
2023-01-12 20:46:05 +00:00
|
|
|
folio_set_hugetlb_raw_hwp_unreliable(folio);
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
/*
|
2023-01-12 20:46:05 +00:00
|
|
|
* Once hugetlb_raw_hwp_unreliable is set, raw_hwp_page is not
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
* used any more, so free it.
|
|
|
|
*/
|
2023-01-12 20:46:06 +00:00
|
|
|
__folio_free_raw_hwp(folio, false);
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2023-01-12 20:46:04 +00:00
|
|
|
static unsigned long folio_free_raw_hwp(struct folio *folio, bool move_flag)
|
2022-07-14 04:24:16 +00:00
|
|
|
{
|
|
|
|
/*
|
2023-01-12 20:46:04 +00:00
|
|
|
* hugetlb_vmemmap_optimized hugepages can't be freed because struct
|
2022-07-14 04:24:16 +00:00
|
|
|
* pages for tail pages are required but they don't exist.
|
|
|
|
*/
|
2023-01-12 20:46:04 +00:00
|
|
|
if (move_flag && folio_test_hugetlb_vmemmap_optimized(folio))
|
2022-07-14 04:24:16 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
2023-01-12 20:46:04 +00:00
|
|
|
* hugetlb_raw_hwp_unreliable hugepages shouldn't be unpoisoned by
|
2022-07-14 04:24:16 +00:00
|
|
|
* definition.
|
|
|
|
*/
|
2023-01-12 20:46:04 +00:00
|
|
|
if (folio_test_hugetlb_raw_hwp_unreliable(folio))
|
2022-07-14 04:24:16 +00:00
|
|
|
return 0;
|
|
|
|
|
2023-01-12 20:46:06 +00:00
|
|
|
return __folio_free_raw_hwp(folio, move_flag);
|
2022-07-14 04:24:16 +00:00
|
|
|
}
|
|
|
|
|
2023-01-12 20:46:03 +00:00
|
|
|
void folio_clear_hugetlb_hwpoison(struct folio *folio)
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
{
|
2023-01-12 20:46:03 +00:00
|
|
|
if (folio_test_hugetlb_raw_hwp_unreliable(folio))
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
return;
|
2023-07-11 05:50:10 +00:00
|
|
|
if (folio_test_hugetlb_vmemmap_optimized(folio))
|
|
|
|
return;
|
2023-01-12 20:46:03 +00:00
|
|
|
folio_clear_hwpoison(folio);
|
2023-01-12 20:46:04 +00:00
|
|
|
folio_free_raw_hwp(folio, true);
|
mm, hwpoison, hugetlb: support saving mechanism of raw error pages
When handling memory error on a hugetlb page, the error handler tries to
dissolve and turn it into 4kB pages. If it's successfully dissolved,
PageHWPoison flag is moved to the raw error page, so that's all right.
However, dissolve sometimes fails, then the error page is left as
hwpoisoned hugepage. It's useful if we can retry to dissolve it to save
healthy pages, but that's not possible now because the information about
where the raw error pages is lost.
Use the private field of a few tail pages to keep that information. The
code path of shrinking hugepage pool uses this info to try delayed
dissolve. In order to remember multiple errors in a hugepage, a
singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is
constructed. Only simple operations (adding an entry or clearing all) are
required and the list is assumed not to be very long, so this simple data
structure should be enough.
If we failed to save raw error info, the hwpoison hugepage has errors on
unknown subpage, then this new saving mechanism does not work any more, so
disable saving new raw error info and freeing hwpoison hugepages.
Link: https://lkml.kernel.org/r/20220714042420.1847125-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-14 04:24:15 +00:00
|
|
|
}
|
|
|
|
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
/*
|
|
|
|
* Called from hugetlb code with hugetlb_lock held.
|
|
|
|
*
|
|
|
|
* Return values:
|
|
|
|
* 0 - free hugepage
|
|
|
|
* 1 - in-use hugepage
|
|
|
|
* 2 - not a hugepage
|
|
|
|
* -EBUSY - the hugepage is busy (try to retry)
|
|
|
|
* -EHWPOISON - the hugepage is already hwpoisoned
|
|
|
|
*/
|
mm,hwpoison,hugetlb,memory_hotplug: hotremove memory section with hwpoisoned hugepage
Patch series "mm, hwpoison: improve handling workload related to hugetlb
and memory_hotplug", v7.
This patchset tries to solve the issue among memory_hotplug, hugetlb and hwpoison.
In this patchset, memory hotplug handles hwpoison pages like below:
- hwpoison pages should not prevent memory hotremove,
- memory block with hwpoison pages should not be onlined.
This patch (of 4):
HWPoisoned page is not supposed to be accessed once marked, but currently
such accesses can happen during memory hotremove because
do_migrate_range() can be called before dissolve_free_huge_pages() is
called.
Clear HPageMigratable for hwpoisoned hugepages to prevent them from being
migrated. This should be done in hugetlb_lock to avoid race against
isolate_hugetlb().
get_hwpoison_huge_page() needs to have a flag to show it's called from
unpoison to take refcount of hwpoisoned hugepages, so add it.
[naoya.horiguchi@linux.dev: remove TestClearHPageMigratable and reduce to test and clear separately]
Link: https://lkml.kernel.org/r/20221025053559.GA2104800@ik1-406-35019.vs.sakura.ne.jp
Link: https://lkml.kernel.org/r/20221024062012.1520887-1-naoya.horiguchi@linux.dev
Link: https://lkml.kernel.org/r/20221024062012.1520887-2-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-10-24 06:20:09 +00:00
|
|
|
int __get_huge_page_for_hwpoison(unsigned long pfn, int flags,
|
|
|
|
bool *migratable_cleared)
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
{
|
|
|
|
struct page *page = pfn_to_page(pfn);
|
2023-01-12 20:46:01 +00:00
|
|
|
struct folio *folio = page_folio(page);
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
int ret = 2; /* fallback to normal page handling */
|
|
|
|
bool count_increased = false;
|
|
|
|
|
2023-01-12 20:46:01 +00:00
|
|
|
if (!folio_test_hugetlb(folio))
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (flags & MF_COUNT_INCREASED) {
|
|
|
|
ret = 1;
|
|
|
|
count_increased = true;
|
2023-01-12 20:46:01 +00:00
|
|
|
} else if (folio_test_hugetlb_freed(folio)) {
|
2022-04-29 06:16:02 +00:00
|
|
|
ret = 0;
|
2023-01-12 20:46:01 +00:00
|
|
|
} else if (folio_test_hugetlb_migratable(folio)) {
|
|
|
|
ret = folio_try_get(folio);
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
if (ret)
|
|
|
|
count_increased = true;
|
|
|
|
} else {
|
|
|
|
ret = -EBUSY;
|
2022-07-14 04:24:17 +00:00
|
|
|
if (!(flags & MF_NO_RETRY))
|
|
|
|
goto out;
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
}
|
|
|
|
|
2023-01-12 20:46:07 +00:00
|
|
|
if (folio_set_hugetlb_hwpoison(folio, page)) {
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
ret = -EHWPOISON;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
mm,hwpoison,hugetlb,memory_hotplug: hotremove memory section with hwpoisoned hugepage
Patch series "mm, hwpoison: improve handling workload related to hugetlb
and memory_hotplug", v7.
This patchset tries to solve the issue among memory_hotplug, hugetlb and hwpoison.
In this patchset, memory hotplug handles hwpoison pages like below:
- hwpoison pages should not prevent memory hotremove,
- memory block with hwpoison pages should not be onlined.
This patch (of 4):
HWPoisoned page is not supposed to be accessed once marked, but currently
such accesses can happen during memory hotremove because
do_migrate_range() can be called before dissolve_free_huge_pages() is
called.
Clear HPageMigratable for hwpoisoned hugepages to prevent them from being
migrated. This should be done in hugetlb_lock to avoid race against
isolate_hugetlb().
get_hwpoison_huge_page() needs to have a flag to show it's called from
unpoison to take refcount of hwpoisoned hugepages, so add it.
[naoya.horiguchi@linux.dev: remove TestClearHPageMigratable and reduce to test and clear separately]
Link: https://lkml.kernel.org/r/20221025053559.GA2104800@ik1-406-35019.vs.sakura.ne.jp
Link: https://lkml.kernel.org/r/20221024062012.1520887-1-naoya.horiguchi@linux.dev
Link: https://lkml.kernel.org/r/20221024062012.1520887-2-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-10-24 06:20:09 +00:00
|
|
|
/*
|
2023-01-12 20:46:01 +00:00
|
|
|
* Clearing hugetlb_migratable for hwpoisoned hugepages to prevent them
|
mm,hwpoison,hugetlb,memory_hotplug: hotremove memory section with hwpoisoned hugepage
Patch series "mm, hwpoison: improve handling workload related to hugetlb
and memory_hotplug", v7.
This patchset tries to solve the issue among memory_hotplug, hugetlb and hwpoison.
In this patchset, memory hotplug handles hwpoison pages like below:
- hwpoison pages should not prevent memory hotremove,
- memory block with hwpoison pages should not be onlined.
This patch (of 4):
HWPoisoned page is not supposed to be accessed once marked, but currently
such accesses can happen during memory hotremove because
do_migrate_range() can be called before dissolve_free_huge_pages() is
called.
Clear HPageMigratable for hwpoisoned hugepages to prevent them from being
migrated. This should be done in hugetlb_lock to avoid race against
isolate_hugetlb().
get_hwpoison_huge_page() needs to have a flag to show it's called from
unpoison to take refcount of hwpoisoned hugepages, so add it.
[naoya.horiguchi@linux.dev: remove TestClearHPageMigratable and reduce to test and clear separately]
Link: https://lkml.kernel.org/r/20221025053559.GA2104800@ik1-406-35019.vs.sakura.ne.jp
Link: https://lkml.kernel.org/r/20221024062012.1520887-1-naoya.horiguchi@linux.dev
Link: https://lkml.kernel.org/r/20221024062012.1520887-2-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-10-24 06:20:09 +00:00
|
|
|
* from being migrated by memory hotremove.
|
|
|
|
*/
|
2023-01-12 20:46:01 +00:00
|
|
|
if (count_increased && folio_test_hugetlb_migratable(folio)) {
|
|
|
|
folio_clear_hugetlb_migratable(folio);
|
mm,hwpoison,hugetlb,memory_hotplug: hotremove memory section with hwpoisoned hugepage
Patch series "mm, hwpoison: improve handling workload related to hugetlb
and memory_hotplug", v7.
This patchset tries to solve the issue among memory_hotplug, hugetlb and hwpoison.
In this patchset, memory hotplug handles hwpoison pages like below:
- hwpoison pages should not prevent memory hotremove,
- memory block with hwpoison pages should not be onlined.
This patch (of 4):
HWPoisoned page is not supposed to be accessed once marked, but currently
such accesses can happen during memory hotremove because
do_migrate_range() can be called before dissolve_free_huge_pages() is
called.
Clear HPageMigratable for hwpoisoned hugepages to prevent them from being
migrated. This should be done in hugetlb_lock to avoid race against
isolate_hugetlb().
get_hwpoison_huge_page() needs to have a flag to show it's called from
unpoison to take refcount of hwpoisoned hugepages, so add it.
[naoya.horiguchi@linux.dev: remove TestClearHPageMigratable and reduce to test and clear separately]
Link: https://lkml.kernel.org/r/20221025053559.GA2104800@ik1-406-35019.vs.sakura.ne.jp
Link: https://lkml.kernel.org/r/20221024062012.1520887-1-naoya.horiguchi@linux.dev
Link: https://lkml.kernel.org/r/20221024062012.1520887-2-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-10-24 06:20:09 +00:00
|
|
|
*migratable_cleared = true;
|
|
|
|
}
|
|
|
|
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
return ret;
|
|
|
|
out:
|
|
|
|
if (count_increased)
|
2023-01-12 20:46:01 +00:00
|
|
|
folio_put(folio);
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Taking refcount of hugetlb pages needs extra care about race conditions
|
|
|
|
* with basic operations like hugepage allocation/free/demotion.
|
|
|
|
* So some of prechecks for hwpoison (pinning, and testing/setting
|
|
|
|
* PageHWPoison) should be done in single hugetlb_lock range.
|
|
|
|
*/
|
|
|
|
static int try_memory_failure_hugetlb(unsigned long pfn, int flags, int *hugetlb)
|
2017-07-10 22:47:56 +00:00
|
|
|
{
|
2017-07-10 22:47:47 +00:00
|
|
|
int res;
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
struct page *p = pfn_to_page(pfn);
|
2023-01-12 20:46:02 +00:00
|
|
|
struct folio *folio;
|
2017-07-10 22:47:47 +00:00
|
|
|
unsigned long page_flags;
|
mm,hwpoison,hugetlb,memory_hotplug: hotremove memory section with hwpoisoned hugepage
Patch series "mm, hwpoison: improve handling workload related to hugetlb
and memory_hotplug", v7.
This patchset tries to solve the issue among memory_hotplug, hugetlb and hwpoison.
In this patchset, memory hotplug handles hwpoison pages like below:
- hwpoison pages should not prevent memory hotremove,
- memory block with hwpoison pages should not be onlined.
This patch (of 4):
HWPoisoned page is not supposed to be accessed once marked, but currently
such accesses can happen during memory hotremove because
do_migrate_range() can be called before dissolve_free_huge_pages() is
called.
Clear HPageMigratable for hwpoisoned hugepages to prevent them from being
migrated. This should be done in hugetlb_lock to avoid race against
isolate_hugetlb().
get_hwpoison_huge_page() needs to have a flag to show it's called from
unpoison to take refcount of hwpoisoned hugepages, so add it.
[naoya.horiguchi@linux.dev: remove TestClearHPageMigratable and reduce to test and clear separately]
Link: https://lkml.kernel.org/r/20221025053559.GA2104800@ik1-406-35019.vs.sakura.ne.jp
Link: https://lkml.kernel.org/r/20221024062012.1520887-1-naoya.horiguchi@linux.dev
Link: https://lkml.kernel.org/r/20221024062012.1520887-2-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-10-24 06:20:09 +00:00
|
|
|
bool migratable_cleared = false;
|
2017-07-10 22:47:47 +00:00
|
|
|
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
*hugetlb = 1;
|
|
|
|
retry:
|
mm,hwpoison,hugetlb,memory_hotplug: hotremove memory section with hwpoisoned hugepage
Patch series "mm, hwpoison: improve handling workload related to hugetlb
and memory_hotplug", v7.
This patchset tries to solve the issue among memory_hotplug, hugetlb and hwpoison.
In this patchset, memory hotplug handles hwpoison pages like below:
- hwpoison pages should not prevent memory hotremove,
- memory block with hwpoison pages should not be onlined.
This patch (of 4):
HWPoisoned page is not supposed to be accessed once marked, but currently
such accesses can happen during memory hotremove because
do_migrate_range() can be called before dissolve_free_huge_pages() is
called.
Clear HPageMigratable for hwpoisoned hugepages to prevent them from being
migrated. This should be done in hugetlb_lock to avoid race against
isolate_hugetlb().
get_hwpoison_huge_page() needs to have a flag to show it's called from
unpoison to take refcount of hwpoisoned hugepages, so add it.
[naoya.horiguchi@linux.dev: remove TestClearHPageMigratable and reduce to test and clear separately]
Link: https://lkml.kernel.org/r/20221025053559.GA2104800@ik1-406-35019.vs.sakura.ne.jp
Link: https://lkml.kernel.org/r/20221024062012.1520887-1-naoya.horiguchi@linux.dev
Link: https://lkml.kernel.org/r/20221024062012.1520887-2-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-10-24 06:20:09 +00:00
|
|
|
res = get_huge_page_for_hwpoison(pfn, flags, &migratable_cleared);
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
if (res == 2) { /* fallback to normal page handling */
|
|
|
|
*hugetlb = 0;
|
|
|
|
return 0;
|
|
|
|
} else if (res == -EHWPOISON) {
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_err("%#lx: already hardware poisoned\n", pfn);
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
if (flags & MF_ACTION_REQUIRED) {
|
2023-01-12 20:46:02 +00:00
|
|
|
folio = page_folio(p);
|
|
|
|
res = kill_accessing_process(current, folio_pfn(folio), flags);
|
2024-05-24 21:53:04 +00:00
|
|
|
action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED);
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
}
|
|
|
|
return res;
|
|
|
|
} else if (res == -EBUSY) {
|
2022-07-14 04:24:17 +00:00
|
|
|
if (!(flags & MF_NO_RETRY)) {
|
|
|
|
flags |= MF_NO_RETRY;
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
goto retry;
|
|
|
|
}
|
2024-05-24 21:53:04 +00:00
|
|
|
return action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED);
|
2017-07-10 22:47:47 +00:00
|
|
|
}
|
|
|
|
|
2023-01-12 20:46:02 +00:00
|
|
|
folio = page_folio(p);
|
|
|
|
folio_lock(folio);
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
|
|
|
|
if (hwpoison_filter(p)) {
|
2023-01-12 20:46:03 +00:00
|
|
|
folio_clear_hugetlb_hwpoison(folio);
|
mm,hwpoison,hugetlb,memory_hotplug: hotremove memory section with hwpoisoned hugepage
Patch series "mm, hwpoison: improve handling workload related to hugetlb
and memory_hotplug", v7.
This patchset tries to solve the issue among memory_hotplug, hugetlb and hwpoison.
In this patchset, memory hotplug handles hwpoison pages like below:
- hwpoison pages should not prevent memory hotremove,
- memory block with hwpoison pages should not be onlined.
This patch (of 4):
HWPoisoned page is not supposed to be accessed once marked, but currently
such accesses can happen during memory hotremove because
do_migrate_range() can be called before dissolve_free_huge_pages() is
called.
Clear HPageMigratable for hwpoisoned hugepages to prevent them from being
migrated. This should be done in hugetlb_lock to avoid race against
isolate_hugetlb().
get_hwpoison_huge_page() needs to have a flag to show it's called from
unpoison to take refcount of hwpoisoned hugepages, so add it.
[naoya.horiguchi@linux.dev: remove TestClearHPageMigratable and reduce to test and clear separately]
Link: https://lkml.kernel.org/r/20221025053559.GA2104800@ik1-406-35019.vs.sakura.ne.jp
Link: https://lkml.kernel.org/r/20221024062012.1520887-1-naoya.horiguchi@linux.dev
Link: https://lkml.kernel.org/r/20221024062012.1520887-2-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-10-24 06:20:09 +00:00
|
|
|
if (migratable_cleared)
|
2023-01-12 20:46:02 +00:00
|
|
|
folio_set_hugetlb_migratable(folio);
|
|
|
|
folio_unlock(folio);
|
2022-08-18 13:00:11 +00:00
|
|
|
if (res == 1)
|
2023-01-12 20:46:02 +00:00
|
|
|
folio_put(folio);
|
2022-08-18 13:00:11 +00:00
|
|
|
return -EOPNOTSUPP;
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Handling free hugepage. The possible race with hugepage allocation
|
|
|
|
* or demotion can be prevented by PageHWPoison flag.
|
|
|
|
*/
|
|
|
|
if (res == 0) {
|
2023-01-12 20:46:02 +00:00
|
|
|
folio_unlock(folio);
|
2024-05-23 07:12:17 +00:00
|
|
|
if (__page_handle_poison(p) > 0) {
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
page_ref_inc(p);
|
|
|
|
res = MF_RECOVERED;
|
2022-07-14 04:24:19 +00:00
|
|
|
} else {
|
|
|
|
res = MF_FAILED;
|
2017-07-10 22:47:47 +00:00
|
|
|
}
|
2022-10-21 08:46:11 +00:00
|
|
|
return action_result(pfn, MF_MSG_FREE_HUGE, res);
|
2017-07-10 22:47:47 +00:00
|
|
|
}
|
|
|
|
|
2023-01-12 20:46:02 +00:00
|
|
|
page_flags = folio->flags;
|
2017-07-10 22:47:47 +00:00
|
|
|
|
2024-04-12 19:35:05 +00:00
|
|
|
if (!hwpoison_user_mappings(folio, p, pfn, flags)) {
|
2023-01-12 20:46:02 +00:00
|
|
|
folio_unlock(folio);
|
2024-05-24 21:53:04 +00:00
|
|
|
return action_result(pfn, MF_MSG_UNMAP_FAILED, MF_FAILED);
|
2017-07-10 22:47:47 +00:00
|
|
|
}
|
|
|
|
|
2021-06-25 01:40:01 +00:00
|
|
|
return identify_page_state(pfn, p, page_flags);
|
2017-07-10 22:47:47 +00:00
|
|
|
}
|
2022-06-03 05:37:26 +00:00
|
|
|
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
#else
|
|
|
|
static inline int try_memory_failure_hugetlb(unsigned long pfn, int flags, int *hugetlb)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2022-06-03 05:37:26 +00:00
|
|
|
|
2023-01-12 20:46:04 +00:00
|
|
|
static inline unsigned long folio_free_raw_hwp(struct folio *folio, bool flag)
|
2022-07-14 04:24:16 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2022-06-03 05:37:26 +00:00
|
|
|
#endif /* CONFIG_HUGETLB_PAGE */
|
2017-07-10 22:47:47 +00:00
|
|
|
|
2022-10-21 08:46:09 +00:00
|
|
|
/* Drop the extra refcount in case we come from madvise() */
|
|
|
|
static void put_ref_page(unsigned long pfn, int flags)
|
|
|
|
{
|
|
|
|
if (!(flags & MF_COUNT_INCREASED))
|
|
|
|
return;
|
|
|
|
|
2024-06-12 07:18:23 +00:00
|
|
|
put_page(pfn_to_page(pfn));
|
2022-10-21 08:46:09 +00:00
|
|
|
}
|
|
|
|
|
2018-07-14 04:50:21 +00:00
|
|
|
static int memory_failure_dev_pagemap(unsigned long pfn, int flags,
|
|
|
|
struct dev_pagemap *pgmap)
|
|
|
|
{
|
2022-06-03 05:37:26 +00:00
|
|
|
int rc = -ENXIO;
|
2018-07-14 04:50:21 +00:00
|
|
|
|
2021-02-26 01:17:08 +00:00
|
|
|
/* device metadata space is not recoverable */
|
2022-06-03 05:37:26 +00:00
|
|
|
if (!pgmap_pfn_valid(pgmap, pfn))
|
2021-02-26 01:17:08 +00:00
|
|
|
goto out;
|
2022-01-29 21:41:01 +00:00
|
|
|
|
2018-07-14 04:50:21 +00:00
|
|
|
/*
|
2022-06-03 05:37:27 +00:00
|
|
|
* Call driver's implementation to handle the memory failure, otherwise
|
|
|
|
* fall back to generic handler.
|
2018-07-14 04:50:21 +00:00
|
|
|
*/
|
2022-08-26 17:18:07 +00:00
|
|
|
if (pgmap_has_memory_failure(pgmap)) {
|
2022-06-03 05:37:27 +00:00
|
|
|
rc = pgmap->ops->memory_failure(pgmap, pfn, 1, flags);
|
2018-07-14 04:50:21 +00:00
|
|
|
/*
|
2022-06-03 05:37:27 +00:00
|
|
|
* Fall back to generic handler too if operation is not
|
|
|
|
* supported inside the driver/device/filesystem.
|
2018-07-14 04:50:21 +00:00
|
|
|
*/
|
2022-06-03 05:37:27 +00:00
|
|
|
if (rc != -EOPNOTSUPP)
|
|
|
|
goto out;
|
2018-07-14 04:50:21 +00:00
|
|
|
}
|
|
|
|
|
2022-06-03 05:37:26 +00:00
|
|
|
rc = mf_generic_kill_procs(pfn, flags, pgmap);
|
2018-07-14 04:50:21 +00:00
|
|
|
out:
|
|
|
|
/* drop pgmap ref acquired in caller */
|
|
|
|
put_dev_pagemap(pgmap);
|
2023-07-11 05:50:11 +00:00
|
|
|
if (rc != -EOPNOTSUPP)
|
|
|
|
action_result(pfn, MF_MSG_DAX, rc ? MF_FAILED : MF_RECOVERED);
|
2018-07-14 04:50:21 +00:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2024-05-24 21:53:06 +00:00
|
|
|
/*
|
|
|
|
* The calling condition is as such: thp split failed, page might have
|
|
|
|
* been RDMA pinned, not much can be done for recovery.
|
|
|
|
* But a SIGBUS should be delivered with vaddr provided so that the user
|
|
|
|
* application has a chance to recover. Also, application processes'
|
|
|
|
* election for MCE early killed will be honored.
|
|
|
|
*/
|
|
|
|
static void kill_procs_now(struct page *p, unsigned long pfn, int flags,
|
|
|
|
struct folio *folio)
|
|
|
|
{
|
|
|
|
LIST_HEAD(tokill);
|
|
|
|
|
|
|
|
collect_procs(folio, p, &tokill, flags & MF_ACTION_REQUIRED);
|
|
|
|
kill_procs(&tokill, true, pfn, flags);
|
|
|
|
}
|
|
|
|
|
2011-12-15 18:48:12 +00:00
|
|
|
/**
|
|
|
|
* memory_failure - Handle memory failure of a page.
|
|
|
|
* @pfn: Page Number of the corrupted page
|
|
|
|
* @flags: fine tune action taken
|
|
|
|
*
|
|
|
|
* This function is called by the low level machine check code
|
|
|
|
* of an architecture when it detects hardware memory corruption
|
|
|
|
* of a page. It tries its best to recover, which includes
|
|
|
|
* dropping pages, killing processes etc.
|
|
|
|
*
|
|
|
|
* The function is primarily of use for corruptions that
|
|
|
|
* happen outside the current execution context (e.g. when
|
|
|
|
* detected by a background scrubber)
|
|
|
|
*
|
|
|
|
* Must run in process context (e.g. a work queue) with interrupts
|
2023-07-11 05:50:14 +00:00
|
|
|
* enabled and no spinlocks held.
|
2022-03-22 21:44:38 +00:00
|
|
|
*
|
|
|
|
* Return: 0 for successfully handled the memory error,
|
2022-05-13 03:23:10 +00:00
|
|
|
* -EOPNOTSUPP for hwpoison_filter() filtered the error event,
|
2022-03-22 21:44:38 +00:00
|
|
|
* < 0(except -EOPNOTSUPP) on failure.
|
2011-12-15 18:48:12 +00:00
|
|
|
*/
|
2017-07-09 23:14:01 +00:00
|
|
|
int memory_failure(unsigned long pfn, int flags)
|
2009-09-16 09:50:15 +00:00
|
|
|
{
|
|
|
|
struct page *p;
|
2024-04-12 19:35:04 +00:00
|
|
|
struct folio *folio;
|
2018-07-14 04:50:21 +00:00
|
|
|
struct dev_pagemap *pgmap;
|
2021-06-25 01:39:55 +00:00
|
|
|
int res = 0;
|
2013-02-23 00:35:51 +00:00
|
|
|
unsigned long page_flags;
|
mm,hwpoison: take free pages off the buddy freelists
The crux of the matter is that historically we left poisoned pages in the
buddy system because we have some checks in place when allocating a page
that are gatekeeper for poisoned pages. Unfortunately, we do have other
users (e.g: compaction [1]) that scan buddy freelists and try to get a
page from there without checking whether the page is HWPoison.
As I stated already, I think it is fundamentally wrong to keep HWPoison
pages within the buddy systems, checks in place or not.
Let us fix this the same way we did for soft_offline [2], taking the page
off the buddy freelist so it is completely unreachable.
Note that this is fairly simple to trigger, as we only need to poison free
buddy pages (madvise MADV_HWPOISON) and then run some sort of memory
stress system.
Just for a matter of reference, I put a dump_page() in compaction_alloc()
to trigger for HWPoison patches:
page:0000000012b2982b refcount:1 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x1d5db
flags: 0xfffffc0800000(hwpoison)
raw: 000fffffc0800000 ffffea00007573c8 ffffc90000857de0 0000000000000000
raw: 0000000000000001 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: compaction_alloc
CPU: 4 PID: 123 Comm: kcompactd0 Tainted: G E 5.9.0-rc2-mm1-1-default+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
Call Trace:
dump_stack+0x6d/0x8b
compaction_alloc+0xb2/0xc0
migrate_pages+0x2a6/0x12a0
compact_zone+0x5eb/0x11c0
proactive_compact_node+0x89/0xf0
kcompactd+0x2d0/0x3a0
kthread+0x118/0x130
ret_from_fork+0x22/0x30
After that, if e.g: a process faults in the page, it will get killed
unexpectedly.
Fix it by containing the page immediatelly.
Besides that, two more changes can be noticed:
* MF_DELAYED no longer suits as we are fixing the issue by containing
the page immediately, so it does no longer rely on the allocation-time
checks to stop HWPoison to be handed over.
gain unless it is unpoisoned, so we fixed the situation.
Because of that, let us use MF_RECOVERED from now on.
* The second block that handles PageBuddy pages is no longer needed:
We call shake_page and then check whether the page is Buddy
because shake_page calls drain_all_pages, which sends pcp-pages back to
the buddy freelists, so we could have a chance to handle free pages.
Currently, get_hwpoison_page already calls drain_all_pages, and we call
get_hwpoison_page right before coming here, so we should be on the safe
side.
[1] https://lore.kernel.org/linux-mm/20190826104144.GA7849@linux/T/#u
[2] https://patchwork.kernel.org/cover/11792607/
[osalvador@suse.de: take the poisoned subpage off the buddy frelists]
Link: https://lkml.kernel.org/r/20201013144447.6706-4-osalvador@suse.de
Link: https://lkml.kernel.org/r/20201013144447.6706-3-osalvador@suse.de
Signed-off-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-12-15 03:11:32 +00:00
|
|
|
bool retry = true;
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
int hugetlb = 0;
|
2009-09-16 09:50:15 +00:00
|
|
|
|
|
|
|
if (!sysctl_memory_failure_recovery)
|
2017-07-09 23:14:01 +00:00
|
|
|
panic("Memory failure on page %lx", pfn);
|
2009-09-16 09:50:15 +00:00
|
|
|
|
2021-10-26 22:00:48 +00:00
|
|
|
mutex_lock(&mf_mutex);
|
|
|
|
|
2022-06-15 09:32:09 +00:00
|
|
|
if (!(flags & MF_SW_SIMULATED))
|
|
|
|
hw_memory_failure = true;
|
|
|
|
|
2019-10-19 03:19:23 +00:00
|
|
|
p = pfn_to_online_page(pfn);
|
|
|
|
if (!p) {
|
2021-10-26 22:00:48 +00:00
|
|
|
res = arch_memory_failure(pfn, flags);
|
|
|
|
if (res == 0)
|
|
|
|
goto unlock_mutex;
|
|
|
|
|
2019-10-19 03:19:23 +00:00
|
|
|
if (pfn_valid(pfn)) {
|
|
|
|
pgmap = get_dev_pagemap(pfn, NULL);
|
2023-07-01 07:28:37 +00:00
|
|
|
put_ref_page(pfn, flags);
|
2021-10-26 22:00:48 +00:00
|
|
|
if (pgmap) {
|
|
|
|
res = memory_failure_dev_pagemap(pfn, flags,
|
|
|
|
pgmap);
|
|
|
|
goto unlock_mutex;
|
|
|
|
}
|
2019-10-19 03:19:23 +00:00
|
|
|
}
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_err("%#lx: memory outside kernel control\n", pfn);
|
2021-10-26 22:00:48 +00:00
|
|
|
res = -ENXIO;
|
|
|
|
goto unlock_mutex;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
mm,hwpoison: take free pages off the buddy freelists
The crux of the matter is that historically we left poisoned pages in the
buddy system because we have some checks in place when allocating a page
that are gatekeeper for poisoned pages. Unfortunately, we do have other
users (e.g: compaction [1]) that scan buddy freelists and try to get a
page from there without checking whether the page is HWPoison.
As I stated already, I think it is fundamentally wrong to keep HWPoison
pages within the buddy systems, checks in place or not.
Let us fix this the same way we did for soft_offline [2], taking the page
off the buddy freelist so it is completely unreachable.
Note that this is fairly simple to trigger, as we only need to poison free
buddy pages (madvise MADV_HWPOISON) and then run some sort of memory
stress system.
Just for a matter of reference, I put a dump_page() in compaction_alloc()
to trigger for HWPoison patches:
page:0000000012b2982b refcount:1 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x1d5db
flags: 0xfffffc0800000(hwpoison)
raw: 000fffffc0800000 ffffea00007573c8 ffffc90000857de0 0000000000000000
raw: 0000000000000001 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: compaction_alloc
CPU: 4 PID: 123 Comm: kcompactd0 Tainted: G E 5.9.0-rc2-mm1-1-default+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
Call Trace:
dump_stack+0x6d/0x8b
compaction_alloc+0xb2/0xc0
migrate_pages+0x2a6/0x12a0
compact_zone+0x5eb/0x11c0
proactive_compact_node+0x89/0xf0
kcompactd+0x2d0/0x3a0
kthread+0x118/0x130
ret_from_fork+0x22/0x30
After that, if e.g: a process faults in the page, it will get killed
unexpectedly.
Fix it by containing the page immediatelly.
Besides that, two more changes can be noticed:
* MF_DELAYED no longer suits as we are fixing the issue by containing
the page immediately, so it does no longer rely on the allocation-time
checks to stop HWPoison to be handed over.
gain unless it is unpoisoned, so we fixed the situation.
Because of that, let us use MF_RECOVERED from now on.
* The second block that handles PageBuddy pages is no longer needed:
We call shake_page and then check whether the page is Buddy
because shake_page calls drain_all_pages, which sends pcp-pages back to
the buddy freelists, so we could have a chance to handle free pages.
Currently, get_hwpoison_page already calls drain_all_pages, and we call
get_hwpoison_page right before coming here, so we should be on the safe
side.
[1] https://lore.kernel.org/linux-mm/20190826104144.GA7849@linux/T/#u
[2] https://patchwork.kernel.org/cover/11792607/
[osalvador@suse.de: take the poisoned subpage off the buddy frelists]
Link: https://lkml.kernel.org/r/20201013144447.6706-4-osalvador@suse.de
Link: https://lkml.kernel.org/r/20201013144447.6706-3-osalvador@suse.de
Signed-off-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-12-15 03:11:32 +00:00
|
|
|
try_again:
|
mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()
There is a race condition between memory_failure_hugetlb() and hugetlb
free/demotion, which causes setting PageHWPoison flag on the wrong page.
The one simple result is that wrong processes can be killed, but another
(more serious) one is that the actual error is left unhandled, so no one
prevents later access to it, and that might lead to more serious results
like consuming corrupted data.
Think about the below race window:
CPU 1 CPU 2
memory_failure_hugetlb
struct page *head = compound_head(p);
hugetlb page might be freed to
buddy, or even changed to another
compound page.
get_hwpoison_page -- page is not what we want now...
The current code first does prechecks roughly and then reconfirms after
taking refcount, but it's found that it makes code overly complicated,
so move the prechecks in a single hugetlb_lock range.
A newly introduced function, try_memory_failure_hugetlb(), always takes
hugetlb_lock (even for non-hugetlb pages). That can be improved, but
memory_failure() is rare in principle, so should not be a big problem.
Link: https://lkml.kernel.org/r/20220408135323.1559401-2-naoya.horiguchi@linux.dev
Fixes: 761ad8d7c7b5 ("mm: hwpoison: introduce memory_failure_hugetlb()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-21 23:35:33 +00:00
|
|
|
res = try_memory_failure_hugetlb(pfn, flags, &hugetlb);
|
|
|
|
if (hugetlb)
|
2021-06-25 01:39:55 +00:00
|
|
|
goto unlock_mutex;
|
|
|
|
|
2009-09-16 09:50:15 +00:00
|
|
|
if (TestSetPageHWPoison(p)) {
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_err("%#lx: already hardware poisoned\n", pfn);
|
mm,hwpoison: return -EHWPOISON to denote that the page has already been poisoned
When memory_failure() is called with MF_ACTION_REQUIRED on the page that
has already been hwpoisoned, memory_failure() could fail to send SIGBUS
to the affected process, which results in infinite loop of MCEs.
Currently memory_failure() returns 0 if it's called for already
hwpoisoned page, then the caller, kill_me_maybe(), could return without
sending SIGBUS to current process. An action required MCE is raised
when the current process accesses to the broken memory, so no SIGBUS
means that the current process continues to run and access to the error
page again soon, so running into MCE loop.
This issue can arise for example in the following scenarios:
- Two or more threads access to the poisoned page concurrently. If
local MCE is enabled, MCE handler independently handles the MCE
events. So there's a race among MCE events, and the second or latter
threads fall into the situation in question.
- If there was a precedent memory error event and memory_failure() for
the event failed to unmap the error page for some reason, the
subsequent memory access to the error page triggers the MCE loop
situation.
To fix the issue, make memory_failure() return an error code when the
error page has already been hwpoisoned. This allows memory error
handler to control how it sends signals to userspace. And make sure
that any process touching a hwpoisoned page should get a SIGBUS even in
"already hwpoisoned" path of memory_failure() as is done in page fault
path.
Link: https://lkml.kernel.org/r/20210521030156.2612074-3-nao.horiguchi@gmail.com
Signed-off-by: Aili Yao <yaoaili@kingsoft.com>
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jue Wang <juew@google.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-06-25 01:39:58 +00:00
|
|
|
res = -EHWPOISON;
|
2021-06-29 02:43:14 +00:00
|
|
|
if (flags & MF_ACTION_REQUIRED)
|
|
|
|
res = kill_accessing_process(current, pfn, flags);
|
2022-04-29 06:16:02 +00:00
|
|
|
if (flags & MF_COUNT_INCREASED)
|
|
|
|
put_page(p);
|
2024-05-24 21:53:04 +00:00
|
|
|
action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED);
|
2021-06-25 01:39:55 +00:00
|
|
|
goto unlock_mutex;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We need/can do nothing about count=0 pages.
|
|
|
|
* 1) it's a free page, and therefore in safe hand:
|
2022-08-30 12:36:04 +00:00
|
|
|
* check_new_page() will be the gate keeper.
|
2017-07-10 22:47:47 +00:00
|
|
|
* 2) it's part of a non-compound high order page.
|
2009-09-16 09:50:15 +00:00
|
|
|
* Implies some kernel user: cannot stop them from
|
|
|
|
* R/W the page; let's pray that the page has been
|
|
|
|
* used and will be freed some time later.
|
|
|
|
* In fact it's dangerous to directly bump up page count from 0,
|
2018-08-22 04:53:13 +00:00
|
|
|
* that may make page_ref_freeze()/page_ref_unfreeze() mismatch.
|
2009-09-16 09:50:15 +00:00
|
|
|
*/
|
2021-06-29 02:43:17 +00:00
|
|
|
if (!(flags & MF_COUNT_INCREASED)) {
|
|
|
|
res = get_hwpoison_page(p, flags);
|
|
|
|
if (!res) {
|
|
|
|
if (is_free_buddy_page(p)) {
|
|
|
|
if (take_page_off_buddy(p)) {
|
|
|
|
page_ref_inc(p);
|
|
|
|
res = MF_RECOVERED;
|
|
|
|
} else {
|
|
|
|
/* We lost the race, try again */
|
|
|
|
if (retry) {
|
|
|
|
ClearPageHWPoison(p);
|
|
|
|
retry = false;
|
|
|
|
goto try_again;
|
|
|
|
}
|
|
|
|
res = MF_FAILED;
|
mm,hwpoison: take free pages off the buddy freelists
The crux of the matter is that historically we left poisoned pages in the
buddy system because we have some checks in place when allocating a page
that are gatekeeper for poisoned pages. Unfortunately, we do have other
users (e.g: compaction [1]) that scan buddy freelists and try to get a
page from there without checking whether the page is HWPoison.
As I stated already, I think it is fundamentally wrong to keep HWPoison
pages within the buddy systems, checks in place or not.
Let us fix this the same way we did for soft_offline [2], taking the page
off the buddy freelist so it is completely unreachable.
Note that this is fairly simple to trigger, as we only need to poison free
buddy pages (madvise MADV_HWPOISON) and then run some sort of memory
stress system.
Just for a matter of reference, I put a dump_page() in compaction_alloc()
to trigger for HWPoison patches:
page:0000000012b2982b refcount:1 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x1d5db
flags: 0xfffffc0800000(hwpoison)
raw: 000fffffc0800000 ffffea00007573c8 ffffc90000857de0 0000000000000000
raw: 0000000000000001 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: compaction_alloc
CPU: 4 PID: 123 Comm: kcompactd0 Tainted: G E 5.9.0-rc2-mm1-1-default+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
Call Trace:
dump_stack+0x6d/0x8b
compaction_alloc+0xb2/0xc0
migrate_pages+0x2a6/0x12a0
compact_zone+0x5eb/0x11c0
proactive_compact_node+0x89/0xf0
kcompactd+0x2d0/0x3a0
kthread+0x118/0x130
ret_from_fork+0x22/0x30
After that, if e.g: a process faults in the page, it will get killed
unexpectedly.
Fix it by containing the page immediatelly.
Besides that, two more changes can be noticed:
* MF_DELAYED no longer suits as we are fixing the issue by containing
the page immediately, so it does no longer rely on the allocation-time
checks to stop HWPoison to be handed over.
gain unless it is unpoisoned, so we fixed the situation.
Because of that, let us use MF_RECOVERED from now on.
* The second block that handles PageBuddy pages is no longer needed:
We call shake_page and then check whether the page is Buddy
because shake_page calls drain_all_pages, which sends pcp-pages back to
the buddy freelists, so we could have a chance to handle free pages.
Currently, get_hwpoison_page already calls drain_all_pages, and we call
get_hwpoison_page right before coming here, so we should be on the safe
side.
[1] https://lore.kernel.org/linux-mm/20190826104144.GA7849@linux/T/#u
[2] https://patchwork.kernel.org/cover/11792607/
[osalvador@suse.de: take the poisoned subpage off the buddy frelists]
Link: https://lkml.kernel.org/r/20201013144447.6706-4-osalvador@suse.de
Link: https://lkml.kernel.org/r/20201013144447.6706-3-osalvador@suse.de
Signed-off-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-12-15 03:11:32 +00:00
|
|
|
}
|
2022-10-21 08:46:11 +00:00
|
|
|
res = action_result(pfn, MF_MSG_BUDDY, res);
|
2021-06-29 02:43:17 +00:00
|
|
|
} else {
|
2022-10-21 08:46:11 +00:00
|
|
|
res = action_result(pfn, MF_MSG_KERNEL_HIGH_ORDER, MF_IGNORED);
|
mm,hwpoison: take free pages off the buddy freelists
The crux of the matter is that historically we left poisoned pages in the
buddy system because we have some checks in place when allocating a page
that are gatekeeper for poisoned pages. Unfortunately, we do have other
users (e.g: compaction [1]) that scan buddy freelists and try to get a
page from there without checking whether the page is HWPoison.
As I stated already, I think it is fundamentally wrong to keep HWPoison
pages within the buddy systems, checks in place or not.
Let us fix this the same way we did for soft_offline [2], taking the page
off the buddy freelist so it is completely unreachable.
Note that this is fairly simple to trigger, as we only need to poison free
buddy pages (madvise MADV_HWPOISON) and then run some sort of memory
stress system.
Just for a matter of reference, I put a dump_page() in compaction_alloc()
to trigger for HWPoison patches:
page:0000000012b2982b refcount:1 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x1d5db
flags: 0xfffffc0800000(hwpoison)
raw: 000fffffc0800000 ffffea00007573c8 ffffc90000857de0 0000000000000000
raw: 0000000000000001 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: compaction_alloc
CPU: 4 PID: 123 Comm: kcompactd0 Tainted: G E 5.9.0-rc2-mm1-1-default+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
Call Trace:
dump_stack+0x6d/0x8b
compaction_alloc+0xb2/0xc0
migrate_pages+0x2a6/0x12a0
compact_zone+0x5eb/0x11c0
proactive_compact_node+0x89/0xf0
kcompactd+0x2d0/0x3a0
kthread+0x118/0x130
ret_from_fork+0x22/0x30
After that, if e.g: a process faults in the page, it will get killed
unexpectedly.
Fix it by containing the page immediatelly.
Besides that, two more changes can be noticed:
* MF_DELAYED no longer suits as we are fixing the issue by containing
the page immediately, so it does no longer rely on the allocation-time
checks to stop HWPoison to be handed over.
gain unless it is unpoisoned, so we fixed the situation.
Because of that, let us use MF_RECOVERED from now on.
* The second block that handles PageBuddy pages is no longer needed:
We call shake_page and then check whether the page is Buddy
because shake_page calls drain_all_pages, which sends pcp-pages back to
the buddy freelists, so we could have a chance to handle free pages.
Currently, get_hwpoison_page already calls drain_all_pages, and we call
get_hwpoison_page right before coming here, so we should be on the safe
side.
[1] https://lore.kernel.org/linux-mm/20190826104144.GA7849@linux/T/#u
[2] https://patchwork.kernel.org/cover/11792607/
[osalvador@suse.de: take the poisoned subpage off the buddy frelists]
Link: https://lkml.kernel.org/r/20201013144447.6706-4-osalvador@suse.de
Link: https://lkml.kernel.org/r/20201013144447.6706-3-osalvador@suse.de
Signed-off-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-12-15 03:11:32 +00:00
|
|
|
}
|
2021-06-29 02:43:17 +00:00
|
|
|
goto unlock_mutex;
|
|
|
|
} else if (res < 0) {
|
2024-05-24 21:53:04 +00:00
|
|
|
res = action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED);
|
2021-06-29 02:43:17 +00:00
|
|
|
goto unlock_mutex;
|
2009-12-16 11:19:58 +00:00
|
|
|
}
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
2024-04-12 19:35:04 +00:00
|
|
|
folio = page_folio(p);
|
2024-05-24 21:53:05 +00:00
|
|
|
|
|
|
|
/* filter pages that are protected from hwpoison test by users */
|
|
|
|
folio_lock(folio);
|
|
|
|
if (hwpoison_filter(p)) {
|
|
|
|
ClearPageHWPoison(p);
|
|
|
|
folio_unlock(folio);
|
|
|
|
folio_put(folio);
|
|
|
|
res = -EOPNOTSUPP;
|
|
|
|
goto unlock_mutex;
|
|
|
|
}
|
|
|
|
folio_unlock(folio);
|
|
|
|
|
2024-04-12 19:35:04 +00:00
|
|
|
if (folio_test_large(folio)) {
|
2021-10-28 21:36:11 +00:00
|
|
|
/*
|
|
|
|
* The flag must be set after the refcount is bumped
|
|
|
|
* otherwise it may race with THP split.
|
|
|
|
* And the flag can't be set in get_hwpoison_page() since
|
|
|
|
* it is called by soft offline too and it is just called
|
2023-07-11 05:50:14 +00:00
|
|
|
* for !MF_COUNT_INCREASED. So here seems to be the best
|
2021-10-28 21:36:11 +00:00
|
|
|
* place.
|
|
|
|
*
|
|
|
|
* Don't need care about the above error handling paths for
|
|
|
|
* get_hwpoison_page() since they handle either free page
|
|
|
|
* or unhandlable page. The refcount is bumped iff the
|
|
|
|
* page is a valid handlable page.
|
|
|
|
*/
|
2024-04-12 19:35:04 +00:00
|
|
|
folio_set_has_hwpoisoned(folio);
|
2024-05-24 21:53:06 +00:00
|
|
|
if (try_to_split_thp_page(p, false) < 0) {
|
|
|
|
res = -EHWPOISON;
|
|
|
|
kill_procs_now(p, pfn, flags, folio);
|
|
|
|
put_page(p);
|
|
|
|
action_result(pfn, MF_MSG_UNSPLIT_THP, MF_FAILED);
|
2021-06-25 01:39:55 +00:00
|
|
|
goto unlock_mutex;
|
2020-10-16 03:07:21 +00:00
|
|
|
}
|
2015-06-24 23:56:45 +00:00
|
|
|
VM_BUG_ON_PAGE(!page_count(p), p);
|
2024-04-12 19:35:04 +00:00
|
|
|
folio = page_folio(p);
|
2015-06-24 23:56:45 +00:00
|
|
|
}
|
|
|
|
|
2009-09-29 05:16:20 +00:00
|
|
|
/*
|
|
|
|
* We ignore non-LRU pages for good reasons.
|
|
|
|
* - PG_locked is only well defined for LRU pages and a few others
|
2016-01-16 00:51:24 +00:00
|
|
|
* - to avoid races with __SetPageLocked()
|
2009-09-29 05:16:20 +00:00
|
|
|
* - to avoid races with __SetPageSlab*() (and more non-atomic ops)
|
|
|
|
* The check (unnecessarily) ignores LRU pages being isolated and
|
|
|
|
* walked by the page reclaim code, however that's not a big loss.
|
|
|
|
*/
|
2024-04-12 19:35:04 +00:00
|
|
|
shake_folio(folio);
|
2009-09-29 05:16:20 +00:00
|
|
|
|
2024-04-12 19:35:04 +00:00
|
|
|
folio_lock(folio);
|
2009-12-16 11:19:58 +00:00
|
|
|
|
2014-08-06 23:06:49 +00:00
|
|
|
/*
|
2022-03-22 21:44:21 +00:00
|
|
|
* We're only intended to deal with the non-Compound page here.
|
|
|
|
* However, the page could have changed compound pages due to
|
|
|
|
* race window. If this happens, we could try again to hopefully
|
|
|
|
* handle the page next round.
|
2014-08-06 23:06:49 +00:00
|
|
|
*/
|
2024-04-12 19:35:04 +00:00
|
|
|
if (folio_test_large(folio)) {
|
2022-03-22 21:44:21 +00:00
|
|
|
if (retry) {
|
2022-05-13 03:23:10 +00:00
|
|
|
ClearPageHWPoison(p);
|
2024-04-12 19:35:04 +00:00
|
|
|
folio_unlock(folio);
|
|
|
|
folio_put(folio);
|
2022-03-22 21:44:21 +00:00
|
|
|
flags &= ~MF_COUNT_INCREASED;
|
|
|
|
retry = false;
|
|
|
|
goto try_again;
|
|
|
|
}
|
2022-10-21 08:46:11 +00:00
|
|
|
res = action_result(pfn, MF_MSG_DIFFERENT_COMPOUND, MF_IGNORED);
|
2021-06-25 01:39:55 +00:00
|
|
|
goto unlock_page;
|
2014-08-06 23:06:49 +00:00
|
|
|
}
|
|
|
|
|
2013-02-23 00:35:51 +00:00
|
|
|
/*
|
|
|
|
* We use page flags to determine what action should be taken, but
|
|
|
|
* the flags can be modified by the error containment action. One
|
|
|
|
* example is an mlocked page, where PG_mlocked is cleared by
|
2023-12-20 22:44:56 +00:00
|
|
|
* folio_remove_rmap_*() in try_to_unmap_one(). So to determine page
|
|
|
|
* status correctly, we save a copy of the page flags at this time.
|
2013-02-23 00:35:51 +00:00
|
|
|
*/
|
2024-04-12 19:35:04 +00:00
|
|
|
page_flags = folio->flags;
|
2013-02-23 00:35:51 +00:00
|
|
|
|
2021-06-16 01:23:32 +00:00
|
|
|
/*
|
2024-04-12 19:35:04 +00:00
|
|
|
* __munlock_folio() may clear a writeback folio's LRU flag without
|
|
|
|
* the folio lock. We need to wait for writeback completion for this
|
|
|
|
* folio or it may trigger a vfs BUG while evicting inode.
|
2021-06-16 01:23:32 +00:00
|
|
|
*/
|
2024-04-12 19:35:04 +00:00
|
|
|
if (!folio_test_lru(folio) && !folio_test_writeback(folio))
|
hwpoison: fix the handling path of the victimized page frame that belong to non-LRU
Until now, the kernel has the same policy to handle victimized page
frames that belong to kernel-space(reserved/slab-subsystem) or
non-LRU(unknown page state). In other word, the result of handling
either of these victimized page frames is (IGNORED | FAILED), and the
return value of memory_failure() is -EBUSY.
This patch is to avoid that memory_failure() returns very soon due to
the "true" value of (!PageLRU(p)), and it also ensures that
action_result() can report more precise information("reserved kernel",
"kernel slab", and "unknown page state") instead of "non LRU",
especially for memory errors which are detected by memory-scrubbing.
Andi said:
: While running the mcelog test suite on 3.14 I hit the following VM_BUG_ON:
:
: soft_offline: 0x56d4: unknown non LRU page type 3ffff800008000
: page:ffffea000015b400 count:3 mapcount:2097169 mapping: (null) index:0xffff8800056d7000
: page flags: 0x3ffff800004081(locked|slab|head)
: ------------[ cut here ]------------
: kernel BUG at mm/rmap.c:1495!
:
: I think what happened is that a LRU page turned into a slab page in
: parallel with offlining. memory_failure initially tests for this case,
: but doesn't retest later after the page has been locked.
:
: ...
:
: I ran this patch in a loop over night with some stress plus
: the mcelog test suite running in a loop. I cannot guarantee it hit it,
: but it should have given it a good beating.
:
: The kernel survived with no messages, although the mcelog test suite
: got killed at some point because it couldn't fork anymore. Probably
: some unrelated problem.
:
: So the patch is ok for me for .16.
Signed-off-by: Chen Yucong <slaoub@gmail.com>
Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reported-by: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-07-02 22:22:37 +00:00
|
|
|
goto identify_page_state;
|
|
|
|
|
2014-06-04 23:10:35 +00:00
|
|
|
/*
|
|
|
|
* It's very difficult to mess with pages currently under IO
|
|
|
|
* and in many cases impossible, so we just avoid it here.
|
|
|
|
*/
|
2024-04-12 19:35:04 +00:00
|
|
|
folio_wait_writeback(folio);
|
2009-09-16 09:50:15 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now take care of user space mappings.
|
2022-06-29 00:41:40 +00:00
|
|
|
* Abort on fail: __filemap_remove_folio() assumes unmapped page.
|
2009-09-16 09:50:15 +00:00
|
|
|
*/
|
2024-04-12 19:35:05 +00:00
|
|
|
if (!hwpoison_user_mappings(folio, p, pfn, flags)) {
|
2024-05-24 21:53:04 +00:00
|
|
|
res = action_result(pfn, MF_MSG_UNMAP_FAILED, MF_FAILED);
|
2021-06-25 01:39:55 +00:00
|
|
|
goto unlock_page;
|
2009-12-16 11:19:58 +00:00
|
|
|
}
|
2009-09-16 09:50:15 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Torn down by someone else?
|
|
|
|
*/
|
2024-04-12 19:35:04 +00:00
|
|
|
if (folio_test_lru(folio) && !folio_test_swapcache(folio) &&
|
|
|
|
folio->mapping == NULL) {
|
2022-10-21 08:46:11 +00:00
|
|
|
res = action_result(pfn, MF_MSG_TRUNCATED_LRU, MF_IGNORED);
|
2021-06-25 01:39:55 +00:00
|
|
|
goto unlock_page;
|
2009-09-16 09:50:15 +00:00
|
|
|
}
|
|
|
|
|
hwpoison: fix the handling path of the victimized page frame that belong to non-LRU
Until now, the kernel has the same policy to handle victimized page
frames that belong to kernel-space(reserved/slab-subsystem) or
non-LRU(unknown page state). In other word, the result of handling
either of these victimized page frames is (IGNORED | FAILED), and the
return value of memory_failure() is -EBUSY.
This patch is to avoid that memory_failure() returns very soon due to
the "true" value of (!PageLRU(p)), and it also ensures that
action_result() can report more precise information("reserved kernel",
"kernel slab", and "unknown page state") instead of "non LRU",
especially for memory errors which are detected by memory-scrubbing.
Andi said:
: While running the mcelog test suite on 3.14 I hit the following VM_BUG_ON:
:
: soft_offline: 0x56d4: unknown non LRU page type 3ffff800008000
: page:ffffea000015b400 count:3 mapcount:2097169 mapping: (null) index:0xffff8800056d7000
: page flags: 0x3ffff800004081(locked|slab|head)
: ------------[ cut here ]------------
: kernel BUG at mm/rmap.c:1495!
:
: I think what happened is that a LRU page turned into a slab page in
: parallel with offlining. memory_failure initially tests for this case,
: but doesn't retest later after the page has been locked.
:
: ...
:
: I ran this patch in a loop over night with some stress plus
: the mcelog test suite running in a loop. I cannot guarantee it hit it,
: but it should have given it a good beating.
:
: The kernel survived with no messages, although the mcelog test suite
: got killed at some point because it couldn't fork anymore. Probably
: some unrelated problem.
:
: So the patch is ok for me for .16.
Signed-off-by: Chen Yucong <slaoub@gmail.com>
Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reported-by: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-07-02 22:22:37 +00:00
|
|
|
identify_page_state:
|
2017-07-10 22:47:56 +00:00
|
|
|
res = identify_page_state(pfn, p, page_flags);
|
2021-06-25 01:40:01 +00:00
|
|
|
mutex_unlock(&mf_mutex);
|
|
|
|
return res;
|
2021-06-25 01:39:55 +00:00
|
|
|
unlock_page:
|
2024-04-12 19:35:04 +00:00
|
|
|
folio_unlock(folio);
|
2021-06-25 01:39:55 +00:00
|
|
|
unlock_mutex:
|
|
|
|
mutex_unlock(&mf_mutex);
|
2009-09-16 09:50:15 +00:00
|
|
|
return res;
|
|
|
|
}
|
2011-12-15 18:48:12 +00:00
|
|
|
EXPORT_SYMBOL_GPL(memory_failure);
|
2009-12-16 11:19:58 +00:00
|
|
|
|
2011-07-13 05:14:27 +00:00
|
|
|
#define MEMORY_FAILURE_FIFO_ORDER 4
|
|
|
|
#define MEMORY_FAILURE_FIFO_SIZE (1 << MEMORY_FAILURE_FIFO_ORDER)
|
|
|
|
|
|
|
|
struct memory_failure_entry {
|
|
|
|
unsigned long pfn;
|
|
|
|
int flags;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct memory_failure_cpu {
|
|
|
|
DECLARE_KFIFO(fifo, struct memory_failure_entry,
|
|
|
|
MEMORY_FAILURE_FIFO_SIZE);
|
|
|
|
spinlock_t lock;
|
|
|
|
struct work_struct work;
|
|
|
|
};
|
|
|
|
|
|
|
|
static DEFINE_PER_CPU(struct memory_failure_cpu, memory_failure_cpu);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* memory_failure_queue - Schedule handling memory failure of a page.
|
|
|
|
* @pfn: Page Number of the corrupted page
|
|
|
|
* @flags: Flags for memory failure handling
|
|
|
|
*
|
|
|
|
* This function is called by the low level hardware error handler
|
|
|
|
* when it detects hardware memory corruption of a page. It schedules
|
|
|
|
* the recovering of error page, including dropping pages, killing
|
|
|
|
* processes etc.
|
|
|
|
*
|
|
|
|
* The function is primarily of use for corruptions that
|
|
|
|
* happen outside the current execution context (e.g. when
|
|
|
|
* detected by a background scrubber)
|
|
|
|
*
|
|
|
|
* Can run in IRQ context.
|
|
|
|
*/
|
2017-07-09 23:14:01 +00:00
|
|
|
void memory_failure_queue(unsigned long pfn, int flags)
|
2011-07-13 05:14:27 +00:00
|
|
|
{
|
|
|
|
struct memory_failure_cpu *mf_cpu;
|
|
|
|
unsigned long proc_flags;
|
|
|
|
struct memory_failure_entry entry = {
|
|
|
|
.pfn = pfn,
|
|
|
|
.flags = flags,
|
|
|
|
};
|
|
|
|
|
|
|
|
mf_cpu = &get_cpu_var(memory_failure_cpu);
|
|
|
|
spin_lock_irqsave(&mf_cpu->lock, proc_flags);
|
2013-11-14 22:32:17 +00:00
|
|
|
if (kfifo_put(&mf_cpu->fifo, entry))
|
2011-07-13 05:14:27 +00:00
|
|
|
schedule_work_on(smp_processor_id(), &mf_cpu->work);
|
|
|
|
else
|
2022-07-26 08:10:46 +00:00
|
|
|
pr_err("buffer overflow when queuing memory failure at %#lx\n",
|
2011-07-13 05:14:27 +00:00
|
|
|
pfn);
|
|
|
|
spin_unlock_irqrestore(&mf_cpu->lock, proc_flags);
|
|
|
|
put_cpu_var(memory_failure_cpu);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(memory_failure_queue);
|
|
|
|
|
|
|
|
static void memory_failure_work_func(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct memory_failure_cpu *mf_cpu;
|
|
|
|
struct memory_failure_entry entry = { 0, };
|
|
|
|
unsigned long proc_flags;
|
|
|
|
int gotten;
|
|
|
|
|
2020-05-01 16:45:41 +00:00
|
|
|
mf_cpu = container_of(work, struct memory_failure_cpu, work);
|
2011-07-13 05:14:27 +00:00
|
|
|
for (;;) {
|
|
|
|
spin_lock_irqsave(&mf_cpu->lock, proc_flags);
|
|
|
|
gotten = kfifo_get(&mf_cpu->fifo, &entry);
|
|
|
|
spin_unlock_irqrestore(&mf_cpu->lock, proc_flags);
|
|
|
|
if (!gotten)
|
|
|
|
break;
|
2013-07-10 09:27:01 +00:00
|
|
|
if (entry.flags & MF_SOFT_OFFLINE)
|
2019-12-01 01:53:38 +00:00
|
|
|
soft_offline_page(entry.pfn, entry.flags);
|
2013-07-10 09:27:01 +00:00
|
|
|
else
|
2017-07-09 23:14:01 +00:00
|
|
|
memory_failure(entry.pfn, entry.flags);
|
2011-07-13 05:14:27 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-01 16:45:41 +00:00
|
|
|
/*
|
|
|
|
* Process memory_failure work queued on the specified CPU.
|
|
|
|
* Used to avoid return-to-userspace racing with the memory_failure workqueue.
|
|
|
|
*/
|
|
|
|
void memory_failure_queue_kick(int cpu)
|
|
|
|
{
|
|
|
|
struct memory_failure_cpu *mf_cpu;
|
|
|
|
|
|
|
|
mf_cpu = &per_cpu(memory_failure_cpu, cpu);
|
|
|
|
cancel_work_sync(&mf_cpu->work);
|
|
|
|
memory_failure_work_func(&mf_cpu->work);
|
|
|
|
}
|
|
|
|
|
2011-07-13 05:14:27 +00:00
|
|
|
static int __init memory_failure_init(void)
|
|
|
|
{
|
|
|
|
struct memory_failure_cpu *mf_cpu;
|
|
|
|
int cpu;
|
|
|
|
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
mf_cpu = &per_cpu(memory_failure_cpu, cpu);
|
|
|
|
spin_lock_init(&mf_cpu->lock);
|
|
|
|
INIT_KFIFO(mf_cpu->fifo);
|
|
|
|
INIT_WORK(&mf_cpu->work, memory_failure_work_func);
|
|
|
|
}
|
|
|
|
|
2023-05-08 11:41:28 +00:00
|
|
|
register_sysctl_init("vm", memory_failure_table);
|
|
|
|
|
2011-07-13 05:14:27 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
core_initcall(memory_failure_init);
|
|
|
|
|
2022-07-26 08:10:46 +00:00
|
|
|
#undef pr_fmt
|
2024-06-19 06:33:55 +00:00
|
|
|
#define pr_fmt(fmt) "Unpoison: " fmt
|
2015-11-06 02:47:26 +00:00
|
|
|
#define unpoison_pr_info(fmt, pfn, rs) \
|
|
|
|
({ \
|
|
|
|
if (__ratelimit(rs)) \
|
|
|
|
pr_info(fmt, pfn); \
|
|
|
|
})
|
|
|
|
|
2009-12-16 11:19:58 +00:00
|
|
|
/**
|
|
|
|
* unpoison_memory - Unpoison a previously poisoned page
|
|
|
|
* @pfn: Page number of the to be unpoisoned page
|
|
|
|
*
|
|
|
|
* Software-unpoison a page that has been poisoned by
|
|
|
|
* memory_failure() earlier.
|
|
|
|
*
|
|
|
|
* This is only done on the software-level, so it only works
|
|
|
|
* for linux injected failures, not real hardware failures
|
|
|
|
*
|
|
|
|
* Returns 0 for success, otherwise -errno.
|
|
|
|
*/
|
|
|
|
int unpoison_memory(unsigned long pfn)
|
|
|
|
{
|
2023-01-12 20:46:04 +00:00
|
|
|
struct folio *folio;
|
2009-12-16 11:19:58 +00:00
|
|
|
struct page *p;
|
2023-07-27 11:56:41 +00:00
|
|
|
int ret = -EBUSY, ghp;
|
2024-06-12 07:18:28 +00:00
|
|
|
unsigned long count;
|
2022-10-24 06:20:12 +00:00
|
|
|
bool huge = false;
|
2015-11-06 02:47:26 +00:00
|
|
|
static DEFINE_RATELIMIT_STATE(unpoison_rs, DEFAULT_RATELIMIT_INTERVAL,
|
|
|
|
DEFAULT_RATELIMIT_BURST);
|
2009-12-16 11:19:58 +00:00
|
|
|
|
|
|
|
if (!pfn_valid(pfn))
|
|
|
|
return -ENXIO;
|
|
|
|
|
|
|
|
p = pfn_to_page(pfn);
|
2023-01-12 20:46:04 +00:00
|
|
|
folio = page_folio(p);
|
2009-12-16 11:19:58 +00:00
|
|
|
|
2022-01-14 22:09:02 +00:00
|
|
|
mutex_lock(&mf_mutex);
|
|
|
|
|
2022-06-15 09:32:09 +00:00
|
|
|
if (hw_memory_failure) {
|
2024-06-19 06:33:55 +00:00
|
|
|
unpoison_pr_info("%#lx: disabled after HW memory failure\n",
|
2022-06-15 09:32:09 +00:00
|
|
|
pfn, &unpoison_rs);
|
|
|
|
ret = -EOPNOTSUPP;
|
|
|
|
goto unlock_mutex;
|
|
|
|
}
|
|
|
|
|
2024-05-16 12:26:08 +00:00
|
|
|
if (is_huge_zero_folio(folio)) {
|
2024-06-19 06:33:55 +00:00
|
|
|
unpoison_pr_info("%#lx: huge zero page is not supported\n",
|
2024-05-16 12:26:08 +00:00
|
|
|
pfn, &unpoison_rs);
|
|
|
|
ret = -EOPNOTSUPP;
|
|
|
|
goto unlock_mutex;
|
|
|
|
}
|
|
|
|
|
2023-07-17 18:18:12 +00:00
|
|
|
if (!PageHWPoison(p)) {
|
2024-06-19 06:33:55 +00:00
|
|
|
unpoison_pr_info("%#lx: page was already unpoisoned\n",
|
2015-11-06 02:47:26 +00:00
|
|
|
pfn, &unpoison_rs);
|
2022-01-14 22:09:02 +00:00
|
|
|
goto unlock_mutex;
|
2009-12-16 11:19:58 +00:00
|
|
|
}
|
|
|
|
|
2023-01-12 20:46:08 +00:00
|
|
|
if (folio_ref_count(folio) > 1) {
|
2024-06-19 06:33:55 +00:00
|
|
|
unpoison_pr_info("%#lx: someone grabs the hwpoison page\n",
|
2015-11-06 02:47:26 +00:00
|
|
|
pfn, &unpoison_rs);
|
2022-01-14 22:09:02 +00:00
|
|
|
goto unlock_mutex;
|
2015-09-08 22:03:29 +00:00
|
|
|
}
|
|
|
|
|
2024-04-12 19:35:06 +00:00
|
|
|
if (folio_test_slab(folio) || folio_test_pgtable(folio) ||
|
|
|
|
folio_test_reserved(folio) || folio_test_offline(folio))
|
2023-07-27 11:56:42 +00:00
|
|
|
goto unlock_mutex;
|
|
|
|
|
2023-01-12 20:46:08 +00:00
|
|
|
if (folio_mapped(folio)) {
|
2024-06-19 06:33:55 +00:00
|
|
|
unpoison_pr_info("%#lx: someone maps the hwpoison page\n",
|
2015-11-06 02:47:26 +00:00
|
|
|
pfn, &unpoison_rs);
|
2022-01-14 22:09:02 +00:00
|
|
|
goto unlock_mutex;
|
2015-09-08 22:03:29 +00:00
|
|
|
}
|
|
|
|
|
2023-01-12 20:46:08 +00:00
|
|
|
if (folio_mapping(folio)) {
|
2024-06-19 06:33:55 +00:00
|
|
|
unpoison_pr_info("%#lx: the hwpoison page has non-NULL mapping\n",
|
2015-11-06 02:47:26 +00:00
|
|
|
pfn, &unpoison_rs);
|
2022-01-14 22:09:02 +00:00
|
|
|
goto unlock_mutex;
|
2013-09-11 21:22:53 +00:00
|
|
|
}
|
|
|
|
|
2023-07-27 11:56:41 +00:00
|
|
|
ghp = get_hwpoison_page(p, MF_UNPOISON);
|
|
|
|
if (!ghp) {
|
2024-04-12 19:35:06 +00:00
|
|
|
if (folio_test_hugetlb(folio)) {
|
2022-10-24 06:20:12 +00:00
|
|
|
huge = true;
|
2023-01-12 20:46:04 +00:00
|
|
|
count = folio_free_raw_hwp(folio, false);
|
2023-07-27 11:56:41 +00:00
|
|
|
if (count == 0)
|
2022-07-14 04:24:16 +00:00
|
|
|
goto unlock_mutex;
|
|
|
|
}
|
2023-01-12 20:46:08 +00:00
|
|
|
ret = folio_test_clear_hwpoison(folio) ? 0 : -EBUSY;
|
2023-07-27 11:56:41 +00:00
|
|
|
} else if (ghp < 0) {
|
|
|
|
if (ghp == -EHWPOISON) {
|
2022-05-13 03:23:09 +00:00
|
|
|
ret = put_page_back_buddy(p) ? 0 : -EBUSY;
|
2023-07-27 11:56:41 +00:00
|
|
|
} else {
|
|
|
|
ret = ghp;
|
2024-06-19 06:33:55 +00:00
|
|
|
unpoison_pr_info("%#lx: failed to grab page\n",
|
mm/hwpoison: fix unpoison_memory()
After recent soft-offline rework, error pages can be taken off from
buddy allocator, but the existing unpoison_memory() does not properly
undo the operation. Moreover, due to the recent change on
__get_hwpoison_page(), get_page_unless_zero() is hardly called for
hwpoisoned pages. So __get_hwpoison_page() highly likely returns -EBUSY
(meaning to fail to grab page refcount) and unpoison just clears
PG_hwpoison without releasing a refcount. That does not lead to a
critical issue like kernel panic, but unpoisoned pages never get back to
buddy (leaked permanently), which is not good.
To (partially) fix this, we need to identify "taken off" pages from
other types of hwpoisoned pages. We can't use refcount or page flags
for this purpose, so a pseudo flag is defined by hacking ->private
field. Someone might think that put_page() is enough to cancel
taken-off pages, but the normal free path contains some operations not
suitable for the current purpose, and can fire VM_BUG_ON().
Note that unpoison_memory() is now supposed to be cancel hwpoison events
injected only by madvise() or
/sys/devices/system/memory/{hard,soft}_offline_page, not by MCE
injection, so please don't try to use unpoison when testing with MCE
injection.
[lkp@intel.com: report build failure for ARCH=i386]
Link: https://lkml.kernel.org/r/20211115084006.3728254-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Ding Hui <dinghui@sangfor.com.cn>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-14 22:09:09 +00:00
|
|
|
pfn, &unpoison_rs);
|
2023-07-27 11:56:41 +00:00
|
|
|
}
|
mm/hwpoison: fix unpoison_memory()
After recent soft-offline rework, error pages can be taken off from
buddy allocator, but the existing unpoison_memory() does not properly
undo the operation. Moreover, due to the recent change on
__get_hwpoison_page(), get_page_unless_zero() is hardly called for
hwpoisoned pages. So __get_hwpoison_page() highly likely returns -EBUSY
(meaning to fail to grab page refcount) and unpoison just clears
PG_hwpoison without releasing a refcount. That does not lead to a
critical issue like kernel panic, but unpoisoned pages never get back to
buddy (leaked permanently), which is not good.
To (partially) fix this, we need to identify "taken off" pages from
other types of hwpoisoned pages. We can't use refcount or page flags
for this purpose, so a pseudo flag is defined by hacking ->private
field. Someone might think that put_page() is enough to cancel
taken-off pages, but the normal free path contains some operations not
suitable for the current purpose, and can fire VM_BUG_ON().
Note that unpoison_memory() is now supposed to be cancel hwpoison events
injected only by madvise() or
/sys/devices/system/memory/{hard,soft}_offline_page, not by MCE
injection, so please don't try to use unpoison when testing with MCE
injection.
[lkp@intel.com: report build failure for ARCH=i386]
Link: https://lkml.kernel.org/r/20211115084006.3728254-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Ding Hui <dinghui@sangfor.com.cn>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-14 22:09:09 +00:00
|
|
|
} else {
|
2024-04-12 19:35:06 +00:00
|
|
|
if (folio_test_hugetlb(folio)) {
|
2022-10-24 06:20:12 +00:00
|
|
|
huge = true;
|
2023-01-12 20:46:04 +00:00
|
|
|
count = folio_free_raw_hwp(folio, false);
|
2022-07-14 04:24:16 +00:00
|
|
|
if (count == 0) {
|
2023-01-12 20:46:08 +00:00
|
|
|
folio_put(folio);
|
2022-07-14 04:24:16 +00:00
|
|
|
goto unlock_mutex;
|
|
|
|
}
|
|
|
|
}
|
2009-12-16 11:19:58 +00:00
|
|
|
|
2023-01-12 20:46:08 +00:00
|
|
|
folio_put(folio);
|
2022-11-25 06:54:44 +00:00
|
|
|
if (TestClearPageHWPoison(p)) {
|
2023-01-12 20:46:08 +00:00
|
|
|
folio_put(folio);
|
mm/hwpoison: fix unpoison_memory()
After recent soft-offline rework, error pages can be taken off from
buddy allocator, but the existing unpoison_memory() does not properly
undo the operation. Moreover, due to the recent change on
__get_hwpoison_page(), get_page_unless_zero() is hardly called for
hwpoisoned pages. So __get_hwpoison_page() highly likely returns -EBUSY
(meaning to fail to grab page refcount) and unpoison just clears
PG_hwpoison without releasing a refcount. That does not lead to a
critical issue like kernel panic, but unpoisoned pages never get back to
buddy (leaked permanently), which is not good.
To (partially) fix this, we need to identify "taken off" pages from
other types of hwpoisoned pages. We can't use refcount or page flags
for this purpose, so a pseudo flag is defined by hacking ->private
field. Someone might think that put_page() is enough to cancel
taken-off pages, but the normal free path contains some operations not
suitable for the current purpose, and can fire VM_BUG_ON().
Note that unpoison_memory() is now supposed to be cancel hwpoison events
injected only by madvise() or
/sys/devices/system/memory/{hard,soft}_offline_page, not by MCE
injection, so please don't try to use unpoison when testing with MCE
injection.
[lkp@intel.com: report build failure for ARCH=i386]
Link: https://lkml.kernel.org/r/20211115084006.3728254-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Ding Hui <dinghui@sangfor.com.cn>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-14 22:09:09 +00:00
|
|
|
ret = 0;
|
|
|
|
}
|
|
|
|
}
|
2009-12-16 11:19:58 +00:00
|
|
|
|
2022-01-14 22:09:02 +00:00
|
|
|
unlock_mutex:
|
|
|
|
mutex_unlock(&mf_mutex);
|
2022-11-25 06:54:44 +00:00
|
|
|
if (!ret) {
|
2022-10-24 06:20:12 +00:00
|
|
|
if (!huge)
|
|
|
|
num_poisoned_pages_sub(pfn, 1);
|
2024-06-19 06:33:55 +00:00
|
|
|
unpoison_pr_info("%#lx: software-unpoisoned page\n",
|
2022-05-13 03:23:09 +00:00
|
|
|
page_to_pfn(p), &unpoison_rs);
|
|
|
|
}
|
2022-01-14 22:09:02 +00:00
|
|
|
return ret;
|
2009-12-16 11:19:58 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(unpoison_memory);
|
2009-12-16 11:20:00 +00:00
|
|
|
|
mm/memory-failure: refactor log format in soft offline code
Patch series "Userspace controls soft-offline pages", v6.
Correctable memory errors are very common on servers with large amount of
memory, and are corrected by ECC, but with two pain points to users:
1. Correction usually happens on the fly and adds latency overhead
2. Not-fully-proved theory states excessive correctable memory
errors can develop into uncorrectable memory error.
Soft offline is kernel's additional solution for memory pages having
(excessive) corrected memory errors. Impacted page is migrated to healthy
page if it is in use, then the original page is discarded for any future
use.
The actual policy on whether (and when) to soft offline should be
maintained by userspace, especially in case of an 1G HugeTLB page.
Soft-offline dissolves the HugeTLB page, either in-use or free, into
chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If
userspace has not acknowledged such behavior, it may be surprised when
later mmap hugepages MAP_FAILED due to lack of hugepages. In case of a
transparent hugepage, it will be split into 4K pages as well; userspace
will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of
corrected memory errors sounds very costly and kernel better not doing
under the hood. But today there are at least 2 such cases:
1. GHES driver sees both GHES_SEV_CORRECTED and
CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
2. RAS Correctable Errors Collector counts correctable errors per
PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed by
kernel's memory failure recovery.
This patch series give userspace the control of softofflining any page:
kernel only soft offlines raw page / transparent hugepage / HugeTLB
hugepage if userspace has agreed to. The interface to userspace is a new
sysctl called enable_soft_offline under /proc/sys/vm. By default
enable_soft_line is 1 to preserve existing behavior in kernel.
This patch (of 4):
Logs from soft_offline_page and soft_offline_in_use_page have different
formats than majority of the memory failure code:
"Memory failure: 0x${pfn}: ${lower_case_message}"
Convert them to the following format:
"Soft offline: 0x${pfn}: ${lower_case_message}"
No functional change in this commit.
Link: https://lkml.kernel.org/r/20240626050818.2277273-1-jiaqiyan@google.com
Link: https://lkml.kernel.org/r/20240626050818.2277273-2-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Lance Yang <ioworker0@gmail.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-26 05:08:15 +00:00
|
|
|
#undef pr_fmt
|
|
|
|
#define pr_fmt(fmt) "Soft offline: " fmt
|
|
|
|
|
2023-11-08 18:28:08 +00:00
|
|
|
static bool mf_isolate_folio(struct folio *folio, struct list_head *pagelist)
|
2010-09-08 01:19:39 +00:00
|
|
|
{
|
2020-10-16 03:07:13 +00:00
|
|
|
bool isolated = false;
|
2010-09-08 01:19:39 +00:00
|
|
|
|
2023-11-08 18:28:08 +00:00
|
|
|
if (folio_test_hugetlb(folio)) {
|
|
|
|
isolated = isolate_hugetlb(folio, pagelist);
|
2020-10-16 03:07:13 +00:00
|
|
|
} else {
|
2023-11-08 18:28:08 +00:00
|
|
|
bool lru = !__folio_test_movable(folio);
|
2022-08-30 12:36:00 +00:00
|
|
|
|
2020-10-16 03:07:13 +00:00
|
|
|
if (lru)
|
2023-11-08 18:28:08 +00:00
|
|
|
isolated = folio_isolate_lru(folio);
|
2020-10-16 03:07:13 +00:00
|
|
|
else
|
2023-11-08 18:28:08 +00:00
|
|
|
isolated = isolate_movable_page(&folio->page,
|
2023-02-15 10:39:37 +00:00
|
|
|
ISOLATE_UNEVICTABLE);
|
2020-10-16 03:07:13 +00:00
|
|
|
|
2022-08-30 12:36:00 +00:00
|
|
|
if (isolated) {
|
2023-11-08 18:28:08 +00:00
|
|
|
list_add(&folio->lru, pagelist);
|
2022-08-30 12:36:00 +00:00
|
|
|
if (lru)
|
2023-11-08 18:28:08 +00:00
|
|
|
node_stat_add_folio(folio, NR_ISOLATED_ANON +
|
|
|
|
folio_is_file_lru(folio));
|
2022-08-30 12:36:00 +00:00
|
|
|
}
|
2013-02-23 00:33:59 +00:00
|
|
|
}
|
2010-09-08 01:19:39 +00:00
|
|
|
|
2015-08-14 22:34:59 +00:00
|
|
|
/*
|
2023-11-08 18:28:08 +00:00
|
|
|
* If we succeed to isolate the folio, we grabbed another refcount on
|
|
|
|
* the folio, so we can safely drop the one we got from get_any_page().
|
|
|
|
* If we failed to isolate the folio, it means that we cannot go further
|
2020-10-16 03:07:13 +00:00
|
|
|
* and we will return an error, so drop the reference we got from
|
2023-07-11 05:50:14 +00:00
|
|
|
* get_any_page() as well.
|
2015-08-14 22:34:59 +00:00
|
|
|
*/
|
2023-11-08 18:28:08 +00:00
|
|
|
folio_put(folio);
|
2020-10-16 03:07:13 +00:00
|
|
|
return isolated;
|
2010-09-08 01:19:39 +00:00
|
|
|
}
|
|
|
|
|
2020-10-16 03:07:13 +00:00
|
|
|
/*
|
2022-08-19 03:34:02 +00:00
|
|
|
* soft_offline_in_use_page handles hugetlb-pages and non-hugetlb pages.
|
2020-10-16 03:07:13 +00:00
|
|
|
* If the page is a non-dirty unmapped page-cache page, it simply invalidates.
|
|
|
|
* If the page is mapped, it migrates the contents over.
|
|
|
|
*/
|
2022-08-19 03:34:02 +00:00
|
|
|
static int soft_offline_in_use_page(struct page *page)
|
2013-02-23 00:34:03 +00:00
|
|
|
{
|
2022-02-13 20:22:28 +00:00
|
|
|
long ret = 0;
|
2013-02-23 00:34:03 +00:00
|
|
|
unsigned long pfn = page_to_pfn(page);
|
2023-11-08 18:28:07 +00:00
|
|
|
struct folio *folio = page_folio(page);
|
2020-10-16 03:07:13 +00:00
|
|
|
char const *msg_page[] = {"page", "hugepage"};
|
2023-11-08 18:28:07 +00:00
|
|
|
bool huge = folio_test_hugetlb(folio);
|
2020-10-16 03:07:13 +00:00
|
|
|
LIST_HEAD(pagelist);
|
2020-10-17 23:13:57 +00:00
|
|
|
struct migration_target_control mtc = {
|
|
|
|
.nid = NUMA_NO_NODE,
|
|
|
|
.gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL,
|
2024-03-06 10:13:26 +00:00
|
|
|
.reason = MR_MEMORY_FAILURE,
|
2020-10-17 23:13:57 +00:00
|
|
|
};
|
2009-12-16 11:20:00 +00:00
|
|
|
|
2023-11-08 18:28:07 +00:00
|
|
|
if (!huge && folio_test_large(folio)) {
|
2024-05-24 21:53:06 +00:00
|
|
|
if (try_to_split_thp_page(page, true)) {
|
mm/memory-failure: refactor log format in soft offline code
Patch series "Userspace controls soft-offline pages", v6.
Correctable memory errors are very common on servers with large amount of
memory, and are corrected by ECC, but with two pain points to users:
1. Correction usually happens on the fly and adds latency overhead
2. Not-fully-proved theory states excessive correctable memory
errors can develop into uncorrectable memory error.
Soft offline is kernel's additional solution for memory pages having
(excessive) corrected memory errors. Impacted page is migrated to healthy
page if it is in use, then the original page is discarded for any future
use.
The actual policy on whether (and when) to soft offline should be
maintained by userspace, especially in case of an 1G HugeTLB page.
Soft-offline dissolves the HugeTLB page, either in-use or free, into
chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If
userspace has not acknowledged such behavior, it may be surprised when
later mmap hugepages MAP_FAILED due to lack of hugepages. In case of a
transparent hugepage, it will be split into 4K pages as well; userspace
will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of
corrected memory errors sounds very costly and kernel better not doing
under the hood. But today there are at least 2 such cases:
1. GHES driver sees both GHES_SEV_CORRECTED and
CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
2. RAS Correctable Errors Collector counts correctable errors per
PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed by
kernel's memory failure recovery.
This patch series give userspace the control of softofflining any page:
kernel only soft offlines raw page / transparent hugepage / HugeTLB
hugepage if userspace has agreed to. The interface to userspace is a new
sysctl called enable_soft_offline under /proc/sys/vm. By default
enable_soft_line is 1 to preserve existing behavior in kernel.
This patch (of 4):
Logs from soft_offline_page and soft_offline_in_use_page have different
formats than majority of the memory failure code:
"Memory failure: 0x${pfn}: ${lower_case_message}"
Convert them to the following format:
"Soft offline: 0x${pfn}: ${lower_case_message}"
No functional change in this commit.
Link: https://lkml.kernel.org/r/20240626050818.2277273-1-jiaqiyan@google.com
Link: https://lkml.kernel.org/r/20240626050818.2277273-2-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Lance Yang <ioworker0@gmail.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-26 05:08:15 +00:00
|
|
|
pr_info("%#lx: thp split failed\n", pfn);
|
2022-08-19 03:34:02 +00:00
|
|
|
return -EBUSY;
|
|
|
|
}
|
2023-11-08 18:28:07 +00:00
|
|
|
folio = page_folio(page);
|
2022-08-19 03:34:02 +00:00
|
|
|
}
|
|
|
|
|
2023-11-08 18:28:07 +00:00
|
|
|
folio_lock(folio);
|
2023-07-11 05:50:12 +00:00
|
|
|
if (!huge)
|
2023-11-08 18:28:07 +00:00
|
|
|
folio_wait_writeback(folio);
|
2013-02-23 00:34:03 +00:00
|
|
|
if (PageHWPoison(page)) {
|
2023-11-08 18:28:07 +00:00
|
|
|
folio_unlock(folio);
|
|
|
|
folio_put(folio);
|
mm/memory-failure: refactor log format in soft offline code
Patch series "Userspace controls soft-offline pages", v6.
Correctable memory errors are very common on servers with large amount of
memory, and are corrected by ECC, but with two pain points to users:
1. Correction usually happens on the fly and adds latency overhead
2. Not-fully-proved theory states excessive correctable memory
errors can develop into uncorrectable memory error.
Soft offline is kernel's additional solution for memory pages having
(excessive) corrected memory errors. Impacted page is migrated to healthy
page if it is in use, then the original page is discarded for any future
use.
The actual policy on whether (and when) to soft offline should be
maintained by userspace, especially in case of an 1G HugeTLB page.
Soft-offline dissolves the HugeTLB page, either in-use or free, into
chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If
userspace has not acknowledged such behavior, it may be surprised when
later mmap hugepages MAP_FAILED due to lack of hugepages. In case of a
transparent hugepage, it will be split into 4K pages as well; userspace
will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of
corrected memory errors sounds very costly and kernel better not doing
under the hood. But today there are at least 2 such cases:
1. GHES driver sees both GHES_SEV_CORRECTED and
CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
2. RAS Correctable Errors Collector counts correctable errors per
PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed by
kernel's memory failure recovery.
This patch series give userspace the control of softofflining any page:
kernel only soft offlines raw page / transparent hugepage / HugeTLB
hugepage if userspace has agreed to. The interface to userspace is a new
sysctl called enable_soft_offline under /proc/sys/vm. By default
enable_soft_line is 1 to preserve existing behavior in kernel.
This patch (of 4):
Logs from soft_offline_page and soft_offline_in_use_page have different
formats than majority of the memory failure code:
"Memory failure: 0x${pfn}: ${lower_case_message}"
Convert them to the following format:
"Soft offline: 0x${pfn}: ${lower_case_message}"
No functional change in this commit.
Link: https://lkml.kernel.org/r/20240626050818.2277273-1-jiaqiyan@google.com
Link: https://lkml.kernel.org/r/20240626050818.2277273-2-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Lance Yang <ioworker0@gmail.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-26 05:08:15 +00:00
|
|
|
pr_info("%#lx: page already poisoned\n", pfn);
|
2020-10-16 03:07:17 +00:00
|
|
|
return 0;
|
2013-02-23 00:34:03 +00:00
|
|
|
}
|
2020-10-16 03:07:13 +00:00
|
|
|
|
2023-11-08 18:28:07 +00:00
|
|
|
if (!huge && folio_test_lru(folio) && !folio_test_swapcache(folio))
|
2020-10-16 03:07:13 +00:00
|
|
|
/*
|
|
|
|
* Try to invalidate first. This should work for
|
|
|
|
* non dirty unmapped page cache pages.
|
|
|
|
*/
|
2023-11-08 18:28:07 +00:00
|
|
|
ret = mapping_evict_folio(folio_mapping(folio), folio);
|
|
|
|
folio_unlock(folio);
|
2020-10-16 03:07:13 +00:00
|
|
|
|
|
|
|
if (ret) {
|
mm/memory-failure: refactor log format in soft offline code
Patch series "Userspace controls soft-offline pages", v6.
Correctable memory errors are very common on servers with large amount of
memory, and are corrected by ECC, but with two pain points to users:
1. Correction usually happens on the fly and adds latency overhead
2. Not-fully-proved theory states excessive correctable memory
errors can develop into uncorrectable memory error.
Soft offline is kernel's additional solution for memory pages having
(excessive) corrected memory errors. Impacted page is migrated to healthy
page if it is in use, then the original page is discarded for any future
use.
The actual policy on whether (and when) to soft offline should be
maintained by userspace, especially in case of an 1G HugeTLB page.
Soft-offline dissolves the HugeTLB page, either in-use or free, into
chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If
userspace has not acknowledged such behavior, it may be surprised when
later mmap hugepages MAP_FAILED due to lack of hugepages. In case of a
transparent hugepage, it will be split into 4K pages as well; userspace
will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of
corrected memory errors sounds very costly and kernel better not doing
under the hood. But today there are at least 2 such cases:
1. GHES driver sees both GHES_SEV_CORRECTED and
CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
2. RAS Correctable Errors Collector counts correctable errors per
PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed by
kernel's memory failure recovery.
This patch series give userspace the control of softofflining any page:
kernel only soft offlines raw page / transparent hugepage / HugeTLB
hugepage if userspace has agreed to. The interface to userspace is a new
sysctl called enable_soft_offline under /proc/sys/vm. By default
enable_soft_line is 1 to preserve existing behavior in kernel.
This patch (of 4):
Logs from soft_offline_page and soft_offline_in_use_page have different
formats than majority of the memory failure code:
"Memory failure: 0x${pfn}: ${lower_case_message}"
Convert them to the following format:
"Soft offline: 0x${pfn}: ${lower_case_message}"
No functional change in this commit.
Link: https://lkml.kernel.org/r/20240626050818.2277273-1-jiaqiyan@google.com
Link: https://lkml.kernel.org/r/20240626050818.2277273-2-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Lance Yang <ioworker0@gmail.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-26 05:08:15 +00:00
|
|
|
pr_info("%#lx: invalidated\n", pfn);
|
2020-10-16 03:07:13 +00:00
|
|
|
page_handle_poison(page, false, true);
|
2013-02-23 00:34:03 +00:00
|
|
|
return 0;
|
2009-12-16 11:20:00 +00:00
|
|
|
}
|
|
|
|
|
2023-11-08 18:28:08 +00:00
|
|
|
if (mf_isolate_folio(folio, &pagelist)) {
|
2020-10-17 23:13:57 +00:00
|
|
|
ret = migrate_pages(&pagelist, alloc_migration_target, NULL,
|
2021-09-02 21:59:13 +00:00
|
|
|
(unsigned long)&mtc, MIGRATE_SYNC, MR_MEMORY_FAILURE, NULL);
|
mm,hwpoison: rework soft offline for in-use pages
This patch changes the way we set and handle in-use poisoned pages. Until
now, poisoned pages were released to the buddy allocator, trusting that
the checks that take place at allocation time would act as a safe net and
would skip that page.
This has proved to be wrong, as we got some pfn walkers out there, like
compaction, that all they care is the page to be in a buddy freelist.
Although this might not be the only user, having poisoned pages in the
buddy allocator seems a bad idea as we should only have free pages that
are ready and meant to be used as such.
Before explaining the taken approach, let us break down the kind of pages
we can soft offline.
- Anonymous THP (after the split, they end up being 4K pages)
- Hugetlb
- Order-0 pages (that can be either migrated or invalited)
* Normal pages (order-0 and anon-THP)
- If they are clean and unmapped page cache pages, we invalidate
then by means of invalidate_inode_page().
- If they are mapped/dirty, we do the isolate-and-migrate dance.
Either way, do not call put_page directly from those paths. Instead, we
keep the page and send it to page_handle_poison to perform the right
handling.
page_handle_poison sets the HWPoison flag and does the last put_page.
Down the chain, we placed a check for HWPoison page in
free_pages_prepare, that just skips any poisoned page, so those pages
do not end up in any pcplist/freelist.
After that, we set the refcount on the page to 1 and we increment
the poisoned pages counter.
If we see that the check in free_pages_prepare creates trouble, we can
always do what we do for free pages:
- wait until the page hits buddy's freelists
- take it off, and flag it
The downside of the above approach is that we could race with an
allocation, so by the time we want to take the page off the buddy, the
page has been already allocated so we cannot soft offline it.
But the user could always retry it.
* Hugetlb pages
- We isolate-and-migrate them
After the migration has been successful, we call dissolve_free_huge_page,
and we set HWPoison on the page if we succeed.
Hugetlb has a slightly different handling though.
While for non-hugetlb pages we cared about closing the race with an
allocation, doing so for hugetlb pages requires quite some additional
and intrusive code (we would need to hook in free_huge_page and some other
places).
So I decided to not make the code overly complicated and just fail
normally if the page we allocated in the meantime.
We can always build on top of this.
As a bonus, because of the way we handle now in-use pages, we no longer
need the put-as-isolation-migratetype dance, that was guarding for poisoned
pages to end up in pcplists.
Signed-off-by: Oscar Salvador <osalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Aristeu Rozanski <aris@ruivo.org>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Dmitry Yakunin <zeil@yandex-team.ru>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Oscar Salvador <osalvador@suse.com>
Cc: Qian Cai <cai@lca.pw>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20200922135650.1634-10-osalvador@suse.de
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-16 03:07:09 +00:00
|
|
|
if (!ret) {
|
2020-10-16 03:07:13 +00:00
|
|
|
bool release = !huge;
|
|
|
|
|
|
|
|
if (!page_handle_poison(page, huge, release))
|
|
|
|
ret = -EBUSY;
|
mm,hwpoison: rework soft offline for in-use pages
This patch changes the way we set and handle in-use poisoned pages. Until
now, poisoned pages were released to the buddy allocator, trusting that
the checks that take place at allocation time would act as a safe net and
would skip that page.
This has proved to be wrong, as we got some pfn walkers out there, like
compaction, that all they care is the page to be in a buddy freelist.
Although this might not be the only user, having poisoned pages in the
buddy allocator seems a bad idea as we should only have free pages that
are ready and meant to be used as such.
Before explaining the taken approach, let us break down the kind of pages
we can soft offline.
- Anonymous THP (after the split, they end up being 4K pages)
- Hugetlb
- Order-0 pages (that can be either migrated or invalited)
* Normal pages (order-0 and anon-THP)
- If they are clean and unmapped page cache pages, we invalidate
then by means of invalidate_inode_page().
- If they are mapped/dirty, we do the isolate-and-migrate dance.
Either way, do not call put_page directly from those paths. Instead, we
keep the page and send it to page_handle_poison to perform the right
handling.
page_handle_poison sets the HWPoison flag and does the last put_page.
Down the chain, we placed a check for HWPoison page in
free_pages_prepare, that just skips any poisoned page, so those pages
do not end up in any pcplist/freelist.
After that, we set the refcount on the page to 1 and we increment
the poisoned pages counter.
If we see that the check in free_pages_prepare creates trouble, we can
always do what we do for free pages:
- wait until the page hits buddy's freelists
- take it off, and flag it
The downside of the above approach is that we could race with an
allocation, so by the time we want to take the page off the buddy, the
page has been already allocated so we cannot soft offline it.
But the user could always retry it.
* Hugetlb pages
- We isolate-and-migrate them
After the migration has been successful, we call dissolve_free_huge_page,
and we set HWPoison on the page if we succeed.
Hugetlb has a slightly different handling though.
While for non-hugetlb pages we cared about closing the race with an
allocation, doing so for hugetlb pages requires quite some additional
and intrusive code (we would need to hook in free_huge_page and some other
places).
So I decided to not make the code overly complicated and just fail
normally if the page we allocated in the meantime.
We can always build on top of this.
As a bonus, because of the way we handle now in-use pages, we no longer
need the put-as-isolation-migratetype dance, that was guarding for poisoned
pages to end up in pcplists.
Signed-off-by: Oscar Salvador <osalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Aristeu Rozanski <aris@ruivo.org>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Dmitry Yakunin <zeil@yandex-team.ru>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Oscar Salvador <osalvador@suse.com>
Cc: Qian Cai <cai@lca.pw>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20200922135650.1634-10-osalvador@suse.de
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-16 03:07:09 +00:00
|
|
|
} else {
|
2017-02-24 22:57:35 +00:00
|
|
|
if (!list_empty(&pagelist))
|
|
|
|
putback_movable_pages(&pagelist);
|
2014-01-21 23:51:17 +00:00
|
|
|
|
mm/memory-failure: refactor log format in soft offline code
Patch series "Userspace controls soft-offline pages", v6.
Correctable memory errors are very common on servers with large amount of
memory, and are corrected by ECC, but with two pain points to users:
1. Correction usually happens on the fly and adds latency overhead
2. Not-fully-proved theory states excessive correctable memory
errors can develop into uncorrectable memory error.
Soft offline is kernel's additional solution for memory pages having
(excessive) corrected memory errors. Impacted page is migrated to healthy
page if it is in use, then the original page is discarded for any future
use.
The actual policy on whether (and when) to soft offline should be
maintained by userspace, especially in case of an 1G HugeTLB page.
Soft-offline dissolves the HugeTLB page, either in-use or free, into
chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If
userspace has not acknowledged such behavior, it may be surprised when
later mmap hugepages MAP_FAILED due to lack of hugepages. In case of a
transparent hugepage, it will be split into 4K pages as well; userspace
will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of
corrected memory errors sounds very costly and kernel better not doing
under the hood. But today there are at least 2 such cases:
1. GHES driver sees both GHES_SEV_CORRECTED and
CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
2. RAS Correctable Errors Collector counts correctable errors per
PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed by
kernel's memory failure recovery.
This patch series give userspace the control of softofflining any page:
kernel only soft offlines raw page / transparent hugepage / HugeTLB
hugepage if userspace has agreed to. The interface to userspace is a new
sysctl called enable_soft_offline under /proc/sys/vm. By default
enable_soft_line is 1 to preserve existing behavior in kernel.
This patch (of 4):
Logs from soft_offline_page and soft_offline_in_use_page have different
formats than majority of the memory failure code:
"Memory failure: 0x${pfn}: ${lower_case_message}"
Convert them to the following format:
"Soft offline: 0x${pfn}: ${lower_case_message}"
No functional change in this commit.
Link: https://lkml.kernel.org/r/20240626050818.2277273-1-jiaqiyan@google.com
Link: https://lkml.kernel.org/r/20240626050818.2277273-2-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Lance Yang <ioworker0@gmail.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-26 05:08:15 +00:00
|
|
|
pr_info("%#lx: %s migration failed %ld, type %pGp\n",
|
2021-10-19 14:26:21 +00:00
|
|
|
pfn, msg_page[huge], ret, &page->flags);
|
2009-12-16 11:20:00 +00:00
|
|
|
if (ret > 0)
|
2020-12-15 03:11:51 +00:00
|
|
|
ret = -EBUSY;
|
2009-12-16 11:20:00 +00:00
|
|
|
}
|
|
|
|
} else {
|
mm/memory-failure: refactor log format in soft offline code
Patch series "Userspace controls soft-offline pages", v6.
Correctable memory errors are very common on servers with large amount of
memory, and are corrected by ECC, but with two pain points to users:
1. Correction usually happens on the fly and adds latency overhead
2. Not-fully-proved theory states excessive correctable memory
errors can develop into uncorrectable memory error.
Soft offline is kernel's additional solution for memory pages having
(excessive) corrected memory errors. Impacted page is migrated to healthy
page if it is in use, then the original page is discarded for any future
use.
The actual policy on whether (and when) to soft offline should be
maintained by userspace, especially in case of an 1G HugeTLB page.
Soft-offline dissolves the HugeTLB page, either in-use or free, into
chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If
userspace has not acknowledged such behavior, it may be surprised when
later mmap hugepages MAP_FAILED due to lack of hugepages. In case of a
transparent hugepage, it will be split into 4K pages as well; userspace
will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of
corrected memory errors sounds very costly and kernel better not doing
under the hood. But today there are at least 2 such cases:
1. GHES driver sees both GHES_SEV_CORRECTED and
CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
2. RAS Correctable Errors Collector counts correctable errors per
PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed by
kernel's memory failure recovery.
This patch series give userspace the control of softofflining any page:
kernel only soft offlines raw page / transparent hugepage / HugeTLB
hugepage if userspace has agreed to. The interface to userspace is a new
sysctl called enable_soft_offline under /proc/sys/vm. By default
enable_soft_line is 1 to preserve existing behavior in kernel.
This patch (of 4):
Logs from soft_offline_page and soft_offline_in_use_page have different
formats than majority of the memory failure code:
"Memory failure: 0x${pfn}: ${lower_case_message}"
Convert them to the following format:
"Soft offline: 0x${pfn}: ${lower_case_message}"
No functional change in this commit.
Link: https://lkml.kernel.org/r/20240626050818.2277273-1-jiaqiyan@google.com
Link: https://lkml.kernel.org/r/20240626050818.2277273-2-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Lance Yang <ioworker0@gmail.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-26 05:08:15 +00:00
|
|
|
pr_info("%#lx: %s isolation failed, page count %d, type %pGp\n",
|
2021-10-19 14:26:21 +00:00
|
|
|
pfn, msg_page[huge], page_count(page), &page->flags);
|
2020-10-16 03:07:13 +00:00
|
|
|
ret = -EBUSY;
|
2009-12-16 11:20:00 +00:00
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
2013-09-11 21:22:56 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* soft_offline_page - Soft offline a page.
|
2019-12-01 01:53:38 +00:00
|
|
|
* @pfn: pfn to soft-offline
|
2013-09-11 21:22:56 +00:00
|
|
|
* @flags: flags. Same as memory_failure().
|
|
|
|
*
|
mm/memory-failure: userspace controls soft-offlining pages
Correctable memory errors are very common on servers with large amount of
memory, and are corrected by ECC. Soft offline is kernel's additional
recovery handling for memory pages having (excessive) corrected memory
errors. Impacted page is migrated to a healthy page if inuse; the
original page is discarded for any future use.
The actual policy on whether (and when) to soft offline should be
maintained by userspace, especially in case of an 1G HugeTLB page.
Soft-offline dissolves the HugeTLB page, either in-use or free, into
chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If
userspace has not acknowledged such behavior, it may be surprised when
later failed to mmap hugepages due to lack of hugepages. In case of a
transparent hugepage, it will be split into 4K pages as well; userspace
will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of
corrected memory errors sounds very costly and kernel better not doing
under the hood. But today there are at least 2 such cases doing so:
1. when GHES driver sees both GHES_SEV_CORRECTED and
CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
2. RAS Correctable Errors Collector counts correctable errors per
PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed
by kernel's memory failure recovery.
This commit gives userspace the control of softofflining any page: kernel
only soft offlines raw page / transparent hugepage / HugeTLB hugepage if
userspace has agreed to. The interface to userspace is a new sysctl at
/proc/sys/vm/enable_soft_offline. By default its value is set to 1 to
preserve existing behavior in kernel. When set to 0, soft-offline (e.g.
MADV_SOFT_OFFLINE) will fail with EOPNOTSUPP.
[jiaqiyan@google.com: v7]
Link: https://lkml.kernel.org/r/20240628205958.2845610-3-jiaqiyan@google.com
Link: https://lkml.kernel.org/r/20240626050818.2277273-3-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Lance Yang <ioworker0@gmail.com>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-26 05:08:16 +00:00
|
|
|
* Returns 0 on success,
|
|
|
|
* -EOPNOTSUPP for hwpoison_filter() filtered the error event, or
|
|
|
|
* disabled by /proc/sys/vm/enable_soft_offline,
|
2022-05-13 03:23:10 +00:00
|
|
|
* < 0 otherwise negated errno.
|
2013-09-11 21:22:56 +00:00
|
|
|
*
|
|
|
|
* Soft offline a page, by migration or invalidation,
|
|
|
|
* without killing anything. This is for the case when
|
|
|
|
* a page is not corrupted yet (so it's still valid to access),
|
|
|
|
* but has had a number of corrected errors and is better taken
|
|
|
|
* out.
|
|
|
|
*
|
|
|
|
* The actual policy on when to do that is maintained by
|
|
|
|
* user space.
|
|
|
|
*
|
|
|
|
* This should never impact any application or cause data loss,
|
|
|
|
* however it might take some time.
|
|
|
|
*
|
|
|
|
* This is not a 100% solution for all memory, but tries to be
|
|
|
|
* ``good enough'' for the majority of memory.
|
|
|
|
*/
|
2019-12-01 01:53:38 +00:00
|
|
|
int soft_offline_page(unsigned long pfn, int flags)
|
2013-09-11 21:22:56 +00:00
|
|
|
{
|
|
|
|
int ret;
|
2020-10-16 03:07:29 +00:00
|
|
|
bool try_again = true;
|
2022-10-21 08:46:09 +00:00
|
|
|
struct page *page;
|
2021-01-24 05:01:52 +00:00
|
|
|
|
2022-10-21 08:46:10 +00:00
|
|
|
if (!pfn_valid(pfn)) {
|
|
|
|
WARN_ON_ONCE(flags & MF_COUNT_INCREASED);
|
2019-12-01 01:53:38 +00:00
|
|
|
return -ENXIO;
|
2022-10-21 08:46:10 +00:00
|
|
|
}
|
2021-01-24 05:01:52 +00:00
|
|
|
|
2019-12-01 01:53:38 +00:00
|
|
|
/* Only online pages can be soft-offlined (esp., not ZONE_DEVICE). */
|
|
|
|
page = pfn_to_online_page(pfn);
|
2021-01-24 05:01:52 +00:00
|
|
|
if (!page) {
|
2022-10-21 08:46:09 +00:00
|
|
|
put_ref_page(pfn, flags);
|
2018-07-14 04:49:56 +00:00
|
|
|
return -EIO;
|
2021-01-24 05:01:52 +00:00
|
|
|
}
|
2018-07-14 04:49:56 +00:00
|
|
|
|
mm/memory-failure: userspace controls soft-offlining pages
Correctable memory errors are very common on servers with large amount of
memory, and are corrected by ECC. Soft offline is kernel's additional
recovery handling for memory pages having (excessive) corrected memory
errors. Impacted page is migrated to a healthy page if inuse; the
original page is discarded for any future use.
The actual policy on whether (and when) to soft offline should be
maintained by userspace, especially in case of an 1G HugeTLB page.
Soft-offline dissolves the HugeTLB page, either in-use or free, into
chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If
userspace has not acknowledged such behavior, it may be surprised when
later failed to mmap hugepages due to lack of hugepages. In case of a
transparent hugepage, it will be split into 4K pages as well; userspace
will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of
corrected memory errors sounds very costly and kernel better not doing
under the hood. But today there are at least 2 such cases doing so:
1. when GHES driver sees both GHES_SEV_CORRECTED and
CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
2. RAS Correctable Errors Collector counts correctable errors per
PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed
by kernel's memory failure recovery.
This commit gives userspace the control of softofflining any page: kernel
only soft offlines raw page / transparent hugepage / HugeTLB hugepage if
userspace has agreed to. The interface to userspace is a new sysctl at
/proc/sys/vm/enable_soft_offline. By default its value is set to 1 to
preserve existing behavior in kernel. When set to 0, soft-offline (e.g.
MADV_SOFT_OFFLINE) will fail with EOPNOTSUPP.
[jiaqiyan@google.com: v7]
Link: https://lkml.kernel.org/r/20240628205958.2845610-3-jiaqiyan@google.com
Link: https://lkml.kernel.org/r/20240626050818.2277273-3-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Lance Yang <ioworker0@gmail.com>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-26 05:08:16 +00:00
|
|
|
if (!sysctl_enable_soft_offline) {
|
|
|
|
pr_info_once("disabled by /proc/sys/vm/enable_soft_offline\n");
|
|
|
|
put_ref_page(pfn, flags);
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
2022-01-14 22:09:02 +00:00
|
|
|
mutex_lock(&mf_mutex);
|
|
|
|
|
2013-09-11 21:22:56 +00:00
|
|
|
if (PageHWPoison(page)) {
|
mm/memory-failure: refactor log format in soft offline code
Patch series "Userspace controls soft-offline pages", v6.
Correctable memory errors are very common on servers with large amount of
memory, and are corrected by ECC, but with two pain points to users:
1. Correction usually happens on the fly and adds latency overhead
2. Not-fully-proved theory states excessive correctable memory
errors can develop into uncorrectable memory error.
Soft offline is kernel's additional solution for memory pages having
(excessive) corrected memory errors. Impacted page is migrated to healthy
page if it is in use, then the original page is discarded for any future
use.
The actual policy on whether (and when) to soft offline should be
maintained by userspace, especially in case of an 1G HugeTLB page.
Soft-offline dissolves the HugeTLB page, either in-use or free, into
chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If
userspace has not acknowledged such behavior, it may be surprised when
later mmap hugepages MAP_FAILED due to lack of hugepages. In case of a
transparent hugepage, it will be split into 4K pages as well; userspace
will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of
corrected memory errors sounds very costly and kernel better not doing
under the hood. But today there are at least 2 such cases:
1. GHES driver sees both GHES_SEV_CORRECTED and
CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
2. RAS Correctable Errors Collector counts correctable errors per
PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed by
kernel's memory failure recovery.
This patch series give userspace the control of softofflining any page:
kernel only soft offlines raw page / transparent hugepage / HugeTLB
hugepage if userspace has agreed to. The interface to userspace is a new
sysctl called enable_soft_offline under /proc/sys/vm. By default
enable_soft_line is 1 to preserve existing behavior in kernel.
This patch (of 4):
Logs from soft_offline_page and soft_offline_in_use_page have different
formats than majority of the memory failure code:
"Memory failure: 0x${pfn}: ${lower_case_message}"
Convert them to the following format:
"Soft offline: 0x${pfn}: ${lower_case_message}"
No functional change in this commit.
Link: https://lkml.kernel.org/r/20240626050818.2277273-1-jiaqiyan@google.com
Link: https://lkml.kernel.org/r/20240626050818.2277273-2-jiaqiyan@google.com
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Lance Yang <ioworker0@gmail.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-26 05:08:15 +00:00
|
|
|
pr_info("%#lx: page already poisoned\n", pfn);
|
2022-10-21 08:46:09 +00:00
|
|
|
put_ref_page(pfn, flags);
|
2022-01-14 22:09:02 +00:00
|
|
|
mutex_unlock(&mf_mutex);
|
2020-10-16 03:07:17 +00:00
|
|
|
return 0;
|
2013-09-11 21:22:56 +00:00
|
|
|
}
|
|
|
|
|
2020-10-16 03:07:29 +00:00
|
|
|
retry:
|
mem-hotplug: implement get/put_online_mems
kmem_cache_{create,destroy,shrink} need to get a stable value of
cpu/node online mask, because they init/destroy/access per-cpu/node
kmem_cache parts, which can be allocated or destroyed on cpu/mem
hotplug. To protect against cpu hotplug, these functions use
{get,put}_online_cpus. However, they do nothing to synchronize with
memory hotplug - taking the slab_mutex does not eliminate the
possibility of race as described in patch 2.
What we need there is something like get_online_cpus, but for memory.
We already have lock_memory_hotplug, which serves for the purpose, but
it's a bit of a hammer right now, because it's backed by a mutex. As a
result, it imposes some limitations to locking order, which are not
desirable, and can't be used just like get_online_cpus. That's why in
patch 1 I substitute it with get/put_online_mems, which work exactly
like get/put_online_cpus except they block not cpu, but memory hotplug.
[ v1 can be found at https://lkml.org/lkml/2014/4/6/68. I NAK'ed it by
myself, because it used an rw semaphore for get/put_online_mems,
making them dead lock prune. ]
This patch (of 2):
{un}lock_memory_hotplug, which is used to synchronize against memory
hotplug, is currently backed by a mutex, which makes it a bit of a
hammer - threads that only want to get a stable value of online nodes
mask won't be able to proceed concurrently. Also, it imposes some
strong locking ordering rules on it, which narrows down the set of its
usage scenarios.
This patch introduces get/put_online_mems, which are the same as
get/put_online_cpus, but for memory hotplug, i.e. executing a code
inside a get/put_online_mems section will guarantee a stable value of
online nodes, present pages, etc.
lock_memory_hotplug()/unlock_memory_hotplug() are removed altogether.
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: Xishi Qiu <qiuxishi@huawei.com>
Cc: Jiang Liu <liuj97@gmail.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-04 23:07:18 +00:00
|
|
|
get_online_mems();
|
2022-03-22 21:44:50 +00:00
|
|
|
ret = get_hwpoison_page(page, flags | MF_SOFT_OFFLINE);
|
mem-hotplug: implement get/put_online_mems
kmem_cache_{create,destroy,shrink} need to get a stable value of
cpu/node online mask, because they init/destroy/access per-cpu/node
kmem_cache parts, which can be allocated or destroyed on cpu/mem
hotplug. To protect against cpu hotplug, these functions use
{get,put}_online_cpus. However, they do nothing to synchronize with
memory hotplug - taking the slab_mutex does not eliminate the
possibility of race as described in patch 2.
What we need there is something like get_online_cpus, but for memory.
We already have lock_memory_hotplug, which serves for the purpose, but
it's a bit of a hammer right now, because it's backed by a mutex. As a
result, it imposes some limitations to locking order, which are not
desirable, and can't be used just like get_online_cpus. That's why in
patch 1 I substitute it with get/put_online_mems, which work exactly
like get/put_online_cpus except they block not cpu, but memory hotplug.
[ v1 can be found at https://lkml.org/lkml/2014/4/6/68. I NAK'ed it by
myself, because it used an rw semaphore for get/put_online_mems,
making them dead lock prune. ]
This patch (of 2):
{un}lock_memory_hotplug, which is used to synchronize against memory
hotplug, is currently backed by a mutex, which makes it a bit of a
hammer - threads that only want to get a stable value of online nodes
mask won't be able to proceed concurrently. Also, it imposes some
strong locking ordering rules on it, which narrows down the set of its
usage scenarios.
This patch introduces get/put_online_mems, which are the same as
get/put_online_cpus, but for memory hotplug, i.e. executing a code
inside a get/put_online_mems section will guarantee a stable value of
online nodes, present pages, etc.
lock_memory_hotplug()/unlock_memory_hotplug() are removed altogether.
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: Xishi Qiu <qiuxishi@huawei.com>
Cc: Jiang Liu <liuj97@gmail.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-04 23:07:18 +00:00
|
|
|
put_online_mems();
|
2016-01-16 00:54:07 +00:00
|
|
|
|
2022-05-13 03:23:10 +00:00
|
|
|
if (hwpoison_filter(page)) {
|
|
|
|
if (ret > 0)
|
|
|
|
put_page(page);
|
|
|
|
|
|
|
|
mutex_unlock(&mf_mutex);
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
2020-12-15 03:11:38 +00:00
|
|
|
if (ret > 0) {
|
2020-10-16 03:07:13 +00:00
|
|
|
ret = soft_offline_in_use_page(page);
|
2020-12-15 03:11:38 +00:00
|
|
|
} else if (ret == 0) {
|
2023-06-27 11:28:08 +00:00
|
|
|
if (!page_handle_poison(page, true, false)) {
|
|
|
|
if (try_again) {
|
|
|
|
try_again = false;
|
|
|
|
flags &= ~MF_COUNT_INCREASED;
|
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
ret = -EBUSY;
|
2020-10-16 03:07:29 +00:00
|
|
|
}
|
2020-12-15 03:11:38 +00:00
|
|
|
}
|
2016-01-16 00:54:07 +00:00
|
|
|
|
2022-01-14 22:09:02 +00:00
|
|
|
mutex_unlock(&mf_mutex);
|
|
|
|
|
2013-09-11 21:22:56 +00:00
|
|
|
return ret;
|
|
|
|
}
|