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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 04701C63797 for ; Thu, 22 Jul 2021 14:17:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E1FA061353 for ; Thu, 22 Jul 2021 14:17:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232389AbhGVNhM (ORCPT ); Thu, 22 Jul 2021 09:37:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232353AbhGVNg6 (ORCPT ); Thu, 22 Jul 2021 09:36:58 -0400 Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42781C061757 for ; Thu, 22 Jul 2021 07:17:31 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id s23so6682112oiw.12 for ; Thu, 22 Jul 2021 07:17:31 -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; bh=KOkTn1Mo3J70M4pI86xRHRtEhS/5VnuRa5a5gN9AGgg=; b=LsVzVbt3s0KFfGDHXPhExLl0OU37cfjOF9hKSeAC0uzfH7noURB5hSgFZLTJNHM1Vu PdYAOHxTDvALN390iroNSMPoAMsFh+9Ir2K4iEsCQr31z7SGvUuLxfa5MU8DV1htQC8T vE88dKRZFdDpqpKrwysvc+Xcu0pVQTZx+E2+g= 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; bh=KOkTn1Mo3J70M4pI86xRHRtEhS/5VnuRa5a5gN9AGgg=; b=UNEaKtrTOTyUB80PqnSgO5BOm7Rbs8WFxluav3LUUI2nW3kTd2jxmPOc8ogYgR5AjW /cyLu3CjikpjLW+w7lBcqrRkBscNlJxz5hydo7IHHnUrSvroGoGSsgY09D/ldjceVvCB ElD2qpBzBEllKbdwIPRZo8Z596Di7X7k59rH6gHdoffQwWnGqPIdS48BwBKxm7JM98DS WGeTkbjJzRLoOudRKhojUEsQSqA3DTVyMsCMsxAK7jAWWaCs3gI1aX/OQFEsv7//TAZ7 tFMFh3GZS6mi6pJYJh1Avyh2N5WRG7UvKGWf9+Vl+TfJP+lrIjb55VdhFhDOJShOaSfK VDbw== X-Gm-Message-State: AOAM531wrpkloGBG1jwYowpOH00mUYKu2XkpH7cqHc5xNuUz31SzCdqM zsgpgXmjANy2MJMAVP5/s8jkHiwP+1NRLVbp+96PSw== X-Google-Smtp-Source: ABdhPJwqTklvotR9LbnbPWDna0E/3csMrWphC75ewwvNxmZ2rg11wkD8Dt31hlSAGFCDJOPSPPQUYSYIZd/CqiU4Roo= X-Received: by 2002:aca:d682:: with SMTP id n124mr174005oig.128.1626963450521; Thu, 22 Jul 2021 07:17:30 -0700 (PDT) MIME-Version: 1.0 References: <20210722092929.244629-1-desmondcheongzx@gmail.com> <20210722092929.244629-3-desmondcheongzx@gmail.com> <5b8b3bd5-7519-e383-cb84-f354d898dc81@gmail.com> In-Reply-To: <5b8b3bd5-7519-e383-cb84-f354d898dc81@gmail.com> From: Daniel Vetter Date: Thu, 22 Jul 2021 16:17:17 +0200 Message-ID: Subject: Re: [PATCH 2/3] drm: clarify lifetime/locking for drm_master's lease fields To: Desmond Cheong Zhi Xi Cc: VMware Graphics , Zack Rusin , Dave Airlie , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , dri-devel , Linux Kernel Mailing List , intel-gfx , Shuah Khan , Greg KH , linux-kernel-mentees@lists.linuxfoundation.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 22, 2021 at 3:03 PM Desmond Cheong Zhi Xi wrote: > > On 22/7/21 6:35 pm, Daniel Vetter wrote: > > On Thu, Jul 22, 2021 at 05:29:28PM +0800, Desmond Cheong Zhi Xi wrote: > >> In particular, we make it clear that &drm_device.mode_config.idr_mutex > >> protects the lease idr and list structures for drm_master. The lessor > >> field itself doesn't need to be protected as it doesn't change after > >> it's set in drm_lease_create. > >> > >> Additionally, we add descriptions for the lifetime of lessors and > >> leases to make it easier to reason about them. > >> > >> Signed-off-by: Desmond Cheong Zhi Xi > >> --- > >> include/drm/drm_auth.h | 62 ++++++++++++++++++++++++++++++++++-------- > >> 1 file changed, 51 insertions(+), 11 deletions(-) > >> > >> diff --git a/include/drm/drm_auth.h b/include/drm/drm_auth.h > >> index f99d3417f304..c978c85464fa 100644 > >> --- a/include/drm/drm_auth.h > >> +++ b/include/drm/drm_auth.h > >> @@ -58,12 +58,6 @@ struct drm_lock_data { > >> * @refcount: Refcount for this master object. > >> * @dev: Link back to the DRM device > >> * @driver_priv: Pointer to driver-private information. > >> - * @lessor: Lease holder > >> - * @lessee_id: id for lessees. Owners always have id 0 > >> - * @lessee_list: other lessees of the same master > >> - * @lessees: drm_masters leasing from this one > >> - * @leases: Objects leased to this drm_master. > >> - * @lessee_idr: All lessees under this owner (only used where lessor == NULL) > >> * > >> * Note that master structures are only relevant for the legacy/primary device > >> * nodes, hence there can only be one per device, not one per drm_minor. > >> @@ -88,17 +82,63 @@ struct drm_master { > >> struct idr magic_map; > >> void *driver_priv; > >> > >> - /* Tree of display resource leases, each of which is a drm_master struct > >> - * All of these get activated simultaneously, so drm_device master points > >> - * at the top of the tree (for which lessor is NULL). Protected by > >> - * &drm_device.mode_config.idr_mutex. > >> + /** > >> + * @lessor: > >> + * > >> + * Lease holder. The lessor does not change once it's set in > > > > Lessor is the lease grantor, lessee is the one receiving the lease. Maybe > > clarify this with > > > > "Lease grantor, only set if this struct drm_master represents a lessee > > holding a lease of objects from @lessor. Full owners of the device have > > this set to NULL." > > > >> + * drm_lease_create(). Each lessee holds a reference to its lessor that > > > > I also figured it'd be a good idea to link to the drm_lease docs here to > > explain the concepts, but alas we don't have those :-( Hence at least > > define what we mean with lessor, lessee, lease and owner. > > > > Thanks for the suggestions, Daniel. I'll incorporate them in a v2. > > Regarding the missing drm_lease docs... any reason we can't just add it > in? Seems like most of the comments in drm_lease.c are almost correctly > formatted too. I could clean them up, define the terms in a preamble, > then add it to the v2 patch. Sure if you want to do that, that would be great. Usual style tips: - We only document driver interfaces, so structs/inline functions in headers and exported symbols in .c files. - Anything else interesting just leave as normal C comments - An overview DOC: section that explains a bit how leases work and why (git blame on the commit that added it should help, otherwise I can type that up) would also be really great. I think the right place for this is in the drm-uapi.rst section after the section about primary nodes: https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#modeset-base-object-abstraction Cheers, Daniel > > >> + * it releases upon being destroyed in drm_lease_destroy(). > >> + * > >> + * Display resource leases form a tree of &struct drm_master. All of > > > > For now we've limited the tree to a depth of 1, you can't create another > > lease if yourself are a lease. I guess another reason to update the > > drm_lease.c docs. > > > > So maybe add "Currently the lease tree depth is limited to 1." > > > >> + * these get activated simultaneously, so &drm_device.master > >> + * points at the top of the tree (for which lessor is NULL). > >> */ > >> - > >> struct drm_master *lessor; > >> + > >> + /** > >> + * @lessee_id: > >> + * > >> + * ID for lessees. Owners always have ID 0. Protected by > > > > Maybe clarify to "Owners (i.e. @lessor is NULL) ..." > > > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + */ > >> int lessee_id; > >> + > >> + /** > >> + * @lessee_list: > >> + * > >> + * List of lessees of the same master. Protected by > > > > We try to distinguis between list entries and the list, even though it's > > the same struct. So maybe > > > > "List entry of lessees of @lessor, where they are linked to @lessee. Not > > use for owners." > > > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > > > >> + */ > >> struct list_head lessee_list; > >> + > >> + /** > >> + * @lessees: > >> + * > >> + * List of drm_masters leasing from this one. Protected by > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + * > >> + * This master cannot be destroyed unless this list is empty as lessors > >> + * are referenced by all their lessees. > > > > Maybe add "this list is empty of no leases have been granted." > > > >> + */ > >> struct list_head lessees; > >> + > >> + /** > >> + * @leases: > >> + * > >> + * Objects leased to this drm_master. Protected by > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + * > >> + * Objects are leased all together in drm_lease_create(), and are > >> + * removed all together when the lease is revoked. > >> + */ > >> struct idr leases; > >> + > >> + /** > >> + * @lessee_idr: > >> + * > >> + * All lessees under this owner (only used where lessor is NULL). > > > > @lessor so it's highlighted correctly > > > >> + * Protected by &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + */ > >> struct idr lessee_idr; > >> /* private: */ > > > > With the nits addressed: > > > > Reviewed-by: Daniel Vetter > > > > Thanks for updating the docs! > > -Daniel > > > >> #if IS_ENABLED(CONFIG_DRM_LEGACY) > >> -- > >> 2.25.1 > >> > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch 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=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 8B8C0C63797 for ; Thu, 22 Jul 2021 14:17:38 +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 5BD556128C for ; Thu, 22 Jul 2021 14:17:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5BD556128C 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 7194D6E8FD; Thu, 22 Jul 2021 14:17:32 +0000 (UTC) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by gabe.freedesktop.org (Postfix) with ESMTPS id 52E8B6E8C9 for ; Thu, 22 Jul 2021 14:17:31 +0000 (UTC) Received: by mail-oi1-x236.google.com with SMTP id c197so6690405oib.11 for ; Thu, 22 Jul 2021 07:17:31 -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; bh=KOkTn1Mo3J70M4pI86xRHRtEhS/5VnuRa5a5gN9AGgg=; b=LsVzVbt3s0KFfGDHXPhExLl0OU37cfjOF9hKSeAC0uzfH7noURB5hSgFZLTJNHM1Vu PdYAOHxTDvALN390iroNSMPoAMsFh+9Ir2K4iEsCQr31z7SGvUuLxfa5MU8DV1htQC8T vE88dKRZFdDpqpKrwysvc+Xcu0pVQTZx+E2+g= 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; bh=KOkTn1Mo3J70M4pI86xRHRtEhS/5VnuRa5a5gN9AGgg=; b=i2phtjuJv47szngaYS5x1kFumWhUQemvL6lKVPVHPvYe1j2HoFVTgq6QEvCUOGIAsj 24fGUXj27Mdnh7FZ7rFfhMtt66JU90FS2njYTc4qX5kx+JUfmKFB0J07T20E8Lv+J64j GElP6x8UCXrlyM9p9RT4DLfHxSWQihluoeKzJkaki7jbPVjeKLU97sF8zxcyZgJDHVxr D3aWI4RemO5Na263tKlx5IGe0sjI0lbdHL8qlEBOLZ7ix3mBxWvvvYnUzVCKp5HmDArR Ism9ulA0yW9IOyCxTdIurr2ufUsnErb0hMHSCB4UD7gLzq4OC2bw0msiGm4eDU99vGkN TKNQ== X-Gm-Message-State: AOAM5309bhme3ynwq217icY8weg3xnEdY59RvHLzsEppo9DNhj9fpJRV IF6Y1054ACrZ2vjkWJ/Vi8OKRN9R+PtfRfcNkDONJg== X-Google-Smtp-Source: ABdhPJwqTklvotR9LbnbPWDna0E/3csMrWphC75ewwvNxmZ2rg11wkD8Dt31hlSAGFCDJOPSPPQUYSYIZd/CqiU4Roo= X-Received: by 2002:aca:d682:: with SMTP id n124mr174005oig.128.1626963450521; Thu, 22 Jul 2021 07:17:30 -0700 (PDT) MIME-Version: 1.0 References: <20210722092929.244629-1-desmondcheongzx@gmail.com> <20210722092929.244629-3-desmondcheongzx@gmail.com> <5b8b3bd5-7519-e383-cb84-f354d898dc81@gmail.com> In-Reply-To: <5b8b3bd5-7519-e383-cb84-f354d898dc81@gmail.com> From: Daniel Vetter Date: Thu, 22 Jul 2021 16:17:17 +0200 Message-ID: To: Desmond Cheong Zhi Xi Subject: Re: [Intel-gfx] [PATCH 2/3] drm: clarify lifetime/locking for drm_master's lease fields 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: Dave Airlie , Greg KH , intel-gfx , Linux Kernel Mailing List , Maxime Ripard , VMware Graphics , dri-devel , Thomas Zimmermann , Shuah Khan , linux-kernel-mentees@lists.linuxfoundation.org, Zack Rusin Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Thu, Jul 22, 2021 at 3:03 PM Desmond Cheong Zhi Xi wrote: > > On 22/7/21 6:35 pm, Daniel Vetter wrote: > > On Thu, Jul 22, 2021 at 05:29:28PM +0800, Desmond Cheong Zhi Xi wrote: > >> In particular, we make it clear that &drm_device.mode_config.idr_mutex > >> protects the lease idr and list structures for drm_master. The lessor > >> field itself doesn't need to be protected as it doesn't change after > >> it's set in drm_lease_create. > >> > >> Additionally, we add descriptions for the lifetime of lessors and > >> leases to make it easier to reason about them. > >> > >> Signed-off-by: Desmond Cheong Zhi Xi > >> --- > >> include/drm/drm_auth.h | 62 ++++++++++++++++++++++++++++++++++-------- > >> 1 file changed, 51 insertions(+), 11 deletions(-) > >> > >> diff --git a/include/drm/drm_auth.h b/include/drm/drm_auth.h > >> index f99d3417f304..c978c85464fa 100644 > >> --- a/include/drm/drm_auth.h > >> +++ b/include/drm/drm_auth.h > >> @@ -58,12 +58,6 @@ struct drm_lock_data { > >> * @refcount: Refcount for this master object. > >> * @dev: Link back to the DRM device > >> * @driver_priv: Pointer to driver-private information. > >> - * @lessor: Lease holder > >> - * @lessee_id: id for lessees. Owners always have id 0 > >> - * @lessee_list: other lessees of the same master > >> - * @lessees: drm_masters leasing from this one > >> - * @leases: Objects leased to this drm_master. > >> - * @lessee_idr: All lessees under this owner (only used where lessor == NULL) > >> * > >> * Note that master structures are only relevant for the legacy/primary device > >> * nodes, hence there can only be one per device, not one per drm_minor. > >> @@ -88,17 +82,63 @@ struct drm_master { > >> struct idr magic_map; > >> void *driver_priv; > >> > >> - /* Tree of display resource leases, each of which is a drm_master struct > >> - * All of these get activated simultaneously, so drm_device master points > >> - * at the top of the tree (for which lessor is NULL). Protected by > >> - * &drm_device.mode_config.idr_mutex. > >> + /** > >> + * @lessor: > >> + * > >> + * Lease holder. The lessor does not change once it's set in > > > > Lessor is the lease grantor, lessee is the one receiving the lease. Maybe > > clarify this with > > > > "Lease grantor, only set if this struct drm_master represents a lessee > > holding a lease of objects from @lessor. Full owners of the device have > > this set to NULL." > > > >> + * drm_lease_create(). Each lessee holds a reference to its lessor that > > > > I also figured it'd be a good idea to link to the drm_lease docs here to > > explain the concepts, but alas we don't have those :-( Hence at least > > define what we mean with lessor, lessee, lease and owner. > > > > Thanks for the suggestions, Daniel. I'll incorporate them in a v2. > > Regarding the missing drm_lease docs... any reason we can't just add it > in? Seems like most of the comments in drm_lease.c are almost correctly > formatted too. I could clean them up, define the terms in a preamble, > then add it to the v2 patch. Sure if you want to do that, that would be great. Usual style tips: - We only document driver interfaces, so structs/inline functions in headers and exported symbols in .c files. - Anything else interesting just leave as normal C comments - An overview DOC: section that explains a bit how leases work and why (git blame on the commit that added it should help, otherwise I can type that up) would also be really great. I think the right place for this is in the drm-uapi.rst section after the section about primary nodes: https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#modeset-base-object-abstraction Cheers, Daniel > > >> + * it releases upon being destroyed in drm_lease_destroy(). > >> + * > >> + * Display resource leases form a tree of &struct drm_master. All of > > > > For now we've limited the tree to a depth of 1, you can't create another > > lease if yourself are a lease. I guess another reason to update the > > drm_lease.c docs. > > > > So maybe add "Currently the lease tree depth is limited to 1." > > > >> + * these get activated simultaneously, so &drm_device.master > >> + * points at the top of the tree (for which lessor is NULL). > >> */ > >> - > >> struct drm_master *lessor; > >> + > >> + /** > >> + * @lessee_id: > >> + * > >> + * ID for lessees. Owners always have ID 0. Protected by > > > > Maybe clarify to "Owners (i.e. @lessor is NULL) ..." > > > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + */ > >> int lessee_id; > >> + > >> + /** > >> + * @lessee_list: > >> + * > >> + * List of lessees of the same master. Protected by > > > > We try to distinguis between list entries and the list, even though it's > > the same struct. So maybe > > > > "List entry of lessees of @lessor, where they are linked to @lessee. Not > > use for owners." > > > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > > > >> + */ > >> struct list_head lessee_list; > >> + > >> + /** > >> + * @lessees: > >> + * > >> + * List of drm_masters leasing from this one. Protected by > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + * > >> + * This master cannot be destroyed unless this list is empty as lessors > >> + * are referenced by all their lessees. > > > > Maybe add "this list is empty of no leases have been granted." > > > >> + */ > >> struct list_head lessees; > >> + > >> + /** > >> + * @leases: > >> + * > >> + * Objects leased to this drm_master. Protected by > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + * > >> + * Objects are leased all together in drm_lease_create(), and are > >> + * removed all together when the lease is revoked. > >> + */ > >> struct idr leases; > >> + > >> + /** > >> + * @lessee_idr: > >> + * > >> + * All lessees under this owner (only used where lessor is NULL). > > > > @lessor so it's highlighted correctly > > > >> + * Protected by &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + */ > >> struct idr lessee_idr; > >> /* private: */ > > > > With the nits addressed: > > > > Reviewed-by: Daniel Vetter > > > > Thanks for updating the docs! > > -Daniel > > > >> #if IS_ENABLED(CONFIG_DRM_LEGACY) > >> -- > >> 2.25.1 > >> > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx 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=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, 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 5206DC63793 for ; Thu, 22 Jul 2021 14:17:34 +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 6D5C16128C for ; Thu, 22 Jul 2021 14:17:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D5C16128C 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 2AECB6E8C9; Thu, 22 Jul 2021 14:17:32 +0000 (UTC) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by gabe.freedesktop.org (Postfix) with ESMTPS id 63BDE6E8FD for ; Thu, 22 Jul 2021 14:17:31 +0000 (UTC) Received: by mail-oi1-x229.google.com with SMTP id w188so6690354oif.10 for ; Thu, 22 Jul 2021 07:17:31 -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; bh=KOkTn1Mo3J70M4pI86xRHRtEhS/5VnuRa5a5gN9AGgg=; b=LsVzVbt3s0KFfGDHXPhExLl0OU37cfjOF9hKSeAC0uzfH7noURB5hSgFZLTJNHM1Vu PdYAOHxTDvALN390iroNSMPoAMsFh+9Ir2K4iEsCQr31z7SGvUuLxfa5MU8DV1htQC8T vE88dKRZFdDpqpKrwysvc+Xcu0pVQTZx+E2+g= 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; bh=KOkTn1Mo3J70M4pI86xRHRtEhS/5VnuRa5a5gN9AGgg=; b=IUqZiRULahVSbh4vBD75qDk1aTCgN0nquF6Cu/dsA44dek6NtiR1omz3GApI3QRPFl F0y+6RRJmqADPjusKbA2n1/23NyU218n/cdsvr/IYKdqdPzaI9xOHGWplow2BFh0vMID iG+V2vC9CpY5nbI+dM8vRwjGNBsZwyehLxfhF2LdB86VP+GzvbBEaLSe0aY5eP3+PXuK 2SFVjuEtUt30qo8DyRlOIJKeugPBwygeS3TDl6DEKTQzEhvMTwCRLZ2Ktldrv4rWtPHz nNfsB0L6BljjTnk/gvNVJMemEJGjfjSpzWiUl5L/GqbqyL28Bzcu+6W3e44+dHDxFRA5 l0LA== X-Gm-Message-State: AOAM533yuvwY1AwHPThd4A/Kl8Mr0vAeLQrej8AR+kiFSTbe5Jm0kvom pdCnFt2d/J4tfjDWr6ZcXUhUFxmTE1B0D8ejelooDg== X-Google-Smtp-Source: ABdhPJwqTklvotR9LbnbPWDna0E/3csMrWphC75ewwvNxmZ2rg11wkD8Dt31hlSAGFCDJOPSPPQUYSYIZd/CqiU4Roo= X-Received: by 2002:aca:d682:: with SMTP id n124mr174005oig.128.1626963450521; Thu, 22 Jul 2021 07:17:30 -0700 (PDT) MIME-Version: 1.0 References: <20210722092929.244629-1-desmondcheongzx@gmail.com> <20210722092929.244629-3-desmondcheongzx@gmail.com> <5b8b3bd5-7519-e383-cb84-f354d898dc81@gmail.com> In-Reply-To: <5b8b3bd5-7519-e383-cb84-f354d898dc81@gmail.com> From: Daniel Vetter Date: Thu, 22 Jul 2021 16:17:17 +0200 Message-ID: Subject: Re: [PATCH 2/3] drm: clarify lifetime/locking for drm_master's lease fields To: Desmond Cheong Zhi Xi Content-Type: text/plain; charset="UTF-8" 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: Dave Airlie , Greg KH , intel-gfx , Linux Kernel Mailing List , VMware Graphics , dri-devel , Thomas Zimmermann , Shuah Khan , linux-kernel-mentees@lists.linuxfoundation.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Jul 22, 2021 at 3:03 PM Desmond Cheong Zhi Xi wrote: > > On 22/7/21 6:35 pm, Daniel Vetter wrote: > > On Thu, Jul 22, 2021 at 05:29:28PM +0800, Desmond Cheong Zhi Xi wrote: > >> In particular, we make it clear that &drm_device.mode_config.idr_mutex > >> protects the lease idr and list structures for drm_master. The lessor > >> field itself doesn't need to be protected as it doesn't change after > >> it's set in drm_lease_create. > >> > >> Additionally, we add descriptions for the lifetime of lessors and > >> leases to make it easier to reason about them. > >> > >> Signed-off-by: Desmond Cheong Zhi Xi > >> --- > >> include/drm/drm_auth.h | 62 ++++++++++++++++++++++++++++++++++-------- > >> 1 file changed, 51 insertions(+), 11 deletions(-) > >> > >> diff --git a/include/drm/drm_auth.h b/include/drm/drm_auth.h > >> index f99d3417f304..c978c85464fa 100644 > >> --- a/include/drm/drm_auth.h > >> +++ b/include/drm/drm_auth.h > >> @@ -58,12 +58,6 @@ struct drm_lock_data { > >> * @refcount: Refcount for this master object. > >> * @dev: Link back to the DRM device > >> * @driver_priv: Pointer to driver-private information. > >> - * @lessor: Lease holder > >> - * @lessee_id: id for lessees. Owners always have id 0 > >> - * @lessee_list: other lessees of the same master > >> - * @lessees: drm_masters leasing from this one > >> - * @leases: Objects leased to this drm_master. > >> - * @lessee_idr: All lessees under this owner (only used where lessor == NULL) > >> * > >> * Note that master structures are only relevant for the legacy/primary device > >> * nodes, hence there can only be one per device, not one per drm_minor. > >> @@ -88,17 +82,63 @@ struct drm_master { > >> struct idr magic_map; > >> void *driver_priv; > >> > >> - /* Tree of display resource leases, each of which is a drm_master struct > >> - * All of these get activated simultaneously, so drm_device master points > >> - * at the top of the tree (for which lessor is NULL). Protected by > >> - * &drm_device.mode_config.idr_mutex. > >> + /** > >> + * @lessor: > >> + * > >> + * Lease holder. The lessor does not change once it's set in > > > > Lessor is the lease grantor, lessee is the one receiving the lease. Maybe > > clarify this with > > > > "Lease grantor, only set if this struct drm_master represents a lessee > > holding a lease of objects from @lessor. Full owners of the device have > > this set to NULL." > > > >> + * drm_lease_create(). Each lessee holds a reference to its lessor that > > > > I also figured it'd be a good idea to link to the drm_lease docs here to > > explain the concepts, but alas we don't have those :-( Hence at least > > define what we mean with lessor, lessee, lease and owner. > > > > Thanks for the suggestions, Daniel. I'll incorporate them in a v2. > > Regarding the missing drm_lease docs... any reason we can't just add it > in? Seems like most of the comments in drm_lease.c are almost correctly > formatted too. I could clean them up, define the terms in a preamble, > then add it to the v2 patch. Sure if you want to do that, that would be great. Usual style tips: - We only document driver interfaces, so structs/inline functions in headers and exported symbols in .c files. - Anything else interesting just leave as normal C comments - An overview DOC: section that explains a bit how leases work and why (git blame on the commit that added it should help, otherwise I can type that up) would also be really great. I think the right place for this is in the drm-uapi.rst section after the section about primary nodes: https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#modeset-base-object-abstraction Cheers, Daniel > > >> + * it releases upon being destroyed in drm_lease_destroy(). > >> + * > >> + * Display resource leases form a tree of &struct drm_master. All of > > > > For now we've limited the tree to a depth of 1, you can't create another > > lease if yourself are a lease. I guess another reason to update the > > drm_lease.c docs. > > > > So maybe add "Currently the lease tree depth is limited to 1." > > > >> + * these get activated simultaneously, so &drm_device.master > >> + * points at the top of the tree (for which lessor is NULL). > >> */ > >> - > >> struct drm_master *lessor; > >> + > >> + /** > >> + * @lessee_id: > >> + * > >> + * ID for lessees. Owners always have ID 0. Protected by > > > > Maybe clarify to "Owners (i.e. @lessor is NULL) ..." > > > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + */ > >> int lessee_id; > >> + > >> + /** > >> + * @lessee_list: > >> + * > >> + * List of lessees of the same master. Protected by > > > > We try to distinguis between list entries and the list, even though it's > > the same struct. So maybe > > > > "List entry of lessees of @lessor, where they are linked to @lessee. Not > > use for owners." > > > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > > > >> + */ > >> struct list_head lessee_list; > >> + > >> + /** > >> + * @lessees: > >> + * > >> + * List of drm_masters leasing from this one. Protected by > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + * > >> + * This master cannot be destroyed unless this list is empty as lessors > >> + * are referenced by all their lessees. > > > > Maybe add "this list is empty of no leases have been granted." > > > >> + */ > >> struct list_head lessees; > >> + > >> + /** > >> + * @leases: > >> + * > >> + * Objects leased to this drm_master. Protected by > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + * > >> + * Objects are leased all together in drm_lease_create(), and are > >> + * removed all together when the lease is revoked. > >> + */ > >> struct idr leases; > >> + > >> + /** > >> + * @lessee_idr: > >> + * > >> + * All lessees under this owner (only used where lessor is NULL). > > > > @lessor so it's highlighted correctly > > > >> + * Protected by &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + */ > >> struct idr lessee_idr; > >> /* private: */ > > > > With the nits addressed: > > > > Reviewed-by: Daniel Vetter > > > > Thanks for updating the docs! > > -Daniel > > > >> #if IS_ENABLED(CONFIG_DRM_LEGACY) > >> -- > >> 2.25.1 > >> > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch 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=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 0EDFBC6377D for ; Thu, 22 Jul 2021 14:17:38 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (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 2AA276128D for ; Thu, 22 Jul 2021 14:17:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2AA276128D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-kernel-mentees-bounces@lists.linuxfoundation.org Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id E4924405BF; Thu, 22 Jul 2021 14:17:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXPa9hHrmUbb; Thu, 22 Jul 2021 14:17:35 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp4.osuosl.org (Postfix) with ESMTPS id 7B75D405B1; Thu, 22 Jul 2021 14:17:35 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 593E7C001A; Thu, 22 Jul 2021 14:17:35 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 09415C000E for ; Thu, 22 Jul 2021 14:17:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id EAA26608BB for ; Thu, 22 Jul 2021 14:17:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=ffwll.ch Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-bx19mGVmRA for ; Thu, 22 Jul 2021 14:17:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) by smtp3.osuosl.org (Postfix) with ESMTPS id C6F8B608C3 for ; Thu, 22 Jul 2021 14:17:31 +0000 (UTC) Received: by mail-oi1-x230.google.com with SMTP id t143so6713628oie.8 for ; Thu, 22 Jul 2021 07:17:31 -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; bh=KOkTn1Mo3J70M4pI86xRHRtEhS/5VnuRa5a5gN9AGgg=; b=LsVzVbt3s0KFfGDHXPhExLl0OU37cfjOF9hKSeAC0uzfH7noURB5hSgFZLTJNHM1Vu PdYAOHxTDvALN390iroNSMPoAMsFh+9Ir2K4iEsCQr31z7SGvUuLxfa5MU8DV1htQC8T vE88dKRZFdDpqpKrwysvc+Xcu0pVQTZx+E2+g= 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; bh=KOkTn1Mo3J70M4pI86xRHRtEhS/5VnuRa5a5gN9AGgg=; b=N8Hh9X+/+Rdy8f4e1ns1ght+6PxBlqKEVQIxjiz6SV6s9nXdboR3MO1j1fVq/C3o9z zDsc0uEhoM5LjdnoF7yzDdyYw+B2l98MZ5mjuxGOkjxTLsyuZLgZTuV8YJ8RcQOBM+xb zPlf4YSHxqZiHdYPniLhBBnof4yTmp9Op8iKEb1jq4w6BuimyHenlg7ibwsFdOBeVG2r P1wKi6YJr0E3E0s/+M4ZSNhjH1c147Tcf/Sa+2W9E9u/2soY/pj4px+DIFThgQSFA5hr 90cXemtCd2TH1ehjTCngfsZzluM1ZIbjim8mMAyv/CPYr2TrkIeui8IAIWtyrskACQCL rpHw== X-Gm-Message-State: AOAM530JV2Hn7TCLXeimPH+MVqVbg6wScyRRkNaqu4xyIIfcivhSWjXe j9syVRbs0MqaMkrcu/5cxlXQqMoJ+VzWEi6rMcoBrQ== X-Google-Smtp-Source: ABdhPJwqTklvotR9LbnbPWDna0E/3csMrWphC75ewwvNxmZ2rg11wkD8Dt31hlSAGFCDJOPSPPQUYSYIZd/CqiU4Roo= X-Received: by 2002:aca:d682:: with SMTP id n124mr174005oig.128.1626963450521; Thu, 22 Jul 2021 07:17:30 -0700 (PDT) MIME-Version: 1.0 References: <20210722092929.244629-1-desmondcheongzx@gmail.com> <20210722092929.244629-3-desmondcheongzx@gmail.com> <5b8b3bd5-7519-e383-cb84-f354d898dc81@gmail.com> In-Reply-To: <5b8b3bd5-7519-e383-cb84-f354d898dc81@gmail.com> From: Daniel Vetter Date: Thu, 22 Jul 2021 16:17:17 +0200 Message-ID: Subject: Re: [PATCH 2/3] drm: clarify lifetime/locking for drm_master's lease fields To: Desmond Cheong Zhi Xi Cc: Dave Airlie , intel-gfx , Maarten Lankhorst , Linux Kernel Mailing List , Maxime Ripard , VMware Graphics , dri-devel , Thomas Zimmermann , linux-kernel-mentees@lists.linuxfoundation.org, Zack Rusin X-BeenThere: linux-kernel-mentees@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-kernel-mentees-bounces@lists.linuxfoundation.org Sender: "Linux-kernel-mentees" On Thu, Jul 22, 2021 at 3:03 PM Desmond Cheong Zhi Xi wrote: > > On 22/7/21 6:35 pm, Daniel Vetter wrote: > > On Thu, Jul 22, 2021 at 05:29:28PM +0800, Desmond Cheong Zhi Xi wrote: > >> In particular, we make it clear that &drm_device.mode_config.idr_mutex > >> protects the lease idr and list structures for drm_master. The lessor > >> field itself doesn't need to be protected as it doesn't change after > >> it's set in drm_lease_create. > >> > >> Additionally, we add descriptions for the lifetime of lessors and > >> leases to make it easier to reason about them. > >> > >> Signed-off-by: Desmond Cheong Zhi Xi > >> --- > >> include/drm/drm_auth.h | 62 ++++++++++++++++++++++++++++++++++-------- > >> 1 file changed, 51 insertions(+), 11 deletions(-) > >> > >> diff --git a/include/drm/drm_auth.h b/include/drm/drm_auth.h > >> index f99d3417f304..c978c85464fa 100644 > >> --- a/include/drm/drm_auth.h > >> +++ b/include/drm/drm_auth.h > >> @@ -58,12 +58,6 @@ struct drm_lock_data { > >> * @refcount: Refcount for this master object. > >> * @dev: Link back to the DRM device > >> * @driver_priv: Pointer to driver-private information. > >> - * @lessor: Lease holder > >> - * @lessee_id: id for lessees. Owners always have id 0 > >> - * @lessee_list: other lessees of the same master > >> - * @lessees: drm_masters leasing from this one > >> - * @leases: Objects leased to this drm_master. > >> - * @lessee_idr: All lessees under this owner (only used where lessor == NULL) > >> * > >> * Note that master structures are only relevant for the legacy/primary device > >> * nodes, hence there can only be one per device, not one per drm_minor. > >> @@ -88,17 +82,63 @@ struct drm_master { > >> struct idr magic_map; > >> void *driver_priv; > >> > >> - /* Tree of display resource leases, each of which is a drm_master struct > >> - * All of these get activated simultaneously, so drm_device master points > >> - * at the top of the tree (for which lessor is NULL). Protected by > >> - * &drm_device.mode_config.idr_mutex. > >> + /** > >> + * @lessor: > >> + * > >> + * Lease holder. The lessor does not change once it's set in > > > > Lessor is the lease grantor, lessee is the one receiving the lease. Maybe > > clarify this with > > > > "Lease grantor, only set if this struct drm_master represents a lessee > > holding a lease of objects from @lessor. Full owners of the device have > > this set to NULL." > > > >> + * drm_lease_create(). Each lessee holds a reference to its lessor that > > > > I also figured it'd be a good idea to link to the drm_lease docs here to > > explain the concepts, but alas we don't have those :-( Hence at least > > define what we mean with lessor, lessee, lease and owner. > > > > Thanks for the suggestions, Daniel. I'll incorporate them in a v2. > > Regarding the missing drm_lease docs... any reason we can't just add it > in? Seems like most of the comments in drm_lease.c are almost correctly > formatted too. I could clean them up, define the terms in a preamble, > then add it to the v2 patch. Sure if you want to do that, that would be great. Usual style tips: - We only document driver interfaces, so structs/inline functions in headers and exported symbols in .c files. - Anything else interesting just leave as normal C comments - An overview DOC: section that explains a bit how leases work and why (git blame on the commit that added it should help, otherwise I can type that up) would also be really great. I think the right place for this is in the drm-uapi.rst section after the section about primary nodes: https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#modeset-base-object-abstraction Cheers, Daniel > > >> + * it releases upon being destroyed in drm_lease_destroy(). > >> + * > >> + * Display resource leases form a tree of &struct drm_master. All of > > > > For now we've limited the tree to a depth of 1, you can't create another > > lease if yourself are a lease. I guess another reason to update the > > drm_lease.c docs. > > > > So maybe add "Currently the lease tree depth is limited to 1." > > > >> + * these get activated simultaneously, so &drm_device.master > >> + * points at the top of the tree (for which lessor is NULL). > >> */ > >> - > >> struct drm_master *lessor; > >> + > >> + /** > >> + * @lessee_id: > >> + * > >> + * ID for lessees. Owners always have ID 0. Protected by > > > > Maybe clarify to "Owners (i.e. @lessor is NULL) ..." > > > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + */ > >> int lessee_id; > >> + > >> + /** > >> + * @lessee_list: > >> + * > >> + * List of lessees of the same master. Protected by > > > > We try to distinguis between list entries and the list, even though it's > > the same struct. So maybe > > > > "List entry of lessees of @lessor, where they are linked to @lessee. Not > > use for owners." > > > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > > > >> + */ > >> struct list_head lessee_list; > >> + > >> + /** > >> + * @lessees: > >> + * > >> + * List of drm_masters leasing from this one. Protected by > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + * > >> + * This master cannot be destroyed unless this list is empty as lessors > >> + * are referenced by all their lessees. > > > > Maybe add "this list is empty of no leases have been granted." > > > >> + */ > >> struct list_head lessees; > >> + > >> + /** > >> + * @leases: > >> + * > >> + * Objects leased to this drm_master. Protected by > >> + * &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + * > >> + * Objects are leased all together in drm_lease_create(), and are > >> + * removed all together when the lease is revoked. > >> + */ > >> struct idr leases; > >> + > >> + /** > >> + * @lessee_idr: > >> + * > >> + * All lessees under this owner (only used where lessor is NULL). > > > > @lessor so it's highlighted correctly > > > >> + * Protected by &drm_device.mode_config's &drm_mode_config.idr_mutex. > >> + */ > >> struct idr lessee_idr; > >> /* private: */ > > > > With the nits addressed: > > > > Reviewed-by: Daniel Vetter > > > > Thanks for updating the docs! > > -Daniel > > > >> #if IS_ENABLED(CONFIG_DRM_LEGACY) > >> -- > >> 2.25.1 > >> > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees