All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Sjur Brændeland" <sjurbren@gmail.com>
Cc: linux-kernel@vger.kernel.org, "Guzman Lugo,
	Fernadndo" <fernando.lugo@ti.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH] virtio: Don't access device data after unregistration.
Date: Tue, 4 Sep 2012 17:13:21 +0300	[thread overview]
Message-ID: <20120904141321.GJ9805@redhat.com> (raw)
In-Reply-To: <CAJK669ZVHOZVEw+1UeLU5KyxZexGfWC0VPnrK5XZd9x935PznQ@mail.gmail.com>

On Tue, Sep 04, 2012 at 02:12:33PM +0200, Sjur Brændeland wrote:
> Hi Michael,
> 
> >> >> Fix panic in virtio.c when CONFIG_DEBUG_SLAB is set.
> >> >
> >> > What's the root cause of the panic?
> >>
> >> I believe the cause of the panic is calling
> >> ida_simple_remove(&virtio_index_ida, dev->index);
> >> when the dev structure is "poisoned" after kfree.
> >> It might be the "BUG_ON((int)id < 0)" that bites...
> >>
> >> >> Use device_del() and put_device() instead of
> >> >> device_unregister(), and access device data before
> >> >> calling put_device().
> >>
> >> > Why does this help? Does device_unregister free the
> >> > device so dev->index access crashes?
> >>
> >> Yes, if device ref-count is one when calling unregister
> >> the device is freed.
> >
> > Interesting. Where exactly?...
> 
> I was wrong here, the reason is not related to ref-count being
> above one. The reason this issue do not show up in virtio_pci
> is that the release function is a dummy:
> 
> [snip]
> static void virtio_pci_release_dev(struct device *_d)
> {
> 	/*
> 	 * No need for a release method as we allocate/free
> 	 * all devices together with the pci devices.
> 	 * Provide an empty one to avoid getting a warning from core.
> 	 */
> }
> 
> The device structure uses a kref for reference counting the device.
> In virtio_pci() the release function virtio_pci_release_dev()
> will be called when the device is unregistered, but because the
> release function is dummy, data isn't freed or reset at this point.
> So for virtio devices created from virtio_pci my patch is not
> currently needed.
> 
> However, empty release functions are not the preferred way, e.g look at
> https://lkml.org/lkml/2012/4/3/301
> 
> [Greg K.H:]
> > > > > +static void hsi_port_release(struct device *dev __maybe_unused)
> > > > > +{
> > > > > +}
> > > >
> > > > As per the documentation in the kernel tree, I get to mock you
> > > > mercilessly for doing something as foolish as this.  You are not smarter
> > > > than the kernel and don't think that you got rid of the kernel warning
> > > > properly by doing this.  Do you think that I wrote that code for no good
> > > > reason?  The kernel was being nice and telling you what you did wrong,
> > > > don't try to fake it out, it's smarter than you are here.
> 
> But remoteproc frees the device memory in the release function
> rproc_vdev_release() and needs this patch.
> 
> Regards,
> Sjur


Okay, so let's add a comment in virtio in unregister
function. Also slightly preferable to just use device_unregister
IMHO. Something like the below?

	/*
	   device_unregister drops reference to device so put_device could
	   invoke release callback. In case that callback will free the device,
	   make sure we don't access device after this call.
	 */

	int index = dev->index;
        device_unregister(&dev->dev);
        ida_simple_remove(&virtio_index_ida, index);

-- 
MST

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Sjur Brændeland" <sjurbren@gmail.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org, "Guzman Lugo,
	Fernadndo" <fernando.lugo@ti.com>,
	virtualization@lists.linux-foundation.org,
	Ohad Ben-Cohen <ohad@wizery.com>
Subject: Re: [PATCH] virtio: Don't access device data after unregistration.
Date: Tue, 4 Sep 2012 17:13:21 +0300	[thread overview]
Message-ID: <20120904141321.GJ9805@redhat.com> (raw)
In-Reply-To: <CAJK669ZVHOZVEw+1UeLU5KyxZexGfWC0VPnrK5XZd9x935PznQ@mail.gmail.com>

On Tue, Sep 04, 2012 at 02:12:33PM +0200, Sjur Brændeland wrote:
> Hi Michael,
> 
> >> >> Fix panic in virtio.c when CONFIG_DEBUG_SLAB is set.
> >> >
> >> > What's the root cause of the panic?
> >>
> >> I believe the cause of the panic is calling
> >> ida_simple_remove(&virtio_index_ida, dev->index);
> >> when the dev structure is "poisoned" after kfree.
> >> It might be the "BUG_ON((int)id < 0)" that bites...
> >>
> >> >> Use device_del() and put_device() instead of
> >> >> device_unregister(), and access device data before
> >> >> calling put_device().
> >>
> >> > Why does this help? Does device_unregister free the
> >> > device so dev->index access crashes?
> >>
> >> Yes, if device ref-count is one when calling unregister
> >> the device is freed.
> >
> > Interesting. Where exactly?...
> 
> I was wrong here, the reason is not related to ref-count being
> above one. The reason this issue do not show up in virtio_pci
> is that the release function is a dummy:
> 
> [snip]
> static void virtio_pci_release_dev(struct device *_d)
> {
> 	/*
> 	 * No need for a release method as we allocate/free
> 	 * all devices together with the pci devices.
> 	 * Provide an empty one to avoid getting a warning from core.
> 	 */
> }
> 
> The device structure uses a kref for reference counting the device.
> In virtio_pci() the release function virtio_pci_release_dev()
> will be called when the device is unregistered, but because the
> release function is dummy, data isn't freed or reset at this point.
> So for virtio devices created from virtio_pci my patch is not
> currently needed.
> 
> However, empty release functions are not the preferred way, e.g look at
> https://lkml.org/lkml/2012/4/3/301
> 
> [Greg K.H:]
> > > > > +static void hsi_port_release(struct device *dev __maybe_unused)
> > > > > +{
> > > > > +}
> > > >
> > > > As per the documentation in the kernel tree, I get to mock you
> > > > mercilessly for doing something as foolish as this.  You are not smarter
> > > > than the kernel and don't think that you got rid of the kernel warning
> > > > properly by doing this.  Do you think that I wrote that code for no good
> > > > reason?  The kernel was being nice and telling you what you did wrong,
> > > > don't try to fake it out, it's smarter than you are here.
> 
> But remoteproc frees the device memory in the release function
> rproc_vdev_release() and needs this patch.
> 
> Regards,
> Sjur


Okay, so let's add a comment in virtio in unregister
function. Also slightly preferable to just use device_unregister
IMHO. Something like the below?

	/*
	   device_unregister drops reference to device so put_device could
	   invoke release callback. In case that callback will free the device,
	   make sure we don't access device after this call.
	 */

	int index = dev->index;
        device_unregister(&dev->dev);
        ida_simple_remove(&virtio_index_ida, index);

-- 
MST

  reply	other threads:[~2012-09-04 14:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-03 13:50 [PATCH] virtio: Don't access device data after unregistration sjur.brandeland
2012-09-03 14:14 ` Michael S. Tsirkin
2012-09-03 14:14   ` Michael S. Tsirkin
2012-09-03 14:50   ` Sjur Brændeland
2012-09-03 14:50     ` Sjur Brændeland
2012-09-03 20:18     ` Michael S. Tsirkin
2012-09-03 20:18       ` Michael S. Tsirkin
2012-09-04 12:12       ` Sjur Brændeland
2012-09-04 14:13         ` Michael S. Tsirkin [this message]
2012-09-04 14:13           ` Michael S. Tsirkin
2012-09-04 12:12       ` Sjur Brændeland
  -- strict thread matches above, loose matches on Subject: below --
2012-09-03 13:50 sjur.brandeland

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=20120904141321.GJ9805@redhat.com \
    --to=mst@redhat.com \
    --cc=fernando.lugo@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sjurbren@gmail.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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.