Re: [PATCH v2 3/3] drivers/base/memory: fix locking for poison accounting lookup

Usama Arif
2026-04-29T10:11:57Z

On Wed, 29 Apr 2026 12:18:08 +0800 Muchun Song <muchun.song@linux.dev> wrote:

>
>
> > On Apr 29, 2026, at 11:32, Oscar Salvador <osalvador@suse.de> wrote:
> >
> > On Wed, Apr 29, 2026 at 11:08:51AM +0800, Miaohe Lin wrote:
> >> Right, I missed that. Thanks. But I'm still worried that there might be potential issues.
> >> For example, this function could be called while lock_page is held. Acquiring lock_device_hotplug
> >> while already holding lock_page might cause problems, though I haven't seen any specific issues yet.
> >> Also there might be some other potential scenarios that haven't been considered. Hope I'm just
> >> overthinking it. :)
> >
> > lock_device_hotplug is a mutex lock, and we already take other mutex locks while
> > holding lock_folio in other paths, so I am not sure I see what should be special
> > in this case.
>
> Hi Oscar and Miaohe,
>
> I saw sashiko's report [1] related to folio lock and lock_device_hotplug.
> Seems it is possible. You can correct me if I am wrong.
>
> [1] https://sashiko.dev/#/patchset/20260428085219.1316047-1-songmuchun%40bytedance.com
>
> We could fix this by calling action_result() without holding folio lock.
> What do you think?
>

Hello Muchun,

You could end up in memblk_nr_poison_sub() while holding hugetlb_lock spin lock
from get_huge_page_for_hwpoison(), right?

Lockdep would flag this as sleeping while atomic when acquiring mutex I think.