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]
Message-ID: <20171222215500.qygjml645spdwrxm@sasha-lappy>
Date:   Fri, 22 Dec 2017 21:55:03 +0000
From:   alexander.levin@...izon.com
To:     Michal Hocko <mhocko@...nel.org>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Shakeel Butt <shakeelb@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to
 kmemcg

On Fri, Dec 22, 2017 at 07:22:32PM +0100, Michal Hocko wrote:
>On Fri 22-12-17 18:07:23, Sasha Levin wrote:
>> I don't try and override maintainers, I mostly try to get fixes out
>> of subsystems where maintainers/authors partially (or just don't)
>> mark their commits for stable.
>
>Well, I have see quite some MM patches and I believe we are quite good
>at marking patches for stable trees... I also think we we (as the whole
>kernel) are much better are using Fixes tag (although it is over used
>sometimes).

Indeed, mm/ is probably as good as it gets in the kernel.

>Moreover it makes more sense to push on those maintainers than try to
>substitude them without being so closely familiar with the subsystem. If
>missing backports result in bug reports then this just increase the
>pressure on those maintainers /me think.

Both is happening, but it's difficult to force maintainers into doing
anything, as you might have guessed...

I'm hoping that one result of this work is a tool we can stick into
scripts/ (maybe glue it to checkpatch) that'll alert when the patch
is -stable material and suggest adding tags.

>> These patches also go through a much longer review process than
>> commits that are marked for stable (there are at least 3 emails issued
>> for each such commit, and at least 1 week (usually much more) is
>> given for reviews).
>
>Does any of the maintainers read those emails? How many acks/reviewes do
>you get for those patches for the stable tree? To be honest I tend to

I get a fair amount of reviews which seems to be slightly above what
-stable tagged patches get, which is good.

Acks are not expected, and are not happening too often.

>ignore those patchbombs most of the time because it is simply impossible
>to handle them for me. I try to help backporting obvious fixes but
>reviewing seemingly randomly selected patch which applies and changelog
>looks reasonaly is simply out of my time budget. Not to mention that
>this is not just about the patch itself but also the tree it is applied
>to and other patches that are in the same pile.

I'd hope that these patches aren't "random" :)

For some background, this is based on Julia Lawall's work (and paper
https://soarsmu.github.io/papers/icse12-patch.pdf).

-- 

Thanks,
Sasha

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ