linux-kernel - Re: DRM pull for v5.3-rc1

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]

Date:   Mon, 15 Jul 2019 11:16:11 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jason Gunthorpe <jgg@...lanox.com>
Cc:     Dave Airlie <airlied@...il.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jerome Glisse <jglisse@...hat.com>,
        Thomas Hellstrom <thellstrom@...are.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: DRM pull for v5.3-rc1

[ Ugh, I have three different threads about the drm pull because of
the subject / html confusion. So now I'm replying in separate threads
and I'm hoping the people involved have better threading than gmail
does ;/ ]

On Mon, Jul 15, 2019 at 5:29 AM Jason Gunthorpe <jgg@...lanox.com> wrote:
>
> The 'hmm' tree is something I ran to try and help workflow issues like
> this, as it could be merged to DRM as a topic branch - maybe consider
> this flow in future?
>
> Linus, do you have any advice on how best to handle sharing mm
> patches?

I don't have a lot of advice except for "very very carefully".

I think the hmm tree worked really well this merge window, at least
from my standpoint.

But it is of course possible that my happiness about the hmm tree is a
complete fluke and came about because pretty much all the patches were
removing oddities and cleaning things up, and they weren't adding new
odd things (or if they were, you hid it better ;^).

Basically, people should know that there are some subsystems that I
end up being *much* more worried about than others. If I see a pull
request that modifies core VM of VFS code, I tend to go into "careful
mode", in ways that I don't do when some maintainer sends me a pull
request that obviously only changes some subtree that the maintainer
owns.

When driver maintainers send me patches that touch their drivers, I
look at the diffstat.

But when driver maintainers send me patches that change mm/, I look at
individual commit messages and the actual diff itself, and if I see
contentious stuff, I simply won't pull.

It's why I left the hmm pull request (which came in early - thank you)
until yesterday, simply because just from the diffstat I could tell
that "ok, this merge isn't just me merging and doing sanity checks,
this is me having to set aside time to do reviews". So just from the
diffstat, I avoided even looking at it while I still had a mailbox
full of other pull requests.

So I do like seeing core mm changes come in through a separate branch.
That's partly because that way it's easier to review without having
the parts I care about be mixed up with other parts (it's one reason I
asked the security layer pulls to be split up, to pick another area
entirely as an example). But it's also partly because if you have a
separate branch for the stuff that you know is contentious, that
doesn't then hold up the parts that _aren't_.

For example, right now I'm not pulling _any_ of the drm updates,
simply because there's a part of it that I can't stomach.  It would
have been so much nicer if the contentious things that need a lot of
care separate, and I could have at least pulled the other stuff.

                  Linus