netdev - Re: WARN_ON() hit in fsl bitbanged phy driver

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:	Mon, 11 Feb 2008 16:26:01 -0600
From:	Scott Wood <scottwood@...escale.com>
To:	Rune Torgersen <runet@...ovsys.com>
CC:	linuxppc-dev@...abs.org, netdev@...r.kernel.org
Subject: Re: WARN_ON() hit in fsl bitbanged phy driver

Rune Torgersen wrote:
> Scott Wood wrote:
>> Rune Torgersen wrote:
>>> I hit the following WARN_ON when using mii-tools agains a ethernet
>>> interface using a bit-banged mii interface
>> It looks like the kernel thinks it's in an interrupt, even though it
>> clearly isn't from the backtrace.  Presumably, something
>> slept from an
>> interrupt handler; try turning on sleep-in-spinlock debugging.
> 
> I turned on sleep-in-spinlock and it did not reveal anything. I'm trying
> some other debug options.
> 
>> The root cause was probably something other than the phy code.
> I'm not so sure, because it only happens when I run mii-tool agains the
> interface useing the bit-banged driver, and then only the first time.

OK, it seems I should have checked 2.6.24 instead of head-of-tree; 
softirq.c:139 is a different assertion than I thought.  It's not 
in_irq(), but irqs_disabled().  fs_ioctl() is disabling interrupts, and 
spin_unlock_bh() doesn't like that.  The current use of mutexes likes it 
even less.  The locking should be moved inside the phy bus 
implementation, if it's needed at all.

It only happens once because it's a WARN_ON_ONCE(). :-)

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