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]

Message-ID: <20190715150402.GD15202@mellanox.com>
Date:   Mon, 15 Jul 2019 15:04:06 +0000
From:   Jason Gunthorpe <jgg@...lanox.com>
To:     Daniel Vetter <daniel.vetter@...ll.ch>
CC:     Dave Airlie <airlied@...il.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        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

On Mon, Jul 15, 2019 at 04:19:26PM +0200, Daniel Vetter wrote:

> > Linus, do you have any advice on how best to handle sharing mm
> > patches? The hmm.git was mildly painful as it sits between quilt on
> > the -mm side and what seems like 'a world of interesting git things'
> > on the DRM side (but maybe I just don't know enough about DRM).
> 
> I think the approach in this merge window worked fairly well:
> - refactor/rework core mm stuff in (h)mm.git
> - handle all the gpu stuff in drm.git
> - make the clashes workable through some clever prep patches like
>   we've done this time around

Okay, as long as we agree.

I think part of the challenge with hmm.git was setting some
expectation for managing conflicts - there is some happy middle ground
between none & scary we need to navigate to make this work.

> I think Linus wants to be able to look through core mm stuff quite
> closely, so not a good idea if we deeply intertwin it with one of the
> biggest subsystems there is.

There is definately a bunch of stuff that is under the mm/ directory
but is not quite 'core mm' - it would be good if we could rely on
mailing list review of that part and use a topic workflow to manage
things. This was/is more or less my plan with hmm.git

Otherwise yes, as much as reasonable we should avoid topic merges
between the trees.

However, I again see conflict risk coming this cycle ..

>  And I don't think there will be a real conflict like this every
> merge window, this should be the exception.  Worst case we have to
> stage some work 1 release cycle apart, i.e.  merge mm stuff first,
> then drm 3 months later. 

I really dislike this idea. Not being able to provide users for core
APIs is a huge process/review problem. Worse it tends to create a
'ladder' where in-flight changes to drivers (to implement the new
core) now block any changes to the core APIs on alternating cycles. So
'the big pitcture' starts to fall a part if we can't co-ordinate cross
tree changes in some way.

.. and honestly, splitting a review process across a 9 week gap is one
of the best ways I've seen to get a poor quality review :(

I'm pretty familiar with this problem, we had it in spades between RDMA
and netdev for a long time, and it is finally fully resolved now
through a careful use of topic branches and merges.

For example, next week I'll queue CH's patches that shift the last
batch of hmm 'conflict management' shims into nouveau, and tries to
fix them:

  https://patchwork.kernel.org/project/linux-mm/list/?series=141835

This is something uncontroversial that really should go into the DRM
world as a topic so it doesn't interfere with ongoing nouveau dev. But
I want to keep the hmm.c/.h bits in the hmm.git to avoid conflicts.

So, I'll put it on a topic and send you two a note next week to decide
if you want to merge it or not. I'm really unclear how nouveau's and
AMD's patchflow works..

Thanks.
Jason