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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 83E5DC48BD1 for ; Thu, 10 Jun 2021 20:42:51 +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 AD70B613FF for ; Thu, 10 Jun 2021 20:42:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AD70B613FF 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 13D4A6EDDC; Thu, 10 Jun 2021 20:42:50 +0000 (UTC) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3BB9F6EDDA for ; Thu, 10 Jun 2021 20:42:49 +0000 (UTC) Received: by mail-ot1-x336.google.com with SMTP id j11-20020a9d738b0000b02903ea3c02ded8so1017236otk.5 for ; Thu, 10 Jun 2021 13:42:49 -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=3MteMUmpbOhv5skxW3ZChFAKsrp5eoLJOhSTSRIlg8A=; b=LMgGpM5wo/Fqto1RB0jmfkjSUlY6Y5O3sVD/2KLe7oIr7kCJ1QMFVpSdpbrM28Syzm 8TuhVvQu+g3J6zr07q5fyHwvgCPrE97dfDX5PQyk1yi4vqs47LUC5kgPgrP4t+kykLWB a/pxAoxxFFl/f+o2UfgG11d6KXwVCMlxYJYNk= 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=3MteMUmpbOhv5skxW3ZChFAKsrp5eoLJOhSTSRIlg8A=; b=oaDborx2DknkkU0imAdwgq2yXV9qa1qPc8pstvAhBwsNpSBgkbWk1hu9KeQmB9sWni 8Az1WNcrpD+ZYOCpBKXQsmPbMy+z/DDE7jgoNxBMP5g1SKmQNOQs/unL7UDDfZ973JIZ j7wBJytHrDNXMhHYzDmHINo80TK4XHP7BJfke5S1NEAAsQOoj8X5jLMeCpy+ACkIZ1w/ 44bae12LefkAIMc5F1Ziy1QdDUtMbIcrfAPsnamm5oHUl+QZcUmXAaukNm6IHroQz6kK XDgwC8uvCcf+4mZTEy/cRcw/dV5hJ5CWaU9TMF+Uz6HErl2RXmLhxT6x1gq/Js9awEbR jzaQ== X-Gm-Message-State: AOAM533sYy8MIgVF93e3G+/H8GguSAsQ7M23x+o2KZxViyLBhPNKNmpQ qKuxiAef7Xs3E7G/ZZmy7BJWelkbjFiugyFGaaTTfg== X-Google-Smtp-Source: ABdhPJzSDKdq4MUnQpGarh3SOEwvktAtLgAz7jqCDG5WY2Rg7/mzkfLC17VBf30qhwbJT152N0HlzRRnAmolrQLtNWI= X-Received: by 2002:a9d:12eb:: with SMTP id g98mr179122otg.303.1623357768536; Thu, 10 Jun 2021 13:42:48 -0700 (PDT) MIME-Version: 1.0 References: <20210609212959.471209-1-jason@jlekstrand.net> In-Reply-To: From: Daniel Vetter Date: Thu, 10 Jun 2021 22:42:36 +0200 Message-ID: To: Jason Ekstrand 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 , =?UTF-8?Q?Christian_K=C3=B6nig?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" T24gVGh1LCBKdW4gMTAsIDIwMjEgYXQgMTA6MTAgUE0gSmFzb24gRWtzdHJhbmQgPGphc29uQGps ZWtzdHJhbmQubmV0PiB3cm90ZToKPgo+IE9uIFRodSwgSnVuIDEwLCAyMDIxIGF0IDg6MzUgQU0g SmFzb24gRWtzdHJhbmQgPGphc29uQGpsZWtzdHJhbmQubmV0PiB3cm90ZToKPiA+IE9uIFRodSwg SnVuIDEwLCAyMDIxIGF0IDY6MzAgQU0gRGFuaWVsIFZldHRlciA8ZGFuaWVsLnZldHRlckBmZnds bC5jaD4gd3JvdGU6Cj4gPiA+IE9uIFRodSwgSnVuIDEwLCAyMDIxIGF0IDExOjM5IEFNIENocmlz dGlhbiBLw7ZuaWcKPiA+ID4gPGNocmlzdGlhbi5rb2VuaWdAYW1kLmNvbT4gd3JvdGU6Cj4gPiA+ ID4gQW0gMTAuMDYuMjEgdW0gMTE6Mjkgc2NocmllYiBUdnJ0a28gVXJzdWxpbjoKPiA+ID4gPiA+ IE9uIDA5LzA2LzIwMjEgMjI6MjksIEphc29uIEVrc3RyYW5kIHdyb3RlOgo+ID4gPiA+ID4+Cj4g PiA+ID4gPj4gV2UndmUgdHJpZWQgdG8ga2VlcCBpdCBzb21ld2hhdCBjb250YWluZWQgYnkgZG9p bmcgbW9zdCBvZiB0aGUgaGFyZCB3b3JrCj4gPiA+ID4gPj4gdG8gcHJldmVudCBhY2Nlc3Mgb2Yg cmVjeWNsZWQgb2JqZWN0cyB2aWEgZG1hX2ZlbmNlX2dldF9yY3Vfc2FmZSgpLgo+ID4gPiA+ID4+ IEhvd2V2ZXIsIGEgcXVpY2sgZ3JlcCBvZiBrZXJuZWwgc291cmNlcyBzYXlzIHRoYXQsIG9mIHRo ZSAzMCBpbnN0YW5jZXMKPiA+ID4gPiA+PiBvZiBkbWFfZmVuY2VfZ2V0X3JjdSosIG9ubHkgMTEg b2YgdGhlbSB1c2UgZG1hX2ZlbmNlX2dldF9yY3Vfc2FmZSgpLgo+ID4gPiA+ID4+IEl0J3MgbGlr ZWx5IHRoZXJlIGJlYXIgdHJhcHMgaW4gRFJNIGFuZCByZWxhdGVkIHN1YnN5c3RlbXMganVzdCB3 YWl0aW5nCj4gPiA+ID4gPj4gZm9yIHNvbWVvbmUgdG8gYWNjaWRlbnRhbGx5IHN0ZXAgaW4gdGhl bS4KPiA+ID4gPiA+Cj4gPiA+ID4gPiAuLi5iZWNhdXNlIGRtYV9mZW5jZV9nZXRfcmN1X3NhZmUg YXBlYXJzIHRvIGJlIGFib3V0IHdoZXRoZXIgdGhlCj4gPiA+ID4gPiAqcG9pbnRlciogdG8gdGhl IGZlbmNlIGl0c2VsZiBpcyByY3UgcHJvdGVjdGVkLCBub3QgYWJvdXQgdGhlIGZlbmNlCj4gPiA+ ID4gPiBvYmplY3QgaXRzZWxmLgo+ID4gPiA+Cj4gPiA+ID4gWWVzLCBleGFjdGx5IHRoYXQuCj4g Pgo+ID4gVGhlIGZhY3QgdGhhdCBib3RoIG9mIHlvdSB0aGluayB0aGlzIGVpdGhlciBtZWFucyB0 aGF0IEkndmUgY29tcGxldGVseQo+ID4gbWlzc2VkIHdoYXQncyBnb2luZyBvbiB3aXRoIFJDVXMg aGVyZSAocG9zc2libGUgYnV0LCBpbiB0aGlzIGNhc2UsIEkKPiA+IHRoaW5rIHVubGlrZWx5KSBv ciBSQ1VzIG9uIGRtYSBmZW5jZXMgc2hvdWxkIHNjYXJlIHVzIGFsbC4KPgo+IFRha2luZyBhIHN0 ZXAgYmFjayBmb3IgYSBzZWNvbmQgYW5kIGlnbm9yaW5nIFNMQUJfVFlQRVNBRkVfQllfUkNVIGFz Cj4gc3VjaCwgIEknZCBsaWtlIHRvIGFzayBhIHNsaWdodGx5IGRpZmZlcmVudCBxdWVzdGlvbjog IFdoYXQgYXJlIHRoZQo+IHJ1bGVzIGFib3V0IHdoYXQgaXMgYWxsb3dlZCB0byBiZSBkb25lIHVu ZGVyIHRoZSBSQ1UgcmVhZCBsb2NrIGFuZAo+IHdoYXQgZ3VhcmFudGVlcyBkb2VzIGEgZHJpdmVy IG5lZWQgdG8gcHJvdmlkZT8KPgo+IEkgdGhpbmsgc28gZmFyIHRoYXQgd2UndmUgYWxsIGFncmVl ZCBvbiB0aGUgZm9sbG93aW5nOgo+Cj4gIDEuIEZyZWVpbmcgYW4gdW5zaWduYWxlZCBmZW5jZSBp cyBvayBhcyBsb25nIGFzIGl0IGRvZXNuJ3QgaGF2ZSBhbnkKPiBwZW5kaW5nIGNhbGxiYWNrcy4g IChDYWxsYmFja3Mgc2hvdWxkIGhvbGQgYSByZWZlcmVuY2UgYW55d2F5KS4KPgo+ICAyLiBUaGUg cG9pbnRlciByYWNlIHNvbHZlZCBieSBkbWFfZmVuY2VfZ2V0X3JjdV9zYWZlIGlzIHJlYWwgYW5k Cj4gcmVxdWlyZXMgdGhlIGxvb3AgdG8gc29ydCBvdXQuCj4KPiBCdXQgbGV0J3Mgc2F5IEkgaGF2 ZSBhIGRtYV9mZW5jZSBwb2ludGVyIHRoYXQgSSBnb3QgZnJvbSwgc2F5LCBjYWxsaW5nCj4gZG1h X3Jlc3ZfZXhjbF9mZW5jZSgpIHVuZGVyIHJjdV9yZWFkX2xvY2soKS4gIFdoYXQgYW0gSSBhbGxv d2VkIHRvIGRvCj4gd2l0aCBpdCB1bmRlciB0aGUgUkNVIGxvY2s/ICBXaGF0IGFzc3VtcHRpb25z IGNhbiBJIG1ha2U/ICBJcyB0aGlzCj4gY29kZSwgZm9yIGluc3RhbmNlLCBvaz8KPgo+IHJjdV9y ZWFkX2xvY2soKTsKPiBmZW5jZSA9IGRtYV9yZXN2X2V4Y2xfZmVuY2Uob2JqKTsKPiBpZGxlID0g IWZlbmNlIHx8IHRlc3RfYml0KERNQV9GRU5DRV9GTEFHX1NJR05BTEVEX0JJVCwgJmZlbmNlLT5m bGFncyk7Cj4gcmN1X3JlYWRfdW5sb2NrKCk7Cj4KPiBUaGlzIGNvZGUgdmVyeSBtdWNoIGxvb2tz IGNvcnJlY3QgdW5kZXIgdGhlIGZvbGxvd2luZyBhc3N1bXB0aW9uczoKPgo+ICAxLiBBIHZhbGlk IGZlbmNlIHBvaW50ZXIgc3RheXMgYWxpdmUgdW5kZXIgdGhlIFJDVSByZWFkIGxvY2sKPiAgMi4g U0lHTkFMRURfQklUIGlzIHNldC1vbmNlIChpdCdzIG5ldmVyIHVuc2V0IGFmdGVyIGJlaW5nIHNl dCkuCj4KPiBIb3dldmVyLCBpZiBpdCB3ZXJlLCB3ZSB3b3VsZG4ndCBoYXZlIGRtYV9yZXN2X3Rl c3Rfc2luZ25hbGVkKCksIG5vdwo+IHdvdWxkIHdlPyA6LSkKPgo+IFRoZSBtb21lbnQgeW91IGlu dHJvZHVjZSBBTlkgZG1hX2ZlbmNlIHJlY3ljbGluZyB0aGF0IHJlY3ljbGVzIGEKPiBkbWFfZmVu Y2Ugd2l0aGluIGEgc2luZ2xlIFJDVSBncmFjZSBwZXJpb2QsIGFsbCB5b3VyIGFzc3VtcHRpb25z IGJyZWFrCj4gZG93bi4gIFNMQUJfVFlQRVNBRkVfQllfUkNVIGlzIGp1c3Qgb25lIHdheSB0aGF0 IGk5MTUgZG9lcyB0aGlzLiAgV2UKPiBhbHNvIGhhdmUgYSBsaXR0bGUgaTkxNV9yZXF1ZXN0IHJl Y3ljbGVyIHRvIHRyeSBhbmQgaGVscCB3aXRoIG1lbW9yeQo+IHByZXNzdXJlIHNjZW5hcmlvcyBp biBjZXJ0YWluIGNyaXRpY2FsIHNlY3Rpb25zIHRoYXQgYWxzbyBkb2Vzbid0Cj4gcmVzcGVjdCBS Q1UgZ3JhY2UgcGVyaW9kcy4gIEFuZCwgYXMgbWVudGlvbmVkIG11bHRpcGxlIHRpbWVzLCBvdXIK PiByZWN5Y2xpbmcgbGVha3MgaW50byBldmVyeSBvdGhlciBkcml2ZXIgYmVjYXVzZSwgdGhhbmtz IHRvIGk5MTUncwo+IGNob2ljZSwgdGhlIGFib3ZlIDQtbGluZSBjb2RlIHNuaXBwZXQgaXNuJ3Qg dmFsaWQgQU5ZV0hFUkUgaW4gdGhlCj4ga2VybmVsLgo+Cj4gU28gdGhlIHF1ZXN0aW9uIEknbSBy YWlzaW5nIGlzbid0IHNvIG11Y2ggYWJvdXQgdGhlIHJ1bGVzIHRvZGF5Lgo+IFRvZGF5LCB3ZSBs aXZlIGluIHRoZSB3aWxkIHdpbGQgd2VzdCB3aGVyZSBldmVyeXRoaW5nIGlzIFlPTE8uICBCdXQK PiB3aGVyZSBkbyB3ZSB3YW50IHRvIGdvPyAgRG8gd2UgbGlrZSB0aGlzIHdpbGQgd2VzdCB3b3Js ZD8gIFNvIHdlIHdhbnQKPiBtb3JlIGNvbnNpc3RlbmN5IHVuZGVyIHRoZSBSQ1UgcmVhZCBsb2Nr PyAgSWYgc28sIHdoYXQgZG8gd2Ugd2FudCB0aGUKPiBydWxlcyB0byBiZT8KPgo+IE9uZSBvcHRp b24gd291bGQgYmUgdG8gYWNjZXB0IHRoZSB3aWxkLXdlc3Qgd29ybGQgd2UgbGl2ZSBpbiBhbmQg c2F5Cj4gIlRoZSBSQ1UgcmVhZCBsb2NrIGdhaW5zIHlvdSBub3RoaW5nLiAgSWYgeW91IHdhbnQg dG8gdG91Y2ggdGhlIGd1dHMKPiBvZiBhIGRtYV9mZW5jZSwgdGFrZSBhIHJlZmVyZW5jZSIuICBC dXQsIGF0IHRoYXQgcG9pbnQsIHdlJ3JlIGVhdGluZwo+IHR3byBhdG9taWNzIGZvciBldmVyeSB0 aW1lIHNvbWVvbmUgd2FudHMgdG8gbG9vayBhdCBhIGRtYV9mZW5jZS4gIERvCj4gd2Ugd2FudCB0 aGF0Pwo+Cj4gQWx0ZXJuYXRpdmVseSwgYW5kIHRoaXMgd2hhdCBJIHRoaW5rIERhbmllbCBhbmQg SSB3ZXJlIHRyeWluZyB0bwo+IHByb3Bvc2UgaGVyZSwgaXMgdGhhdCB3ZSBwbGFjZSBzb21lIGNv bnN0cmFpbnRzIG9uIGRtYV9mZW5jZQo+IHJlY3ljbGluZy4gIFNwZWNpZmljYWxseSB0aGF0LCB1 bmRlciB0aGUgUkNVIHJlYWQgbG9jaywgdGhlIGZlbmNlCj4gZG9lc24ndCBzdWRkZW5seSBiZWNv bWUgYSBuZXcgZmVuY2UuICBBbGwgb2YgdGhlIGltbXV0YWJpbGl0eSBhbmQKPiBvbmNlLW11dGFi aWxpdHkgZ3VhcmFudGVlcyBvZiB2YXJpb3VzIGJpdHMgb2YgZG1hX2ZlbmNlIGhvbGQgYXMgbG9u Zwo+IGFzIHlvdSBoYXZlIHRoZSBSQ1UgcmVhZCBsb2NrLgoKWWVhaCB0aGlzIGlzIHN1Ym9wdGlt YWwuIFRvbyBtYW55IHBvdGVudGlhbCBidWdzLCBub3QgZW5vdWdoIGJlbmVmaXRzLgoKVGhpcyBl bnRpcmUgX19yY3UgYnVzaW5lc3Mgc3RhcnRlZCBzbyB0aGF0IHRoZXJlIHdvdWxkIGJlIGEgbG9j a2xlc3MKd2F5IHRvIGdldCBhdCBmZW5jZXMsIG9yIGF0IGxlYXN0IHRoZSBleGNsdXNpdmUgb25l LiBUaGF0IGRpZCBub3QKcmVhbGx5IHBhbiBvdXQuIEkgdGhpbmsgd2UgaGF2ZSBhIGZldyBvcHRp b25zOgoKLSBkcm9wIHRoZSBpZGVhIG9mIHJjdS9sb2NrbGVzcyBkbWEtZmVuY2UgYWNjZXNzIG91 dHJpZ2h0LiBBIHF1aWNrCnNlcXVlbmNlIG9mIGdyYWJiaW5nIHRoZSBsb2NrLCBhY3F1aXJpbmcg dGhlIGRtYV9mZW5jZSBhbmQgdGhlbgpkcm9wcGluZyB5b3VyIGxvY2sgYWdhaW4gaXMgcHJvYmFi bHkgcGxlbnR5IGdvb2QuIFRoZXJlJ3MgYSBsb3Qgb2YKY2FsbF9yY3UgYW5kIG90aGVyIHN0dWZm IHdlIGNvdWxkIHByb2JhYmx5IGRlbGV0ZS4gSSBoYXZlIG5vIGlkZWEgd2hhdAp0aGUgcGVyZiBp bXBhY3QgYWNyb3NzIGFsbCB0aGUgZHJpdmVycyB3b3VsZCBiZS4KCi0gdHJ5IHRvIG1ha2UgYWxs IGRyaXZlcnMgZm9sbG93IHNvbWUgc3RyaWN0ZXIgcnVsZXMuIFRoZSB0cm91YmxlIGlzCnRoYXQg YXQgbGVhc3Qgd2l0aCByYWRlb24gZG1hX2ZlbmNlIGNhbGxiYWNrcyBhcmVuJ3QgZXZlbiB2ZXJ5 CnJlbGlhYmxlICh0aGF0J3Mgd2h5IGl0IGhhcyBpdHMgb3duIGRtYV9mZW5jZV93YWl0IGltcGxl bWVudGF0aW9uKSwgc28KdGhpbmdzIGFyZSB3b2JibHkgYW55d2F5LgoKLSBsaXZlIHdpdGggdGhl IGN1cnJlbnQgc2l0dWF0aW9uLCBidXQgcmFkaWNhbGx5IGRlbGV0ZSBhbGwgdW5zYWZlCmludGVy ZmFjZXMuIEkuZS4gbm90aGluZyBpcyBhbGxvd2VkIHRvIGRpcmVjdGx5IGRlcmVmIGFuIHJjdSBm ZW5jZQpwb2ludGVyLCBldmVyeXRoaW5nIGdvZXMgdGhyb3VnaCBkbWFfZmVuY2VfZ2V0X3JjdV9z YWZlLiBUaGUKa3JlZl9nZXRfdW5sZXNzX3plcm8gd291bGQgYmVjb21lIGFuIGludGVybmFsIGlt cGxlbWVudGF0aW9uIGRldGFpbC4KT3VyICJmYXN0IiBhbmQgImxvY2tsZXNzIiBkbWFfcmVzdiBm ZW5jZSBhY2Nlc3Mgc3RheXMgYSBwaWxlIG9mCnNlcWxvY2ssIHJldHJ5IGxvb3AgYW5kIGFuIGEg Y29uZGl0aW9uYWwgYXRvbWljIGluYyArIGF0b21pYyBkZWMuIFRoZQpvbmx5IHRoaW5nIHRoYXQn cyBzbGlnaHRseSBmYXN0ZXIgd291bGQgYmUgZG1hX3Jlc3ZfdGVzdF9zaWduYWxlZCgpCgotIEkg Z3Vlc3MgbWluaW1hbGx5IHdlIHNob3VsZCByZW5hbWUgZG1hX2ZlbmNlX2dldF9yY3UgdG8KZG1h X2ZlbmNlX3RyeWdldC4gSXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCByY3UgcmVhbGx5LCBhbmQg dGhlIHVzZSBpcwp2ZXJ5LCB2ZXJ5IGxpbWl0ZWQuCgpOb3Qgc3VyZSB3aGF0J3MgYSBnb29kIGlk ZWEgaGVyZSB0YmguCi1EYW5pZWwKLS0gCkRhbmllbCBWZXR0ZXIKU29mdHdhcmUgRW5naW5lZXIs IEludGVsIENvcnBvcmF0aW9uCmh0dHA6Ly9ibG9nLmZmd2xsLmNoCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkludGVsLWdmeCBtYWlsaW5nIGxpc3QKSW50 ZWwtZ2Z4QGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ludGVsLWdmeAo= 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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 2411CC48BE0 for ; Thu, 10 Jun 2021 20:42:54 +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 433F661404 for ; Thu, 10 Jun 2021 20:42:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 433F661404 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 4C79A6EDDD; Thu, 10 Jun 2021 20:42:50 +0000 (UTC) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) by gabe.freedesktop.org (Postfix) with ESMTPS id 45D1D6EDDC for ; Thu, 10 Jun 2021 20:42:49 +0000 (UTC) Received: by mail-ot1-x334.google.com with SMTP id 6-20020a9d07860000b02903e83bf8f8fcso978639oto.12 for ; Thu, 10 Jun 2021 13:42:49 -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=3MteMUmpbOhv5skxW3ZChFAKsrp5eoLJOhSTSRIlg8A=; b=LMgGpM5wo/Fqto1RB0jmfkjSUlY6Y5O3sVD/2KLe7oIr7kCJ1QMFVpSdpbrM28Syzm 8TuhVvQu+g3J6zr07q5fyHwvgCPrE97dfDX5PQyk1yi4vqs47LUC5kgPgrP4t+kykLWB a/pxAoxxFFl/f+o2UfgG11d6KXwVCMlxYJYNk= 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=3MteMUmpbOhv5skxW3ZChFAKsrp5eoLJOhSTSRIlg8A=; b=f+qzqWW3nQy7u7J7jQZnQfjUj8Rx1x2DDoBcv/Gal86JzUjtdpYFsMJtxEH1cszJqZ pjKj+ZQ7FWU8vpeOQwPXovJjNApqt4hXLMr1Ilhfw/Xc1XHcdwZlIQDHJjiQvsl5yam1 JV+CzC9BIe27NmyFjG84v3uyddiw0xPoXIkzIfYkQCyu6KSmwrhp9FN3KS80V2FrU4fV 3oi/1BcGd5nZF1UUlVZ3QwZOfiDM1F4qM5ZsDHX6EJ9EQhw+JdUeViZVF6zNRNmIHGku IIuKK0ge6KuFlkGqS2HO5tZC5lEaYijIMvB/lDEMmlmFxJyHp4FEnUvKT0yhQDOt4akT dnyg== X-Gm-Message-State: AOAM530rtKsVfP+Jq/YAVy1H/bJYyjrtcN9MxfyT0OoAiN2gWrmG3QEV rRSftDlQl4/K7mT2QzLj7eog3x76PYdOIvP4iOETxA== X-Google-Smtp-Source: ABdhPJzSDKdq4MUnQpGarh3SOEwvktAtLgAz7jqCDG5WY2Rg7/mzkfLC17VBf30qhwbJT152N0HlzRRnAmolrQLtNWI= X-Received: by 2002:a9d:12eb:: with SMTP id g98mr179122otg.303.1623357768536; Thu, 10 Jun 2021 13:42:48 -0700 (PDT) MIME-Version: 1.0 References: <20210609212959.471209-1-jason@jlekstrand.net> In-Reply-To: From: Daniel Vetter Date: Thu, 10 Jun 2021 22:42:36 +0200 Message-ID: Subject: Re: [Intel-gfx] [PATCH 0/5] dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence To: Jason Ekstrand 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 , Dave Airlie , =?UTF-8?Q?Christian_K=C3=B6nig?= Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Jun 10, 2021 at 10:10 PM Jason Ekstrand wrot= e: > > On Thu, Jun 10, 2021 at 8:35 AM Jason Ekstrand wro= te: > > On Thu, Jun 10, 2021 at 6:30 AM Daniel Vetter = wrote: > > > 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: > > > > >> > > > > >> We've tried to keep it somewhat contained by doing most of the h= ard 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 ins= tances > > > > >> of dma_fence_get_rcu*, only 11 of them use dma_fence_get_rcu_saf= e(). > > > > >> It's likely there bear traps in DRM and related subsystems just = waiting > > > > >> 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 fen= ce > > > > > object itself. > > > > > > > > Yes, exactly that. > > > > The fact that both of you think this either means that I've completely > > missed what's going on with RCUs here (possible but, in this case, I > > think unlikely) or RCUs on dma fences should scare us all. > > Taking a step back for a second and ignoring SLAB_TYPESAFE_BY_RCU as > such, I'd like to ask a slightly different question: What are the > rules about what is allowed to be done under the RCU read lock and > what guarantees does a driver need to provide? > > I think so far that we've all agreed on the following: > > 1. Freeing an unsignaled fence is ok as long as it doesn't have any > pending callbacks. (Callbacks should hold a reference anyway). > > 2. The pointer race solved by dma_fence_get_rcu_safe is real and > requires the loop to sort out. > > But let's say I have a dma_fence pointer that I got from, say, calling > dma_resv_excl_fence() under rcu_read_lock(). What am I allowed to do > with it under the RCU lock? What assumptions can I make? Is this > code, for instance, ok? > > rcu_read_lock(); > fence =3D dma_resv_excl_fence(obj); > idle =3D !fence || test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags); > rcu_read_unlock(); > > This code very much looks correct under the following assumptions: > > 1. A valid fence pointer stays alive under the RCU read lock > 2. SIGNALED_BIT is set-once (it's never unset after being set). > > However, if it were, we wouldn't have dma_resv_test_singnaled(), now > would we? :-) > > The moment you introduce ANY dma_fence recycling that recycles a > dma_fence within a single RCU grace period, all your assumptions break > down. SLAB_TYPESAFE_BY_RCU is just one way that i915 does this. We > also have a little i915_request recycler to try and help with memory > pressure scenarios in certain critical sections that also doesn't > respect RCU grace periods. And, as mentioned multiple times, our > recycling leaks into every other driver because, thanks to i915's > choice, the above 4-line code snippet isn't valid ANYWHERE in the > kernel. > > So the question I'm raising isn't so much about the rules today. > Today, we live in the wild wild west where everything is YOLO. But > where do we want to go? Do we like this wild west world? So we want > more consistency under the RCU read lock? If so, what do we want the > rules to be? > > One option would be to accept the wild-west world we live in and say > "The RCU read lock gains you nothing. If you want to touch the guts > of a dma_fence, take a reference". But, at that point, we're eating > two atomics for every time someone wants to look at a dma_fence. Do > we want that? > > Alternatively, and this what I think Daniel and I were trying to > propose here, is that we place some constraints on dma_fence > recycling. Specifically that, under the RCU read lock, the fence > doesn't suddenly become a new fence. All of the immutability and > once-mutability guarantees of various bits of dma_fence hold as long > as you have the RCU read lock. Yeah this is suboptimal. Too many potential bugs, not enough benefits. This entire __rcu business started so that there would be a lockless way to get at fences, or at least the exclusive one. That did not really pan out. I think we have a few options: - drop the idea of rcu/lockless dma-fence access outright. A quick sequence of grabbing the lock, acquiring the dma_fence and then dropping your lock again is probably plenty good. There's a lot of call_rcu and other stuff we could probably delete. I have no idea what the perf impact across all the drivers would be. - try to make all drivers follow some stricter rules. The trouble is that at least with radeon dma_fence callbacks aren't even very reliable (that's why it has its own dma_fence_wait implementation), so things are wobbly anyway. - live with the current situation, but radically delete all unsafe interfaces. I.e. nothing is allowed to directly deref an rcu fence pointer, everything goes through dma_fence_get_rcu_safe. The kref_get_unless_zero would become an internal implementation detail. Our "fast" and "lockless" dma_resv fence access stays a pile of seqlock, retry loop and an a conditional atomic inc + atomic dec. The only thing that's slightly faster would be dma_resv_test_signaled() - I guess minimally we should rename dma_fence_get_rcu to dma_fence_tryget. It has nothing to do with rcu really, and the use is very, very limited. Not sure what's a good idea here tbh. -Daniel --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch