netdev - Re: [Bugme-new] [Bug 16257] New: sysfs changes break hwsim and bnep drivers

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]

Message-ID: <m1wrt56hgk.fsf@fess.ebiederm.org>
Date:	Thu, 08 Jul 2010 09:55:55 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Greg KH <gregkh@...e.de>
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

Greg KH <gregkh@...e.de> writes:

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

It is a problem with the normal kernel configuration.  In that case
we have a single network namespace.  

> 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?

The problem is that when we remove symlinks we look at the target of
the symlink to see which tag to remove it in it's parent directory.
Because the target of the symlink was not in a class directory because
of that crazy class on class stacking exception in get_device_parent
we fail to find the symlink when we attempt to remove it.

My one line patch to get_device_parent really does fix this.  I have
just sent you a patch to prevent the creation of these crazy symlinks
in sysfs, which at least clearly isolates this to a handful of drivers.

> 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?

Nope, it isn't as simple as disabling network namespaces.

For the mac80211_hwsim we can just remove the device parent, and all will
be well for the moment.

For the bnep code we could also not set the parent but I don't know if
that would have undesirable complications for power management or not.
I don't have a bluetooth attached network device so I don't even know how
to test that code.

My preferred fix is the one liner I set you to get_device_parent.  It
is no worse than the magic device_is_not_partition checks then we
already have in sysfs.  Especially when it is a bug that
get_device_parent does that early return in the first place.  To fix
this we will have to introduce the missing subdirectory one way or
another.

With SYSFS_DEPRECATED enabled I don't believe this problem can actually
happen, as all network devices are placed immediately under
/sys/class/net/ in sysfs.

Eric
--
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