Bug 1401612 - kernel oops when creating a bond device with virtio-net interface
Summary: kernel oops when creating a bond device with virtio-net interface
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-05 17:23 UTC by Zbigniew Jędrzejewski-Szmek
Modified: 2019-01-09 12:54 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-06 16:51:48 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Zbigniew Jędrzejewski-Szmek 2016-12-05 17:23:40 UTC
Description of problem:
I was trying to experiment with bond devices in a qemu machine.
I added two virtio-net interfaces. Adding them as slaves results in oops:

$ ip l
...
5: ens14: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:e9:64:41 brd ff:ff:ff:ff:ff:ff
6: ens15: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:e9:64:42 brd ff:ff:ff:ff:ff:ff

$ sudo ip link add bond1 type bond
$ sudo ip link set ens14 master bond1
Segmentation fault

Mon 2016-12-05 12:15:25 EST kernel: ------------[ cut here ]------------
Mon 2016-12-05 12:15:25 EST kernel: kernel BUG at ./include/linux/scatterlist.h:140!
Mon 2016-12-05 12:15:25 EST kernel: invalid opcode: 0000 [#1] SMP
Mon 2016-12-05 12:15:25 EST kernel: Modules linked in: bonding ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip
Mon 2016-12-05 12:15:25 EST kernel:  ata_generic crc32c_intel qxl drm_kms_helper virtio_pci serio_raw ttm drm pata_acpi
Mon 2016-12-05 12:15:25 EST kernel: CPU: 5 PID: 1983 Comm: ip Not tainted 4.9.0-0.rc6.git2.1.fc26.x86_64 #1
Mon 2016-12-05 12:15:25 EST kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
Mon 2016-12-05 12:15:25 EST kernel: task: ffff9d50a3583240 task.stack: ffffb06e41040000
Mon 2016-12-05 12:15:25 EST kernel: RIP: 0010:[<ffffffffbc4896fc>]  [<ffffffffbc4896fc>] sg_init_one+0x8c/0xa0
Mon 2016-12-05 12:15:25 EST kernel: RSP: 0018:ffffb06e41043698  EFLAGS: 00010246
Mon 2016-12-05 12:15:25 EST kernel: RAX: 0000000000000000 RBX: ffffb06e41043774 RCX: 0000000000000028
Mon 2016-12-05 12:15:25 EST kernel: RDX: 0000131ec1043774 RSI: 0000000000000013 RDI: ffffb06ec1043774
Mon 2016-12-05 12:15:25 EST kernel: RBP: ffffb06e410436b0 R08: 00000000001ddbe0 R09: ffffb06e410436c8
Mon 2016-12-05 12:15:25 EST kernel: R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000006
Mon 2016-12-05 12:15:25 EST kernel: R13: ffffb06e410436c8 R14: ffff9d50b2dc1800 R15: ffff9d50b3db9600
Mon 2016-12-05 12:15:25 EST kernel: FS:  00007f15347e5700(0000) GS:ffff9d50bb000000(0000) knlGS:0000000000000000
Mon 2016-12-05 12:15:25 EST kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Mon 2016-12-05 12:15:25 EST kernel: CR2: 00007ffc09bc4000 CR3: 0000000135797000 CR4: 00000000000406e0
Mon 2016-12-05 12:15:25 EST kernel: Stack:
Mon 2016-12-05 12:15:25 EST kernel:  ffff9d50b229d000 0000000000000000 ffffb06e41043772 ffffb06e41043720
Mon 2016-12-05 12:15:25 EST kernel:  ffffffffc0051123 ffff9d50a3583240 0000000087654321 0000000000000002
Mon 2016-12-05 12:15:25 EST kernel:  0000000000000000 0000000000000000 0000000000000000 000000007b8f5301
Mon 2016-12-05 12:15:25 EST kernel: Call Trace:
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffc0051123>] virtnet_set_mac_address+0xb3/0x140 [virtio_net]
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc7ae305>] dev_set_mac_address+0x55/0xc0
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffc03f319e>] bond_enslave+0x34e/0x1180 [bonding]
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc7ca22f>] do_setlink+0x6cf/0xd10
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc20dd6a>] ? get_page_from_freelist+0x6ba/0xca0
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc037de9>] ? sched_clock+0x9/0x10
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc068475>] ? kvm_sched_clock_read+0x25/0x40
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc111ed6>] ? __lock_acquire+0x346/0x1290
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc4aa436>] ? nla_parse+0xa6/0x120
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc7ce9e8>] rtnl_newlink+0x5c8/0x870
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc3ecb32>] ? avc_has_perm_noaudit+0x32/0x210
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc0bbfca>] ? ns_capable_common+0x7a/0x90
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc0bbff3>] ? ns_capable+0x13/0x20
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc7ced76>] rtnetlink_rcv_msg+0xe6/0x210
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc7c951b>] ? rtnetlink_rcv+0x1b/0x40
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc7c951b>] ? rtnetlink_rcv+0x1b/0x40
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc7cec90>] ? rtnl_newlink+0x870/0x870
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc7f7394>] netlink_rcv_skb+0xa4/0xc0
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc7c952a>] rtnetlink_rcv+0x2a/0x40
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc7f6d07>] netlink_unicast+0x1f7/0x2f0
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc7f6c7f>] ? netlink_unicast+0x16f/0x2f0
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc7f7102>] netlink_sendmsg+0x302/0x3c0
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc790c28>] sock_sendmsg+0x38/0x50
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc791773>] ___sys_sendmsg+0x2e3/0x2f0
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc18830d>] ? __audit_syscall_entry+0xad/0xf0
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc068475>] ? kvm_sched_clock_read+0x25/0x40
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc037de9>] ? sched_clock+0x9/0x10
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc18830d>] ? __audit_syscall_entry+0xad/0xf0
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc18830d>] ? __audit_syscall_entry+0xad/0xf0
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc111775>] ? trace_hardirqs_on_caller+0xf5/0x1b0
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc7924b4>] __sys_sendmsg+0x54/0x90
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc792502>] SyS_sendmsg+0x12/0x20
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc003eec>] do_syscall_64+0x6c/0x1f0
Mon 2016-12-05 12:15:25 EST kernel:  [<ffffffffbc917589>] entry_SYSCALL64_slow_path+0x25/0x25
Mon 2016-12-05 12:15:25 EST kernel: Code: ca 75 2c 49 8b 55 08 f6 c2 01 75 25 83 e2 03 81 e3 ff 0f 00 00 45 89 65 14 48
Mon 2016-12-05 12:15:25 EST kernel: RIP  [<ffffffffbc4896fc>] sg_init_one+0x8c/0xa0
Mon 2016-12-05 12:15:25 EST kernel:  RSP <ffffb06e41043698>
Mon 2016-12-05 12:15:25 EST kernel: ---[ end trace 9076d2284efbf735 ]---

Version-Release number of selected component (if applicable):
kernel-4.9.0-0.rc6.git2.1.fc26.x86_64

How reproducible:
100%.
systemd-networkd triggers the same oops.

Comment 1 Zbigniew Jędrzejewski-Szmek 2016-12-05 18:07:10 UTC
With the device type changed to e1000, no crash.

Comment 2 Laura Abbott 2016-12-05 18:56:21 UTC
BUG_ON(!virt_addr_valid(buf));

This looks like another issue with vmap stacks. I'll double check the mailing list archives to see if this has been reported already.

Comment 4 Laura Abbott 2016-12-06 16:51:48 UTC
Fix given and accepted by maintainers. I threw it in today's rawhide, should actually be showing up in Linus' tree before the final 4.9 release.

Comment 5 Zbigniew Jędrzejewski-Szmek 2016-12-06 17:35:58 UTC
That was fast. Thanks!


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