From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerome Glisse Subject: Re: i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b) Date: Mon, 19 Mar 2012 12:16:35 -0400 Message-ID: <1332173795.2986.2.camel@localhost.localdomain> References: <864ntoduba.fsf@sumi.keithp.com> <86ehsrcav1.fsf@sumi.keithp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-yx0-f177.google.com (mail-yx0-f177.google.com [209.85.213.177]) by gabe.freedesktop.org (Postfix) with ESMTP id 4CBBB9E7D2 for ; Mon, 19 Mar 2012 09:16:41 -0700 (PDT) Received: by yenm10 with SMTP id m10so6328106yen.36 for ; Mon, 19 Mar 2012 09:16:40 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Linus Torvalds Cc: Hugh@freedesktop.org, Dickins , Al Viro , DRI List-Id: dri-devel@lists.freedesktop.org On Sat, 2012-03-17 at 14:14 -0700, Linus Torvalds wrote: > On Sat, Mar 17, 2012 at 1:23 PM, Dave Airlie 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? It's not an issue for ttm, as we never us page allocated through shmem for the hw. We use shmem to swapout buffer object (ttm_tt_swapout func in ttm_tt.c). Cheers, Jerome