On 3/25/21 4:21 AM, Michal Hocko wrote: > On Wed 24-03-21 17:28:34, Mike Kravetz wrote: >> Commit c77c0a8ac4c5 ("mm/hugetlb: defer freeing of huge pages if in >> non-task context") was added to address the issue of free_huge_page >> being called from irq context. That commit hands off free_huge_page >> processing to a workqueue if !in_task. However, as seen in [1] this >> does not cover all cases. Instead, make the locks taken in the >> free_huge_page irq safe. > > I would just call out the deadlock scenario here in the changelog > rathert than torture people by forcing them to follow up on the 0day > report. Something like the below? > " > " > However this doesn't cover all the cases as pointed out by 0day bot > lockdep report [1] > : Possible interrupt unsafe locking scenario: > : > : CPU0 CPU1 > : ---- ---- > : lock(hugetlb_lock); > : local_irq_disable(); > : lock(slock-AF_INET); > : lock(hugetlb_lock); > : <Interrupt> > : lock(slock-AF_INET); > > Shakeel has later explained that this is very likely TCP TX > zerocopy from hugetlb pages scenario when the networking code drops a > last reference to hugetlb page while having IRQ disabled. Hugetlb > freeing path doesn't disable IRQ while holding hugetlb_lock so a lock > dependency chain can lead to a deadlock. > Thanks. I will update changelog. > >> This patch does the following: >> - Make hugetlb_lock irq safe. This is mostly a simple process of >> changing spin_*lock calls to spin_*lock_irq* calls. >> - Make subpool lock irq safe in a similar manner. >> - Revert the !in_task check and workqueue handoff. >> >> [1] https://lore.kernel.org/linux-mm/000000000000f1c03b05bc43aadc@xxxxxxxxxx/ >> >> Signed-off-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx> > > Acked-by: Michal Hocko <mhocko@xxxxxxxx> And, thanks for looking at the series! -- Mike Kravetz