On 12/16/19 8:37 AM, Michal Hocko wrote: > On Thu 12-12-19 11:04:27, Davidlohr Bueso wrote: >> There have been deadlock reports[1, 2] where put_page is called >> from softirq context and this causes trouble with the hugetlb_lock, >> as well as potentially the subpool lock. >> >> For such an unlikely scenario, lets not add irq dancing overhead >> to the lock+unlock operations, which could incur in expensive >> instruction dependencies, particularly when considering hard-irq >> safety. For example PUSHF+POPF on x86. >> >> Instead, just use a workqueue and do the free_huge_page() in regular >> task context. > I am afraid that work_struct is too large to be stuffed into the struct > page array (because of the lockdep part). > > I think that it would be just safer to make hugetlb_lock irq safe. Are > there any other locks that would require the same? Currently, free_huge_page() can be called from the softIRQ context. The hugetlb_lock will be acquired during that call. The subpool lock may conditionally be acquired as well. I am still torn between converting both locks to be irq-safe or deferring the freeing to a workqueue. Cheers, Longman
