Messages in this thread | | | From | HORIGUCHI NAOYA(堀口 直也) <> | Subject | Re: [PATCH v5 1/3] mm/memory-failure: Use a mutex to avoid memory_failure() races | Date | Mon, 24 May 2021 08:42:33 +0000 |
| |
On Sat, May 22, 2021 at 03:09:00PM -0700, Andrew Morton wrote: > On Fri, 21 May 2021 12:01:54 +0900 Naoya Horiguchi <nao.horiguchi@gmail.com> wrote: > > > There can be races when multiple CPUs consume poison from the same > > page. The first into memory_failure() atomically sets the HWPoison > > page flag and begins hunting for tasks that map this page. Eventually > > it invalidates those mappings and may send a SIGBUS to the affected > > tasks. > > > > But while all that work is going on, other CPUs see a "success" > > return code from memory_failure() and so they believe the error > > has been handled and continue executing. > > > > Fix by wrapping most of the internal parts of memory_failure() in > > a mutex. > > We can reduce the scope of that mutex, which helps readability at least.
Thanks, this change is totally fine to me.
> > --- a/mm/memory-failure.c~mm-memory-failure-use-a-mutex-to-avoid-memory_failure-races-fix > +++ a/mm/memory-failure.c > @@ -1397,8 +1397,6 @@ out: > return rc; > } > > -static DEFINE_MUTEX(mf_mutex); > - > /** > * memory_failure - Handle memory failure of a page. > * @pfn: Page Number of the corrupted page > @@ -1425,6 +1423,7 @@ int memory_failure(unsigned long pfn, in > int res = 0; > unsigned long page_flags; > bool retry = true; > + static DEFINE_MUTEX(mf_mutex); > > if (!sysctl_memory_failure_recovery) > panic("Memory failure on page %lx", pfn); > _ > | |