On Thu, Mar 11, 2021 at 10:44:56AM +0100, Michal Hocko wrote: > On Thu 11-03-21 10:32:24, Peter Zijlstra wrote: > > The whole changelog reads like a trainwreck, but akpm already commented > > on that. I picked out a small factual incorrectness, simply because if > > you can't get that right, the whole argument looses weight. > > Is there any reason why in_atomic || irq_disabled wouldn't work > universally? I just explained to you how you really wanted: in_atomic() && !irq_disabled() > > That said, I don't think you actually need it, if as you write the lock > > should be IRQ-safe, then you're worried about the IRQ recursion > > deadlock: > > making hugetlb_lock irqsafe is a long way as explained by Mike > elsewhere. Not only that. The upcoming hugeltb feature to have sparse > vmemmap for hugetlb pages will need to allocate vmemmap when hugetlb > page is to be freed back to the allocator. That cannot happen in any > atomic context so there will be a need to tell those contexts for > special casing. Then scrap the vmemmap code *NOW*. Do not merge more shit before fixing existing problems. Especially not if that's known to make it harder to fix the problems.
