From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A93EF43 for ; Fri, 7 Sep 2018 09:17:42 +0000 (UTC) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 26D4CA8 for ; Fri, 7 Sep 2018 09:17:42 +0000 (UTC) From: Jani Nikula To: Linus Torvalds , Jiri Kosina In-Reply-To: References: Date: Fri, 07 Sep 2018 12:17:13 +0300 Message-ID: <87tvn1y8di.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Cc: ksummit Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, 06 Sep 2018, Linus Torvalds wrote: > A lot of that was that the actual *fixes* were marked for stable, but > quite often they were preceded by cleanups and other updates that > didn't actually fix things directly, and that weren't in themselves > explicitly marked for stable and didn't have a Fixes: tag, because > they were prep-work. There's always the struggle of whether to put fixes or cleanups first in the series. The former makes backports easier, the latter makes the actual fixes easier. And the prep work could be committed quickly while the fixes are still being debated. > So we had _several_ nasty regressions in stable that never showed up > in mainline, because there was some non-obvious dependency that didn't > cause a merge conflict, but did cause a "this commit needed that other > commit to work right". > > We should probably at least think about having a way to mark those. > Something like a "for-stable-because-of-subsequent-patches" tag? If you know the commit ids of the dependencies, i.e. they've been applied, per Documentation/process/stable-kernel-rules.rst you could add: Cc: # 3.3.x: a1f84a3: sched: Check for idle Cc: # 3.3.x: 1b9508f: sched: Rate-limit newidle Cc: # 3.3.x: fd21073: sched: Fix affinity logic Cc: # 3.3.x listing the dependencies. I don't see that used much, though, so not sure defining something new could gain more traction. > Or just more eager use of the table cc? I often feel bad about adding > "cc: stable" to preparatory patches that don't actually fix the bug, > but I think it was bad this time around. If the fix with prep work is in a topic branch, one could add cc: stable to the merge commit. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center