Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> writes: > On 2023/05/22 12:07, Huang, Ying wrote: >> Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> writes: >> >>> On 2023/05/22 11:13, Huang, Ying wrote: >>>>> Any atomic allocation used by KASAN needs to drop __GFP_KSWAPD_RECLAIM bit. >>>>> Where do we want to drop this bit (in the caller side, or in the callee side)? >>>> >>>> Yes. I think we should fix the KASAN. Maybe define a new GFP_XXX >>>> (instead of GFP_ATOMIC) for debug code? The debug code may be called at >>>> almost arbitrary places, and wakeup_kswap() isn't safe to be called in >>>> some situations. >>> >>> What do you think about removing __GFP_KSWAPD_RECLAIM from GFP_ATOMIC and GFP_NOWAIT? >>> Recent reports indicate that atomic allocations (GFP_ATOMIC and GFP_NOWAIT) are not safe >>> enough to think "atomic". They just don't do direct reclaim, but they do take spinlocks. >>> Removing __GFP_KSWAPD_RECLAIM from GFP_ATOMIC and GFP_NOWAIT simplifies locking dependency and >>> reduces latency of atomic allocations (which is important when called from "atomic" context). >>> I consider that memory allocations which do not do direct reclaim should be geared towards >>> less locking dependency. >> >> Except debug code, where do you find locking issues for waking up kswapd? > > I'm not aware of lockdep reports except debug code. > > But due to too many locking dependency, lockdep gives up tracking all dependency (e.g. > > https://syzkaller.appspot.com/bug?extid=8a249628ae32ea7de3a2 > https://syzkaller.appspot.com/bug?extid=a70a6358abd2c3f9550f > https://syzkaller.appspot.com/bug?extid=9bbbacfbf1e04d5221f7 > https://syzkaller.appspot.com/bug?extid=b04c9ffbbd2f303d00d9 > > ). I want to reduce locking patterns where possible. pgdat->{kswapd,kcompactd}_wait.lock > and zonelist_update_seq are candidates which need not to be held from interrupt context. Why is it not safe to wake up kswapd/kcompactd from interrupt context? Best Regards, Huang, Ying
