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]

Message-Id: <1257266647.3420.105.camel@localhost.localdomain>
Date:	Wed, 04 Nov 2009 01:44:07 +0900
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	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

Hi Linus,

> > I do have a patch in my inbox from Johannes from 4 days ago that fixes
> > this issue.
> > 
> > 	http://marc.info/?l=linux-wireless&m=125697124819563&w=2
> > 
> > So what is the take away from this now? Do you wanna have Johannes step
> > over John and Dave and send such a patch directly to you?
> 
> Hell yes. If it causes lockups for people, and the original commit is 
> _known_ to be buggy, these kinds of things should be expedited.
> 
> How much users time and effort do we want to waste?
> 
> And there's a secondary issue too - how comfortable do we want people to 
> be to test late-in-the-game -git trees? I should hope that they should be 
> considered pretty stable. And ask yourself: would it have been better to 
> have had this bug in my -git tree for just one day, or for five days?
> 
> Of course, the optimal situation would have been that such a buggy commit 
> wouldn't have been ever merged in the first place - at least not after 
> -rc5. But notice how I'm not really complaining about that part: I'm a 
> firm believer in the "bugs happen" reality, and while we should try to be 
> careful, things like this _will_ slip through. 
> 
> So I'm not unhappy about the bug happening in the first place. It would 
> have been better had it not, but hey, mistakes happen. We should just 
> "Deal with it". 
> 
> And yes, "dealing with it" very much means by-passing maintainers if 
> necessary. It can mean sending patches directly to me, but it _also_ means 
> asking me to just revert a commit that turns out to be buggy and was 
> merged late.
> 
> And that's what I'm really arguing for here - I don't like how you and 
> Johannes were arguing against "dealing with it". As it was, we clearly had 
> users wasting their time on this.

that is a clear statement and I am perfectly fine with this.

However to be fair here, this one didn't hit everybody. I for myself
haven't seen it at all and actually I have been running this "faulty"
kernel for a while now and suspending happily multiple times a day. As
much as you hate that the patch for this bug took longer than needed to
find its way into your tree, the immediate need and the wide problem was
not clear. So there will be always cases where at the time of writing
the patch, the sensible thing to do is following the normal merge path
and the patch will end up in your tree multiple days later. It is not
optimal, but it happens.

And for the record, I think that a quick bug report to linux-wireless
would have been as effective and a request for a revert. But that is my
pure personal opinion here.

Regards

Marcel


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