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 16:19:26 +0200
From:   Daniel Vetter <daniel.vetter@...ll.ch>
To:     Jason Gunthorpe <jgg@...lanox.com>
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 2:29 PM Jason Gunthorpe <jgg@...lanox.com> wrote:
>
> [urk, html email.. forgive the mess]
>
> On Mon, Jul 15, 2019 at 04:59:39PM +1000, Dave Airlie wrote:
>
> >      VMware had some mm helpers go in via my tree (looking back I'm
> >      not sure Thomas really secured enough acks on these, but I'm
>
> I saw those patches, honestly I couldn't entirely understand what
> problem they were trying to address..
>
> >      going with it for now until I get push back). They conflicted
> >      with one of the mm cleanups in the hmm tree, I've pushed a
> >      patch to the top of my next to fix most of the fallout in my
> >      tree, and the resulting fixup is to pick the closure->ptefn
> >      hunk and apply something like in mm/memory.c
>
> Did I mess a notification from StephenR in linux-next? I was unwaware
> of this conflict?
>
> 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? 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

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. 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. Usually that's not
going to slow things down noticeable given average merge latency for
core mm features :-)
-Daniel

> > @@ -2201,7 +2162,7 @@ static int apply_to_page_range_wrapper(pte_t
> >      *pte,
> >              struct page_range_apply *pra =
> >                      container_of(pter, typeof(*pra), pter);
> >      -       return pra->fn(pte, NULL, addr, pra->data);
> >      +       return pra->fn(pte, addr, pra->data);
> >       }
>
> I looked through this and it looks OK to me, thanks
>
> Jason



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch