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.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 01074C47094 for ; Thu, 10 Jun 2021 11:53:24 +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 6FB1E613CA for ; Thu, 10 Jun 2021 11:53:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6FB1E613CA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 16FC16E5D2; Thu, 10 Jun 2021 11:53:23 +0000 (UTC) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8994D6E5D2 for ; Thu, 10 Jun 2021 11:53:21 +0000 (UTC) Received: by mail-oi1-x22b.google.com with SMTP id a26so1791524oie.11 for ; Thu, 10 Jun 2021 04:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=k7yCmETNGZzL+ZXKNRZN5dPexuRJ9DzOaDWEpkXCVd0=; b=EmA7l4fEDq/uauQLfr4lKUFXKqtp+Buau4ulZUc4ZW77NSXeauxy4fNwNGIKitftJm 52ecLgayKXrIWgB/eD2hnwLIJ1FgAVue6mEYuyzvwgPO8SJXY+ozWbBXfX3XC+2PN9mX 5xEVPMU08nDSUeGYafJNAqMrJ02ic2nCiVswY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=k7yCmETNGZzL+ZXKNRZN5dPexuRJ9DzOaDWEpkXCVd0=; b=qEcJthu+paQN0yLorU+f7CHNH65p8+r7svv2krYcmnP/9TIxo0bERRkRAZeaPL4voJ aXAC6UZ7NN9MHsmH5JxkiG7cg6aHmIrSnPpSHiIks45joKCkYQdjIRikgahvMho8Z4MK 4y8KrW597ujKN0KeW21WGTYfScRIy7fiwRPBF2nrr5Woy8+MfR41Z7NZRlYba502dwot DuBYpD6YgjpJQqCUUYAfHIHf5lJg0HkYKDR3yGHpjHAtDe6L4aqWj2wDzhd4Suh3HPDo fCihZQk/AbZKLSNYemOLvKJQkpArmpciGTf5mVO1dvago6tRnhyFrKfnIoP9PBEC8ppE ypeQ== X-Gm-Message-State: AOAM531uREB9Xal2bMTMjPxRKHQ/HD1ts/G37v1FWxNc1OZQ10EK6kBn vh/TMyT/IOm48SJb7u7hjQm0T913DJSmcQolw2WYfg== X-Google-Smtp-Source: ABdhPJxdC5qRlB1ir525aY5SaJCqS1jupGOIcR2pG0ve1z75TQI8OtaoAynIgkjSEdIJeI6Z/nW8fHBrzvLVeagKXPE= X-Received: by 2002:aca:1210:: with SMTP id 16mr4319286ois.14.1623326001018; Thu, 10 Jun 2021 04:53:21 -0700 (PDT) MIME-Version: 1.0 References: <20210609212959.471209-1-jason@jlekstrand.net> In-Reply-To: From: Daniel Vetter Date: Thu, 10 Jun 2021 13:53:09 +0200 Message-ID: To: =?UTF-8?Q?Christian_K=C3=B6nig?= Subject: Re: [Intel-gfx] [PATCH 0/5] dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx , dri-devel , Matthew Auld , Dave Airlie Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" T24gVGh1LCBKdW4gMTAsIDIwMjEgYXQgMToyOSBQTSBEYW5pZWwgVmV0dGVyIDxkYW5pZWwudmV0 dGVyQGZmd2xsLmNoPiB3cm90ZToKPiBPbiBUaHUsIEp1biAxMCwgMjAyMSBhdCAxMTozOSBBTSBD aHJpc3RpYW4gS8O2bmlnCj4gPGNocmlzdGlhbi5rb2VuaWdAYW1kLmNvbT4gd3JvdGU6Cj4gPiBB bSAxMC4wNi4yMSB1bSAxMToyOSBzY2hyaWViIFR2cnRrbyBVcnN1bGluOgo+ID4gPiBPbiAwOS8w Ni8yMDIxIDIyOjI5LCBKYXNvbiBFa3N0cmFuZCB3cm90ZToKPiA+ID4+IEV2ZXIgc2luY2UgMGVh ZmVjNmQzMjQ0ICgiZHJtL2k5MTU6IEVuYWJsZSBsb2NrbGVzcyBsb29rdXAgb2YgcmVxdWVzdAo+ ID4gPj4gdHJhY2tpbmcgdmlhIFJDVSIpLCB0aGUgaTkxNSBkcml2ZXIgaGFzIHVzZWQgU0xBQl9U WVBFU0FGRV9CWV9SQ1UgKGl0Cj4gPiA+PiB3YXMgY2FsbGVkIFNMQUJfREVTVFJPWV9CWV9SQ1Ug YXQgdGhlIHRpbWUpIGluIG9yZGVyIHRvIGFsbG93IFJDVSBvbgo+ID4gPj4gaTkxNV9yZXF1ZXN0 LiAgQXMgbmlmdHkgYXMgU0xBQl9UWVBFU0FGRV9CWV9SQ1UgbWF5IGJlLCBpdCBjb21lcyB3aXRo Cj4gPiA+PiBzb21lIHNlcmlvdXMgZGlzY2xhaW1lcnMuICBJbiBwYXJ0aWN1bGFyLCBvYmplY3Rz IGNhbiBnZXQgcmVjeWNsZWQgd2hpbGUKPiA+ID4+IFJDVSByZWFkZXJzIGFyZSBzdGlsbCBpbi1m bGlnaHQuICBUaGlzIGNhbiBiZSBvayBpZiBldmVyeW9uZSB3aG8gdG91Y2hlcwo+ID4gPj4gdGhl c2Ugb2JqZWN0cyBrbm93cyBhYm91dCB0aGUgZGlzY2xhaW1lcnMgYW5kIGlzIGNhcmVmdWwuIEhv d2V2ZXIsCj4gPiA+PiBiZWNhdXNlIHdlJ3ZlIGNob3NlbiB0byB1c2UgU0xBQl9UWVBFU0FGRV9C WV9SQ1UgZm9yIGk5MTVfcmVxdWVzdCBhbmQKPiA+ID4+IGJlY2F1c2UgaTkxNV9yZXF1ZXN0IGNv bnRhaW5zIGEgZG1hX2ZlbmNlLCB3ZSd2ZSBsZWFrZWQKPiA+ID4+IFNMQUJfVFlQRVNBRkVfQllf UkNVIGFuZCBpdHMgd2hvbGUgcGlsZSBvZiBkaXNjbGFpbWVycyB0byBldmVyeSBkcml2ZXIKPiA+ ID4+IGluIHRoZSBrZXJuZWwgd2hpY2ggbWF5IGNvbnN1bWUgYSBkbWFfZmVuY2UuCj4gPiA+Cj4g PiA+IEkgZG9uJ3QgdGhpbmsgdGhlIHBhcnQgYWJvdXQgbGVha2luZyBpcyB0cnVlLi4uCj4gPiA+ Cj4gPiA+PiBXZSd2ZSB0cmllZCB0byBrZWVwIGl0IHNvbWV3aGF0IGNvbnRhaW5lZCBieSBkb2lu ZyBtb3N0IG9mIHRoZSBoYXJkIHdvcmsKPiA+ID4+IHRvIHByZXZlbnQgYWNjZXNzIG9mIHJlY3lj bGVkIG9iamVjdHMgdmlhIGRtYV9mZW5jZV9nZXRfcmN1X3NhZmUoKS4KPiA+ID4+IEhvd2V2ZXIs IGEgcXVpY2sgZ3JlcCBvZiBrZXJuZWwgc291cmNlcyBzYXlzIHRoYXQsIG9mIHRoZSAzMCBpbnN0 YW5jZXMKPiA+ID4+IG9mIGRtYV9mZW5jZV9nZXRfcmN1Kiwgb25seSAxMSBvZiB0aGVtIHVzZSBk bWFfZmVuY2VfZ2V0X3JjdV9zYWZlKCkuCj4gPiA+PiBJdCdzIGxpa2VseSB0aGVyZSBiZWFyIHRy YXBzIGluIERSTSBhbmQgcmVsYXRlZCBzdWJzeXN0ZW1zIGp1c3Qgd2FpdGluZwo+ID4gPj4gZm9y IHNvbWVvbmUgdG8gYWNjaWRlbnRhbGx5IHN0ZXAgaW4gdGhlbS4KPiA+ID4KPiA+ID4gLi4uYmVj YXVzZSBkbWFfZmVuY2VfZ2V0X3JjdV9zYWZlIGFwZWFycyB0byBiZSBhYm91dCB3aGV0aGVyIHRo ZQo+ID4gPiAqcG9pbnRlciogdG8gdGhlIGZlbmNlIGl0c2VsZiBpcyByY3UgcHJvdGVjdGVkLCBu b3QgYWJvdXQgdGhlIGZlbmNlCj4gPiA+IG9iamVjdCBpdHNlbGYuCj4gPgo+ID4gWWVzLCBleGFj dGx5IHRoYXQuCj4KPiBXZSBkbyBsZWFrLCBhbmQgYmFkbHkuIEFueSBfX3JjdSBwcm90ZWN0ZWQg ZmVuY2UgcG9pbnRlciB3aGVyZSBhCj4gc2hhcmVkIGZlbmNlIGNvdWxkIHNob3cgdXAgaXMgYWZm ZWN0ZWQuIEFuZCB0aGUgcG9pbnQgb2YgZG1hX2ZlbmNlIGlzCj4gdGhhdCB0aGV5J3JlIHNoYXJl YWJsZSwgYW5kIHdlJ3JlIGludmVudGluZyBldmVyIG1vcmUgd2F5cyB0byBkbyBzbwo+IChzeW5j X2ZpbGUsIGRybV9zeW5jb2JqLCBpbXBsaWNpdCBmZW5jaW5nIG1heWJlIHNvb24gd2l0aAo+IGlt cG9ydC9leHBvcnQgaW9jdGwgb24gdG9wLCBpbi9vdXQgZmVuY2VzIGluIENTIGlvY3RsLCBhdG9t aWMgaW9jdGwsCj4gLi4uKS4KPgo+IFNvIHdpdGhvdXQgYSBmdWxsIGF1ZGl0IGFueXRoaW5nIHRo YXQgdXNlcyB0aGUgZm9sbG93aW5nIHBhdHRlcm4gaXMKPiBwcm9iYWJseSBidXN0ZWQ6Cj4KPiBy Y3VfcmVhZF9sb2NrKCk7Cj4gZmVuY2UgPSByY3VfZGVyZWZlcmVuY2UoKTsKPiBmZW5jZSA9IGRt YV9mZW5jZV9nZXRfcmN1KCk7Cj4gcmN1X3JlYWRfbG9jaygpOwo+Cj4gLyogdXNlIHRoZSBmZW5j ZSBub3cgdGhhdCB3ZSBhY3F1aXJlZCBhIGZ1bGwgcmVmZXJlbmNlICovCj4KPiBBbmQgSSBkb24n dCBtZWFuICJ5b3UgbWlnaHQgd2FpdCBhIGJpdCB0b28gbXVjaCIgYnVzdGVkLCBidXQgInRoaXMg Y2FuCj4gbGVhZCB0byBsb29wcyBpbiB0aGUgZG1hX2ZlbmNlIGRlcGVuZGVuY3kgY2hhaW4sIHJl c3VsdGluZyBpbgo+IGRlYWRsb2NrcyIga2luZCBvZiBidXN0ZWQuIFdoYXQncyB3b3JzZSwgdGhl IHN0YW5kYXJkIHJjdSBsb2NrbGVzcwo+IGFjY2VzcyBwYXR0ZXJuIGlzIGFsc28gYnVzdGVkIGNv bXBsZXRlbHk6Cj4KPiByY3VfcmVhZF9sb2NrKCk7Cj4gZmVuY2UgPSByY3VfZGVyZWZlbmNlKCk7 Cj4gLyogbG9ja2xlc3NseSBjaGVjayB0aGUgc3RhdGUgb2YgZmVuY2UgKi8KPiByY3VfcmVhZF91 bmxvY2soKTsKPgo+IGJlY2F1c2Ugb25jZSB5b3UgaGF2ZSBUWVBFU0FGRV9CWV9SQ1UgcmN1X3Jl YWRfbG9jayBkb2Vzbid0IHByZXZlbnQgYQo+IHVzZS1hZnRlci1mcmVlIGFueW1vcmUuIFRoZSBv bmx5IHRoaW5nIGl0IGd1YXJhbnRlZXMgaXMgdGhhdCB5b3VyCj4gZmVuY2UgcG9pbnRlciBrZWVw cyBwb2ludGluZyBhdCBlaXRoZXIgZnJlZWQgbWVtb3J5LCBvciBhIGZlbmNlLCBidXQKPiBub3Ro aW5nIGVsc2UuIFlvdSBoYXZlIHRvIHdyYXAgeW91ciByY3VfZGVyZWZlbmNlIGFuZCBjb2RlIGlu dG8gYQo+IHNlcWxvY2sgb2Ygc29tZSBraW5kLCBlaXRoZXIgYSByZWFsIG9uZSBsaWtlIGRtYV9y ZXN2LCBvciBhbgo+IG9wZW4tY29kZWQgb25lIGxpa2UgZG1hX2ZlbmNlX2dldF9yY3Vfc2FmZSB1 c2VzLiBBbmQgeWVzIHRoZSBsYXR0ZXIgaXMKPiBhIHNwZWNpYWxpemVkIHNlcWxvY2ssIGV4Y2Vw dCBpdCBmYWlscyB0byBwcm9wZXJseSBkb2N1bWVudCBpbgo+IGNvbW1lbnRzIHdoZXJlIGFsbCB0 aGUgcmVxdWlyZWQgYmFycmllcnMgYXJlLgo+Cj4gdGxkcjsgYWxsIHRoZSBjb2RlIHVzaW5nIGRt YV9mZW5jZV9nZXRfcmN1IG5lZWRzIHRvIGJlIGFzc3VtZWQgdG8gYmUgYnJva2VuLgo+Cj4gSGVj ayB0aGlzIGlzIGZyYWdpbGUgYW5kIHRyaWNreSBlbm91Z2ggdGhhdCBpOTE1IHNob3QgaXRzIG93 biBsZWcgb2ZmCj4gcm91dGluZWx5ICh0aGVyZSdzIGEgYnVnZml4IGZsb2F0aW5nIGFyb3VuZCBq dXN0IG5vdyksIHNvIG5vdCBldmVuCj4gaW50ZXJuYWxseSB3ZSdyZSB2ZXJ5IGdvb2QgYXQgZ2V0 dGluZyB0aGlzIHJpZ2h0Lgo+Cj4gPiA+IElmIG9uZSBoYXMgYSBzdGFibGUgcG9pbnRlciB0byBh IGZlbmNlIGRtYV9mZW5jZV9nZXRfcmN1IGlzIEkgdGhpbmsKPiA+ID4gZW5vdWdoIHRvIGRlYWwg d2l0aCBTTEFCX1RZUEVTQUZFX0JZX1JDVSB1c2VkIGJ5IGk5MTVfcmVxdWVzdCAoYXMgZG1hCj4g PiA+IGZlbmNlIGlzIGEgYmFzZSBvYmplY3QgdGhlcmUpLiBVbmxlc3MgeW91IGZvdW5kIGEgYnVn IGluIHJxIGZpZWxkCj4gPiA+IHJlY3ljbGluZy4gQnV0IGFjY2VzcyB0byB0aGUgZG1hIGZlbmNl IGlzIGFsbCB0aWdodGx5IGNvbnRyb2xsZWQgc28gSQo+ID4gPiBkb24ndCBnZXQgd2hhdCBsZWFr cy4KPiA+ID4KPiA+ID4+IFRoaXMgcGF0Y2ggc2VyaWVzIHN0b3BzIHVzIHVzaW5nIFNMQUJfVFlQ RVNBRkVfQllfUkNVIGZvciBpOTE1X3JlcXVlc3QKPiA+ID4+IGFuZCwgaW5zdGVhZCwgZG9lcyBh biBSQ1Utc2FmZSBzbGFiIGZyZWUgdmlhIHJjdV9jYWxsKCkuICBUaGlzIHNob3VsZAo+ID4gPj4g bGV0IHVzIGtlZXAgbW9zdCBvZiB0aGUgcGVyZiBiZW5lZml0cyBvZiBzbGFiIGFsbG9jYXRpb24g d2hpbGUgYXZvaWRpbmcKPiA+ID4+IHRoZSBiZWFyIHRyYXBzIGluaGVyZW50IGluIFNMQUJfVFlQ RVNBRkVfQllfUkNVLiAgSXQgdGhlbiByZW1vdmVzCj4gPiA+PiBzdXBwb3J0Cj4gPiA+PiBmb3Ig U0xBQl9UWVBFU0FGRV9CWV9SQ1UgZnJvbSBkbWFfZmVuY2UgZW50aXJlbHkuCj4gPiA+Cj4gPiA+ IEFjY29yZGluZyB0byB0aGUgcmF0aW9uYWxlIGJlaGluZCBTTEFCX1RZUEVTQUZFX0JZX1JDVSB0 cmFkaXRpb25hbCBSQ1UKPiA+ID4gZnJlZWluZyBjYW4gYmUgYSBsb3QgbW9yZSBjb3N0bHkgc28g SSB0aGluayB3ZSBuZWVkIGEgY2xlYXIKPiA+ID4ganVzdGlmaWNhdGlvbiBvbiB3aHkgdGhpcyBj aGFuZ2UgaXMgYmVpbmcgY29uc2lkZXJlZC4KPiA+Cj4gPiBUaGUgcHJvYmxlbSBpcyB0aGF0IFNM QUJfVFlQRVNBRkVfQllfUkNVIHJlcXVpcmVzIHRoYXQgd2UgdXNlIGEgc2VxdWVuY2UKPiA+IGNv dW50ZXIgdG8gbWFrZSBzdXJlIHRoYXQgd2UgZG9uJ3QgZ3JhYiB0aGUgcmVmZXJlbmNlIHRvIGEg cmVhbGxvY2F0ZWQKPiA+IGRtYV9mZW5jZS4KPiA+Cj4gPiBVcGRhdGluZyB0aGUgc2VxdWVuY2Ug Y291bnRlciBldmVyeSB0aW1lIHdlIGFkZCBhIGZlbmNlIG5vdyBtZWFucyB0d28KPiA+IGFkZGl0 aW9ucyB3cml0ZXMgYW5kIG9uZSBhZGRpdGlvbmFsIGJhcnJpZXIgZm9yIGFuIGV4dHJlbWVseSBo b3QgcGF0aC4KPiA+IFRoZSBleHRyYSBvdmVyaGVhZCBvZiBSQ1UgZnJlZWluZyBpcyBjb21wbGV0 ZWx5IG5lZ2xpZ2libGUgY29tcGFyZWQgdG8gdGhhdC4KPiA+Cj4gPiBUaGUgZ29vZCBuZXdzIGlz IHRoYXQgSSB0aGluayBpZiB3ZSBhcmUganVzdCBhIGJpdCBtb3JlIGNsZXZlciBhYm91dCBvdXIK PiA+IGhhbmRsZSB3ZSBjYW4gYm90aCBhdm9pZCB0aGUgc2VxdWVuY2UgY291bnRlciBhbmQga2Vl cAo+ID4gU0xBQl9UWVBFU0FGRV9CWV9SQ1UgYXJvdW5kLgo+Cj4gWW91IHN0aWxsIG5lZWQgYSBz ZXFsb2NrLCBvciBzb21ldGhpbmcgZWxzZSB0aGF0J3Mgc2VydmluZyBhcyB5b3VyCj4gc2VxbG9j ay4gZG1hX2ZlbmNlX2xpc3QgYmVoaW5kIGEgc2luZ2xlIF9fcmN1IHByb3RlY3RlZCBwb2ludGVy LCB3aXRoCj4gYWxsIHN1YnNlcXVlbnQgZmVuY2UgcG9pbnRlcnMgX25vdF8gYmVpbmcgcmN1IHBy b3RlY3RlZCAoaS5lLiBmdWxsCj4gcmVmZXJlbmNlLCBvbiBldmVyeSBjaGFuZ2Ugd2UgYWxsb2Nh dGUgbWlnaHQgd29yay4gV2hpY2ggaXMgYSB2ZXJ5Cj4gZnVubnkgd2F5IG9mIGltcGxlbWVudGlu ZyBzb21ldGhpbmcgbGlrZSBhIHNlcWxvY2suCj4KPiBBbmQgdGhhdCBvbmx5IGNvdmVycyBkbWFf cmVzdiwgeW91IF9oYXZlXyB0byBkbyB0aGlzIF9ldmVyeXdoZXJlXyBpbgo+IGV2ZXJ5IGRyaXZl ci4gRXhjZXB0IGlmIHlvdSBjYW4gcHJvb2YgdGhhdCB5b3VyIF9fcmN1IGZlbmNlIHBvaW50ZXIK PiBvbmx5IGV2ZXIgcG9pbnRzIGF0IHlvdXIgb3duIGRyaXZlcidzIGZlbmNlcy4KPgo+IFNvIHVu bGVzcyB5b3UncmUgdm9sdW50ZWVyaW5nIHRvIGF1ZGl0IGFsbCB0aGUgZHJpdmVycywgYW5kIGNv bnN0YW50bHkKPiByZS1hdWRpdCB0aGVtIChiZWNhdXNlIHJjdSBvbmx5IGd1YXJhbnRlZWluZyB0 eXBlLXNhZmV0eSBidXQgbm90Cj4gYWN0dWFsbHkgcHJldmVudGluZyB1c2UtYWZ0ZXItZnJlZSBp cyB2ZXJ5IHVudXN1YWwgaW4gdGhlIGtlcm5lbCkganVzdAo+IGZpeGluZyBkbWFfcmVzdiBkb2Vz bid0IHNvbHZlIHRoZSBwcm9ibGVtIGhlcmUgYXQgYWxsLgo+Cj4gPiBCdXQgdGhpcyBuZWVkcyBt b3JlIGNvZGUgY2xlYW51cCBhbmQgYWJzdHJhY3RpbmcgdGhlIHNlcXVlbmNlIGNvdW50ZXIKPiA+ IHVzYWdlIGluIGEgbWFjcm8uCj4KPiBUaGUgb3RoZXIgdGhpbmcgaXMgdGhhdCB0aGlzIGRvZXNu J3QgZXZlbiBtYWtlIHNlbnNlIGZvciBpOTE1IGFueW1vcmUuCj4gVGhlIHNvbHV0aW9uIHRvIHRo ZSAidXNlcnNwYWNlIHdhbnRzIHRvIHN1Ym1pdCBiYXppbGxpb24gcmVxdWVzdHMiCj4gcHJvYmxl bSBpcyBkaXJlY3QgdXNlcnNwYWNlIHN1Ym1pdC4gQ3VycmVudCBodyBkb2Vzbid0IGhhdmUgdXNl cnNwYWNlCj4gcmluZ2J1ZmZlciwgYnV0IHdlIGhhdmUgYSBwcmV0dHkgY2xldmVyIHRyaWNrIGlu IHRoZSB3b3JrcyB0byBtYWtlCj4gdGhpcyBwb3NzaWJsZSB3aXRoIGN1cnJlbnQgaHcsIGVzc2Vu dGlhbGx5IGJ5IHN1Ym1pdHRpbmcgYSBDUyB0aGF0Cj4gbG9vcHMgb24gaXRzZWxmLCBhbmQgdGhl biBpbnNlcnRpbmcgYmF0Y2hlcyBpbnRvIHRoaXMgInJpbmciIGJ5Cj4gbGF0Y2hpbmcgYSBjb25k aXRpb25hbCBicmFuY2ggaW4gdGhpcyBDUy4gSXQncyBub3QgcHJldHR5LCBidXQgaXQgZ2V0cwo+ IHRoZSBqb2IgZG9uZSBhbmQgb3V0cmlnaHQgcmVtb3ZlcyB0aGUgbmVlZCBmb3IgcGxhaWQgbW9k ZSB0aHJvdWdocHV0Cj4gb2YgaTkxNV9yZXF1ZXN0IGRtYSBmZW5jZXMuCgpUbyBwdXQgaXQgYW5v dGhlciB3YXk6IEknbSB0aGUgZ3V5IHdobyByZXZpZXdlZCB0aGUgcGF0Y2ggd2hpY2gKc3RhcnRl ZCB0aGlzIGVudGlyZSBUWVBFU0FGRV9CWV9SQ1UgbWVzcyB3ZSBnb3Qgb3Vyc2VsdmVzIGludG86 Cgpjb21taXQgMGVhZmVjNmQzMjQ0ODAyZDQ2OTcxMjY4MmIwZjUxMzk2M2MyM2VmZgpBdXRob3I6 IENocmlzIFdpbHNvbiA8Y2hyaXNAY2hyaXMtd2lsc29uLmNvLnVrPgpEYXRlOiAgIFRodSBBdWcg NCAxNjozMjo0MSAyMDE2ICswMTAwCgogICBkcm0vaTkxNTogRW5hYmxlIGxvY2tsZXNzIGxvb2t1 cCBvZiByZXF1ZXN0IHRyYWNraW5nIHZpYSBSQ1UKCi4uLgoKICAgU2lnbmVkLW9mZi1ieTogQ2hy aXMgV2lsc29uIDxjaHJpc0BjaHJpcy13aWxzb24uY28udWs+CiAgIENjOiBNYWFydGVuIExhbmto b3JzdCA8bWFhcnRlbi5sYW5raG9yc3RAbGludXguaW50ZWwuY29tPgogICBDYzogIkdvZWwsIEFr YXNoIiA8YWthc2guZ29lbEBpbnRlbC5jb20+CiAgIENjOiBKb3NoIFRyaXBsZXR0IDxqb3NoQGpv c2h0cmlwbGV0dC5vcmc+CiAgIENjOiBEYW5pZWwgVmV0dGVyIDxkYW5pZWwudmV0dGVyQGZmd2xs LmNoPgogICBSZXZpZXdlZC1ieTogRGFuaWVsIFZldHRlciA8ZGFuaWVsLnZldHRlckBmZndsbC5j aD4KICAgTGluazogaHR0cDovL3BhdGNod29yay5mcmVlZGVza3RvcC5vcmcvcGF0Y2gvbXNnaWQv MTQ3MDMyNDc2Mi0yNTQ1LTI1LWdpdC1zZW5kLWVtYWlsLWNocmlzQGNocmlzLXdpbHNvbi5jby51 awoKTG9va2luZyBiYWNrIHRoaXMgd2FzIGEgbWlzdGFrZS4gVGhlIGlubm9jZW50bHkgbGFiZWxs ZWQKREVTVFJPWV9CWV9SQ1UgdHJpY2tlZCBtZSByZWFsIGJhZCwgYW5kIHdlIG5ldmVyIGhhZCBh bnkgcmVhbC13b3JsZAp1c2UtY2FzZSB0byBqdXN0aWZ5IGFsbCB0aGUgZGFuZ2VyIHRoaXMgYnJv dWdodCBub3QganVzdCB0byBpOTE1LCBidXQKdG8gYW55IGRyaXZlciB1c2luZyBfX3JjdSBwcm90 ZWN0ZWQgZG1hX2ZlbmNlIGFjY2Vzcy4gSXQncyBub3Qgd29ydGgKaXQuCi1EYW5pZWwKLS0gCkRh bmllbCBWZXR0ZXIKU29mdHdhcmUgRW5naW5lZXIsIEludGVsIENvcnBvcmF0aW9uCmh0dHA6Ly9i bG9nLmZmd2xsLmNoCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCkludGVsLWdmeCBtYWlsaW5nIGxpc3QKSW50ZWwtZ2Z4QGxpc3RzLmZyZWVkZXNrdG9wLm9y ZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludGVsLWdm eAo= 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.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 6A2F5C48BDF for ; Thu, 10 Jun 2021 11:53:26 +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 F2B62613CA for ; Thu, 10 Jun 2021 11:53:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F2B62613CA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch 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 EF11F6E4F1; Thu, 10 Jun 2021 11:53:23 +0000 (UTC) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8B22E88007 for ; Thu, 10 Jun 2021 11:53:21 +0000 (UTC) Received: by mail-oi1-x234.google.com with SMTP id u11so1826753oiv.1 for ; Thu, 10 Jun 2021 04:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=k7yCmETNGZzL+ZXKNRZN5dPexuRJ9DzOaDWEpkXCVd0=; b=EmA7l4fEDq/uauQLfr4lKUFXKqtp+Buau4ulZUc4ZW77NSXeauxy4fNwNGIKitftJm 52ecLgayKXrIWgB/eD2hnwLIJ1FgAVue6mEYuyzvwgPO8SJXY+ozWbBXfX3XC+2PN9mX 5xEVPMU08nDSUeGYafJNAqMrJ02ic2nCiVswY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=k7yCmETNGZzL+ZXKNRZN5dPexuRJ9DzOaDWEpkXCVd0=; b=piIv4f116oFIDEBLOR88vgTr9zKbSQJPtig51YkUOdwKvYXE2nUUAARWasVmOFmlES 1zlGHPcJDA98AbTxXqbAX81N2I5Puq7hmKdhaf72v5HK8BofA3q3MnhB/WL8zJlCCDKo T+aVQ9TehgqsXcRoiGhBitaMThAY9mxsSHW5cI0zLR6ZLmxE0UP9+jUWK+enWZguEzwz ei0MB8qyZmP/STHCs80/17RRHQvfgCPtbZyzSG1pGkkV9hg0ccmEIRAn+SMn5vjkJxwe TRYwG5EZsngRdR1Tk4o1g2dfjKLPShnFUTik1kW66RHzvPbrlZTRxyaWlk1rjqr32465 LA6g== X-Gm-Message-State: AOAM5339r2m3MANi6z8IeabnW47040yktKRqClYweqtBgTOSVgMA0WzG zdzEWoAgADRymm/3nXYDh4Ul1GuqMbLtNm9reAbbH9ycEL/IBg== X-Google-Smtp-Source: ABdhPJxdC5qRlB1ir525aY5SaJCqS1jupGOIcR2pG0ve1z75TQI8OtaoAynIgkjSEdIJeI6Z/nW8fHBrzvLVeagKXPE= X-Received: by 2002:aca:1210:: with SMTP id 16mr4319286ois.14.1623326001018; Thu, 10 Jun 2021 04:53:21 -0700 (PDT) MIME-Version: 1.0 References: <20210609212959.471209-1-jason@jlekstrand.net> In-Reply-To: From: Daniel Vetter Date: Thu, 10 Jun 2021 13:53:09 +0200 Message-ID: Subject: Re: [Intel-gfx] [PATCH 0/5] dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence To: =?UTF-8?Q?Christian_K=C3=B6nig?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tvrtko Ursulin , intel-gfx , dri-devel , Matthew Auld , Jason Ekstrand , Dave Airlie Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Jun 10, 2021 at 1:29 PM Daniel Vetter wrot= e: > On Thu, Jun 10, 2021 at 11:39 AM Christian K=C3=B6nig > wrote: > > Am 10.06.21 um 11:29 schrieb Tvrtko Ursulin: > > > On 09/06/2021 22:29, Jason Ekstrand wrote: > > >> Ever since 0eafec6d3244 ("drm/i915: Enable lockless lookup of reques= t > > >> tracking via RCU"), the i915 driver has used SLAB_TYPESAFE_BY_RCU (i= t > > >> was called SLAB_DESTROY_BY_RCU at the time) in order to allow RCU on > > >> i915_request. As nifty as SLAB_TYPESAFE_BY_RCU may be, it comes wit= h > > >> some serious disclaimers. In particular, objects can get recycled w= hile > > >> RCU readers are still in-flight. This can be ok if everyone who tou= ches > > >> these objects knows about the disclaimers and is careful. However, > > >> because we've chosen to use SLAB_TYPESAFE_BY_RCU for i915_request an= d > > >> because i915_request contains a dma_fence, we've leaked > > >> SLAB_TYPESAFE_BY_RCU and its whole pile of disclaimers to every driv= er > > >> in the kernel which may consume a dma_fence. > > > > > > I don't think the part about leaking is true... > > > > > >> We've tried to keep it somewhat contained by doing most of the hard = work > > >> to prevent access of recycled objects via dma_fence_get_rcu_safe(). > > >> However, a quick grep of kernel sources says that, of the 30 instanc= es > > >> of dma_fence_get_rcu*, only 11 of them use dma_fence_get_rcu_safe(). > > >> It's likely there bear traps in DRM and related subsystems just wait= ing > > >> for someone to accidentally step in them. > > > > > > ...because dma_fence_get_rcu_safe apears to be about whether the > > > *pointer* to the fence itself is rcu protected, not about the fence > > > object itself. > > > > Yes, exactly that. > > We do leak, and badly. Any __rcu protected fence pointer where a > shared fence could show up is affected. And the point of dma_fence is > that they're shareable, and we're inventing ever more ways to do so > (sync_file, drm_syncobj, implicit fencing maybe soon with > import/export ioctl on top, in/out fences in CS ioctl, atomic ioctl, > ...). > > So without a full audit anything that uses the following pattern is > probably busted: > > rcu_read_lock(); > fence =3D rcu_dereference(); > fence =3D dma_fence_get_rcu(); > rcu_read_lock(); > > /* use the fence now that we acquired a full reference */ > > And I don't mean "you might wait a bit too much" busted, but "this can > lead to loops in the dma_fence dependency chain, resulting in > deadlocks" kind of busted. What's worse, the standard rcu lockless > access pattern is also busted completely: > > rcu_read_lock(); > fence =3D rcu_derefence(); > /* locklessly check the state of fence */ > rcu_read_unlock(); > > because once you have TYPESAFE_BY_RCU rcu_read_lock doesn't prevent a > use-after-free anymore. The only thing it guarantees is that your > fence pointer keeps pointing at either freed memory, or a fence, but > nothing else. You have to wrap your rcu_derefence and code into a > seqlock of some kind, either a real one like dma_resv, or an > open-coded one like dma_fence_get_rcu_safe uses. And yes the latter is > a specialized seqlock, except it fails to properly document in > comments where all the required barriers are. > > tldr; all the code using dma_fence_get_rcu needs to be assumed to be brok= en. > > Heck this is fragile and tricky enough that i915 shot its own leg off > routinely (there's a bugfix floating around just now), so not even > internally we're very good at getting this right. > > > > If one has a stable pointer to a fence dma_fence_get_rcu is I think > > > enough to deal with SLAB_TYPESAFE_BY_RCU used by i915_request (as dma > > > fence is a base object there). Unless you found a bug in rq field > > > recycling. But access to the dma fence is all tightly controlled so I > > > don't get what leaks. > > > > > >> This patch series stops us using SLAB_TYPESAFE_BY_RCU for i915_reque= st > > >> and, instead, does an RCU-safe slab free via rcu_call(). This shoul= d > > >> let us keep most of the perf benefits of slab allocation while avoid= ing > > >> the bear traps inherent in SLAB_TYPESAFE_BY_RCU. It then removes > > >> support > > >> for SLAB_TYPESAFE_BY_RCU from dma_fence entirely. > > > > > > According to the rationale behind SLAB_TYPESAFE_BY_RCU traditional RC= U > > > freeing can be a lot more costly so I think we need a clear > > > justification on why this change is being considered. > > > > The problem is that SLAB_TYPESAFE_BY_RCU requires that we use a sequenc= e > > counter to make sure that we don't grab the reference to a reallocated > > dma_fence. > > > > Updating the sequence counter every time we add a fence now means two > > additions writes and one additional barrier for an extremely hot path. > > The extra overhead of RCU freeing is completely negligible compared to = that. > > > > The good news is that I think if we are just a bit more clever about ou= r > > handle we can both avoid the sequence counter and keep > > SLAB_TYPESAFE_BY_RCU around. > > You still need a seqlock, or something else that's serving as your > seqlock. dma_fence_list behind a single __rcu protected pointer, with > all subsequent fence pointers _not_ being rcu protected (i.e. full > reference, on every change we allocate might work. Which is a very > funny way of implementing something like a seqlock. > > And that only covers dma_resv, you _have_ to do this _everywhere_ in > every driver. Except if you can proof that your __rcu fence pointer > only ever points at your own driver's fences. > > So unless you're volunteering to audit all the drivers, and constantly > re-audit them (because rcu only guaranteeing type-safety but not > actually preventing use-after-free is very unusual in the kernel) just > fixing dma_resv doesn't solve the problem here at all. > > > But this needs more code cleanup and abstracting the sequence counter > > usage in a macro. > > The other thing is that this doesn't even make sense for i915 anymore. > The solution to the "userspace wants to submit bazillion requests" > problem is direct userspace submit. Current hw doesn't have userspace > ringbuffer, but we have a pretty clever trick in the works to make > this possible with current hw, essentially by submitting a CS that > loops on itself, and then inserting batches into this "ring" by > latching a conditional branch in this CS. It's not pretty, but it gets > the job done and outright removes the need for plaid mode throughput > of i915_request dma fences. To put it another way: I'm the guy who reviewed the patch which started this entire TYPESAFE_BY_RCU mess we got ourselves into: commit 0eafec6d3244802d469712682b0f513963c23eff Author: Chris Wilson Date: Thu Aug 4 16:32:41 2016 +0100 drm/i915: Enable lockless lookup of request tracking via RCU ... Signed-off-by: Chris Wilson Cc: Maarten Lankhorst Cc: "Goel, Akash" Cc: Josh Triplett Cc: Daniel Vetter Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1470324762-2545-25-gi= t-send-email-chris@chris-wilson.co.uk Looking back this was a mistake. The innocently labelled DESTROY_BY_RCU tricked me real bad, and we never had any real-world use-case to justify all the danger this brought not just to i915, but to any driver using __rcu protected dma_fence access. It's not worth it. -Daniel --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch