netdev - Re: [ofa-general] [PATCH] IB/IPoIB: Fix change mtu when switching to UD mode

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

Message-ID: <20080701134229.GC14384@mtls03>
Date:	Tue, 1 Jul 2008 16:42:29 +0300
From:	Eli Cohen <eli@....mellanox.co.il>
To:	Or Gerlitz <ogerlitz@...taire.com>
Cc:	Roland Dreier <rdreier@...co.com>,
	general-list <general@...ts.openfabrics.org>,
	netdev@...r.kernel.org
Subject: Re: [ofa-general] [PATCH] IB/IPoIB: Fix change mtu when switching
	to UD mode

On Tue, Jul 01, 2008 at 03:01:53PM +0300, Or Gerlitz wrote:
> The calls to dev_set_mtu from the bonding driver are from the device 
> .set_mtu function and this means that the caller have taken the appropriate 
> locking needed (set mtu is done on the master which in turn does it on the 
> slaves). Recently, I worked on some change to bonding and throughout this 
> work I learned on the need (must) to call the rtnl locking when invoking a 
> dev_set_x function who further does call_netdevice_notifiers(), see
>
> "the correct locking context for the notifier calls (which is RTNL and 
> nothing else)"
>
> comment from the bonding maintainer in 
> http://marc.info/?l=linux-netdev&m=121201324611292&w=2
>

I see, though I would expect to see a comment stating this requirement
both at the documentation of call_netdevice_notifiers() and that of
dev_set_mtu() and any other exported functions that requires this kind
of locking.
Moreover, in this specific case, it appears that it is not required to
take the rtlnl lock -- if it would be a must, I would have experienced
a dump_stack() due to

ASSERT_RTNL();

in bond_alb_handle_active_change().


The fact that I did not hit such an assert does not mean I may avoid
taking the rtnl lock but it appears to me that the issue is not well
undrestood.
--
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