Re: [PATCH v8 09/15] mm: Remove locking mf_mutex in is_raw_hwpoison_page_in_hugepage()

[Gregory Price <gourry@gourry.net>]

On Tue, Aug 04, 2026 at 05:58:26PM +0100, Matthew Wilcox wrote:
> On Tue, Aug 04, 2026 at 12:36:00PM -0400, Gregory Price wrote:
> 
> So we have all manner of protections that prevent us from taking this mutex
> -- the folio must have a hwpoison page in it and must be hugetlb, but at
> the end of the day, one can still be preempted while holding a mutex and
> we never know when we might want to call this from a non-sleepable context.
> 
> I'd be open to arguments that this should be an rwlock rather than
> a spinlock.  Or figure out a way to shard the lock per folio (lockdep
> etc make it very hard to embed a spinlock in struct folio).  I think
> it'd also be profitable to change how we record poison for hugetlb to
> not need locking or memory allocation.
>

I think such complexity needs to be driven by an actual demonstration
the spinlock is problematic.  It seems like if you're hitting devastating
contention here, you have much bigger (hardware) problems.

> But this is all a very long way from where I want to be working -- cleaning
> up the page fault path.  I think I've made a reasonable set of improvements
> here, and somebody else can come along later to make the code even better.
> 

Agreed.

~Gregory