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:	Wed, 5 Dec 2012 22:03:13 +0100
From:	Antonio Quartulli <ordex@...istici.org>
To:	The list for a Better Approach To Mobile Ad-hoc
	 Networking <b.a.t.m.a.n@...ts.open-mesh.org>
Cc:	netdev@...r.kernel.org, Sasha Levin <sasha.levin@...cle.com>
Subject: Re: [B.A.T.M.A.N.] net, batman: lockdep circular dependency warning

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

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ