From: Michael Halcrow <mhalcrow@us.ibm.com>
To: Miklos Szeredi <mszeredi@suse.cz>
Cc: Willy Tarreau <w@1wt.eu>,
stable@kernel.org, linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>
Subject: Re: Missing patch from stable [3/7]
Date: Mon, 9 Jun 2008 13:37:49 -0500 [thread overview]
Message-ID: <20080609183749.GD6836@halcrowt61p.ibm.com> (raw)
In-Reply-To: <1212923462.4020.224.camel@tucsk>
On Sun, Jun 08, 2008 at 01:11:02PM +0200, Miklos Szeredi wrote:
> On Sun, 2008-06-08 at 10:59 +0200, Willy Tarreau wrote:
> Thanks for picking up these ecryptfs patches ...but they hardly meet
> _any_ of the -stable rules. In particular:
>
> - It must be obviously correct and tested.
>
> It's obvious, but I don't know if it's been tested (or even looked
> at by the maintainer).
I see no obvious problems with these patches. I have tested with the
four eCryptfs patches in this thread applied to 2.6.25.5.
> - It must fix a problem that causes a build error (but not for
> things marked CONFIG_BROKEN), an oops, a hang, data corruption, a
> real security issue, or some "oh, that's not good" issue. In
> short, something critical.
>
> Not critical at all.
I am under the impression that bugs that could result in hangs or data
corruption are, by definition, critical.
> - No "theoretical race condition" issues, unless an explanation of
> how the race can be exploited is also provided.
>
> It's theoretical, I have no idea how it's exploitable, if at all.
Exploits can be subtle, so I would be more comfortable with
eliminating known race conditions.
While I agree that "EXPERIMENTAL" features should be less likely to
receive updates in -stable, the experimental status of a feature
should not categorically exclude fixes from getting in. The
experimental status should just be one of the factors used in deciding
whether it is worth the effort.
Mike
> > --
> >
> > From 8dc4e37362a5dc910d704d52ac6542bfd49ddc2f Mon Sep 17 00:00:00 2001
> > From: Miklos Szeredi <mszeredi@suse.cz>
> > Date: Mon, 12 May 2008 14:02:04 -0700
> > Subject: ecryptfs: clean up (un)lock_parent
> >
> > dget(dentry->d_parent) --> dget_parent(dentry)
> >
> > unlock_parent() is racy and unnecessary. Replace single caller with
> > unlock_dir().
> >
> > There are several other suspect uses of ->d_parent in ecryptfs...
> >
> > Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
> > Cc: Michael Halcrow <mhalcrow@us.ibm.com>
> > Cc: Christoph Hellwig <hch@infradead.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > ---
> > fs/ecryptfs/inode.c | 13 ++++---------
> > 1 files changed, 4 insertions(+), 9 deletions(-)
> >
> > diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
> > index 0a13973..c92cc1c 100644
> > --- a/fs/ecryptfs/inode.c
> > +++ b/fs/ecryptfs/inode.c
> > @@ -37,17 +37,11 @@ static struct dentry *lock_parent(struct dentry *dentry)
> > {
> > struct dentry *dir;
> >
> > - dir = dget(dentry->d_parent);
> > + dir = dget_parent(dentry);
> > mutex_lock_nested(&(dir->d_inode->i_mutex), I_MUTEX_PARENT);
> > return dir;
> > }
> >
> > -static void unlock_parent(struct dentry *dentry)
> > -{
> > - mutex_unlock(&(dentry->d_parent->d_inode->i_mutex));
> > - dput(dentry->d_parent);
> > -}
> > -
> > static void unlock_dir(struct dentry *dir)
> > {
> > mutex_unlock(&dir->d_inode->i_mutex);
> > @@ -426,8 +420,9 @@ static int ecryptfs_unlink(struct inode *dir, struct dentry *dentry)
> > int rc = 0;
> > struct dentry *lower_dentry = ecryptfs_dentry_to_lower(dentry);
> > struct inode *lower_dir_inode = ecryptfs_inode_to_lower(dir);
> > + struct dentry *lower_dir_dentry;
> >
> > - lock_parent(lower_dentry);
> > + lower_dir_dentry = lock_parent(lower_dentry);
> > rc = vfs_unlink(lower_dir_inode, lower_dentry);
> > if (rc) {
> > printk(KERN_ERR "Error in vfs_unlink; rc = [%d]\n", rc);
> > @@ -439,7 +434,7 @@ static int ecryptfs_unlink(struct inode *dir, struct dentry *dentry)
> > dentry->d_inode->i_ctime = dir->i_ctime;
> > d_drop(dentry);
> > out_unlock:
> > - unlock_parent(lower_dentry);
> > + unlock_dir(lower_dir_dentry);
> > return rc;
> > }
> >
>
prev parent reply other threads:[~2008-06-09 18:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-08 8:59 Missing patch from stable [3/7] Willy Tarreau
2008-06-08 11:11 ` Miklos Szeredi
2008-06-08 12:29 ` Willy Tarreau
2008-06-08 14:50 ` Miklos Szeredi
2008-06-08 14:53 ` Willy Tarreau
2008-06-09 17:12 ` [stable] " Chris Wright
2008-06-09 18:56 ` Miklos Szeredi
2008-06-09 18:37 ` Michael Halcrow [this message]
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=20080609183749.GD6836@halcrowt61p.ibm.com \
--to=mhalcrow@us.ibm.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mszeredi@suse.cz \
--cc=stable@kernel.org \
--cc=w@1wt.eu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.