From: Tejun Heo <htejun@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
Al Viro <viro@ZenIV.linux.org.uk>,
Gabor Gombas <gombasg@sztaki.hu>, Greg KH <greg@kroah.com>,
Dave Young <hidave.darkstar@gmail.com>,
bluez-devel@lists.sourceforge.net, cornelia.huck@de.ibm.com
Subject: Re: [PATCH 2.6.24-rc7 2/2] sysfs: fix bugs in sysfs_rename/move_dir()
Date: Wed, 16 Jan 2008 15:47:11 +0900 [thread overview]
Message-ID: <478DA86F.10905@gmail.com> (raw)
In-Reply-To: <alpine.LFD.1.00.0801151928380.2806@woody.linux-foundation.org>
Linus Torvalds wrote:
>
> On Wed, 16 Jan 2008, Tejun Heo wrote:
>> * sysfs_move_dir() has an extra dput() on success path.
>
> Are you sure? How did this ever work?
I'm pretty sure. I've seen dentry blowing up due to early release &&
compared it with older code. It was my mistake during restructuring
error path. The only user of sysfs_move_dir() was S390 Cornelia works
on (cc'd). Cornelia is usually very good at spotting and debugging
sysfs bugs. Dunno how it got slipped this time.
> Also, looking at this, I think the "how did this ever work" question is
> answered by "it didn't",
Before dput() bug was introduced, it worked although error handling path
was broken.
> but I also think there are still serious problems
> there. Look at
>
> again:
> mutex_lock(&old_parent->d_inode->i_mutex);
> if (!mutex_trylock(&new_parent->d_inode->i_mutex)) {
> mutex_unlock(&old_parent->d_inode->i_mutex);
> goto again;
> }
>
> and wonder what happen sif old_parent == new_parent. Is that trying to
> avoid an ABBA deadlock?
It will fall in infinite loop if old_parent == new_parent and for the
question, I suppose so. Cornelia, right?
> Normally you'd do it by ordering the locks, or by
> taking a third lock to guarantee serialization at a higher level (ie the
> "s_vfs_rename_mutex" on the VFS layer)
sysfs currently doesn't depend on VFS locking. VFS locking is done just
to keep VFS layer happy. sysfs_dirent hierarchy is protected by
sysfs_mutex and renaming/moving are protected by sysfs_rename_mutex. As
both ops are under rename_mutex, I think the above code just can grab
both mutexes in any order. It's probably a remnant of the days when
sysfs used VFS locking to protect internal structures.
s390 was the only user of the move interface till now and through all
the recent sysfs change, it didn't receive enough attention other than
Cornelia's testing. Eventually, I think sysfs_rename_dir() and
sysfs_move_dir() should be merged into sysfs_move() but for the current
two users, I don't see anything wrong with the locking.
Thanks.
--
tejun
next prev parent reply other threads:[~2008-01-16 6:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-16 3:06 [PATCH 2.6.24-rc7 1/2] sysfs: make sysfs_lookup() return ERR_PTR(-ENOENT) on failed lookup Tejun Heo
2008-01-16 3:10 ` [PATCH 2.6.24-rc7 2/2] sysfs: fix bugs in sysfs_rename/move_dir() Tejun Heo
2008-01-16 3:41 ` Linus Torvalds
2008-01-16 3:52 ` Al Viro
2008-01-16 7:23 ` Tejun Heo
2008-01-17 4:22 ` Al Viro
2008-01-16 6:47 ` Tejun Heo [this message]
2008-01-16 8:20 ` Cornelia Huck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=478DA86F.10905@gmail.com \
--to=htejun@gmail.com \
--cc=bluez-devel@lists.sourceforge.net \
--cc=cornelia.huck@de.ibm.com \
--cc=gombasg@sztaki.hu \
--cc=greg@kroah.com \
--cc=hidave.darkstar@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox