i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b)

[Hugh Dickins]

On Sat, 17 Mar 2012, Linus Torvalds wrote:
> On Sat, Mar 17, 2012 at 3:09 PM, Hugh Dickins <hughd at google.com> wrote:
> >
> > I've got to go out for an hour: I'll digest more and think more about
> > this when I get back.  If someone could explain the original problem
> > with _MOVABLE, that would help me:
> 
> I do not believe we actually ever uncovered the original problem with
> _MOVABLE: the problem was bisected down to the stable-backported
> version of commit 4bdadb978569 ("drm/i915: Selectively enable
> self-reclaim"), and I looked at the changes and decided that one of
> the main ones was the removal of the mapping_set_gfp_mask() - which
> resulted in __GFP_MOVABLE being on for the mapping.
> 
> So we just tried re-introducing that, and it fixed the problem.
> 
> Exactly *why* movable pages are a problem was never all that clear.
> ...

Thanks a lot for your considered and detailed reply on this
(before we added Rafael).

I've come to the (not entirely firm) conclusion that the addition and
removal of __GFP_MOVABLE was just shifting the shmem object allocations
from one block of memory (shared with others not using __GFP_MOVABLE)
to another (shared with others using __GFP_MOVABLE) and back.

So when the __GFP_MOVABLE inadvertently went in, a new group of users
who hadn't noticed the corruption before, now reported it; and when you
removed the __GFP_MOVABLE (a good idea anyway, pinned pages just clogging
up an otherwise movable block of memory), that group of users found their
problem solved.

Not really a problem from i915 specifying __GFP_MOVABLE on shmem objects.

Hugh