Message-ID: <20190812153326.GB17747@sasha-vm>
Date:   Mon, 12 Aug 2019 11:33:26 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Vlastimil Babka <vbabka@...e.cz>,
        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 Mon, Aug 12, 2019 at 03:22:26PM +0200, Michal Hocko wrote:
>On Mon 12-08-19 15:14:12, Vlastimil Babka wrote:
>> 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
>
>I thought that absence of the Cc is the indication :P. Anyway, I really
>do not understand why should we bother, really. I have tried to explain
>that stable maintainers should follow Cc: stable because we bother to
>consider that part and we are quite good at not forgetting (Thanks
>Andrew for persistence). Sasha has told me that MM will be blacklisted
>from automagic selection procedure.

I'll add mm/ to the ignore list for AUTOSEL patches.

>I really do not know much more we can do and I really have strong doubts
>we should care at all. What is the worst that can happen? A potentially
>dangerous commit gets to the stable tree and that blows up? That is
>something that is something inherent when relying on AI and
>aplies-it-must-be-ok workflow.

The issue I see here is that there's no way to validate the patches that
go in mm/. I'd happily run whatever test suite you use to validate these
patches, but it doesn't exist.

I can run xfstests for fs/, I can run blktests for block/, I can run
kselftests for quite a few other subsystems in the kernel. What can I
run for mm?

I'd be happy to run whatever validation/regression suite for mm/ you
would suggest.

I've heard the "every patch is a snowflake" story quite a few times, and
I understand that most mm/ patches are complex, but we agree that
manually testing every patch isn't scalable, right? Even for patches
that mm/ tags for stable, are they actually tested on every stable tree?
How is it different from the "aplies-it-must-be-ok workflow"?

--
Thanks,
Sasha

Powered by blists - more mailing lists