From: Willy Tarreau <w@1wt.eu>
To: Miklos Szeredi <mszeredi@suse.cz>
Cc: stable@kernel.org, linux-kernel@vger.kernel.org,
Michael Halcrow <mhalcrow@us.ibm.com>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: Missing patch from stable [3/7]
Date: Sun, 8 Jun 2008 14:29:20 +0200 [thread overview]
Message-ID: <20080608122920.GA10491@1wt.eu> (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:
> > this patch from mainline seems suitable for -stable,
>
> Willy,
>
> 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).
well, some of them (eg: Cyrill's fix for missed mutex_unlock) are obviously
needed.
> - It cannot be bigger than 100 lines, with context.
>
> Check.
>
> - It must fix only one thing.
>
> No, it's a small fix as well as a cleanup.
>
> - It must fix a real bug that bothers people (not a, "This could be a
> problem..." type thing).
>
> No, it doesn't seem to bother anybody.
Generally speaking, everything which relates to locking is hard to diagnose.
I've been hit for years by locking bugs in the NFS client on old 2.4, and
they hit me at most once in a week.
> - 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.
OK
> - 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.
OK, but being exploitable is one thing, randomly failing is another one. If
you think it cannot cause trouble, then OK.
> - It cannot contain any "trivial" fixes in it (spelling changes,
> whitespace cleanups, etc).
>
> Check.
>
> - It must follow the Documentation/SubmittingPatches rules.
>
> Check.
>
> - It or an equivalent fix must already exist in Linus' tree. Quote the
> respective commit ID in Linus' tree in your patch submission to -stable.
>
> Check.
>
>
> Total: 4/9, not a very convincing score :)
Well, you know the implications of leaving these known bugs open more than
me. If you think some of them are really not needed, I'm fine with this,
but some definitely fix real bugs (judging by the code and the comments).
Thanks,
Willy
next prev parent reply other threads:[~2008-06-08 12:44 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 [this message]
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
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=20080608122920.GA10491@1wt.eu \
--to=w@1wt.eu \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhalcrow@us.ibm.com \
--cc=mszeredi@suse.cz \
--cc=stable@kernel.org \
/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