[Intel-gfx] [PATCH 6/8] drm/i915: Pin the pages first in shmem prepare read/write
Chris Wilson
chris at chris-wilson.co.uk
Thu Jun 9 14:13:00 UTC 2016
On Thu, Jun 09, 2016 at 04:51:41PM +0300, Joonas Lahtinen wrote:
> On to, 2016-06-09 at 14:35 +0100, Chris Wilson wrote:
> > On Thu, Jun 09, 2016 at 04:06:59PM +0300, Joonas Lahtinen wrote:
> > >
> > > On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> > > >
> > > > There is an improbable, but not impossible, case that if we leave the
> > > > pages unpin as we operate on the object, then somebody may steal the
> > > > lock and change the cache domains after we have already inspected them.
> > > >
> > > Which lock exactly?
> > The shrinker steals struct_mutex from underneath us. The guard is
> > pinning pages around operating on the object.
>
> Wouldn't the race scenario I described then apply (between get_pages
> and pin_pages)?
Apart from direct reclaim has no opportunity to run between them. I have
sent patches in the path to change the api such that question cannot
even be raised (the only issue is a bit of ugliness where we abuse the
page pinning to workaround unknown memory layouts) but never pushed
hard. In my recent patches for using pages outside of the struct_mutex,
closing that window makes the api easier to hide the details of
acquiring the pages + pinning them.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list