From: Dan Carpenter <dan.carpenter@oracle.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: kernel test robot <lkp@intel.com>,
David Airlie <airlied@linux.ie>,
dri-devel <dri-devel@lists.freedesktop.org>,
Hans de Goede <hdegoede@redhat.com>,
Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH] drm/vboxvideo: Unmap iomem on probe-failure and remove
Date: Fri, 20 Nov 2020 10:58:11 +0300 [thread overview]
Message-ID: <20201120075811.GJ18329@kadam> (raw)
In-Reply-To: <CAKMK7uGB5-aDSyA42PVs7_86NEfinftvKWx6AKsLFjoUS-1VGw@mail.gmail.com>
On Thu, Nov 19, 2020 at 08:30:59PM +0100, Daniel Vetter wrote:
> On Thu, Nov 19, 2020 at 6:51 PM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> >
> > On Thu, Nov 19, 2020 at 12:35:56PM +0100, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 10/27/20 2:51 PM, Hans de Goede wrote:
> > > > Add missing pci_iounmap() calls to properly unmap the memory on
> > > > probe-failure and remove.
> > > >
> > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > >
> > > For some reason the spam-filter used by Red Hat's email system has eaten
> > > Daniel Vetter's reply to this, so let me copy and paste that from patchwork:
> > >
> > > Daniel Vetter wrote:
> > >
> > > > I think switching over to devm would be really nice. And for pci all
> > > > you need to do is use pcim_enable_device and delete all the cleanup
> > > > code, and it's all done. Hand rolling device cleanup code really isn't
> > > > a great idea and way too error-prone. Plus you're using lots of devm_
> > > > already.
> > >
> > > Good point, so I just checked and the vboxvideo code is already
> > > using pcim_enable_device() so it looks like this is a false-positive
> > > from the lkp@intel.com bot, and Dan Carpenter missed that pcim_enable_device()
> > > makes all subsequent pci-resource acquiring calls behave like devm calls,
> > > when he forwarded the report to me.
> > >
> > > Tl;DR: there is no bug / leak and this patch can be dropped.
> > >
> > > Is there a place where I can report a bug against the lkp@intel.com bot
> > > for this false-positive ?
> >
> > Ah. Thanks!
> >
> > This is a Smatch bug. There is a list for that smatch@vger.kernel.org
> > but I already remove the pci_iomap() from the list of functions that
> > needs to be unwound based on your report.
>
> I guess if smatch sees a pci_enable_device but not pcim_enable_device
> on the same device as passed to pci_iomap (and a pile of other pci
> functions) then it still must be unwound. Could smatch detect that?
> There's a lot of pci drivers not using the managed functions, catching
> bugs in these would be good.
It's a lot of code. There would be two ways to implement this:
1) Somehow store the links to figure out the value of:
devres_find(vbox->ddev.pdev.dev)->enabled
That's very complicated. I'm sort of working on some of the steps
involved but and it's probably a multi year process before it's
possible.
2) Create a data base table with driver data, then store if the driver
calls pcim_enable_device(). This is still a bit of work, but probably
straight forward. Storing driver data would be useful for other things
as well.
regards,
dan carpenter
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-11-20 7:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-27 13:51 [PATCH] drm/vboxvideo: Unmap iomem on probe-failure and remove Hans de Goede
2020-10-27 15:23 ` Daniel Vetter
2020-11-19 11:35 ` Hans de Goede
2020-11-19 17:51 ` Dan Carpenter
2020-11-19 19:30 ` Daniel Vetter
2020-11-20 7:58 ` Dan Carpenter [this message]
2020-11-20 9:39 ` Daniel Vetter
2020-11-20 11:00 ` Dan Carpenter
2020-11-20 14:55 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201120075811.GJ18329@kadam \
--to=dan.carpenter@oracle.com \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=lkp@intel.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.