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 45BF7C48BDF for ; Thu, 10 Jun 2021 20:10:06 +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 C5376613FF for ; Thu, 10 Jun 2021 20:10:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C5376613FF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=jlekstrand.net 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 115226ED13; Thu, 10 Jun 2021 20:10:01 +0000 (UTC) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) by gabe.freedesktop.org (Postfix) with ESMTPS id 679D46ED13 for ; Thu, 10 Jun 2021 20:09:59 +0000 (UTC) Received: by mail-yb1-xb2e.google.com with SMTP id b13so1073085ybk.4 for ; Thu, 10 Jun 2021 13:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jlekstrand-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mGXTVxUaVXWKPTiYzxUjEsvPKDu3sfvYPmlTlLThP8A=; b=wbOu7cr9NUhpa9CieoDwCJSo425nvLJaXZPFDguxP3u6wp0c5foU48lWOBmWfE0l83 x6O6nHFl+VX7GMIU1bre96TQTe+Pzzf6X7rB/pFSeHmEbtuj9sWLNnlBWsvwf8WMiZwU 6aCWpoCYE77oxYx6ZWs/zcfz7/FhQdOcVqTrErUNE31NNMC0pN4RanbtNjcOPHxk9Iud 6DjS2rvPmhI5DS07462zPrFQqKAiQJ5mHRKJ9kTOjYMOF7iXSc/M9R14M1POF+oagqEB ykAuLbmrrYH9AH2DRyxv5MKXHprRF3eXXY6/Jf1v6/hY3flWTW32R2WZTzszFYEY3SBO YELg== 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=mGXTVxUaVXWKPTiYzxUjEsvPKDu3sfvYPmlTlLThP8A=; b=MUsrPOQEmsLvRtncdXkiHAqk6YwYJ7ffXcSZi8wSCxiI7HPh90DnpnTZgxjC3WEidM ykyQoxBXZMWdkekW3EDmINv7tjJBNjWjwUdMAFoX0yKbjxBjAChEYzYaHAOVcJWfTP9k RJK8ZHU/M8cCpdVDULt/ZeDKJkfaa5ySnSSz2gdBodPuMdSzpHoBEmB7U/spAIYp81j1 Te/Ysxh0P7MA5pmF6hJZ9Rgx0vZzltyLR63c28ZtNPXWOIM7sqhmbm1iZemEBWssOqnx SzkpsT80lEf2OXAx5Y+/Q/ZtobASi5itZKWNK2YP7awlEQ5HtMMJe2DISCkHN/3/hsUE Obeg== X-Gm-Message-State: AOAM53070H6BT40EfO3TRwQNhS33tmy4N9CttxxHvj7OKCHM/XuA2lkm vBZuNLqFrCCJqeQ9jNvl01NQGILXQtLj/ovD3CryYQ== X-Google-Smtp-Source: ABdhPJye+q2A+te5fLc0UhIDoCDqlpp6wKdABFJG/RvnUM0kV4wCk+hIACNK0Cg4/NYtma1h4pnD0CMwYgVZIwV5NTI= X-Received: by 2002:a25:8804:: with SMTP id c4mr693269ybl.469.1623355798361; Thu, 10 Jun 2021 13:09:58 -0700 (PDT) MIME-Version: 1.0 References: <20210609212959.471209-1-jason@jlekstrand.net> In-Reply-To: From: Jason Ekstrand Date: Thu, 10 Jun 2021 15:09:47 -0500 Message-ID: To: Daniel Vetter 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" T24gVGh1LCBKdW4gMTAsIDIwMjEgYXQgODozNSBBTSBKYXNvbiBFa3N0cmFuZCA8amFzb25Aamxl a3N0cmFuZC5uZXQ+IHdyb3RlOgo+IE9uIFRodSwgSnVuIDEwLCAyMDIxIGF0IDY6MzAgQU0gRGFu aWVsIFZldHRlciA8ZGFuaWVsLnZldHRlckBmZndsbC5jaD4gd3JvdGU6Cj4gPiBPbiBUaHUsIEp1 biAxMCwgMjAyMSBhdCAxMTozOSBBTSBDaHJpc3RpYW4gS8O2bmlnCj4gPiA8Y2hyaXN0aWFuLmtv ZW5pZ0BhbWQuY29tPiB3cm90ZToKPiA+ID4gQW0gMTAuMDYuMjEgdW0gMTE6Mjkgc2NocmllYiBU dnJ0a28gVXJzdWxpbjoKPiA+ID4gPiBPbiAwOS8wNi8yMDIxIDIyOjI5LCBKYXNvbiBFa3N0cmFu ZCB3cm90ZToKPiA+ID4gPj4KPiA+ID4gPj4gV2UndmUgdHJpZWQgdG8ga2VlcCBpdCBzb21ld2hh dCBjb250YWluZWQgYnkgZG9pbmcgbW9zdCBvZiB0aGUgaGFyZCB3b3JrCj4gPiA+ID4+IHRvIHBy ZXZlbnQgYWNjZXNzIG9mIHJlY3ljbGVkIG9iamVjdHMgdmlhIGRtYV9mZW5jZV9nZXRfcmN1X3Nh ZmUoKS4KPiA+ID4gPj4gSG93ZXZlciwgYSBxdWljayBncmVwIG9mIGtlcm5lbCBzb3VyY2VzIHNh eXMgdGhhdCwgb2YgdGhlIDMwIGluc3RhbmNlcwo+ID4gPiA+PiBvZiBkbWFfZmVuY2VfZ2V0X3Jj dSosIG9ubHkgMTEgb2YgdGhlbSB1c2UgZG1hX2ZlbmNlX2dldF9yY3Vfc2FmZSgpLgo+ID4gPiA+ PiBJdCdzIGxpa2VseSB0aGVyZSBiZWFyIHRyYXBzIGluIERSTSBhbmQgcmVsYXRlZCBzdWJzeXN0 ZW1zIGp1c3Qgd2FpdGluZwo+ID4gPiA+PiBmb3Igc29tZW9uZSB0byBhY2NpZGVudGFsbHkgc3Rl cCBpbiB0aGVtLgo+ID4gPiA+Cj4gPiA+ID4gLi4uYmVjYXVzZSBkbWFfZmVuY2VfZ2V0X3JjdV9z YWZlIGFwZWFycyB0byBiZSBhYm91dCB3aGV0aGVyIHRoZQo+ID4gPiA+ICpwb2ludGVyKiB0byB0 aGUgZmVuY2UgaXRzZWxmIGlzIHJjdSBwcm90ZWN0ZWQsIG5vdCBhYm91dCB0aGUgZmVuY2UKPiA+ ID4gPiBvYmplY3QgaXRzZWxmLgo+ID4gPgo+ID4gPiBZZXMsIGV4YWN0bHkgdGhhdC4KPgo+IFRo ZSBmYWN0IHRoYXQgYm90aCBvZiB5b3UgdGhpbmsgdGhpcyBlaXRoZXIgbWVhbnMgdGhhdCBJJ3Zl IGNvbXBsZXRlbHkKPiBtaXNzZWQgd2hhdCdzIGdvaW5nIG9uIHdpdGggUkNVcyBoZXJlIChwb3Nz aWJsZSBidXQsIGluIHRoaXMgY2FzZSwgSQo+IHRoaW5rIHVubGlrZWx5KSBvciBSQ1VzIG9uIGRt YSBmZW5jZXMgc2hvdWxkIHNjYXJlIHVzIGFsbC4KClRha2luZyBhIHN0ZXAgYmFjayBmb3IgYSBz ZWNvbmQgYW5kIGlnbm9yaW5nIFNMQUJfVFlQRVNBRkVfQllfUkNVIGFzCnN1Y2gsICBJJ2QgbGlr ZSB0byBhc2sgYSBzbGlnaHRseSBkaWZmZXJlbnQgcXVlc3Rpb246ICBXaGF0IGFyZSB0aGUKcnVs ZXMgYWJvdXQgd2hhdCBpcyBhbGxvd2VkIHRvIGJlIGRvbmUgdW5kZXIgdGhlIFJDVSByZWFkIGxv Y2sgYW5kCndoYXQgZ3VhcmFudGVlcyBkb2VzIGEgZHJpdmVyIG5lZWQgdG8gcHJvdmlkZT8KCkkg dGhpbmsgc28gZmFyIHRoYXQgd2UndmUgYWxsIGFncmVlZCBvbiB0aGUgZm9sbG93aW5nOgoKIDEu IEZyZWVpbmcgYW4gdW5zaWduYWxlZCBmZW5jZSBpcyBvayBhcyBsb25nIGFzIGl0IGRvZXNuJ3Qg aGF2ZSBhbnkKcGVuZGluZyBjYWxsYmFja3MuICAoQ2FsbGJhY2tzIHNob3VsZCBob2xkIGEgcmVm ZXJlbmNlIGFueXdheSkuCgogMi4gVGhlIHBvaW50ZXIgcmFjZSBzb2x2ZWQgYnkgZG1hX2ZlbmNl X2dldF9yY3Vfc2FmZSBpcyByZWFsIGFuZApyZXF1aXJlcyB0aGUgbG9vcCB0byBzb3J0IG91dC4K CkJ1dCBsZXQncyBzYXkgSSBoYXZlIGEgZG1hX2ZlbmNlIHBvaW50ZXIgdGhhdCBJIGdvdCBmcm9t LCBzYXksIGNhbGxpbmcKZG1hX3Jlc3ZfZXhjbF9mZW5jZSgpIHVuZGVyIHJjdV9yZWFkX2xvY2so KS4gIFdoYXQgYW0gSSBhbGxvd2VkIHRvIGRvCndpdGggaXQgdW5kZXIgdGhlIFJDVSBsb2NrPyAg V2hhdCBhc3N1bXB0aW9ucyBjYW4gSSBtYWtlPyAgSXMgdGhpcwpjb2RlLCBmb3IgaW5zdGFuY2Us IG9rPwoKcmN1X3JlYWRfbG9jaygpOwpmZW5jZSA9IGRtYV9yZXN2X2V4Y2xfZmVuY2Uob2JqKTsK aWRsZSA9ICFmZW5jZSB8fCB0ZXN0X2JpdChETUFfRkVOQ0VfRkxBR19TSUdOQUxFRF9CSVQsICZm ZW5jZS0+ZmxhZ3MpOwpyY3VfcmVhZF91bmxvY2soKTsKClRoaXMgY29kZSB2ZXJ5IG11Y2ggbG9v a3MgY29ycmVjdCB1bmRlciB0aGUgZm9sbG93aW5nIGFzc3VtcHRpb25zOgoKIDEuIEEgdmFsaWQg ZmVuY2UgcG9pbnRlciBzdGF5cyBhbGl2ZSB1bmRlciB0aGUgUkNVIHJlYWQgbG9jawogMi4gU0lH TkFMRURfQklUIGlzIHNldC1vbmNlIChpdCdzIG5ldmVyIHVuc2V0IGFmdGVyIGJlaW5nIHNldCku CgpIb3dldmVyLCBpZiBpdCB3ZXJlLCB3ZSB3b3VsZG4ndCBoYXZlIGRtYV9yZXN2X3Rlc3Rfc2lu Z25hbGVkKCksIG5vdwp3b3VsZCB3ZT8gOi0pCgpUaGUgbW9tZW50IHlvdSBpbnRyb2R1Y2UgQU5Z IGRtYV9mZW5jZSByZWN5Y2xpbmcgdGhhdCByZWN5Y2xlcyBhCmRtYV9mZW5jZSB3aXRoaW4gYSBz aW5nbGUgUkNVIGdyYWNlIHBlcmlvZCwgYWxsIHlvdXIgYXNzdW1wdGlvbnMgYnJlYWsKZG93bi4g IFNMQUJfVFlQRVNBRkVfQllfUkNVIGlzIGp1c3Qgb25lIHdheSB0aGF0IGk5MTUgZG9lcyB0aGlz LiAgV2UKYWxzbyBoYXZlIGEgbGl0dGxlIGk5MTVfcmVxdWVzdCByZWN5Y2xlciB0byB0cnkgYW5k IGhlbHAgd2l0aCBtZW1vcnkKcHJlc3N1cmUgc2NlbmFyaW9zIGluIGNlcnRhaW4gY3JpdGljYWwg c2VjdGlvbnMgdGhhdCBhbHNvIGRvZXNuJ3QKcmVzcGVjdCBSQ1UgZ3JhY2UgcGVyaW9kcy4gIEFu ZCwgYXMgbWVudGlvbmVkIG11bHRpcGxlIHRpbWVzLCBvdXIKcmVjeWNsaW5nIGxlYWtzIGludG8g ZXZlcnkgb3RoZXIgZHJpdmVyIGJlY2F1c2UsIHRoYW5rcyB0byBpOTE1J3MKY2hvaWNlLCB0aGUg YWJvdmUgNC1saW5lIGNvZGUgc25pcHBldCBpc24ndCB2YWxpZCBBTllXSEVSRSBpbiB0aGUKa2Vy bmVsLgoKU28gdGhlIHF1ZXN0aW9uIEknbSByYWlzaW5nIGlzbid0IHNvIG11Y2ggYWJvdXQgdGhl IHJ1bGVzIHRvZGF5LgpUb2RheSwgd2UgbGl2ZSBpbiB0aGUgd2lsZCB3aWxkIHdlc3Qgd2hlcmUg ZXZlcnl0aGluZyBpcyBZT0xPLiAgQnV0CndoZXJlIGRvIHdlIHdhbnQgdG8gZ28/ICBEbyB3ZSBs aWtlIHRoaXMgd2lsZCB3ZXN0IHdvcmxkPyAgU28gd2Ugd2FudAptb3JlIGNvbnNpc3RlbmN5IHVu ZGVyIHRoZSBSQ1UgcmVhZCBsb2NrPyAgSWYgc28sIHdoYXQgZG8gd2Ugd2FudCB0aGUKcnVsZXMg dG8gYmU/CgpPbmUgb3B0aW9uIHdvdWxkIGJlIHRvIGFjY2VwdCB0aGUgd2lsZC13ZXN0IHdvcmxk IHdlIGxpdmUgaW4gYW5kIHNheQoiVGhlIFJDVSByZWFkIGxvY2sgZ2FpbnMgeW91IG5vdGhpbmcu ICBJZiB5b3Ugd2FudCB0byB0b3VjaCB0aGUgZ3V0cwpvZiBhIGRtYV9mZW5jZSwgdGFrZSBhIHJl ZmVyZW5jZSIuICBCdXQsIGF0IHRoYXQgcG9pbnQsIHdlJ3JlIGVhdGluZwp0d28gYXRvbWljcyBm b3IgZXZlcnkgdGltZSBzb21lb25lIHdhbnRzIHRvIGxvb2sgYXQgYSBkbWFfZmVuY2UuICBEbwp3 ZSB3YW50IHRoYXQ/CgpBbHRlcm5hdGl2ZWx5LCBhbmQgdGhpcyB3aGF0IEkgdGhpbmsgRGFuaWVs IGFuZCBJIHdlcmUgdHJ5aW5nIHRvCnByb3Bvc2UgaGVyZSwgaXMgdGhhdCB3ZSBwbGFjZSBzb21l IGNvbnN0cmFpbnRzIG9uIGRtYV9mZW5jZQpyZWN5Y2xpbmcuICBTcGVjaWZpY2FsbHkgdGhhdCwg dW5kZXIgdGhlIFJDVSByZWFkIGxvY2ssIHRoZSBmZW5jZQpkb2Vzbid0IHN1ZGRlbmx5IGJlY29t ZSBhIG5ldyBmZW5jZS4gIEFsbCBvZiB0aGUgaW1tdXRhYmlsaXR5IGFuZApvbmNlLW11dGFiaWxp dHkgZ3VhcmFudGVlcyBvZiB2YXJpb3VzIGJpdHMgb2YgZG1hX2ZlbmNlIGhvbGQgYXMgbG9uZwph cyB5b3UgaGF2ZSB0aGUgUkNVIHJlYWQgbG9jay4KCi0tSmFzb24KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4IG1haWxpbmcgbGlzdApJbnRl bC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3Jn L21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== 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 B8E18C48BD1 for ; Thu, 10 Jun 2021 20:10:01 +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 5769E6139A for ; Thu, 10 Jun 2021 20:10:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5769E6139A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=jlekstrand.net 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 9E3156E0AB; Thu, 10 Jun 2021 20:10:00 +0000 (UTC) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4B0506E0AB for ; Thu, 10 Jun 2021 20:09:59 +0000 (UTC) Received: by mail-yb1-xb35.google.com with SMTP id i6so1095192ybm.1 for ; Thu, 10 Jun 2021 13:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jlekstrand-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mGXTVxUaVXWKPTiYzxUjEsvPKDu3sfvYPmlTlLThP8A=; b=wbOu7cr9NUhpa9CieoDwCJSo425nvLJaXZPFDguxP3u6wp0c5foU48lWOBmWfE0l83 x6O6nHFl+VX7GMIU1bre96TQTe+Pzzf6X7rB/pFSeHmEbtuj9sWLNnlBWsvwf8WMiZwU 6aCWpoCYE77oxYx6ZWs/zcfz7/FhQdOcVqTrErUNE31NNMC0pN4RanbtNjcOPHxk9Iud 6DjS2rvPmhI5DS07462zPrFQqKAiQJ5mHRKJ9kTOjYMOF7iXSc/M9R14M1POF+oagqEB ykAuLbmrrYH9AH2DRyxv5MKXHprRF3eXXY6/Jf1v6/hY3flWTW32R2WZTzszFYEY3SBO YELg== 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=mGXTVxUaVXWKPTiYzxUjEsvPKDu3sfvYPmlTlLThP8A=; b=PTVkjaY/u6L287l/dAeAWQnlTObaKh+JSqtuAKSYZQx+mJdzHjebJP8Q9x13DNFChe QlSo+lwbEskJsH+p3XtJBO20nEytSf/vuhyyO2caW+zdHGnx4+vAPww8U4Gw2z7kKVJa kwgrFWP5+aVbFDEQvzwElOTYk+WJKI1b74s6bmArURqBDIU9rFQAwwfhF/W8UcFdlv2L C/i6wWSvM8qMbenR/rFfzxqev/ycJnDKHUmlrw+hJa1SHZN2hN9Y/YCPiXlc7mjeI8GX QXfh7tk8V7vvfdpl0juJyIAqG+JKOYdL/BjDXmMX1AuT/6gfxqM30PhZ9miy9BFdtHaA rVhg== X-Gm-Message-State: AOAM533ytUQP/WlNXFd6N6RlPcfCqSEtv5GkRJomHIVnOV/sMkvAohc/ 9Yf/Jr4h93/9sIjd8P9k2WfSotokM42ruJV0pbDL5w== X-Google-Smtp-Source: ABdhPJye+q2A+te5fLc0UhIDoCDqlpp6wKdABFJG/RvnUM0kV4wCk+hIACNK0Cg4/NYtma1h4pnD0CMwYgVZIwV5NTI= X-Received: by 2002:a25:8804:: with SMTP id c4mr693269ybl.469.1623355798361; Thu, 10 Jun 2021 13:09:58 -0700 (PDT) MIME-Version: 1.0 References: <20210609212959.471209-1-jason@jlekstrand.net> In-Reply-To: From: Jason Ekstrand Date: Thu, 10 Jun 2021 15:09:47 -0500 Message-ID: Subject: Re: [Intel-gfx] [PATCH 0/5] dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence To: Daniel Vetter 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 8:35 AM Jason Ekstrand wrote= : > On Thu, Jun 10, 2021 at 6:30 AM Daniel Vetter wr= ote: > > 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 har= d 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 insta= nces > > > >> 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 wa= iting > > > >> 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. > > 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. --Jason