Re: [B.A.T.M.A.N.] net, batman: lockdep circular dependency warning

Antonio Quartulli
2012-12-05T21:03:13Z

[-- Attachment #1: Type: text/plain, Size: 2835 bytes --]

Hi all,

On Wed, Dec 05, 2012 at 04:33:08PM +0100, Simon Wunderlich wrote:
> Hey Sven,
> >
> > 1. Remove the sysfs interface to attach/detach net_devices (which
> > destroys/creates batman-adv devices)
> >
> > This is not really backward compatible and therefore not really acceptable.
> > Marek Lindner and Simon Wunderlich are also against forcing users to
> > require special tools to add/configure batman-adv devices (even batctl, ip
> > and so on).
> >
>
> Yeah, at least I think we should keep what we have for now and fix it before
> moving to the next interface. It has its merits I would like to keep, having
> text output is one of them. :)

I agree on this. Not because of the nice text output, but rather because it is
better to first fix this deadlock in the current interface (which might mean
fixing old stable releases) and when we include the new feature.

[...]

> > 5. Add a workaround solution and promote the use of the standard interface
> >
> > So, the basic problem is the s_active mutex locked by the sysfs interface.
> > An idea is to postpone the part which needs the rtnl_mutex to a later time.
> > This has obviously the problem that we cannot return an error code to the
> > caller when the device creation failed in the postponed part. This problem
> > can reduced slightly be moving only the unregister part, but now I'll leave
> > this out for simplicity of the description.
>
> We probably won't need the return code anyway - usually it should never fail,
> and if it does we don't handle it now too.
>
> >
> > A possible implementation would create a work_struct and add it to
> > batadv_event_workqueue. This work item has to contain all information given
> > by the user (which hardif, name of the batman-adv device).
>
> Sounds good.
>
> >
> > Simon Wunderlich already disliked this workaround, but Antonio Quartulli
> > tried to encourage an RFC implementation. I've prefered a textual
> > description rather than a patch missing explanations of the other
> > alternatives.
>
> Well, actually that doesn't sound so bad - I currently don't have an overview
> of how "big" this change would be - this one was one concern, the return code was
> another but it appears that this isn't a problem. If we don't add too much bloat
> this one would probably the best alternative. At least as long as rtnl_unlock()
> behaves like this. :)
>
> What do others think?
>

I like this approach too.
It looks clean and it doesn't affect the rest of the net code.
I think we should put some effort in this and try to come up with a patch soon.

Thank you for your comments.

Cheers,

--
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]