From: Chas W. <3c...@gm...> - 2018-01-30 16:23:18
|
On Fri, Jan 26, 2018 at 3:23 AM, Jia-Ju Bai <bai...@gm...> wrote: > After checking all possible call chains to he_open() here, > my tool finds that he_open() is never called in atomic context. > And this function is assigned to a function pointer "dev->ops->open", > which is only called by __vcc_connect() (net/atm/common.c) > through dev->ops->send(), and __vcc_connect() is only called by > vcc_connect(), which calls mutex_lock(), > so it indicates that he_open() 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. > > Signed-off-by: Jia-Ju Bai <bai...@gm...> > Acked-by: Chas Williams <3c...@gm...> At one point, there was talk of doing open/close in the bottom half of the kernel. Since this only happens in user space as of now, this doesn't need to be ATOMIC. > --- > drivers/atm/he.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/atm/he.c b/drivers/atm/he.c > index e58538c..fea5bf0 100644 > --- a/drivers/atm/he.c > +++ b/drivers/atm/he.c > @@ -2135,7 +2135,7 @@ static int he_start(struct atm_dev *dev) > > cid = he_mkcid(he_dev, vpi, vci); > > - he_vcc = kmalloc(sizeof(struct he_vcc), GFP_ATOMIC); > + he_vcc = kmalloc(sizeof(struct he_vcc), GFP_KERNEL); > if (he_vcc == NULL) { > hprintk("unable to allocate he_vcc during open\n"); > return -ENOMEM; > -- > 1.7.9.5 > > |