netdev - Re: 2.6.27.18: bnx2/tg3: BUG: "scheduling while atomic" trying to ifenslave a second interface to my bond

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]

Message-Id: <1239820785.8944.604.camel@psmith-ubeta.netezza.com>
Date:	Wed, 15 Apr 2009 14:39:45 -0400
From:	Paul Smith <paul@...-scientist.net>
To:	Netdev <netdev@...r.kernel.org>
Subject: Re: 2.6.27.18: bnx2/tg3: BUG: "scheduling while atomic" trying to
	ifenslave a second interface to my bond

On Wed, 2009-04-15 at 11:11 -0700, Jay Vosburgh wrote:
>         The various MAC manipulating functions are either called under
> RTNL (as bond_alb_set_mac_address is) or take pains to acquire RTNL
> before doing anything with the MAC.  Also, the slave list and
> curr_active_slave are mutexed by RTNL, so those inspections should be
> safe.
> 
>         I'm reasonably sure that the curr_slave_lock is superfluous
> (which wasn't the case when it was originally introduced), but I
> haven't had a chance to validate this.  The locking has changed from
> what's documented in the header file; RTNL wasn't used for this when
> that was written.

OK, sounds good.  I'll let you know if I observe any other odd behavior
with the bonding driver.

Thanks for the great support!  Cheers!

-- 
Paul Smith <paul@...-scientist.net>

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