linux-kernel - Re: [Bluez-devel] Oops involving RFCOMM and sysfs

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: <478042F3.7010002@gmail.com>
Date:	Sun, 06 Jan 2008 11:54:43 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Al Viro <viro@...IV.linux.org.uk>
CC:	Gabor Gombas <gombasg@...aki.hu>,
	Dave Young <hidave.darkstar@...il.com>,
	linux-kernel@...r.kernel.org, bluez-devel@...ts.sf.net,
	Greg KH <greg@...ah.com>, ebiederm@...ssion.com
Subject: Re: [Bluez-devel] Oops involving RFCOMM and sysfs

Hello, Al Viro.

Al Viro wrote:
> On Sun, Jan 06, 2008 at 11:07:52AM +0900, Tejun Heo wrote:
> 
>> Right, I haven't thought about that.  When sysfs_get_dentry() is called,
>> @sd is always valid so unless there was existing negative dentry, lookup
>> is guaranteed to return positive dentry, but by populating dcache with
>> negative dentry before a node is created, things can go wrong.  I don't
>> think that's what's going on here tho.  If that was the case, the
>> while() loop looking up the next sd to lookup (@cur) should have blown
>> up as negative dentry will have NULL d_fsdata which doesn't match any sd.
> 
> No.  What happens if sd gets unlinked while we are on the way to
> sysfs_get_dentry() and so does its parent?

That means sysfs_remove_dir() is called on parent while other operations
are in progress on children, right?  sysfs has never allowed such things
&& AFAIK no one does that.  It's somewhat implied in the interface (such
as recursive removing) but I fully agree it's problematic.  Things like
these are why I think we need to unify/simplify locking as I wrote
previously.

> The parent is off the
> sibling list, we get negative dentry from lookup.  It's not hashed,
> so won't stick around in dcache (which is apparently what you are
> thinking about).  However, _THIS_ lookup has returned you a dentry
> with NULL ->d_inode and you are well and truly buggered.

So, the assumption is that while @sd is held and being operated on its
ancestry can never change except for rename and move and those are
protected with sysfs_rename_mutex.

I agree that the locking is awkward but sysfs's internal implementation
has completely changed over last six or so months and the conversion
still isn't complete.  It isn't pretty at all but is at least
understandable now, IMHO.  :-)

The last pending change is separating out kobject from sysfs and
simplifying locking.  I had some disagreement with Greg about the future
of kobject and then there was tsunami of ATA bugs because most major
distros converted to libata from IDE in the second half of the last year
and I'm still buried under it.  I'll get back to sysfs once these ATA
bugs subside a bit.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/