Bug 1046890 - guest Call Trace when write a random value to a random virtio-pci port
Summary: guest Call Trace when write a random value to a random virtio-pci port
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Virtualization Maintenance
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-27 09:38 UTC by ShupingCui
Modified: 2016-05-16 04:07 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-31 15:14:12 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description ShupingCui 2013-12-27 09:38:10 UTC
Description of problem:
guest Call Trace when write a random value to a random virtio-pci port

Version-Release number of selected component (if applicable):
Host:
kernel-3.10.0-64.el7.x86_64
qemu-kvm-1.5.3-30.el7.x86_64 
Guest:
2.6.32-431.3.1.el6.x86_64

How reproducible:
3/10

Steps to Reproduce:
1. boot the guest
/usr/libexec/qemu-kvm \
    -name 'virt-tests-vm1'  \
    -sandbox off  \
    -M pc  \
    -nodefaults  \
    -vga qxl  \
    -global qxl-vga.vram_size=33554432  \
    -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20131227-152635-7Plhm8ko,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control  \
    -chardev socket,id=serial_id_serial0,path=/tmp/serial-serial0-20131227-152635-7Plhm8ko,server,nowait \
    -device isa-serial,chardev=serial_id_serial0  \
    -chardev socket,id=seabioslog_id_20131227-152635-7Plhm8ko,path=/tmp/seabios-20131227-152635-7Plhm8ko,server,nowait \
    -device isa-debugcon,chardev=seabioslog_id_20131227-152635-7Plhm8ko,iobase=0x402 \
    -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
    -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,file=/root/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/RHEL-Server-6.5-64-virtio.qcow2 \
    -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 \
    -device virtio-net-pci,mac=9a:b4:b5:b6:b7:b8,id=idKNnI7x,netdev=idQ2cY4v,bus=pci.0,addr=05  \
    -netdev tap,id=idQ2cY4v,vhost=on,vhostfd=23,fd=22  \
    -m 4096  \
    -smp 4,maxcpus=4,cores=2,threads=1,sockets=2  \
    -cpu 'SandyBridge' \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -spice port=3000,password=123456,addr=0,image-compression=auto_glz,zlib-glz-wan-compression=auto,streaming-video=all,agent-mouse=on,playback-compression=on,ipv4  \
    -rtc base=utc,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off  \
    -no-kvm-pit-reinjection \
    -enable-kvm
2. in guest, write a random value to a random virtio-pci port, like this:
# echo -e '\06' | dd of=/dev/port seek=49170 bs=1 count=1
# echo -e '\0106' | dd of=/dev/port seek=49170 bs=1 count=1
# echo -e '\0' | dd of=/dev/port seek=49168 bs=1 count=1
# echo -e '\0266' | dd of=/dev/port seek=49160 bs=1 count=1
3.

Actual results:
guest get call trace:
 INFO: task jbd2/dm-1-8:322 blocked for more than 120 seconds.
       Not tainted 2.6.32-431.3.1.el6.x86_64 #1
 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 jbd2/dm-1-8   D 0000000000000001     0   322      2 0x00000000
  ffff880118e27c20 0000000000000046 ffff8801ffffffff 00000119feba7485
  ffff880118e27b90 ffff8801196dc9f0 00000000000153f4 ffffffffad42d39f
  ffff880118e93098 ffff880118e27fd8 000000000000fbc8 ffff880118e93098
 Call Trace:
  [<ffffffff810a70b1>] ? ktime_get_ts+0xb1/0xf0
  [<ffffffff811bf130>] ? sync_buffer+0x0/0x50
  [<ffffffff815280b3>] io_schedule+0x73/0xc0
  [<ffffffff811bf170>] sync_buffer+0x40/0x50
  [<ffffffff81528b7f>] __wait_on_bit+0x5f/0x90
  [<ffffffff811bf130>] ? sync_buffer+0x0/0x50
  [<ffffffff81528c28>] out_of_line_wait_on_bit+0x78/0x90
  [<ffffffff8109b330>] ? wake_bit_function+0x0/0x50
  [<ffffffff811bf126>] __wait_on_buffer+0x26/0x30
  [<ffffffffa00607f1>] jbd2_journal_commit_transaction+0x1181/0x1500 [jbd2]
  [<ffffffff810096f0>] ? __switch_to+0xd0/0x320
  [<ffffffff81084d2b>] ? try_to_del_timer_sync+0x7b/0xe0
  [<ffffffffa0065a48>] kjournald2+0xb8/0x220 [jbd2]
  [<ffffffff8109b2b0>] ? autoremove_wake_function+0x0/0x40
  [<ffffffffa0065990>] ? kjournald2+0x0/0x220 [jbd2]
  [<ffffffff8109af06>] kthread+0x96/0xa0
  [<ffffffff8100c20a>] child_rip+0xa/0x20
  [<ffffffff8109ae70>] ? kthread+0x0/0xa0
  [<ffffffff8100c200>] ? child_rip+0x0/0x20
 INFO: task NetworkManager:5368 blocked for more than 120 seconds.
       Not tainted 2.6.32-431.3.1.el6.x86_64 #1
 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 NetworkManage D 0000000000000001     0  5368      1 0x00000080
  ffff880119e23cc8 0000000000000082 0000000000000000 00000119feba7485
  0000000000000282 ffff88011a0b87c0 00000000000174d2 ffffffffad42d39f
  ffff88011a051ab8 ffff880119e23fd8 000000000000fbc8 ffff88011a051ab8
 Call Trace:
  [<ffffffff8111f940>] ? sync_page+0x0/0x50
  [<ffffffff815280b3>] io_schedule+0x73/0xc0
  [<ffffffff8111f97d>] sync_page+0x3d/0x50
  [<ffffffff81528b7f>] __wait_on_bit+0x5f/0x90
  [<ffffffff8111fbb3>] wait_on_page_bit+0x73/0x80
  [<ffffffff8109b330>] ? wake_bit_function+0x0/0x50
  [<ffffffff81135c05>] ? pagevec_lookup_tag+0x25/0x40
  [<ffffffff8111ffdb>] wait_on_page_writeback_range+0xfb/0x190
  [<ffffffff81134ca1>] ? do_writepages+0x21/0x40
  [<ffffffff8112012b>] ? __filemap_fdatawrite_range+0x5b/0x60
  [<ffffffff811201a8>] filemap_write_and_wait_range+0x78/0x90
  [<ffffffff811baa4e>] vfs_fsync_range+0x7e/0x100
  [<ffffffff811bab3d>] vfs_fsync+0x1d/0x20
  [<ffffffff811bab7e>] do_fsync+0x3e/0x60
  [<ffffffff811babd0>] sys_fsync+0x10/0x20
  [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b


Expected results:
Guest works smoothly

Additional info:
Guest:
# cat /proc/ioports
  0000-0cf7 : PCI Bus 0000:00
  0000-001f : dma1
  0020-0021 : pic1
  0040-0043 : timer0
  0050-0053 : timer1
  0060-0060 : keyboard
  0064-0064 : keyboard
  0070-0071 : rtc0
  0080-008f : dma page reg
  00a0-00a1 : pic2
  00c0-00df : dma2
  00f0-00ff : fpu
  0170-0177 : 0000:00:01.1
    0170-0177 : ata_piix
  01f0-01f7 : 0000:00:01.1
    01f0-01f7 : ata_piix
  0376-0376 : 0000:00:01.1
    0376-0376 : ata_piix
  03c0-03df : vga+
  03f6-03f6 : 0000:00:01.1
    03f6-03f6 : ata_piix
  03f8-03ff : serial
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
  afe0-afe3 : ACPI GPE0_BLK
  b000-b03f : 0000:00:01.3
    b000-b003 : ACPI PM1a_EVT_BLK
    b004-b005 : ACPI PM1a_CNT_BLK
    b008-b00b : ACPI PM_TMR
  b100-b10f : 0000:00:01.3
    b100-b107 : piix4_smbus
  c000-c03f : 0000:00:04.0
    c000-c03f : virtio-pci
  c040-c05f : 0000:00:02.0
  c060-c07f : 0000:00:03.0
    c060-c07f : uhci_hcd
  c080-c09f : 0000:00:05.0
    c080-c09f : virtio-pci
  c0a0-c0af : 0000:00:01.1
    c0a0-c0af : ata_piix

Comment 2 Dr. David Alan Gilbert 2014-01-31 15:14:12 UTC
I say NOTABUG because:
   1) Writing into the IO space of any device randomly would have 'undefined' results (I'd bet a real machine would fail if you did the same thing)
   2) Only a privileged user or device driver can do this
   3) QEMU didn't crash or do anything nasty to the host.

If you manage to get QEMU to crash or to write to a device/file that it shouldn't be allowed to on the host then that would be a real problem.

Comment 3 ShupingCui 2014-03-06 01:50:50 UTC
(In reply to Dr. David Alan Gilbert from comment #2)
> I say NOTABUG because:
>    1) Writing into the IO space of any device randomly would have
> 'undefined' results (I'd bet a real machine would fail if you did the same
> thing)
>    2) Only a privileged user or device driver can do this
>    3) QEMU didn't crash or do anything nasty to the host.
> 
> If you manage to get QEMU to crash or to write to a device/file that it
> shouldn't be allowed to on the host then that would be a real problem.

Hi dgilbert,

Thanks for your comment, and I agreed with it's not a qemu bug, do you think re-open this bug on kernel?

Comment 4 Dr. David Alan Gilbert 2014-03-06 09:04:30 UTC
No, not a kernel bug either; if you do something random to a disk controller then you can't expect the kernel to like it.

Comment 5 ShupingCui 2014-03-06 09:07:16 UTC
(In reply to Dr. David Alan Gilbert from comment #4)
> No, not a kernel bug either; if you do something random to a disk controller
> then you can't expect the kernel to like it.

Ok, thank you very much.


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