Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2712093ybe; Thu, 12 Sep 2019 13:44:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqxN0DkX5ZVXt6JovJRA9uJGOCuBu6W1HDmJcEI1M+Sb1I6gAn2X6ETzvw5dcrzCEC2dyzRc X-Received: by 2002:a17:906:7cc7:: with SMTP id h7mr14344014ejp.204.1568321077551; Thu, 12 Sep 2019 13:44:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568321077; cv=none; d=google.com; s=arc-20160816; b=VtvQ7K6Auwgte78Hl8FBvd1B+3WUYJ7vd070bIcJOSIZB4obimEDkHMa4eIF0DGyCU ADfliCCe7qBQ1pGs/nbUfiE96Fib6bICpGoqzEQRreOrRTLiUEwv5AWTzCwUxxYeHPh5 QN1wys5ir+WCbtRB7ifan1l19q0ZhMskvJhRHUYVwHE/vAlBe73DR2X7MtGaPyd05XlK wAf6iWAfF4WIK9Aa1kkjbGsC2No/D1+oKYylyIWpNyJySx7vlJ/2DbB8C7m2EnKXPRyo vRBG5ZAGxxr0fHSm8JezAbJ0GWJ1bvIGM/XIRuHYanW833co5jo/CIhU8IX+9v2Y5SU4 UTsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=gvyMb01pfDEbPWoGLKH1/rE2VZFgMe8r1GYjRacTtRc=; b=ATGBEyNORziHVPhcuBauuBTraHVK6SRja0Xc6/P67430bWF8BeHOaIVjBZtyvH+uYa z4OV52ggkgsp4rBDCWbrQIAswJS/r45e/0YVVmV+np0pM4iNbc46eAtcLK78SspGmq1U SwD5TjyAJuOI+dquuOu5MrVugraCjVlZqBN1IPTNQA3bznRRDR3ViQo8to8RIL4MvUJ+ zaN/nkSCxyNl0OlVtKDv8LNerygsZZ9M6aBcTbrpiiv51WwKu3pUKSxNgwMQnW74C68c 3vXaSf2frQXOIsb8sutaL/okBYwSBqtlqU1LdbrJ3c7YjMvbNBEDce/3pMgu2qdxqFEt AEDA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b44si2387159ede.451.2019.09.12.13.43.49; Thu, 12 Sep 2019 13:44:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732697AbfILOj4 (ORCPT + 99 others); Thu, 12 Sep 2019 10:39:56 -0400 Received: from mga17.intel.com ([192.55.52.151]:64597 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732592AbfILOj4 (ORCPT ); Thu, 12 Sep 2019 10:39:56 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2019 07:39:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,497,1559545200"; d="scan'208";a="186146677" Received: from avrahamr-mobl1.ger.corp.intel.com (HELO [10.252.3.203]) ([10.252.3.203]) by fmsmga007.fm.intel.com with ESMTP; 12 Sep 2019 07:39:54 -0700 Subject: Re: [Intel-gfx] [PATCH] Revert "drm/i915/userptr: Acquire the page lock around set_page_dirty()" To: Chris Wilson , intel-gfx@lists.freedesktop.org, torvalds@linux-foundation.org Cc: tiwai@suse.de, linux-kernel@vger.kernel.org, leho@kraav.com, Jani Nikula , MKoutny@suse.com, stable@vger.kernel.org, Martin.Wilck@suse.com References: <20190912125634.29054-1-chris@chris-wilson.co.uk> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc Message-ID: Date: Thu, 12 Sep 2019 15:39:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190912125634.29054-1-chris@chris-wilson.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/09/2019 13:56, Chris Wilson wrote: > The userptr put_pages can be called from inside try_to_unmap, and so > enters with the page lock held on one of the object's backing pages. We > cannot take the page lock ourselves for fear of recursion. > > Reported-by: Lionel Landwerlin > Reported-by: Martin Wilck > Reported-by: Leo Kraav > Fixes: aa56a292ce62 ("drm/i915/userptr: Acquire the page lock around set_page_dirty()") > References: https://bugzilla.kernel.org/show_bug.cgi?id=203317 > Signed-off-by: Chris Wilson > Cc: Tvrtko Ursulin > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: stable@vger.kernel.org > --- > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 10 +--------- > 1 file changed, 1 insertion(+), 9 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c > index 74da35611d7c..11b231c187c5 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c > @@ -672,15 +672,7 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj, > > for_each_sgt_page(page, sgt_iter, pages) { > if (obj->mm.dirty) > - /* > - * As this may not be anonymous memory (e.g. shmem) > - * but exist on a real mapping, we have to lock > - * the page in order to dirty it -- holding > - * the page reference is not sufficient to > - * prevent the inode from being truncated. > - * Play safe and take the lock. > - */ > - set_page_dirty_lock(page); > + set_page_dirty(page); > > mark_page_accessed(page); > put_page(page); > Acked-by: Tvrtko Ursulin Regards, Tvrtko