linux-kernel - Re: Please consider reverting 7d930bc33653d5592dc386a76a38f39c2e962344

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]

Date:	Tue, 3 Nov 2009 09:37:00 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Luis R. Rodriguez" <mcgrof@...il.com>
cc:	Ingo Molnar <mingo@...e.hu>, Marcel Holtmann <marcel@...tmann.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	David Miller <davem@...emloft.net>, johannes@...solutions.net,
	linville@...driver.com, linux-kernel@...r.kernel.org,
	linux-wireless@...r.kernel.org
Subject: Re: Please consider reverting
 7d930bc33653d5592dc386a76a38f39c2e962344

On Tue, 3 Nov 2009, Luis R. Rodriguez wrote:
> 
> How this sort of issue is dealt with is subjective and it is up to
> maintainers to deal with.

Not when they then complain when others hit the same issue several days 
later.

> Having more information on the patch and better communication about
> the issue it solved, and the issues that reverting it would have
> caused would certainly have helped maintainers make a better call at a
> regression caused by it but knowing Johannes he'd probably cook up a
> followup fix ASAP and that is exactly what he did.

He may have cooked it up, but he didn't send it to me, and he didn't even 
bother to post it as a response to people who complained about the same 
commit.

The fact that people on the wireless mailing lists may have known about 
this just makes things _worse_, I think. It shows that we really _need_ to 
go around maintainers, when not going around them seems to result in days 
of delays and total waste of time for everybody.

Btw, the reason it's likely not getting a lot of reports is not because 
people aren't hitting it, but that the symptom when you _do_ hit it tends 
to be a dead machine. If you were running X, you have no idea what 
happened. This is why "I have one NULL pointer dereference report" should 
mean "The fix needs to go upstream _now_".

(And no, as far as I can tell, it needs no suspend/resume cycle at all. I 
don't know the code very well, but as far as I can tell it just needs a 
wireless deauthentication, which easily happens if you're running 
something like NetworkManager and your wireless network may be noisy or 
weak).

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