linux-kernel - Re: [ath9k-devel] [ 00/78] 3.3.2-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] [day] [month] [year] [list]

Message-ID: <20120417052401.GB5522@1wt.eu>
Date:	Tue, 17 Apr 2012 07:24:01 +0200
From:	Willy Tarreau <w@....eu>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	"ath9k-devel@...ts.ath9k.org" <ath9k-devel@...ema.h4ckr.net>,
	linux-wireless Mailing List <linux-wireless@...r.kernel.org>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	"John W. Linville" <linville@...driver.com>,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk
Subject: Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

On Tue, Apr 17, 2012 at 12:44:25AM +0300, Felipe Contreras wrote:
> >> Perhaps the current process will be continue to be OK, but I do
> >> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
> >
> > How exactly would that have helped here?
> 
> More people would have given it a try. Not that many people read the
> mailing list, and the ones that do certainly might want to avoid
> applying a big series of patches; even if their mail client makes it
> easy (mine (Gmail) doesn't). A tag, and an announcement to give a try
> would make it *much* easier.

That's totally unrelated. A tag means that these changes would have been
committed (with history etc...). This would not have changed anything of
the running/broken code. It would have failed similarly without any way
for you to revert. The rc1 was announced and was available on kernel.org.
A tag would not have changed anything here, except by making the release
process much more complex by basically having to revert every unsuitable
patch instead of dropping it. It would mean that rc1 would in fact have
been 3.3.1 and that 3.3.1 would have been 3.3.2. You just shift the release
by one number and don't bring any value here.

> >> I used to compile my own kernels and use your stable tree, but this a
> >> new laptop and I was using Arch Linux which automatically updated to
> >> v3.3.1, and with no network I had no way to revert to v3.2.x.
> >> Fortunately I had the kernel sources available, but I wonder how many
> >> people were completely stuck.
> >
> > Arch wouldn't have included a -rc in their kernel (unless they are
> > crazy), so this would not have helped your situation at all.
> 
> There's *a lot* of people that got affected by the 3.3.1 release; we
> don't need to break a lot of boxes to figure out there's an issue,
> only a few would suffice, even one.

I'm sorry, but I don't buy this. There are *always* regressions caused by
kernel updates, and even the beginners I know are used to keep a working
kernel on their systems precisely because they know they can be left with
something which does not boot anymore. So if you upgrade your *only* kernel
without keeping a safe one, it's not a mistake, it's a fault, your fault. A
beginner wouldn't have done this. You wouldn't have recovered from a hanging
boot, a panic or a SATA timeout either. Drivers issues are the worst ones
because nobody can exhaustively test them all, not even your distro vendor.
The solution is always to keep a working kernel as an alternate boot.

> >> If some other 3.x.1 release get broken this way, I would seriously
> >> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.
> >
> > "this way" was for a very tiny subset of hardware, so odds are, if this
> > happens again, it wouldn't be caught this way either.  That subset just
> > happened to show up in your machine, but, for example, not in the wide
> > range of hardware I test with here, nor the machines that others test
> > with.
> 
> It was certainly not just me. I have seen a lot of people mentioning
> "their wifi is broken", a lot of them using Arch Linux,
> coincidentally.

Maybe because these are people you know and you taught to blindly update
without keep a safe boot option ?

Now it becomes a lot clearer that you want a user fault to be covered by
a development process. That will never ever work because the only way it
will solve your behavioral issue is to release 100% safe and 100% compatible
kernels each time, which by definition is not possible if anything changes.

Willy

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