[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <39b59001-55c1-a98b-75df-3a5dcec74504@suse.cz>
Date: Mon, 12 Aug 2019 15:14:12 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Michal Hocko <mhocko@...nel.org>, Sasha Levin <sashal@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Mike Kravetz <mike.kravetz@...cle.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, ltp@...ts.linux.it,
Li Wang <liwang@...hat.com>,
Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
Cyril Hrubis <chrubis@...e.cz>, xishi.qiuxishi@...baba-inc.com
Subject: Re: [PATCH] hugetlbfs: fix hugetlb page migration/fault race causing
SIGBUS
On 8/12/19 10:45 AM, Michal Hocko wrote:
> On Sun 11-08-19 19:46:14, Sasha Levin wrote:
>> On Fri, Aug 09, 2019 at 03:17:18PM -0700, Andrew Morton wrote:
>>> On Fri, 9 Aug 2019 08:46:33 +0200 Michal Hocko <mhocko@...nel.org> wrote:
>>>
>>> It should work if we ask stable trees maintainers not to backport
>>> such patches.
>>>
>>> Sasha, please don't backport patches which are marked Fixes-no-stable:
>>> and which lack a cc:stable tag.
>>
>> I'll add it to my filter, thank you!
>
> I would really prefer to stick with Fixes: tag and stable only picking
> up cc: stable patches. I really hate to see workarounds for sensible
> workflows (marking the Fixes) just because we are trying to hide
> something from stable maintainers. Seriously, if stable maintainers have
> a different idea about what should be backported, it is their call. They
> are the ones to deal with regressions and the backporting effort in
> those cases of disagreement.
+1 on not replacing Fixes: tag with some other name, as there might be
automation (not just at SUSE) relying on it.
As a compromise, we can use something else to convey the "maintainers
really don't recommend a stable backport", that Sasha can add to his filter.
Perhaps counter-intuitively, but it could even look like this:
Cc: stable@...r.kernel.org # not recommended at all by maintainer
Powered by blists - more mailing lists