All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ren Mingxin <renmx@cn.fujitsu.com>
To: Rusty Russell <rusty@rustcorp.com.au>,
	"Michael S. Tsirkin" <mst@redhat.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>,
	Tokunaga Kei <tokunaga.keiich@jp.fujitsu.com>,
	LKML <linux-kernel@vger.kernel.org>,
	UDEV <linux-hotplug@vger.kernel.org>
Subject: [RFC PATCH] virtio_blk: Checking "private_data"  to avoid kernel panic when hotplugging
Date: Wed, 28 Mar 2012 03:40:33 +0000	[thread overview]
Message-ID: <4F728831.2090406@cn.fujitsu.com> (raw)

  Hi,

On guest with upstream's kernel(3.3.0-rc7), I
mounted virtblk as:
   a) # mkfs /dev/vda
   b) # mount /dev/vda /mnt
   c) # cd /mnt

Then I did hotplug for virtblk via virsh on host as:
   a) # sudo virsh detach-disk guest vda
   b) # sudo virsh attach-disk guest /media/data/test.img vda

I encountered guest's kernel panic (*probability *
*event*)whose backtrace liked this:

PID: 2496   TASK: ffff88001f5de080  CPU: 0   COMMAND: "blkid"
  #0 [ffff88001afdbb00] machine_kexec at ffffffff81031fcb
  #1 [ffff88001afdbb60] crash_kexec at ffffffff810b8f72
  #2 [ffff88001afdbc30] oops_end at ffffffff814f04b0
  #3 [ffff88001afdbc60] die at ffffffff8100f26b
  #4 [ffff88001afdbc90] do_general_protection at ffffffff814f0042
  #5 [ffff88001afdbcc0] general_protection at ffffffff814ef815
     [exception RIP: virtio_check_driver_offered_feature+27]
     RIP: ffffffffa00540cb  RSP: ffff88001afdbd78  RFLAGS: 00010206
     RAX: ffffffff810ffde0  RBX: ffff88001f14a800  RCX: 000000004cf0758b
     RDX: 4ce86d8b4ce0658b  RSI: 0000000000000007  RDI: ffffffff81a970a0
     RBP: ffff88001afdbd78   R8: ffffffffa009d060   R9: 0000000000000100
     R10: 0000000000000006  R11: 0000000000000246  R12: 000000000000101d
     R13: 0000000000005331  R14: ffffffff81a970a0  R15: 0000000000000000
     ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
  #6 [ffff88001afdbd80] virtblk_ioctl at ffffffffa009c459 [virtio_blk]
  #7 [ffff88001afdbdc0] __blkdev_driver_ioctl at ffffffff81257317
  #8 [ffff88001afdbe00] blkdev_ioctl at ffffffff8125779d
  #9 [ffff88001afdbe50] block_ioctl at ffffffff811aec5c
#10 [ffff88001afdbe60] vfs_ioctl at ffffffff81189342
#11 [ffff88001afdbea0] do_vfs_ioctl at ffffffff811894e4
#12 [ffff88001afdbf30] sys_ioctl at ffffffff81189a61
#13 [ffff88001afdbf80] system_call_fastpath at ffffffff8100b0f2
     RIP: 0000003f566dd847  RSP: 00007fffa23e6130  RFLAGS: 00010202
     RAX: 0000000000000010  RBX: ffffffff8100b0f2  RCX: 0000000000000008
     RDX: 0000000000000000  RSI: 0000000000005331  RDI: 0000000000000003
     RBP: 0000000040000000   R8: 0000003f5699b580   R9: 0000000000000100
     R10: 0000000000000006  R11: 0000000000000246  R12: 0000000000000000
     R13: 0000003f59020ba0  R14: 0000000000000003  R15: 000000000241f030
     ORIG_RAX: 0000000000000010  CS: 0033  SS: 002b

This panic was triggered by the command of "blkid" in
udev's rule "60-persistent-storage.rules".

So, when the virtblk was reattached, command "blkid"
probed filesystem metadata of disks. At that moment,
virtblk_ioctl() was called, but the data of "virtio_blk"
"bdev->bd_disk->private_data" pointing to may not be
updated for the sync reason.

This patch do this check to avoid panic.

Any comment will be appreciated.

Signed-off-by: Ren Mingxin <renmx@cn.fujitsu.com>
---
  virtio_blk.c |    6 ++++++
  1 file changed, 6 insertions(+)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index c4a60ba..4ac81f8 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -245,6 +245,12 @@ static int virtblk_ioctl(struct block_device *bdev, 
fmode_t mode,
         struct virtio_blk *vblk = disk->private_data;

         /*
+        * Check whether the private data pointer has been updated.
+        */
+       if (vblk != vblk->vdev->priv)
+               return -EFAULT;
+
+       /*
          * Only allow the generic SCSI ioctls if the host can support it.
          */
         if (!virtio_has_feature(vblk->vdev, VIRTIO_BLK_F_SCSI))


Thanks,
Ren

WARNING: multiple messages have this Message-ID (diff)
From: Ren Mingxin <renmx@cn.fujitsu.com>
To: Rusty Russell <rusty@rustcorp.com.au>,
	"Michael S. Tsirkin" <mst@redhat.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>,
	Tokunaga Kei <tokunaga.keiich@jp.fujitsu.com>,
	LKML <linux-kernel@vger.kernel.org>,
	UDEV <linux-hotplug@vger.kernel.org>
Subject: [RFC PATCH] virtio_blk: Checking "private_data"  to avoid kernel panic when hotplugging
Date: Wed, 28 Mar 2012 11:40:33 +0800	[thread overview]
Message-ID: <4F728831.2090406@cn.fujitsu.com> (raw)

  Hi,

On guest with upstream's kernel(3.3.0-rc7), I
mounted virtblk as:
   a) # mkfs /dev/vda
   b) # mount /dev/vda /mnt
   c) # cd /mnt

Then I did hotplug for virtblk via virsh on host as:
   a) # sudo virsh detach-disk guest vda
   b) # sudo virsh attach-disk guest /media/data/test.img vda

I encountered guest's kernel panic (*probability *
*event*)whose backtrace liked this:

PID: 2496   TASK: ffff88001f5de080  CPU: 0   COMMAND: "blkid"
  #0 [ffff88001afdbb00] machine_kexec at ffffffff81031fcb
  #1 [ffff88001afdbb60] crash_kexec at ffffffff810b8f72
  #2 [ffff88001afdbc30] oops_end at ffffffff814f04b0
  #3 [ffff88001afdbc60] die at ffffffff8100f26b
  #4 [ffff88001afdbc90] do_general_protection at ffffffff814f0042
  #5 [ffff88001afdbcc0] general_protection at ffffffff814ef815
     [exception RIP: virtio_check_driver_offered_feature+27]
     RIP: ffffffffa00540cb  RSP: ffff88001afdbd78  RFLAGS: 00010206
     RAX: ffffffff810ffde0  RBX: ffff88001f14a800  RCX: 000000004cf0758b
     RDX: 4ce86d8b4ce0658b  RSI: 0000000000000007  RDI: ffffffff81a970a0
     RBP: ffff88001afdbd78   R8: ffffffffa009d060   R9: 0000000000000100
     R10: 0000000000000006  R11: 0000000000000246  R12: 000000000000101d
     R13: 0000000000005331  R14: ffffffff81a970a0  R15: 0000000000000000
     ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
  #6 [ffff88001afdbd80] virtblk_ioctl at ffffffffa009c459 [virtio_blk]
  #7 [ffff88001afdbdc0] __blkdev_driver_ioctl at ffffffff81257317
  #8 [ffff88001afdbe00] blkdev_ioctl at ffffffff8125779d
  #9 [ffff88001afdbe50] block_ioctl at ffffffff811aec5c
#10 [ffff88001afdbe60] vfs_ioctl at ffffffff81189342
#11 [ffff88001afdbea0] do_vfs_ioctl at ffffffff811894e4
#12 [ffff88001afdbf30] sys_ioctl at ffffffff81189a61
#13 [ffff88001afdbf80] system_call_fastpath at ffffffff8100b0f2
     RIP: 0000003f566dd847  RSP: 00007fffa23e6130  RFLAGS: 00010202
     RAX: 0000000000000010  RBX: ffffffff8100b0f2  RCX: 0000000000000008
     RDX: 0000000000000000  RSI: 0000000000005331  RDI: 0000000000000003
     RBP: 0000000040000000   R8: 0000003f5699b580   R9: 0000000000000100
     R10: 0000000000000006  R11: 0000000000000246  R12: 0000000000000000
     R13: 0000003f59020ba0  R14: 0000000000000003  R15: 000000000241f030
     ORIG_RAX: 0000000000000010  CS: 0033  SS: 002b

This panic was triggered by the command of "blkid" in
udev's rule "60-persistent-storage.rules".

So, when the virtblk was reattached, command "blkid"
probed filesystem metadata of disks. At that moment,
virtblk_ioctl() was called, but the data of "virtio_blk"
"bdev->bd_disk->private_data" pointing to may not be
updated for the sync reason.

This patch do this check to avoid panic.

Any comment will be appreciated.

Signed-off-by: Ren Mingxin <renmx@cn.fujitsu.com>
---
  virtio_blk.c |    6 ++++++
  1 file changed, 6 insertions(+)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index c4a60ba..4ac81f8 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -245,6 +245,12 @@ static int virtblk_ioctl(struct block_device *bdev, 
fmode_t mode,
         struct virtio_blk *vblk = disk->private_data;

         /*
+        * Check whether the private data pointer has been updated.
+        */
+       if (vblk != vblk->vdev->priv)
+               return -EFAULT;
+
+       /*
          * Only allow the generic SCSI ioctls if the host can support it.
          */
         if (!virtio_has_feature(vblk->vdev, VIRTIO_BLK_F_SCSI))


Thanks,
Ren

             reply	other threads:[~2012-03-28  3:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-28  3:40 Ren Mingxin [this message]
2012-03-28  3:40 ` [RFC PATCH] virtio_blk: Checking "private_data" to avoid kernel panic when hotplugging Ren Mingxin
2012-03-28 11:11 ` Michael S. Tsirkin
2012-03-28 11:11   ` Michael S. Tsirkin
2012-03-29  4:11   ` Ren Mingxin
2012-03-29  4:11     ` Ren Mingxin
2012-03-29 10:30     ` Michael S. Tsirkin
2012-03-29 10:30       ` Michael S. Tsirkin
2012-04-09  7:53 ` Michael S. Tsirkin
2012-04-09  7:53   ` Michael S. Tsirkin
2012-04-11  3:17   ` Ren Mingxin
2012-04-11  3:17     ` Ren Mingxin
2012-04-11  8:36     ` Michael S. Tsirkin
2012-04-11  8:36       ` Michael S. Tsirkin
2012-04-11  9:09       ` Ren Mingxin
2012-04-11  9:09         ` Ren Mingxin

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=4F728831.2090406@cn.fujitsu.com \
    --to=renmx@cn.fujitsu.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-hotplug@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=tokunaga.keiich@jp.fujitsu.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.