public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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