netdev - Re: 2.6.27-rc1-git4 BUG: sched while atomic

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1217859640.6746.2.camel@HP1>
Date:	Mon, 04 Aug 2008 07:20:40 -0700
From:	"Michael Chan" <mchan@...adcom.com>
To:	"Stephen Hemminger" <shemminger@...tta.com>
cc:	"Randy Dunlap" <randy.dunlap@...cle.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: 2.6.27-rc1-git4 BUG: sched while atomic


On Mon, 2008-08-04 at 10:17 -0700, Stephen Hemminger wrote:
> > In 2.6.27-rc1-git4, I now see this (39 times):
> >
> > BUG: scheduling while atomic: ifconfig/16971/0x00000100
> > Modules linked in: parport_pc lp parport tg3 lpfc cciss ehci_hcd
> ohci_hcd uhci_hcd
> > Pid: 16971, comm: ifconfig Not tainted 2.6.27-rc1-git4 #1
> >
> > Call Trace:
> >  [<ffffffff80283db9>] ? page_add_new_anon_rmap+0x20/0x22
> >  [<ffffffff802310e9>] __schedule_bug+0x62/0x66
> >  [<ffffffff80551146>] schedule+0x99/0x759
> >  [<ffffffff8023dc9f>] ? __mod_timer+0xc1/0xd3
> >  [<ffffffff8055584a>] ? do_page_fault+0x473/0x7dd
> >  [<ffffffff80551ce4>] schedule_timeout+0x8d/0xb4
> >  [<ffffffff8023d99e>] ? process_timeout+0x0/0xb
> >  [<ffffffff80551cdf>] ? schedule_timeout+0x88/0xb4
> >  [<ffffffff80551d24>] schedule_timeout_uninterruptible+0x19/0x1b
> >  [<ffffffff8023dcc5>] msleep+0x14/0x1e
> >  [<ffffffff80375f2f>] pci_set_power_state+0x1cd/0x292
> >  [<ffffffff803739fc>] ? pci_bus_write_config_dword+0x64/0x73
> >  [<ffffffffa00651b6>] tg3_set_power_state+0x58/0x884 [tg3]
> >  [<ffffffff80552525>] ? __mutex_lock_slowpath+0x1d8/0x1e5
> >  [<ffffffffa006b57a>] tg3_open+0x46/0x6cc [tg3]
> >  [<ffffffff80552525>] ? __mutex_lock_slowpath+0x1d8/0x1e5
> >  [<ffffffff804bdcfe>] dev_open+0x73/0xa8
> >  [<ffffffff804bbf5e>] dev_change_flags+0xab/0x167
> >  [<ffffffff804f7094>] devinet_ioctl+0x269/0x5da
> >  [<ffffffff8026d9da>] ? unlock_page+0x2d/0x32
> >  [<ffffffff804f7ca8>] inet_ioctl+0x92/0xaa
> >  [<ffffffff804b2046>] sock_ioctl+0x1d1/0x1fb
> >  [<ffffffff802a50aa>] vfs_ioctl+0x2a/0x77
> >  [<ffffffff802a534c>] do_vfs_ioctl+0x255/0x272
> >  [<ffffffff8055584a>] ? do_page_fault+0x473/0x7dd
> >  [<ffffffff802a53ab>] sys_ioctl+0x42/0x67
> >  [<ffffffff8020beeb>] system_call_fastpath+0x16/0x1b
> 
> This is a bug.
> 

This was introduced by:

tg3: adapt tg3 to use reworked PCI PM code

Adapt the tg3 driver to use the reworked PCI PM and make it use the
exported PCI PM core functions instead of accessing the PCI PM registers
directly by itself.

Signed-off-by: Rafael J. Wysocki <rjw@...k.pl>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: David S. Miller <davem@...emloft.net>

In the original tg3 code, we used udelay() when switching to D0 state
since we were inside tg3_full_lock().


--
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