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  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 <>
To:     Jason Gunthorpe <>
Cc:     Dave Airlie <>,
        Linus Torvalds <>,
        dri-devel <>,
        LKML <>,
        Andrew Morton <>,
        Jerome Glisse <>,
        Thomas Hellstrom <>,
        Stephen Rothwell <>
Subject: Re: DRM pull for v5.3-rc1

On Mon, Jul 15, 2019 at 2:29 PM Jason Gunthorpe <> 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 :-)

> > @@ -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 -

Powered by blists - more mailing lists