Bug 800222 - drivers/vhost/vhost.c:475 suspicious rcu_dereference_protected() usage
drivers/vhost/vhost.c:475 suspicious rcu_dereference_protected() usage
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel (Show other bugs)
7.0
Unspecified Unspecified
medium Severity medium
: beta
: ---
Assigned To: Vlad Yasevich
Red Hat Kernel QE team
:
Depends On:
Blocks: 839713
  Show dependency treegraph
 
Reported: 2012-03-05 21:51 EST by Xiaoqing Wei
Modified: 2016-01-10 19:40 EST (History)
5 users (show)

See Also:
Fixed In Version: Linux 3.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-11 13:14:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Xiaoqing Wei 2012-03-05 21:51:44 EST
Description of problem:
dmesg shows vhost warning, but didn't impact host / guest:
drivers/vhost/vhost.c:475 suspicious rcu_dereference_protected() usage

Version-Release number of selected component (if applicable):
3.2.1-0.8.el7.x86_64

How reproducible:

only once
Steps to Reproduce:
1. boot qemu-kvm guest, with virtio-net && vhost
2. tail -f /var/log/message
3.
  
Actual results:
messages 
Mar  6 04:57:12 localhost kernel: [  389.437551] device t0-000818-jREB entered promiscuous mode
Mar  6 04:57:12 localhost kernel: [  389.439207] switch: port 2(t0-000818-jREB) entering forwarding state
Mar  6 04:57:12 localhost kernel: [  389.439241] switch: port 2(t0-000818-jREB) entering forwarding state
Mar  6 04:57:13 localhost kernel: [  389.986760] 
Mar  6 04:57:13 localhost kernel: [  389.988278] ===============================
Mar  6 04:57:13 localhost kernel: [  389.992496] [ INFO: suspicious RCU usage. ]
Mar  6 04:57:13 localhost kernel: [  389.996727] -------------------------------
Mar  6 04:57:13 localhost kernel: [  390.000948] drivers/vhost/vhost.c:475 suspicious rcu_dereference_protected() usage!
Mar  6 04:57:13 localhost kernel: [  390.008657] 
Mar  6 04:57:13 localhost kernel: [  390.008657] other info that might help us debug this:
Mar  6 04:57:13 localhost kernel: [  390.008658] 
Mar  6 04:57:13 localhost kernel: [  390.016762] 
Mar  6 04:57:13 localhost kernel: [  390.016763] rcu_scheduler_active = 1, debug_locks = 0
Mar  6 04:57:13 localhost kernel: [  390.023358] no locks held by qemu/1733.
Mar  6 04:57:13 localhost kernel: [  390.027228] 
Mar  6 04:57:13 localhost kernel: [  390.027229] stack backtrace:
Mar  6 04:57:13 localhost kernel: [  390.031632] Pid: 1733, comm: qemu Not tainted 3.2.1-0.8.el7.x86_64 #1
Mar  6 04:57:13 localhost kernel: [  390.038133] Call Trace:
Mar  6 04:57:13 localhost kernel: [  390.040607]  [<ffffffff810bfaf7>] lockdep_rcu_suspicious+0xd7/0xe0
Mar  6 04:57:13 localhost kernel: [  390.046849]  [<ffffffffa04d44df>] vhost_dev_cleanup+0x34f/0x370 [vhost_net]
Mar  6 04:57:13 localhost kernel: [  390.053868]  [<ffffffffa04d4794>] vhost_net_release+0x54/0xa0 [vhost_net]
Mar  6 04:57:13 localhost kernel: [  390.060712]  [<ffffffff811b650c>] __fput+0xcc/0x2a0
Mar  6 04:57:13 localhost kernel: [  390.065633]  [<ffffffff811b6705>] fput+0x25/0x30
Mar  6 04:57:13 localhost kernel: [  390.065637]  [<ffffffff811b1dd9>] filp_close+0x69/0x90
Mar  6 04:57:13 localhost kernel: [  390.065640]  [<ffffffff8108379b>] close_files+0xeb/0x1a0
Mar  6 04:57:13 localhost kernel: [  390.065643]  [<ffffffff810836b0>] ? child_wait_callback+0x60/0x60
Mar  6 04:57:13 localhost kernel: [  390.065645]  [<ffffffff810c37f6>] ? lock_release_nested+0x86/0xc0
Mar  6 04:57:13 localhost kernel: [  390.065648]  [<ffffffff81083c38>] put_files_struct.part.5+0x18/0x130
Mar  6 04:57:13 localhost kernel: [  390.065650]  [<ffffffff81085a5d>] put_files_struct+0x1d/0x30
Mar  6 04:57:13 localhost kernel: [  390.065652]  [<ffffffff81085b32>] exit_files+0x52/0x60
Mar  6 04:57:13 localhost kernel: [  390.065655]  [<ffffffff8108605a>] do_exit+0x18a/0x570
Mar  6 04:57:13 localhost kernel: [  390.065657]  [<ffffffff810865ef>] do_group_exit+0x4f/0xc0
Mar  6 04:57:13 localhost kernel: [  390.065660]  [<ffffffff81086677>] sys_exit_group+0x17/0x20
Mar  6 04:57:13 localhost kernel: [  390.065663]  [<ffffffff81639202>] system_call_fastpath+0x16/0x1b
Mar  6 04:57:13 localhost kernel: [  390.161484] switch: port 2(t0-000818-jREB) entering forwarding state
Mar  6 04:57:13 localhost kernel: [  390.169127] switch: port 2(t0-000818-jREB) entering disabled state
Mar  6 04:57:13 localhost kernel: [  390.175540] device t0-000818-jREB left promiscuous mode
Mar  6 04:57:13 localhost kernel: [  390.180851] switch: port 2(t0-000818-jREB) entering disabled state


Expected results:
host / guest works well, not suspicious warning.

Additional info:
kernel-3.2.1-0.8.el7.x86_64
qemu-kvm-0.15.1-3.2.el7.x86_64


qemu_cmd:

/root/staf-kvm-devel/autotest-devel/client/tests/kvm/qemu -name 'vm1' -chardev socket,id=human_monitor_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20120306-000818-jREB,server,nowait -mon chardev=human_monitor_id_humanmonitor1,mode=readline -chardev socket,id=serial_id_20120306-000818-jREB,path=/tmp/serial-20120306-000818-jREB,server,nowait -device isa-serial,chardev=serial_id_20120306-000818-jREB -device ich9-usb-uhci1,id=usb1,multifunction=off,bus=pci.0,addr=0x4 -drive file='/root/staf-kvm-devel/autotest-devel/client/tests/kvm/images/RHEL-Server-6.3-64-virtio.qcow2',index=0,if=none,id=drive-virtio-disk1,media=disk,cache=none,format=qcow2,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -device virtio-net-pci,netdev=idGD9MlS,mac=9a:e4:b3:2a:58:52,id=ndev00idGD9MlS,bus=pci.0,addr=0x3 -netdev tap,id=idGD9MlS,vhost=on,fd=21 -m 2048 -smp 2,cores=1,threads=1,sockets=2 -cpu qemu64,+sse2 -device usb-tablet,id=usb-tablet1,bus=usb1.0 -spice port=8000,disable-ticketing -vga qxl -rtc base=utc,clock=host,driftfix=slew -M pc-0.14 -boot order=cdn,once=c,menu=off    -no-kvm-pit-reinjection -enable-kvm
Comment 3 Vlad Yasevich 2013-07-11 13:14:47 EDT
Fixed by:
commit ea5d404655ba3b356d0c06d6a3c4f24112124522
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Sun Nov 27 19:05:58 2011 +0200

    vhost: fix release path lockdep checks
    
    We shouldn't hold any locks on release path. Pass a flag to
    vhost_dev_cleanup to use the lockdep info correctly.
    
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Tested-by: Sasha Levin <levinsasha928@gmail.com>


Kernel version v3.4.

Note You need to log in before you can comment on or make changes to this bug.