linux-kernel - Re: [ 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] [thread-next>] [day] [month] [year] [list]

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/