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: <20130712201939.GB15261@redhat.com>
Date:	Fri, 12 Jul 2013 16:19:39 -0400
From:	Dave Jones <davej@...hat.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	"Theodore Ts'o" <tytso@....edu>,
	Guenter Roeck <linux@...ck-us.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	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

On Fri, Jul 12, 2013 at 03:49:11PM -0400, Steven Rostedt wrote:
 > On Fri, 2013-07-12 at 15:35 -0400, Theodore Ts'o wrote:
 > 
 > > 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.
 > 
 > Actually, this is a very good point. There were one or two stable
 > patches I had pushed to linux-next that I wasn't too comfortable about.
 > If the fix goes back to older trees, I rather have them stirring in
 > linux-next and push it in the next merge window instead of pushing it to
 > Linus and have it go to stable immediately.
 > 
 > Unless its a obvious fix, I tend to take about a month from the time I
 > get a stable fix to the time I push it out. Making sure the stable fix
 > doesn't introduce new bugs.

Like most of the other examples in this thread, one size doesn't fit all though.

Your example above: If that fix was for "tracing reports wrong results", no big deal,
everyone can live with it for a month. If it was fixing "a bug in tracing can allow
an unprivileged user to crash the kernel", a month is unacceptable, and at
the least we should be getting an interim fix to mitigate the problem.

	Dave

--
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/