On Thu, Jan 15, 2015 at 01:55:52AM +0100, Daniel Vetter wrote: > On Wed, Jan 14, 2015 at 08:34:31PM +0000, Chris Wilson wrote: > > This (partially) reverts > > > > commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd > > Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Date: Tue Mar 25 13:23:06 2014 +0000 > > > > drm/i915: Invalidate our pages under memory pressure > > > > It appears given the right workload, that pages which are swapped out > > more than once are incorrectly invalidated and discarded. I had presumed > > that the swapin would mark the pages dirty again and so preserve them > > against the next cycle of invalidation - that appears to be false, and > > leads to memory corruption (even leak of stale pages to userspace). > > > > Reported-by: Sean V Kelley <sean.v.kelley@xxxxxxxxx> > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Sean V Kelley <sean.v.kelley@xxxxxxxxx> > > Cc: stable@xxxxxxxxxxxxxxx > > Hm, scary. Do we have a testcase for this (might need a correctness > version for some of the swap thrashing tests maybe). Right, based on my theory about how this screws up, a few passes through gem_tiled_swapping should be enough to hit the invalidate. fill_bo -> GTT write, obj->dirty = true -> shinker -> GTT unbind, obj->dirty = false -> check_bo -> GTT read, obj->dirty = false -> shrinker -> GTT unbind, invalidate without us calling page_set_dirty() i.e. a few loops of check_bo should be enough to cycle every object through swap a couple of times and for subsequent swapin/swapouts not to cause us to explicity mark the pages as dirty, thus prone to invalidate_mapping_range() actually removing unwanted pages. The error does not not show up with igt/gem_tiled_swapping. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html