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

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

[Eli Cohen]

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.

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

[Eli Cohen]

On Tue, Jul 01, 2008 at 04:42:29PM +0300, Eli Cohen wrote:
> 
> 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().

Or some other function registered for notifications.

> 
> 
> 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.
> _______________________________________________
> general mailing list
> general@lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general