netdev - Re: 2.6.29-rc1-wl gives WARNING on ich8lan

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 15 Jan 2009 20:13:21 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Cc:	Norbert Preining <preining@...ic.at>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, David Graham <david.graham@...el.com>,
	Bruce Allan <bruce.w.allan@...el.com>
Subject: Re: 2.6.29-rc1-wl gives WARNING on ich8lan

On Thu, 15 Jan 2009 20:06:17 -0800 Jeff Kirsher <jeffrey.t.kirsher@...el.com> wrote:

> On Wed, Jan 14, 2009 at 10:25 PM, Andrew Morton
> <akpm@...ux-foundation.org> wrote:
> > On Thu, 15 Jan 2009 00:15:46 +0100 Norbert Preining <preining@...ic.at> wrote:
> >
> >> Hi all,
> >>
> >> (please cc)
> >
> > (please cc right lists!)
> >
> >> 2.6.29-rc1-wl (wireless testing) gives me:
> >>
> >> [  367.804080] WARNING: at drivers/net/e1000e/ich8lan.c:412 e1000_acquire_swflag_ich8lan+0x35/0xcc()
> >> [  367.804085] Hardware name: VGN-Z11VN_B
> >> [  367.804088] e1000e mutex contention. Owned by pid 3781
> >> [  367.804092] Modules linked in: binfmt_misc rfcomm l2cap kvm isofs zlib_inflate fuse dm_crypt dm_mod firewire_sbp2 loop arc4 iwlagn iwlcore rfkill joydev firewire_ohci mac80211 firewire_core crc_itu_t cfg80211 btusb sony_laptop tpm_infineon video backlight
> >> [  367.804143] Pid: 8, comm: events/1 Not tainted 2.6.29-rc1-wl #1
> >> [  367.804148] Call Trace:
> >> [  367.804158]  [<ffffffff80236441>] warn_slowpath+0xd8/0x112
> >> [  367.804169]  [<ffffffff8051152f>] _spin_unlock_irqrestore+0x31/0x3d
> >> [  367.804178]  [<ffffffff802324f9>] try_to_wake_up+0x168/0x17a
> >> [  367.804186]  [<ffffffff8023250b>] default_wake_function+0x0/0x9
> >> [  367.804196]  [<ffffffff80323438>] delay_tsc+0x0/0xc8
> >> [  367.804204]  [<ffffffff8022c48d>] dequeue_entity+0xf/0x102
> >> [  367.804211]  [<ffffffff803a12a4>] e1000_acquire_swflag_ich8lan+0x35/0xcc
> >> [  367.804219]  [<ffffffff803a5c0b>] e1000e_read_phy_reg_bm+0x39/0xbe
> >> [  367.804227]  [<ffffffff803a5ee7>] e1000e_phy_has_link_generic+0x50/0xcc
> >> [  367.804234]  [<ffffffff8022c48d>] dequeue_entity+0xf/0x102
> >> [  367.804242]  [<ffffffff803ad593>] e1000_watchdog_task+0x0/0x6ef
> >> [  367.804249]  [<ffffffff803a4d25>] e1000e_check_for_copper_link+0x24/0x86
> >> [  367.804257]  [<ffffffff8023f05e>] lock_timer_base+0x26/0x4b
> >> [  367.804265]  [<ffffffff803aa186>] e1000_has_link+0x40/0xc1
> >> [  367.804272]  [<ffffffff803ad5ca>] e1000_watchdog_task+0x37/0x6ef
> >> [  367.804280]  [<ffffffff803ad593>] e1000_watchdog_task+0x0/0x6ef
> >> [  367.804289]  [<ffffffff80245058>] run_workqueue+0x87/0x122
> >> [  367.804296]  [<ffffffff802451cb>] worker_thread+0xd8/0xe7
> >> [  367.804304]  [<ffffffff802487a8>] autoremove_wake_function+0x0/0x2e
> >> [  367.804311]  [<ffffffff802450f3>] worker_thread+0x0/0xe7
> >> [  367.804318]  [<ffffffff802450f3>] worker_thread+0x0/0xe7
> >> [  367.804324]  [<ffffffff8024848f>] kthread+0x47/0x73
> >> [  367.804332]  [<ffffffff8020c6aa>] child_rip+0xa/0x20
> >> [  367.804338]  [<ffffffff80248448>] kthread+0x0/0x73
> >> [  367.804344]  [<ffffffff8020c6a0>] child_rip+0x0/0x20
> >> [  367.804349] ---[ end trace 608ec83548aefe5d ]---
> >>
> >> Should I be concerned?
> >>
> >
> > I don't think so.  It looks like it's just some developer debug code:
> >
> >        if (!mutex_trylock(&nvm_mutex)) {
> >                WARN(1, KERN_ERR "e1000e mutex contention. Owned by process "
> >                     "%s (pid %d), required by process %s (pid %d)\n",
> >                     nvm_owner_name, nvm_owner_pid,
> >                     current->comm, current->pid);
> >
> >                mutex_lock(&nvm_mutex);
> >        }
> >
> > guys, is this actually indicative of a bug?  An unexpected state?
> >
> > If not, I'd suggest that this code simply be removed, or downgraded
> > into a developer-only debug thing.  We don't want the kernel to be
> > spewing scary things at people.
> >
> > --
> >
> 
> A message from Dave Graham <david.graham@...el.com>...
> 
> The message identifies a condition that rarely occurs, and that I'd
> like to monitor for a few more weeks. While this WARN occurred
> fequently until recent 2.6.28 kernels, the messages have already
> helped us to tighten our code to reduce contentious access to this
> path, and so we now longer expect many. In fact at this time we only
> have one (this one) report, out of a total 1,296 WARNs shown at
> www.kerneloops.org for all 2.6.29-rc builds. There's been a minor
> improvement to the WARN message tagged as tag v2.6.29-rc1-6-geefacf3,
> and I'd like to collect & analyze a few reports that include that
> change.
> 
> I'll monitor reports up at keneloops daily, and when I've got 5 or
> more, I can quickly move the WARN to debug-only code, so reports will
> soon stop. Does that sound OK?

OK, thanks, sounds good to me.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html