On Tue 30-08-22 10:02:05, Dan Carpenter wrote: > On Tue, Aug 30, 2022 at 08:46:58AM +0200, Michal Hocko wrote: > > On Tue 30-08-22 09:30:26, Dan Carpenter wrote: > > > Hello Michal Hocko, > > > > > > The patch e8fedfea3dea: "mm: reduce noise in show_mem for lowmem > > > allocations" from Aug 23, 2022, leads to the following Smatch static > > > checker warning: > > > > > > kernel/panic.c:190 panic_print_sys_info() > > > warn: sleeping in atomic context > > > > What is this warning saying? > > > > This is a Smatch warning. > > > > 189 if (panic_print & PANIC_PRINT_MEM_INFO) > > > --> 190 show_mem(0, NULL, GFP_HIGHUSER_MOVABLE); > > > ^^^^^^^^^^^^^^^^^^^^ > > > This obviously seems very deliberate and a lot of weird stuff happens > > > during panic(). But the panic() function disables preemption so > > > shouldn't this be GFP_ATOMIC? GFP_HIGHUSER_MOVABLE has __GFP_RECLAIM > > > and triggering swap during a panic seems bad. > > > > This function shouldn't ever be allocating any memory. The flag is > > solely to infer which memory zones should be displayed. It acts as a > > filter. Is it possible that the checker misinterprets the parameter's > > meaning? > > Ah. Yes. Smatch sees every gfp_t as a sleep/no sleep marker. I > didn't realize it wasn't used like that here. Thanks! OK, fair enough and I can actually see how that can turn out into a real allocation in a distant future when the original intention has been lost in the past. Let me re-open the discussion for that patch and CC you there. Thanks for the report. -- Michal Hocko SUSE Labs
