On Sun, Jun 08, 2008 at 01:11:02PM +0200, Miklos Szeredi wrote:
quoted text
> 
> 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.

quoted text
>  - 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.

quoted text
>  - 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

quoted text
>  - 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.

quoted text
>  - 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

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