Skip to contentSkip to conversation

Bonding two 802.1q interfaces triggers "sleeping function called from invalid context"

DISCUSSION Chuck Ebbert 3 participants 4 messages May 1, 2007

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Chuck Ebbert

author
#0 lore raw

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238307

This is kernel 2.6.20.3.

Quoted 1 line

From the bugzilla comment:

===============================================================================

I need to use a bonding through two 802.1q tag VLAN virtual interface in the same physical network interface. When I bond interface with command :
ifenslave bond0 eth1.10 eth1.20
Console and dmesg will continues report BUG:
--------------Output1 begin kernel 2.6.20-1.2933.fc6------------

BUG: sleeping function called from invalid context at include/asm/uaccess.h:500
in_atomic():1, irqs_disabled():0
 [<c04ecadb>] copy_from_user+0x35/0x66
 [<c05c2e78>] dev_ethtool+0x51/0xa0d
 [<c05ee503>] tcp_current_mss+0x71/0xdf
 [<c05ee169>] tcp_rcv_established+0x74f/0x7de
 [<c04cf48f>] selinux_netlbl_sock_rcv_skb+0x1d/0x5b
 [<c05f3a78>] tcp_v4_do_rcv+0x1bf/0x49c
 [<c05f5f1b>] tcp_v4_rcv+0x564/0x8b1
 [<d8a3ac03>] vlan_dev_ioctl+0x7b/0xa7 [8021q]
 [<d8a3ab88>] vlan_dev_ioctl+0x0/0xa7 [8021q]
 [<d8a53102>] bond_update_speed_duplex+0x88/0xd7 [bonding]
 [<d8a5688e>] bond_mii_monitor+0x0/0x403 [bonding]
 [<d8a56c01>] bond_mii_monitor+0x373/0x403 [bonding]
 [<c061ff9d>] _spin_unlock_irq+0x5/0x7
 [<c0439e73>] hrtimer_run_queues+0x127/0x141
 [<d8a5688e>] bond_mii_monitor+0x0/0x403 [bonding]
 [<c042e673>] run_timer_softirq+0x101/0x164
 [<c042b908>] __do_softirq+0x5d/0xba
 [<c04061b1>] do_softirq+0x59/0xb1
 [<c0419df6>] smp_apic_timer_interrupt+0x76/0x80
 [<c04049b0>] apic_timer_interrupt+0x28/0x30
 [<c0402d52>] default_idle+0x0/0x3e
 [<c0402d7e>] default_idle+0x2c/0x3e
 [<c04023d0>] cpu_idle+0x9e/0xb7
 [<c074a812>] start_kernel+0x3b6/0x3be
 [<c074a25a>] unknown_bootoption+0x0/0x202
#1 lore raw
Quoted 13 lines · Chuck Ebbert

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238307

This is kernel 2.6.20.3.

From the bugzilla comment:

===============================================================================

I need to use a bonding through two 802.1q tag VLAN virtual interface in the same physical network interface. When I bond interface with command :
ifenslave bond0 eth1.10 eth1.20
Console and dmesg will continues report BUG:
--------------Output1 begin kernel 2.6.20-1.2933.fc6------------

Quoted 14 lines
BUG: sleeping function called from invalid context at include/asm/uaccess.h:500
in_atomic():1, irqs_disabled():0
 [<c04ecadb>] copy_from_user+0x35/0x66
 [<c05c2e78>] dev_ethtool+0x51/0xa0d
 [<c05ee503>] tcp_current_mss+0x71/0xdf
 [<c05ee169>] tcp_rcv_established+0x74f/0x7de
 [<c04cf48f>] selinux_netlbl_sock_rcv_skb+0x1d/0x5b
 [<c05f3a78>] tcp_v4_do_rcv+0x1bf/0x49c
 [<c05f5f1b>] tcp_v4_rcv+0x564/0x8b1
 [<d8a3ac03>] vlan_dev_ioctl+0x7b/0xa7 [8021q]
 [<d8a3ab88>] vlan_dev_ioctl+0x0/0xa7 [8021q]
 [<d8a53102>] bond_update_speed_duplex+0x88/0xd7 [bonding]
 [<d8a5688e>] bond_mii_monitor+0x0/0x403 [bonding]
 [<d8a56c01>] bond_mii_monitor+0x373/0x403 [bonding]

Jay Vosburgh and I have been working on something to address this and other issues related to possible sleeping activities that might come from the monitoring functions. I feel like we are getting close to something so I hope we can post something soon.

Care to add anything, Jay?

#2 lore raw
Quoted 20 lines · Andy Gospodarek
Quoted 5 lines

I need to use a bonding through two 802.1q tag VLAN virtual interface in the same physical network interface. When I bond interface with command :
ifenslave bond0 eth1.10 eth1.20
Console and dmesg will continues report BUG:
--------------Output1 begin kernel 2.6.20-1.2933.fc6------------

Quoted 14 lines
BUG: sleeping function called from invalid context at include/asm/uaccess.h:500
in_atomic():1, irqs_disabled():0
 [<c04ecadb>] copy_from_user+0x35/0x66
 [<c05c2e78>] dev_ethtool+0x51/0xa0d
 [<c05ee503>] tcp_current_mss+0x71/0xdf
 [<c05ee169>] tcp_rcv_established+0x74f/0x7de
 [<c04cf48f>] selinux_netlbl_sock_rcv_skb+0x1d/0x5b
 [<c05f3a78>] tcp_v4_do_rcv+0x1bf/0x49c
 [<c05f5f1b>] tcp_v4_rcv+0x564/0x8b1
 [<d8a3ac03>] vlan_dev_ioctl+0x7b/0xa7 [8021q]
 [<d8a3ab88>] vlan_dev_ioctl+0x0/0xa7 [8021q]
 [<d8a53102>] bond_update_speed_duplex+0x88/0xd7 [bonding]
 [<d8a5688e>] bond_mii_monitor+0x0/0x403 [bonding]
 [<d8a56c01>] bond_mii_monitor+0x373/0x403 [bonding]
Quoted 6 lines

Jay Vosburgh and I have been working on something to address this and other issues related to possible sleeping activities that might come from the monitoring functions. I feel like we are getting close to something so I hope we can post something soon.

Care to add anything, Jay?

I was thinking about this one a couple of days ago; it's a
little tricky to get out of, since we nominally need to do the ethtool calls holding only rtnl, but don't want to cycle rtnl for each monitor pass.

The warning only shows up with VLANs because VLAN get_settings()
calls dev_ethtool() directly, and the copy_from_user() in dev_ethtool() is the complaining party here.

Calling an end device driver's get_settings() directly doesn't
trigger the warning. I think that's safe without rtnl (at least insofar as the slave won't vanish), since the slave cannot vanish without bonding being notified via the NETDEV_UNREGISTER notifier.

	-J

---
-Jay Vosburgh, IBM Linux Technology Center, [email protected]

#3 lore raw
Quoted 29 lines · Jay Vosburgh
Quoted 20 lines · Andy Gospodarek
Quoted 5 lines

I need to use a bonding through two 802.1q tag VLAN virtual interface in the same physical network interface. When I bond interface with command :
ifenslave bond0 eth1.10 eth1.20
Console and dmesg will continues report BUG:
--------------Output1 begin kernel 2.6.20-1.2933.fc6------------

Quoted 14 lines
BUG: sleeping function called from invalid context at include/asm/uaccess.h:500
in_atomic():1, irqs_disabled():0
 [<c04ecadb>] copy_from_user+0x35/0x66
 [<c05c2e78>] dev_ethtool+0x51/0xa0d
 [<c05ee503>] tcp_current_mss+0x71/0xdf
 [<c05ee169>] tcp_rcv_established+0x74f/0x7de
 [<c04cf48f>] selinux_netlbl_sock_rcv_skb+0x1d/0x5b
 [<c05f3a78>] tcp_v4_do_rcv+0x1bf/0x49c
 [<c05f5f1b>] tcp_v4_rcv+0x564/0x8b1
 [<d8a3ac03>] vlan_dev_ioctl+0x7b/0xa7 [8021q]
 [<d8a3ab88>] vlan_dev_ioctl+0x0/0xa7 [8021q]
 [<d8a53102>] bond_update_speed_duplex+0x88/0xd7 [bonding]
 [<d8a5688e>] bond_mii_monitor+0x0/0x403 [bonding]
 [<d8a56c01>] bond_mii_monitor+0x373/0x403 [bonding]
Quoted 6 lines

Jay Vosburgh and I have been working on something to address this and other issues related to possible sleeping activities that might come from the monitoring functions. I feel like we are getting close to something so I hope we can post something soon.

Care to add anything, Jay?

Quoted 9 lines

I was thinking about this one a couple of days ago; it's a
little tricky to get out of, since we nominally need to do the ethtool calls holding only rtnl, but don't want to cycle rtnl for each monitor pass.

The warning only shows up with VLANs because VLAN get_settings()
calls dev_ethtool() directly, and the copy_from_user() in dev_ethtool() is the complaining party here.

Agreed. All locks held when calling bond_update_speed_duplex for a vlan interface and need to be non bh-locks and the call needs to be done as a user-process. This might be hard to avoid with bond_enslave but could be avoided with some code restructing.

Quoted 4 lines

Calling an end device driver's get_settings() directly doesn't
trigger the warning. I think that's safe without rtnl (at least insofar as the slave won't vanish), since the slave cannot vanish without bonding being notified via the NETDEV_UNREGISTER notifier.

This does look to be something specific to vlan interfaces being enslaved. Which makes me wonder: Why are we supporting that anyway? I *guess* there might be some crazy network admin that might like this, but it doesn't seem right...

Quoted 9 lines
	-J

---
-Jay Vosburgh, IBM Linux Technology Center, [email protected]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html