On Thu 18-07-24 00:04:54, Christoph Hellwig wrote: > On Thu, Jul 18, 2024 at 08:58:44AM +0200, Michal Hocko wrote: > > WARN_ON is effectively BUG_ON with panic_on_warn so if this happens to > > be in a user triggerable path then you would have an easy way to panic > > the whole machine. It is likely true that the kernel could oops just > > right after the failure but that could be recoverable at least. > > If you set panic_on_warn you are either debugging in which case it's > the right thing, or you are fucked. So don't do it unless you > expet frequent crashes. I do agree and I wouldn't recommend running panic_on_warn on anything even touching production setups. Reality check disagrees. > > If anything I would just pr_warn with caller address or add dump_stack > > to capture the full trace. That would give us the caller that needs > > fixing without panicing the system with panic_on_warn. > > The whole freaking point of __GFP_NOFAIL is that callers don't handle > allocation failures. So in fact a straight BUG is the right thing > here. OOPs from the NULL ptr could be just a safer option bacause it could be recoverable. Anyway, I am questioning that WARN/BUG/pr_warn on overflow check is adding any actual value because GFP_NOFAIL large allocations could be even more dangerous essentially rendering the system completely unsuabale. -- Michal Hocko SUSE Labs
