[LTP] [PATCH] hugetlbfs: fix hugetlb page migration/fault race causing SIGBUS

[Sasha Levin]

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@kernel.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@vger.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