| 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
| ||
|
Message-ID: <20120414094137.54a7f213@stein> Date: Sat, 14 Apr 2012 09:41:37 +0200 From: Stefan Richter <stefanr@...6.in-berlin.de> To: Felipe Contreras <felipe.contreras@...il.com> Cc: Adrian Chadd <adrian@...ebsd.org>, Greg KH <gregkh@...uxfoundation.org>, Sergio Correia <lists@...e.net>, linux-kernel@...r.kernel.org, stable@...r.kernel.org, torvalds@...ux-foundation.org, akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk, linux-wireless Mailing List <linux-wireless@...r.kernel.org>, Sujith Manoharan <c_manoha@....qualcomm.com>, "ath9k-devel@...ts.ath9k.org" <ath9k-devel@...ema.h4ckr.net>, "John W. Linville" <linville@...driver.com> Subject: Re: [ 00/78] 3.3.2-stable review On Apr 14 Felipe Contreras wrote: > I already exemplified how they are very different, but here it goes > again. The patch "drm/i915: Add lock on drm_helper_resume_force_mode" > was just tagged in 3.3.2, if I had said yesterday "this patch breaks > things on my machine", then that patch would have been dropped for > 3.3.2 even though it's still on mainline--why? Because we know it's > broken, and broken patches are not supposed to land to stable. But > today, one day later, we have to wait until it's fixed in master > first. Why? > > What makes a patch droppable yesterday, but dependent on mainline today? Huh? Because "yesterday" was a review before stable release: - A buggy mainline release exists. - No buggy stable release exists. whereas "today" is after stable release: - A buggy mainline release exists. - A buggy stable release exists. (The WLAN breakage wich is being talked about was reported after release, not during review, right?) [quote re-ordered] > Again, you can repeat the same thing as much as you want, it still > doesn't answer what I have asked. Yeah, sorry for that. All the time I thought you asked why a *revert* which is applicable to mainline and stable first happens in stable. But your question was actually what the difference between - dropping a patch from a queue of candidate patches versus - adding a reverting patch to repair a defect from a previous release is. The former is still part of the decision whether a changeset which exists in mainline should be backported into stable. Somebody initially thought it should be, but others should have a look too and amend that decision if need be. Somebody reports that the change would introduce a regression. Usually, this disqualifies a patch from being applied to stable right away, without further work having to be done in stable. "Drop a stable candidate before release" is a form of "decline a submission to stable", happening late in the preparations of a stable release. The latter is when damage was done; it is now about bug fixing. This involves debugging of the regression, finding a right approach to fix it (e.g. revert), write + review + test + commit the fix, port the fix to all relevant other kernel branches, review + test + commit those ports too. "Add a reverting fix" is a form of "add a fix". You are indeed pointing to a procedural flaw here. In "add a fix" cases, stable release procedures ensure that if 3.3.3 included the revert, 3.4 will include it to, by the Linus->Greg order of commiting patches. But in the "drop a candidate before release" case, Greg and the stable reviewers do not have a similarly fool-proof procedure to ensure that the next branch point will be free of the regression. Now they need to watch closely that a fix gets into mainline ideally before the next branch point is going to be released. So there is indeed a difficulty involved with dropping patches from the candidate queue. Fortunately, it is not necessary to subject post-release reverts to the same difficulty. > This of course, has *not* been explained. Others had discussed "not adding a changeset" versus "amending an already released changeset by another changeset on top of it" already. Now I did too and apologize to everybody else for redundancy. -- Stefan Richter -=====-===-- -=-- -===- http://arcgraph.de/sr/ -- 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/
Powered by blists - more mailing lists