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=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=ham 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 51955C2D0B1 for ; Fri, 6 Dec 2019 08:08:15 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 316472466E for ; Fri, 6 Dec 2019 08:08:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 316472466E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8C0646E049; Fri, 6 Dec 2019 08:08:14 +0000 (UTC) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [46.235.227.227]) by gabe.freedesktop.org (Postfix) with ESMTPS id A62F16E049 for ; Fri, 6 Dec 2019 08:08:13 +0000 (UTC) Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 5D8992925B0; Fri, 6 Dec 2019 08:08:12 +0000 (GMT) Date: Fri, 6 Dec 2019 09:08:09 +0100 From: Boris Brezillon To: Rob Herring Subject: Re: [PATCH 2/8] drm/panfrost: Fix a race in panfrost_ioctl_madvise() Message-ID: <20191206090809.0832f4aa@collabora.com> In-Reply-To: <20191206085327.66a8c479@collabora.com> References: <20191129135908.2439529-1-boris.brezillon@collabora.com> <20191129135908.2439529-3-boris.brezillon@collabora.com> <20191129153310.2f9c80e1@collabora.com> <20191206085327.66a8c479@collabora.com> Organization: Collabora X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: stable , dri-devel , Alyssa Rosenzweig , Steven Price Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" T24gRnJpLCA2IERlYyAyMDE5IDA4OjUzOjI3ICswMTAwCkJvcmlzIEJyZXppbGxvbiA8Ym9yaXMu YnJlemlsbG9uQGNvbGxhYm9yYS5jb20+IHdyb3RlOgoKPiBPbiBUaHUsIDUgRGVjIDIwMTkgMTc6 MDg6MDIgLTA2MDAKPiBSb2IgSGVycmluZyA8cm9iaCtkdEBrZXJuZWwub3JnPiB3cm90ZToKPiAK PiA+IE9uIEZyaSwgTm92IDI5LCAyMDE5IGF0IDg6MzMgQU0gQm9yaXMgQnJlemlsbG9uCj4gPiA8 Ym9yaXMuYnJlemlsbG9uQGNvbGxhYm9yYS5jb20+IHdyb3RlOiAgCj4gPiA+Cj4gPiA+IE9uIEZy aSwgMjkgTm92IDIwMTkgMTQ6MjQ6NDggKzAwMDAKPiA+ID4gU3RldmVuIFByaWNlIDxzdGV2ZW4u cHJpY2VAYXJtLmNvbT4gd3JvdGU6Cj4gPiA+ICAgIAo+ID4gPiA+IE9uIDI5LzExLzIwMTkgMTM6 NTksIEJvcmlzIEJyZXppbGxvbiB3cm90ZTogICAgCj4gPiA+ID4gPiBJZiAyIHRocmVhZHMgY2hh bmdlIHRoZSBNQURWSVNFIHByb3BlcnR5IG9mIHRoZSBzYW1lIEJPIGluIHBhcmFsbGVsIHdlCj4g PiA+ID4gPiBtaWdodCBlbmQgdXAgd2l0aCBhbiBzaG1lbS0+bWFkdiB2YWx1ZSB0aGF0J3MgaW5j b25zaXN0ZW50IHdpdGggdGhlCj4gPiA+ID4gPiBwcmVzZW5jZSBvZiB0aGUgQk8gaW4gdGhlIHNo cmlua2VyIGxpc3QuICAgIAo+ID4gPiA+Cj4gPiA+ID4gSSdtIGEgYml0IHdvcnJpZWQgZnJvbSB0 aGUgcG9pbnQgb2YgdmlldyBvZiB1c2VyIHNwYWNlIHNhbml0eSB0aGF0IHlvdQo+ID4gPiA+IG9i c2VydmVkIHRoaXMgLSBidXQgY2xlYXJseSB0aGUga2VybmVsIHNob3VsZCBiZSByb2J1c3QhICAg IAo+ID4gPgo+ID4gPiBJdCdzIG5vdCBzb21ldGhpbmcgSSBvYnNlcnZlZCwganVzdCBmb3VuZCB0 aGUgcmFjZSBieSBpbnNwZWN0aW5nIHRoZQo+ID4gPiBjb2RlLCBhbmQgSSB0aG91Z2h0IGl0IHdh cyB3b3J0aCBmaXhpbmcgaXQuICAgIAo+ID4gCj4gPiBJJ20gbm90IHNvIHN1cmUgdGhlcmUncyBh IHJhY2UuICAKPiAKPiBJJ20gcHJldHR5IHN1cmUgdGhlcmUncyBvbmU6Cj4gCj4gVDAJCQkJVDEK PiAKPiBsb2NrKHBhZ2VzKQo+IG1hZHYgPSAxCj4gdW5sb2NrKHBhZ2VzKQo+IAo+IAkJCQlsb2Nr KHBhZ2VzKQo+IAkJCQltYWR2ID0gMAo+IAkJCQl1bmxvY2socGFnZXMpCj4gCj4gCQkJCWxvY2so c2hyaW5rZXIpCj4gCQkJCXJlbW92ZV9mcm9tX2xpc3QoYm8pCj4gCQkJCXVubG9jayhzaHJpbmtl cikKPiAKPiBsb2NrKHNocmlua2VyKQo+IGFkZF90b19saXN0KGJvKQo+IHVubG9jayhzaHJpbmtl cikKPiAKPiBZb3UgZW5kIHVwIHdpdGggbWFkdiA9IDAgYW5kIHRoZSBCTyBpcyBhZGRlZCB0byB0 aGUgbGlzdC4KPiAKPiA+IElmIHRoZXJlIGlzLCB3ZSBzdGlsbCBjaGVjayBtYWR2IHZhbHVlCj4g PiB3aGVuIHB1cmdpbmcsIHNvIGl0IHdvdWxkIGJlIGhhcm1sZXNzIGV2ZW4gaWYgdGhlIHN0YXRl IGlzCj4gPiBpbmNvbnNpc3RlbnQuICAKPiAKPiBJbmRlZWQuIE5vdGUgdGhhdCB5b3UgY291bGQg YWxzbyBoYXZlIHRoaXMgb3RoZXIgc2l0dWF0aW9uIHdoZXJlIHRoZSBCTwo+IGlzIG1hcmtlZCBw dXJnZWFibGUgYnV0IG5vdCBwcmVzZW50IGluIHRoZSBsaXN0LiBJbiB0aGF0IGNhc2UgaXQgd2ls bAo+IG5ldmVyIGJlIHB1cmdlZCwgYnV0IGl0J3Mga2luZGEgdXNlciBzcGFjZSBmYXVsdCBhbnl3 YXkuIEkgYWdyZWUsIG5vbmUKPiBvZiB0aGlzIHByb2JsZW1zIGFyZSBjcml0aWNhbCwgYW5kIEkn bSBmaW5lIGxlYXZpbmcgaXQgdW5maXhlZCBhcyBsb25nCj4gYXMgaXQncyBkb2N1bWVudGVkIHNv bWV3aGVyZSB0aGF0IHRoZSByYWNlIGV4aXN0IGFuZCBpcyBoYXJtbGVzcy4KPiAKPiA+ICAgCj4g PiA+ID4gPiBUaGUgZWFzaWVzdCBzb2x1dGlvbiB0byBmaXggdGhhdCBpcyB0byBwcm90ZWN0IHRo ZQo+ID4gPiA+ID4gZHJtX2dlbV9zaG1lbV9tYWR2aXNlKCkgY2FsbCB3aXRoIHRoZSBzaHJpbmtl ciBsb2NrLgo+ID4gPiA+ID4KPiA+ID4gPiA+IEZpeGVzOiAwMTNiNjUxMDEzMTUgKCJkcm0vcGFu ZnJvc3Q6IEFkZCBtYWR2aXNlIGFuZCBzaHJpbmtlciBzdXBwb3J0IikKPiA+ID4gPiA+IENjOiA8 c3RhYmxlQHZnZXIua2VybmVsLm9yZz4KPiA+ID4gPiA+IFNpZ25lZC1vZmYtYnk6IEJvcmlzIEJy ZXppbGxvbiA8Ym9yaXMuYnJlemlsbG9uQGNvbGxhYm9yYS5jb20+ICAgIAo+ID4gPiA+Cj4gPiA+ ID4gUmV2aWV3ZWQtYnk6IFN0ZXZlbiBQcmljZSA8c3RldmVuLnByaWNlQGFybS5jb20+ICAgIAo+ ID4gPgo+ID4gPiBUaGFua3MuCj4gPiA+ICAgIAo+ID4gPiA+ICAgIAo+ID4gPiA+ID4gLS0tCj4g PiA+ID4gPiAgZHJpdmVycy9ncHUvZHJtL3BhbmZyb3N0L3BhbmZyb3N0X2Rydi5jIHwgOSArKysr LS0tLS0KPiA+ID4gPiA+ICAxIGZpbGUgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCA1IGRlbGV0 aW9ucygtKQo+ID4gPiA+ID4KPiA+ID4gPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9kcm0v cGFuZnJvc3QvcGFuZnJvc3RfZHJ2LmMgYi9kcml2ZXJzL2dwdS9kcm0vcGFuZnJvc3QvcGFuZnJv c3RfZHJ2LmMKPiA+ID4gPiA+IGluZGV4IGYyMWJjOGE3ZWUzYS4uZWZjMGEyNGQxZjRjIDEwMDY0 NAo+ID4gPiA+ID4gLS0tIGEvZHJpdmVycy9ncHUvZHJtL3BhbmZyb3N0L3BhbmZyb3N0X2Rydi5j Cj4gPiA+ID4gPiArKysgYi9kcml2ZXJzL2dwdS9kcm0vcGFuZnJvc3QvcGFuZnJvc3RfZHJ2LmMK PiA+ID4gPiA+IEBAIC0zNDcsMjAgKzM0NywxOSBAQCBzdGF0aWMgaW50IHBhbmZyb3N0X2lvY3Rs X21hZHZpc2Uoc3RydWN0IGRybV9kZXZpY2UgKmRldiwgdm9pZCAqZGF0YSwKPiA+ID4gPiA+ICAg ICAgICAgICAgIHJldHVybiAtRU5PRU5UOwo+ID4gPiA+ID4gICAgIH0KPiA+ID4gPiA+Cj4gPiA+ ID4gPiArICAgbXV0ZXhfbG9jaygmcGZkZXYtPnNocmlua2VyX2xvY2spOwo+ID4gPiA+ID4gICAg IGFyZ3MtPnJldGFpbmVkID0gZHJtX2dlbV9zaG1lbV9tYWR2aXNlKGdlbV9vYmosIGFyZ3MtPm1h ZHYpOyAgICAKPiA+IAo+ID4gVGhpcyBtZWFucyB3ZSBub3cgaG9sZCB0aGUgc2hyaW5rZXJfbG9j ayB3aGlsZSB3ZSB0YWtlIHRoZSBwYWdlc19sb2NrLgo+ID4gSXMgbG9ja2RlcCBoYXBweSB3aXRo IHRoaXMgY2hhbmdlPyBJIHN1c3BlY3Qgbm90IGdpdmVuIGFsbCB0aGUgZnVuIEkKPiA+IGhhZCBn ZXR0aW5nIGxvY2tkZXAgaGFwcHkuICAKPiAKPiBJIGhhdmUgdGVzdGVkIHdpdGggbG9ja2RlcCBl bmFibGVkIGFuZCBpdCdzIGFsbCBnb29kIGZyb20gbG9ja2RlcCBQb1YKPiBiZWNhdXNlIHRoZSBs b2NrcyBhcmUgdGFrZW4gaW4gdGhlIHNhbWUgb3JkZXIgaW4gdGhlIG1hZHZpc2UoKSBhbmQKPiBz Y2hpbmtlcl9zY2FuKCkgcGF0aCAoZmlyc3QgdGhlIHNocmlua2VyIGxvY2ssIHRoZW4gdGhlIHBh Z2VzIGxvY2spLgo+IAo+IE5vdGUgdGhhdCBwYXRjaCA3IGludHJvZHVjZXMgYSBkZWFkbG9jayBp biB0aGUgc2hyaW5rZXIgcGF0aCwgYnV0IHRoaXMKPiBpcyB1bnJlbGF0ZWQgdG8gdGhpcyBzaHJp bmtlciBsb2NrIGJlaW5nIHRha2VuIGVhcmxpZXIgaW4gbWFkdmlzZQo+IChkcm1fZ2VtX3B1dF9w YWdlcygpIGlzIGNhbGxlZCB3aGlsZSB0aGUgcGFnZXMgbG9jayBpcyBhbHJlYWR5IGhlbGQpLgoK TXkgYmFkLCB0aGVyZSdzIG5vIGRlYWRsb2NrIGluIHRoaXMgdmVyc2lvbiwgYmVjYXVzZSB3ZSBk b24ndCB1c2UKLT5wYWdlc191c2VfY291bnQgdG8gcmV0YWluIHRoZSBwYWdlIHRhYmxlICh3ZSBq dXN0IHVzZSBhIGdwdV91c2Vjb3VudAppbiBwYXRjaCA4IHRvIHByZXZlbnQgdGhlIHB1cmdlKS4g QnV0IEkgc3RhcnRlZCB3b3JraW5nIG9uIGEgdmVyc2lvbgp0aGF0IHVzZXMgLT5wYWdlc191c2Vf Y291bnQgaW5zdGVhZCBvZiBpbnRyb2R1Y2luZyB5ZXQgYW5vdGhlcgpyZWZjb3VudCwgYW5kIGlu IHRoaXMgdmVyc2lvbiBJIHRha2UvcmVsZWFzZSBhIHJlZiBvbiB0aGUgcGFnZSB0YWJsZSBpbgp0 aGUgbW11X21hcCgpL21tdV91bm1hcCgpIHBhdGguIFRoaXMgY2F1c2VzIGEgZGVhZGxvY2sgd2hl biBHRU0gbWFwcGluZ3MKYXJlIHRlYXJlZCBkb3duIGJ5IHRoZSBzaHJpbmtlciBsb2dpYyAoYmVj YXVzZSB0aGUgcGFnZXMgbG9jayBpcyBhbHJlYWR5CnRha2VuIGluIHBhbmZyb3N0X2dlbV9wdXJn ZSgpKS4uLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpo dHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbA== 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=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=ham 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 A3225C43603 for ; Fri, 6 Dec 2019 08:08:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7FEFA2466E for ; Fri, 6 Dec 2019 08:08:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726088AbfLFIIO (ORCPT ); Fri, 6 Dec 2019 03:08:14 -0500 Received: from bhuna.collabora.co.uk ([46.235.227.227]:37552 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725858AbfLFIIO (ORCPT ); Fri, 6 Dec 2019 03:08:14 -0500 Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 5D8992925B0; Fri, 6 Dec 2019 08:08:12 +0000 (GMT) Date: Fri, 6 Dec 2019 09:08:09 +0100 From: Boris Brezillon To: Rob Herring Cc: Steven Price , Tomeu Vizoso , Alyssa Rosenzweig , stable , dri-devel Subject: Re: [PATCH 2/8] drm/panfrost: Fix a race in panfrost_ioctl_madvise() Message-ID: <20191206090809.0832f4aa@collabora.com> In-Reply-To: <20191206085327.66a8c479@collabora.com> References: <20191129135908.2439529-1-boris.brezillon@collabora.com> <20191129135908.2439529-3-boris.brezillon@collabora.com> <20191129153310.2f9c80e1@collabora.com> <20191206085327.66a8c479@collabora.com> Organization: Collabora X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Fri, 6 Dec 2019 08:53:27 +0100 Boris Brezillon wrote: > On Thu, 5 Dec 2019 17:08:02 -0600 > Rob Herring wrote: > > > On Fri, Nov 29, 2019 at 8:33 AM Boris Brezillon > > wrote: > > > > > > On Fri, 29 Nov 2019 14:24:48 +0000 > > > Steven Price wrote: > > > > > > > On 29/11/2019 13:59, Boris Brezillon wrote: > > > > > If 2 threads change the MADVISE property of the same BO in parallel we > > > > > might end up with an shmem->madv value that's inconsistent with the > > > > > presence of the BO in the shrinker list. > > > > > > > > I'm a bit worried from the point of view of user space sanity that you > > > > observed this - but clearly the kernel should be robust! > > > > > > It's not something I observed, just found the race by inspecting the > > > code, and I thought it was worth fixing it. > > > > I'm not so sure there's a race. > > I'm pretty sure there's one: > > T0 T1 > > lock(pages) > madv = 1 > unlock(pages) > > lock(pages) > madv = 0 > unlock(pages) > > lock(shrinker) > remove_from_list(bo) > unlock(shrinker) > > lock(shrinker) > add_to_list(bo) > unlock(shrinker) > > You end up with madv = 0 and the BO is added to the list. > > > If there is, we still check madv value > > when purging, so it would be harmless even if the state is > > inconsistent. > > Indeed. Note that you could also have this other situation where the BO > is marked purgeable but not present in the list. In that case it will > never be purged, but it's kinda user space fault anyway. I agree, none > of this problems are critical, and I'm fine leaving it unfixed as long > as it's documented somewhere that the race exist and is harmless. > > > > > > > > The easiest solution to fix that is to protect the > > > > > drm_gem_shmem_madvise() call with the shrinker lock. > > > > > > > > > > Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support") > > > > > Cc: > > > > > Signed-off-by: Boris Brezillon > > > > > > > > Reviewed-by: Steven Price > > > > > > Thanks. > > > > > > > > > > > > --- > > > > > drivers/gpu/drm/panfrost/panfrost_drv.c | 9 ++++----- > > > > > 1 file changed, 4 insertions(+), 5 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c > > > > > index f21bc8a7ee3a..efc0a24d1f4c 100644 > > > > > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c > > > > > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c > > > > > @@ -347,20 +347,19 @@ static int panfrost_ioctl_madvise(struct drm_device *dev, void *data, > > > > > return -ENOENT; > > > > > } > > > > > > > > > > + mutex_lock(&pfdev->shrinker_lock); > > > > > args->retained = drm_gem_shmem_madvise(gem_obj, args->madv); > > > > This means we now hold the shrinker_lock while we take the pages_lock. > > Is lockdep happy with this change? I suspect not given all the fun I > > had getting lockdep happy. > > I have tested with lockdep enabled and it's all good from lockdep PoV > because the locks are taken in the same order in the madvise() and > schinker_scan() path (first the shrinker lock, then the pages lock). > > Note that patch 7 introduces a deadlock in the shrinker path, but this > is unrelated to this shrinker lock being taken earlier in madvise > (drm_gem_put_pages() is called while the pages lock is already held). My bad, there's no deadlock in this version, because we don't use ->pages_use_count to retain the page table (we just use a gpu_usecount in patch 8 to prevent the purge). But I started working on a version that uses ->pages_use_count instead of introducing yet another refcount, and in this version I take/release a ref on the page table in the mmu_map()/mmu_unmap() path. This causes a deadlock when GEM mappings are teared down by the shrinker logic (because the pages lock is already taken in panfrost_gem_purge())...