Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp2156694rwr; Fri, 21 Apr 2023 05:17:51 -0700 (PDT) X-Google-Smtp-Source: AKy350bckN5BMsYfA83hdWiW9wg1yzBN8msPcD37hgO65CwV3F0svGZwe/N7nyk7sZ6m2yUKCzNf X-Received: by 2002:a05:6a21:3384:b0:f0:251f:f099 with SMTP id yy4-20020a056a21338400b000f0251ff099mr6869852pzb.1.1682079470634; Fri, 21 Apr 2023 05:17:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682079470; cv=none; d=google.com; s=arc-20160816; b=bq43vs3hc/TxRCHICss6MftdR2PSI/WXLHa5r+ATja0wKgeAMH25MklPOVojyapBlw 621Df+Uu85bwYNT7oZDq58mfURNaBP2aVOqezih63TbDr3A8RR+X7DHTIYAdpAjdslAA bLzS7/PIE1qiOVObVBShzdksgHzimdWhHCzD/b7nhLl+IVNVqPfiP27idDQOwF8bcX7O O5cCKn73DtWjeqdf50p/8IMzBENi+h5WXjCnD8L989Dmjiq4toPo85s5FwKZYBTS/8Y4 PSrEWvzoJ1ui6ezA6x89dny7+i8pEZro78zeqmOz0cJfBqozOhgw7io4vLgR+wEtTyRm u90A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=pOvME7tAXZ9JphDrU67XmOOlY2Dekn7UQzOnjzIbu/w=; b=la0Uqt8IFCY+A4GaehQW82CuimSf2YCZJp0zGcalczLfSIR4atS+DfyIaKuPI0kQqi fTEHFsqCq5YrEEUm+duF8cOrtGY5NCDNYKH49WOtHCOgSu4wNcBq7CGjn2kcMqz1uTuE 0MIHFRttqPQF8OAo8/MQn7C/UX9cQ37j0+NuLL2f3X4CATIfBnhk/Q0CgyUi7ziBRL4P TlafOpeZCvS7LjIoPY0KZd9krbDLr7mDzGQ3+MIX9Otn6Yv9hal/tlw7MlbYd8pg97Nt 03zB2N2pWbkqaUUni4+kR+E8w/bhunFHCk8nhwoOrdb0NTImsGbOzo+LYpFuvR0h+RkL YVuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=dOj7qsSo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h9-20020a656389000000b00503a9a71e91si4142674pgv.78.2023.04.21.05.17.25; Fri, 21 Apr 2023 05:17:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=dOj7qsSo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231710AbjDUMNV (ORCPT + 99 others); Fri, 21 Apr 2023 08:13:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229843AbjDUMNU (ORCPT ); Fri, 21 Apr 2023 08:13:20 -0400 Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CF715B93; Fri, 21 Apr 2023 05:13:19 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-b97ec4bbc5aso690532276.3; Fri, 21 Apr 2023 05:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682079198; x=1684671198; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pOvME7tAXZ9JphDrU67XmOOlY2Dekn7UQzOnjzIbu/w=; b=dOj7qsSoqusi9JzHDMCTpPvIgyQPzCzKLm+sIKYvK1CvZPROIce1ddULWduEJd7jrh h9EtoGJ6m1GHmYGpXJU6/6FNPLsCuLt6cW8q2qImYUU4Me5AQY5TlzdLNG24YUAq4d/b zlGbTzgDvqJDlOwMKaEiRsVixMQR0LYg8I9uzwd9DuXOQdacYh2RKW3yFarSSqIZm0e5 jXgDJyaLluMrwFMsYHZLR3DOju3AwGzSKT33SyiKGKcL6YgeBrcoJbjsBjTKixLnXlG+ W46y8eXZCiHZVJ+VEK2Y83z5BnDuzZ4ANfbtnti4CzoG2KX/btAfDEYaiJwWihMcIxck x68g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682079198; x=1684671198; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pOvME7tAXZ9JphDrU67XmOOlY2Dekn7UQzOnjzIbu/w=; b=XUzkxuxPKbuEmyr61zqcdp1aeeyywW2oIenPEgBAjIyigyL3zNgPZcmF7nL4mITHRP WsFpn79wlTZhgQMeNFbra5Sbd/B8ZSQBcy+DrTSs/OV37wxylAxCp+czHMl5IhNIAw6p KL7kDcuUdyxHlJTFWBjlAHQt2WXrv69XDQf/e8EnRpPD2E7bIlQiqOA+gydxgLALsJM0 K2f7ebURBB4aiWQbJjnmtHGxQGdRP7qX485nK1tkM2sNWTG1L1OttmEXOeRkg3BT+WNV 4yplyn1sguMdnA6kcdmCyY+daEvXT0uimmxkkq16VGOTpE7Xfgwso5TtH+6hivmrfJHk 1Jmg== X-Gm-Message-State: AAQBX9fVLeTyPLitPSWr8Hc7HkB86Eq9irGEDW4QcFb4m42UE2yM3NvQ RjGHZOCoU6uUPG/0ncEJFPT3QDbFR2hN5V/fdQo= X-Received: by 2002:a0d:f205:0:b0:541:8810:8d7b with SMTP id b5-20020a0df205000000b0054188108d7bmr1918894ywf.15.1682079198356; Fri, 21 Apr 2023 05:13:18 -0700 (PDT) MIME-Version: 1.0 References: <20230314141904.1210824-1-tvrtko.ursulin@linux.intel.com> <20230314141904.1210824-3-tvrtko.ursulin@linux.intel.com> In-Reply-To: <20230314141904.1210824-3-tvrtko.ursulin@linux.intel.com> From: Emil Velikov Date: Fri, 21 Apr 2023 13:13:07 +0100 Message-ID: Subject: Re: [RFC 02/10] drm: Update file owner during use To: Tvrtko Ursulin Cc: Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Rob Clark , Brian Welty , Kenny.Ho@amd.com, Tvrtko Ursulin , Daniel Vetter , Johannes Weiner , linux-kernel@vger.kernel.org, =?UTF-8?Q?St=C3=A9phane_Marchesin?= , =?UTF-8?Q?Christian_K=C3=B6nig?= , Zefan Li , Dave Airlie , Tejun Heo , cgroups@vger.kernel.org, "T . J . Mercier" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Greetings everyone, Above all - hell yeah. Thank you Tvrtko, this has been annoying the hell out of me for ages. On Tue, 14 Mar 2023 at 14:19, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > With the typical model where the display server opends the file descriptor > and then hands it over to the client we were showing stale data in > debugfs. s/opends/opens/ But as a whole the sentence is fairly misleading. Story time: The traditional model, the server was the orchestrator managing the primary device node. From the fd, to the master status and authentication. But looking at the fd alone, this has varied across the years. IIRC in the DRI1 days, Xorg (libdrm really) would have a list of open fd(s) and reuse those whenever needed, DRI2 the client was responsible for open() themselves and with DRI3 the fd was passed to the client. Around the inception of DRI3 and systemd-logind, the latter became another possible orchestrator. Whereby Xorg and Wayland compositors could ask it for the fd. For various reasons (hysterical and genuine ones) Xorg has a fallback path going the open(), whereas Wayland compositors are moving to solely relying on logind... some never had fallback even. Over the past few years, more projects have emerged which provide functionality similar (be that on API level, Dbus, or otherwise) to systemd-logind. Apart from that, the commit is spot on. I like the use of rcu and the was_master handling is correct. With some message polish this commit is: Reviewed-by: Emil Velikov I also had a brief look at 01/10, although I cannot find many references for the pid <> tguid mappings. Be that on the kernel side or userspace - do you have any links that I can educate myself? Thanks Emil