On Fri, Jan 26, 2018 at 04:00:27PM +0800, Jia-Ju Bai wrote: > After checking all possible call chains to fs_send() here, > my tool finds that fs_send() is never called in atomic context. > And this function is assigned to a function pointer "dev->ops->send", > which is only called by vcc_sendmsg() (net/atm/common.c) > through vcc->dev->ops->send(), and vcc_sendmsg() calls schedule(), > it indicates that fs_send() can call functions which may sleep. > Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL. > > This is found by a static analysis tool named DCNS written by myself.
The trouble is, places like net/atm/raw.c:65: vcc->send = atm_send_aal0; net/atm/raw.c:74: vcc->send = vcc->dev->ops->send; net/atm/raw.c:83: vcc->send = vcc->dev->ops->send; mean extra call chains. It's *not* just vcc_sendmsg(), and e.g. ret = ATM_SKB(skb)->vcc->send(ATM_SKB(skb)->vcc, skb) ? DROP_PACKET : 1; bh_unlock_sock(sk_atm(vcc)); in pppoatm_send() definitely is called under a spinlock. Looking through the driver (in advanced bitrot, as usual for drivers/atm), I'd say that submit_queue() is fucked in head in the "queue full" case. And judging by the history, had been thus since the original merge...