From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1DDF2C433ED for ; Tue, 18 May 2021 06:46:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A1C7D60FE7 for ; Tue, 18 May 2021 06:46:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A1C7D60FE7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 038B78E000F; Tue, 18 May 2021 02:46:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F2C2C8E000C; Tue, 18 May 2021 02:46:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E1AE78E000F; Tue, 18 May 2021 02:46:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0190.hostedemail.com [216.40.44.190]) by kanga.kvack.org (Postfix) with ESMTP id B3C7B8E000C for ; Tue, 18 May 2021 02:46:54 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 53CC29887 for ; Tue, 18 May 2021 06:46:54 +0000 (UTC) X-FDA: 78153419148.13.AA6886C Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf12.hostedemail.com (Postfix) with ESMTP id 2BF2BDD for ; Tue, 18 May 2021 06:46:48 +0000 (UTC) IronPort-SDR: RKU+aua8fflVg7RezTep3f7fhGmRI6gKU7IxacI3dlorAlRXPgt0wo5aMjmptI2VJBdAdT6ygw kmNRC3LClRGg== X-IronPort-AV: E=McAfee;i="6200,9189,9987"; a="200695311" X-IronPort-AV: E=Sophos;i="5.82,309,1613462400"; d="scan'208";a="200695311" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2021 23:46:49 -0700 IronPort-SDR: 7AjQz0vdBoc7zosy1+hwE4iToElxnCsfAZ1jqv5LaJhE/OmnEFNuOVwFSp+guyMvNCchRnsLWX 1noGlrxZc34Q== X-IronPort-AV: E=Sophos;i="5.82,309,1613462400"; d="scan'208";a="630331526" Received: from cmutgix-mobl.gar.corp.intel.com (HELO [10.249.254.195]) ([10.249.254.195]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2021 23:46:46 -0700 Subject: Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m?= To: Christoph Hellwig , Serge Belyshev Cc: Peter Zijlstra , Daniel Vetter , intel-gfx@lists.freedesktop.org, Chris Wilson , linux-mm@kvack.org, dri-devel@lists.freedesktop.org, Andrew Morton References: <20210326055505.1424432-1-hch@lst.de> <20210326055505.1424432-5-hch@lst.de> <87pmxqiry6.fsf@depni.sinp.msu.ru> <20210517123716.GD15150@lst.de> <87lf8dik15.fsf@depni.sinp.msu.ru> <20210517131137.GA19451@lst.de> <976fb38a-7780-6ca6-d602-a5f02c0938c9@linux.intel.com> Message-ID: <6adf9658-25b7-16ef-4b88-fa3911d06b74@linux.intel.com> Date: Tue, 18 May 2021 08:46:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <976fb38a-7780-6ca6-d602-a5f02c0938c9@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none); spf=none (imf12.hostedemail.com: domain of thomas.hellstrom@linux.intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=thomas.hellstrom@linux.intel.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 2BF2BDD X-Stat-Signature: h33ojcsuk36qya3x3ihyaoyrpdwxi73a X-HE-Tag: 1621320408-103129 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 5/17/21 11:46 PM, Thomas Hellstr=C3=B6m wrote: > > On 5/17/21 3:11 PM, Christoph Hellwig wrote: >> On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote: >>> Christoph Hellwig writes: >>> >>>> As an ad-hoc experiment:=C2=A0 can you replace the call to remap_pfn= _range >>>> with remap_pfn_range_notrack (and export it if you build i915 modula= r) >>>> in remap_io_sg and see if that makes any difference? >>> That worked, thanks -- no artifacts seen. >> Looks like it is caused by the validation failure then.=C2=A0 Which me= ans the >> existing code is doing something wrong in its choice of the page >> protection bit.=C2=A0 I really need help from the i915 maintainers her= e.. > > Hmm, > > Apart from the caching aliasing Mattew brought up, doesn't the=20 > remap_pfn_range_xxx() family require the mmap_sem held in write mode=20 > since it modifies the vma structure? remap_io_sg() is called from the=20 > fault handler with the mmap_sem held in read mode only. > > /Thomas And worse, if we prefault a user-space buffer object map using=20 remap_io_sg() and then zap some ptes using madvise(), the next time=20 those ptes are accessed, we'd trigger a new call to remap_io_sg() which=20 would now find already populated ptes. While the old code looks to just=20 silently overwrite those, it looks like the new code would BUG in=20 remap_pte_range()? /Thomas > >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx