lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 15 Jul 2013 08:40:42 +1000
From:	Benjamin Herrenschmidt <>
To:	Greg Kroah-Hartman <>
Cc:	Josh Boyer <>, Ingo Molnar <>,
	Linus Torvalds <>,
	Steven Rostedt <>,
	Guenter Roeck <>,
	Dave Jones <>,
	Linux Kernel Mailing List <>,
	Andrew Morton <>,
	stable <>
Subject: Re: [ 00/19] 3.10.1-stable review

On Fri, 2013-07-12 at 10:05 -0700, Greg Kroah-Hartman wrote:
> Specific example is, again, the powerpc patches.  Out of 21 patches
> marked for stable that showed up in the -rc1 merge, at least 7 of them
> had _plenty_ of time to get into 3.10.0 as they are weeks, and sometimes
> months, old.  Some of the other ones seem _very_ new, being only days
> old before they hit Linus's tree, which makes me worry about them for
> totally different reasons (i.e. not tested in linux-next at all.)

So for the old ones that's me not actively sending you stuff that has a
CC stable tag when I merge it. I should probably fix that indeed. This
is especially true of (but not exclusively) stuff that I don't apply
myself but merge via somebody else branch.

For the new stuff, this is a combinations of some last minute fuckups
which are pretty specific to 3.10 and for which I'm in part responsible,
and in part due to us basically ramping up testing on Power8 and getting
ready for the next RHEL & SLES at the same time, thus doing more testing

You'll notice that a lot of that stuff is P8 support so testing in
"next" isn't going to help much since nobody outside of IBM has access
to these guys yet. We are getting the stuff out there due to distro
unrealistic expectations of having upstream code for new machines years
before a release.

Also keep in mind that sometimes, that stuff has been around on
patchwork for a while and got tested by various people, but the patch
got a last minute rev of improved changeset comment or cosmetic polish.

> I can put a "delay" on patches to not hit a stable release for a few
> weeks until they get some testing in Linus's tree, but in reality,
> what's that going to help with?

Depends. In some of the patches I put in for stable, they fix something
that 3.10 broke and the fixes are quite self-contained, waiting makes no

At some stage I make a judgement call on a given patch, how "obvious"
the fix is (I know they never are completely ... well most of the time),
how invasive it is, what risk it represents outside of the are that it
"fixes". I do mistakes, but generally I am fairly conservative in that

> I guess I can just not apply them at all, tough-love and all that, but
> that just puts an extra burden on the distro kernel maintainers to have
> to go dig up the fixes for their users.

You know how the distro can be about that... especially when they invent
idiotic junk such as kABI which prevents you from fixing things properly
for the sake of [probably illegal] binary drivers, and so on... Distro
seem to enjoy establishing a process that guarantee that an "enterprise
release" is entirely comprise of utter junk (not even talking about all
the in-house untested broken stupid crap they add to their kernels while
at the same time being hard-ass with fixes coming from the vendors).

> Although really, who cares about powerpc anymore :)

That was unfair :-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists