linux-kernel - Re: [ 00/19] 3.10.1-stable review

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-ID: <20130712193557.GB342@thunk.org>
Date:	Fri, 12 Jul 2013 15:35:57 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dave Jones <davej@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	stable <stable@...r.kernel.org>
Subject: Re: [ 00/19] 3.10.1-stable review

The unwritten criteria that I've seen used (and sometimes even
discussed on mailing lists) is that if it's something that distro
kernel maintainers would want, then it's fit for stable.  Now, there's
a grey area here.  The criteria before distro's "golden master" has
been released is quite different compared to a criteria for a Service
Pack 5 kernel.  There's also a hjuge difference between a patch which
has just hit mainline during the merge window, and a bug fix which has
been in Linus's tree for weeks or months.  It's likely that a bug fix
which has been in the kernel since 3.8, even if it is not "critical"
is one which might be suitable merging for 3.4.  Heck, I've even had
users screaming at me that it was somehow my duty as the ext4
maintainer to find these commits and backport them to 3.4 or 3.2.  (Of
course, I blow them off.  :-)

So the problem is that maintainers are lazy.  They don't want to go
back for bug fixes that have "proven" themselves, and even if they
aren't critical bug fixes, they are things which a distro maintainer
or a stable kernel user might want (and sometimes stable uers are
uppity enough to expect subsystem maintainers to do this back
porting).  So subsystem maintainers then react by marking submits for
stable even though they really should soak for a release or two before
submitting them, since by marking them as submit, the commit gets
pushed to stable automatically --- albeit early.

Now, I'm not condoning this practice; but I suspect this is at least
partially the reason why some maintainers have gotten more aggressive
about marking patches for stable and not pushing them to mainline earlier.

If it really is the case that patches that are marked for -stable are
patches that should just be sent to linus pre-rc4, and patches that
had just been added to the subsystem maintainer tree a few weeks
before the merge window shouldn't be automatically be merged into
stable, maybe the right answer is that the stable kernel maintainers
shouldn't be automatically including _any_ patches that are marked for
stable which are sent to mainline during the merge window.

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