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] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 21 Jun 2010 20:56:31 -0700
From:	Greg KH <gregkh@...e.de>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	Kay Sievers <kay.sievers@...y.org>,
	Johannes Berg <johannes@...solutions.net>,
	Greg KH <greg@...ah.com>, netdev <netdev@...r.kernel.org>
Subject: Re: [Bugme-new] [Bug 16257] New: sysfs changes break hwsim and
 bnep drivers

On Mon, Jun 21, 2010 at 05:05:21PM -0700, Eric W. Biederman wrote:
> Greg KH <gregkh@...e.de> writes:
> 
> > On Mon, Jun 21, 2010 at 03:55:35PM -0700, Eric W. Biederman wrote:
> >> Greg KH <gregkh@...e.de> writes:
> >> 
> >> > I _really_ do not like this patch.
> >> >
> >> > The correct thing is to fix the modules that are affected, and that's
> >> > only the wireless testing module, right?  Or is there something else?
> >> >
> >> > And if that code is properly converted to a bus, what needs to change in
> >> > the driver core?
> >> 
> >> The usb bnep driver.
> >
> > Odd, what is bnep doing differently here from all other network drivers?
> > Is it trying to stack the bluetooth class in the middle somehow?
> > Shouldn't this be easy to fix up in the driver itself?
> 
> The cause of all of the failures is a class device with a class device
> parent, instead of a bus device parent.  Which causes the net/ directory 
> not to be created for us to put the network devices under.
> 
> I don't have a clue about how that driver works, and I don't know how many
> other drivers that do something strange like this are out there lurking.
> 
> I have not been involved previously in any changes from class device to
> bus device so I don't have a clue how difficult it would.  All I know
> is that with the mac80211_hwsim driver we had first had two people who
> really knew what they were doing and it was hard enough there still
> isn't a working conversion away from class devices.

But what caused the breakage here?

Does this only show up if you enable network namespaces?  Or is it a
problem with the "normal" kernel configuration of no network namespaces?

The only thing that changed here was your network namespace work, what
caused this problem to show up?  Was it bisectable down to a single
patch?

Classes on top of classes should never have originally worked, I guess
we just let them slide by accident, and we can go and fix them up as
they are found.  But for now, for .35, it would be good to find the root
cause of the problem here.  It might be as simple as putting a
CONFIG_BROKEN on network namespaces until we get this working, right?

thanks,

greg k-h
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ