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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
