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

[Linus Torvalds]

On Sat, Mar 17, 2012 at 1:23 PM, Dave Airlie <airlied at gmail.com> wrote:
>
> I did however get a flashback in google to this:
>
> http://lists.fedoraproject.org/pipermail/scm-commits/2010-July/456636.html
>
> Linus don't think we ever did work out why that worked, I wonder if we
> lost something after that.

Hmm. Maybe we should stop making the default gfp_mask be
GFP_HIGHMEM_MOVABLE (see inode_init_always() in fs/inode.c), and
instead add the _MOVABLE flag only for mappings that use
"generic_file_mmap()".

It does sound a bit scary to just make default mappings use MOVABLE
pages, when we know that can be incorrect for some cases.

But that would require that filesystems like ext4 etc that don't just
use the generic_file_mmap() function would have add do that MOVABLE
thing on their own. And the *normal* case is certainly that pages are
movable and putting them in themovable zone should be ok. It's just
*not* ok if you also map them into some hardware GTT thing or just
otherwise keep track of the pages directly, like DRI does.

The other possibility is to just make this a shm thing, since it's
generally that layer that has the case of "pages allocated with the
mapping gfp masks". Hugh Dickins clearly tried to make sure that the
DRM initialization of the gfp mask was honored, but maybe there is
some case where it is missed. Hugh added a mapping_set_gfp_mask() to
i915_gem_alloc_object(), but maybe we have i915 shmem mappings that
get set up through some other path.

What about the ttm swap storage thing, for example? That also does
shmem_file_setup(), without limiting the pages. But I don't think i915
uses ttm, right?

Al? Hugh? Opinions? Right now anybody who uses the
shmem_read_mapping_page() function is in danger of getting a MOVABLE
page by default. Which may or may not be right.

That said, I don't see how i915 would get a movable page. It *seems*
to do the right setup for the gfp flags of the mapping.

                     Linus