On 8/27/24 09:50, Barry Song wrote: > On Tue, Aug 27, 2024 at 7:38 PM Vlastimil Babka <vbabka@xxxxxxx> wrote: >> >> >> Ugh, wasn't aware, well spotted. So it means there at least shouldn't be >> existing users of __GFP_NOFAIL with order > 1 :) >> >> But also the check is in the hotpath, even before trying the pcplists, so we >> could move it to __alloc_pages_slowpath() while extending it? > > Agreed. I don't think it is reasonable to check the order and flags in > two different places especially rmqueue() has already had > gfp_flags & __GFP_NOFAIL operation and order > 1 > overhead. > > We can at least extend the current check to make some improvement > though I still believe Michal's suggestion of implementing OOPS_ON is a > better approach to pursue, as it doesn't crash the entire system > while ensuring the problematic process is terminated. Linus made clear it's not a mm concern. If e.g. hardening people want to pursuit that instead, they can. BTW I think BUG_ON already works like this, if possible only the calling process is terminated. panic happens in case of being in a irq context, or due to panic_on_oops. Which the security people are setting to 1 anyway and OOPS_ON would have to observe it too. So AFAICS the only difference from BUG_ON would be not panic in the irq context, if panic_on_oops isn't set. (as for "no mm locks held" I think it's already satisfied at the points we check for __GFP_NOFAIL).
