If the tool cannot tell whether the protected state is manipulated by *another* piece of code called in atomic context, then it's insufficient.
> On Jan 26, 2018, at 4:37 AM, Jia-Ju Bai <baijiaju1...@gmail.com> wrote: > > After checking all possible call chains to aoenet_rcv(), > my tool finds that aoenet_rcv() is never called in atomic context, > namely never in an interrupt handler or holding a spinlock. > 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. > > Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com> > --- > drivers/block/aoe/aoenet.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/block/aoe/aoenet.c b/drivers/block/aoe/aoenet.c > index 63773a9..d5fff7a 100644 > --- a/drivers/block/aoe/aoenet.c > +++ b/drivers/block/aoe/aoenet.c > @@ -138,7 +138,7 @@ static int __init aoe_iflist_setup(char *str) > if (dev_net(ifp) != &init_net) > goto exit; > > - skb = skb_share_check(skb, GFP_ATOMIC); > + skb = skb_share_check(skb, GFP_KERNEL); > if (skb == NULL) > return 0; > if (!is_aoe_netif(ifp)) > -- > 1.7.9.5 >
