On Wed, Jul 08, 2015 at 12:06:53PM +0800, Mark yao wrote: > On 2015年07月07日 20:04, Daniel Vetter wrote: > >On Tue, Jul 07, 2015 at 05:03:36PM +0800, Daniel Kurtz wrote: > >>Rather than (incompletely [0]) re-implementing drm_gem_mmap() and > >>drm_gem_mmap_obj() helpers, call them directly from the rockchip mmap > >>routines. > >> > >>Once the core functions return successfully, the rockchip mmap routines > >>can still use dma_mmap_attrs() to simply mmap the entire buffer. > >> > >>[0] Previously, we were performing the mmap() without first taking a > >>reference on the underlying gem buffer. This could leak ptes if the gem > >>object is destroyed while userspace is still holding the mapping. > >> > >>Signed-off-by: Daniel Kurtz <djkurtz@xxxxxxxxxxxx> > >>Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > >>Cc: stable@xxxxxxxxxxxxxxx > >Applied to topic/drm-fixes to make sure it won't get lost, but I expect > >rockchip maintainers to pick this one up. > >-Daniel > I try to pick this patch up, but found it conflicts with patch [0]. Can you > fix it? > > [0]https://patchwork.kernel.org/patch/6226591/ Imo this should be the other way round since Daniel's patch fixes a fairly serious issue: Apply this fix first, rebase&queue the polish for -next. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
