From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [net-next 4/4] ixgbevf: scheduling while atomic in reset hw path Date: Wed, 19 Sep 2012 07:05:46 +0200 Message-ID: <1348031146.26523.276.camel@edumazet-glaptop> References: <1348029108-26659-1-git-send-email-jeffrey.t.kirsher@intel.com> <1348029108-26659-5-git-send-email-jeffrey.t.kirsher@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: davem@davemloft.net, John Fastabend , netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com To: Jeff Kirsher Return-path: Received: from mail-wg0-f44.google.com ([74.125.82.44]:60977 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754536Ab2ISFFu (ORCPT ); Wed, 19 Sep 2012 01:05:50 -0400 Received: by wgbdr13 with SMTP id dr13so515324wgb.1 for ; Tue, 18 Sep 2012 22:05:48 -0700 (PDT) In-Reply-To: <1348029108-26659-5-git-send-email-jeffrey.t.kirsher@intel.com> Sender: netdev-owner@vger.kernel.org List-ID: On Tue, 2012-09-18 at 21:31 -0700, Jeff Kirsher wrote: > From: John Fastabend > > In ixgbevf_reset_hw_vf() msleep is called while holding rtnl_lock > and mbx_lock resulting in a schedule while atomic bug with trace > below. > This sentence is misleading, as rtnl is a mutex. Its legal to sleep while holding it So the atomic context is because of lock #1, not 'lock' #2 > This patch uses mdelay instead. > > BUG: scheduling while atomic: ip/6539/0x00000002 > 2 locks held by ip/6539: > #0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x19 > #1: (&(&adapter->mbx_lock)->rlock){+.+...}, at: [] ixgbevf_reset+0x30/0xc1 [ixgbevf] > Modules linked in: ixgbevf ixgbe mdio libfc scsi_transport_fc 8021q scsi_tgt garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 uinput igb coretemp hwmon crc32c_intel ioatdma i2c_i801 shpchp microcode lpc_ich mfd_core i2c_core joydev dca pcspkr serio_raw pata_acpi ata_generic usb_storage pata_jmicron > Pid: 6539, comm: ip Not tainted 3.6.0-rc3jk-net-next+ #104 > Call Trace: > [] __schedule_bug+0x6a/0x79 > [] __schedule+0xa2/0x684 > [] ? trace_hardirqs_off+0xd/0xf > [] schedule+0x64/0x66 > [] schedule_timeout+0xa6/0xca > [] ? lock_timer_base+0x52/0x52 > [] ? __udelay+0x15/0x17 > [] schedule_timeout_uninterruptible+0x1e/0x20 > [] msleep+0x1b/0x22 > [] ixgbevf_reset_hw_vf+0x90/0xe5 [ixgbevf] > [] ixgbevf_reset+0x3b/0xc1 [ixgbevf] > [] ixgbevf_open+0x43/0x43e [ixgbevf] > [] ? dev_set_rx_mode+0x2e/0x33 > [] __dev_open+0xa0/0xe5 > [] __dev_change_flags+0xbe/0x142 > [] dev_change_flags+0x21/0x56 > [] do_setlink+0x2e2/0x7f4 > [] ? native_sched_clock+0x37/0x39 > [] rtnl_newlink+0x277/0x4bb > [] ? rtnl_newlink+0xb4/0x4bb > [] ? selinux_capable+0x32/0x3a > [] ? ns_capable+0x4f/0x67 > [] ? rtnl_lock+0x17/0x19 > [] rtnetlink_rcv_msg+0x236/0x253 > [] ? rtnetlink_rcv+0x2d/0x2d > [] netlink_rcv_skb+0x43/0x94 > [] rtnetlink_rcv+0x26/0x2d > [] netlink_unicast+0xee/0x174 > [] netlink_sendmsg+0x26a/0x288 > [] ? rcu_read_unlock+0x56/0x67 > [] __sock_sendmsg_nosec+0x58/0x61 > [] __sock_sendmsg+0x3d/0x48 > [] sock_sendmsg+0x6e/0x87 > [] ? might_fault+0xa5/0xac > [] ? copy_from_user+0x2a/0x2c > [] ? verify_iovec+0x54/0xaa > [] __sys_sendmsg+0x206/0x288 > [] ? up_read+0x23/0x3d > [] ? fcheck_files+0xac/0xea > [] ? fget_light+0x3a/0xb9 > [] sys_sendmsg+0x42/0x60 > [] system_call_fastpath+0x16/0x1b > > Signed-off-by: John Fastabend > Tested-by: Robert Garrett > Signed-off-by: Jeff Kirsher > --- > drivers/net/ethernet/intel/ixgbevf/vf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c > index 690801b..87b3f3b 100644 > --- a/drivers/net/ethernet/intel/ixgbevf/vf.c > +++ b/drivers/net/ethernet/intel/ixgbevf/vf.c > @@ -100,7 +100,7 @@ static s32 ixgbevf_reset_hw_vf(struct ixgbe_hw *hw) > msgbuf[0] = IXGBE_VF_RESET; > mbx->ops.write_posted(hw, msgbuf, 1); > > - msleep(10); > + mdelay(10); > > /* set our "perm_addr" based on info provided by PF */ > /* also set up the mc_filter_type which is piggy backed