All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
	linux-kernel@vger.kernel.org,
	weiping zhang <zhangweiping@didichuxing.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCHv2] virtio_mmio: fix devm cleanup
Date: Thu, 14 Dec 2017 20:48:43 +0200	[thread overview]
Message-ID: <20171214204808-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20171213143413.e3efqns53333uf5g@lakrids.cambridge.arm.com>

On Wed, Dec 13, 2017 at 02:34:14PM +0000, Mark Rutland wrote:
> On Tue, Dec 12, 2017 at 06:02:23PM +0100, Cornelia Huck wrote:
> > On Tue, 12 Dec 2017 13:45:50 +0000
> > Mark Rutland <mark.rutland@arm.com> wrote:
> > 
> > > Recent rework of the virtio_mmio probe/remove paths balanced a
> > > devm_ioremap() with an iounmap() rather than its devm variant. This ends
> > > up corrupting the devm datastructures, and results in the following
> > > boot-time splat on arm64 under QEMU 2.9.0:
> > > 
> > > [    3.450397] ------------[ cut here ]------------
> > > [    3.453822] Trying to vfree() nonexistent vm area (00000000c05b4844)
> > > [    3.460534] WARNING: CPU: 1 PID: 1 at mm/vmalloc.c:1525 __vunmap+0x1b8/0x220
> > > [    3.475898] Kernel panic - not syncing: panic_on_warn set ...
> > > [    3.475898]
> > > [    3.493933] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc3 #1
> > > [    3.513109] Hardware name: linux,dummy-virt (DT)
> > > [    3.525382] Call trace:
> > > [    3.531683]  dump_backtrace+0x0/0x368
> > > [    3.543921]  show_stack+0x20/0x30
> > > [    3.547767]  dump_stack+0x108/0x164
> > > [    3.559584]  panic+0x25c/0x51c
> > > [    3.569184]  __warn+0x29c/0x31c
> > > [    3.576023]  report_bug+0x1d4/0x290
> > > [    3.586069]  bug_handler.part.2+0x40/0x100
> > > [    3.597820]  bug_handler+0x4c/0x88
> > > [    3.608400]  brk_handler+0x11c/0x218
> > > [    3.613430]  do_debug_exception+0xe8/0x318
> > > [    3.627370]  el1_dbg+0x18/0x78
> > > [    3.634037]  __vunmap+0x1b8/0x220
> > > [    3.648747]  vunmap+0x6c/0xc0
> > > [    3.653864]  __iounmap+0x44/0x58
> > > [    3.659771]  devm_ioremap_release+0x34/0x68
> > > [    3.672983]  release_nodes+0x404/0x880
> > > [    3.683543]  devres_release_all+0x6c/0xe8
> > > [    3.695692]  driver_probe_device+0x250/0x828
> > > [    3.706187]  __driver_attach+0x190/0x210
> > > [    3.717645]  bus_for_each_dev+0x14c/0x1f0
> > > [    3.728633]  driver_attach+0x48/0x78
> > > [    3.740249]  bus_add_driver+0x26c/0x5b8
> > > [    3.752248]  driver_register+0x16c/0x398
> > > [    3.757211]  __platform_driver_register+0xd8/0x128
> > > [    3.770860]  virtio_mmio_init+0x1c/0x24
> > > [    3.782671]  do_one_initcall+0xe0/0x398
> > > [    3.791890]  kernel_init_freeable+0x594/0x660
> > > [    3.798514]  kernel_init+0x18/0x190
> > > [    3.810220]  ret_from_fork+0x10/0x18
> > > 
> > > To fix this, we can simply rip out the explicit cleanup that the devm
> > > infrastructure will do for us when our probe function returns an error
> > > code, or when our remove function returns.
> > > 
> > > We only need to ensure that we call put_device() if a call to
> > > register_virtio_device() fails in the probe path.
> > > 
> > > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > Fixes: 7eb781b1bbb7136f ("virtio_mmio: add cleanup for virtio_mmio_probe")
> > > Fixes: 25f32223bce5c580 ("virtio_mmio: add cleanup for virtio_mmio_remove")
> > > Cc: Cornelia Huck <cohuck@redhat.com>
> > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > Cc: weiping zhang <zhangweiping@didichuxing.com>
> > > Cc: virtualization@lists.linux-foundation.org
> > > ---
> > >  drivers/virtio/virtio_mmio.c | 43 +++++++++----------------------------------
> > >  1 file changed, 9 insertions(+), 34 deletions(-)
> > 
> > In the hope that I have grokked the devm_* interface by now,
> > 
> > Reviewed-by: Cornelia Huck <cohuck@redhat.com>
> 
> Thanks!
> 
> Michael, could you please queue this as a fix for v4.15?
> 
> This regressed arm64 VMs booting between v4.15-rc1 and v4-15-rc2,
> impacting our automated regression testing, and I'd very much like to
> get back to testing pure mainline rather than mainline + local fixes.
> 
> Thanks,
> Mark.

Yep, plan to.
Thanks!

  parent reply	other threads:[~2017-12-14 18:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-12 13:45 [PATCHv2] virtio_mmio: fix devm cleanup Mark Rutland
2017-12-12 13:45 ` Mark Rutland
2017-12-12 14:26 ` weiping zhang
2017-12-12 14:45   ` Mark Rutland
2017-12-12 14:45   ` Mark Rutland
2017-12-12 15:04     ` weiping zhang
2017-12-12 15:04     ` weiping zhang
2017-12-12 14:26 ` weiping zhang
2017-12-12 17:02 ` Cornelia Huck
2017-12-12 17:02 ` Cornelia Huck
2017-12-13 14:34   ` Mark Rutland
2017-12-13 14:34   ` Mark Rutland
2017-12-14 18:48     ` Michael S. Tsirkin
2017-12-14 18:48     ` Michael S. Tsirkin [this message]
2017-12-15  1:48       ` weiping zhang
2017-12-15  1:48       ` weiping zhang

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=20171214204808-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=zhangweiping@didichuxing.com \
    /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.