Re: [patch] nvme-fabrics: correct some printk information

[Julia Lawall <julia.lawall@lip6.fr>]

On Sat, 10 Dec 2016, Dan Carpenter wrote:

> On Sat, Dec 10, 2016 at 03:27:50AM -0800, Joe Perches wrote:
> > On Sat, 2016-12-10 at 12:06 +0300, Dan Carpenter wrote:
> > > We really don't care where "ctrl" is on the stack since we're just
> > > returning soon what we want is the actual ctrl pointer itself.
> > >
> > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > >
> > > diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
> > []
> > > @@ -2402,7 +2402,7 @@ enum blk_eh_timer_return
> > >
> > >  	dev_info(ctrl->ctrl.device,
> > >  		"NVME-FC{%d}: new ctrl: NQN \"%s\" (%p)\n",
> > > -		ctrl->cnum, ctrl->ctrl.opts->subsysnqn, &ctrl);
> > > +		ctrl->cnum, ctrl->ctrl.opts->subsysnqn, ctrl);
> >
> > Found by script or inspection?
> >
> > If by script, it seems unlikely there's only 1 instance
> > where an address of an automatic pointer type is used
> > incorrectly.
>
> Script.  But it's using a pretty specific heuristic where we kmalloc a
> pointer and then pass the address.  It prints few warnings.  Probably
> 40% false positives, but the remaining examples of course are 100% false
> positives.

I tried anything that looks like a print, ie has a format string argument,
and was taking the address of a local variable as another argument.  But
there are lots of weird format designators in the kernel that Coccinelle
doesn't know about for which passing the address of a local variable is
reasonable.  So for the moment, there are, as far as I can see, just a lot
of false positives.  I did add improving the support for format strings to
my TODO list.

julia


>
> regards,
> dan carpenter
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>