linux-kernel - Re: [RESEND RFC 18/18] drm/display/dp_mst: Move all payload info into the atomic state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 03 Aug 2022 16:27:51 -0400
From:   Lyude Paul <lyude@...hat.com>
To:     "Lin, Wayne" <Wayne.Lin@....com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>,
        "amd-gfx@...ts.freedesktop.org" <amd-gfx@...ts.freedesktop.org>
Cc:     Ville Syrjälä 
        <ville.syrjala@...ux.intel.com>, "Zuo, Jerry" <Jerry.Zuo@....com>,
        Jani Nikula <jani.nikula@...el.com>,
        Imre Deak <imre.deak@...el.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Sean Paul <sean@...rly.run>,
        "Wentland, Harry" <Harry.Wentland@....com>,
        "Li, Sun peng (Leo)" <Sunpeng.Li@....com>,
        "Siqueira, Rodrigo" <Rodrigo.Siqueira@....com>,
        "Deucher, Alexander" <Alexander.Deucher@....com>,
        "Koenig, Christian" <Christian.Koenig@....com>,
        "Pan, Xinhui" <Xinhui.Pan@....com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
        Ben Skeggs <bskeggs@...hat.com>,
        Karol Herbst <kherbst@...hat.com>,
        "Kazlauskas, Nicholas" <Nicholas.Kazlauskas@....com>,
        "Li, Roman" <Roman.Li@....com>, "Shih, Jude" <Jude.Shih@....com>,
        Simon Ser <contact@...rsion.fr>,
        "Lakha, Bhawanpreet" <Bhawanpreet.Lakha@....com>,
        Mikita Lipski <mikita.lipski@....com>,
        Claudio Suarez <cssk@...-c.es>, "Chen, Ian" <Ian.Chen@....com>,
        Colin Ian King <colin.king@...el.com>,
        "Wu, Hersen" <hersenxs.wu@....com>,
        "Liu, Wenjing" <Wenjing.Liu@....com>, "Lei, Jun" <Jun.Lei@....com>,
        "Strauss, Michael" <Michael.Strauss@....com>,
        "Ma, Leo" <Hanghong.Ma@....com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        José Roberto de Souza 
        <jose.souza@...el.com>, He Ying <heying24@...wei.com>,
        Anshuman Gupta <anshuman.gupta@...el.com>,
        Andi Shyti <andi.shyti@...ux.intel.com>,
        Ashutosh Dixit <ashutosh.dixit@...el.com>,
        Juston Li <juston.li@...el.com>,
        Sean Paul <seanpaul@...omium.org>,
        Fernando Ramos <greenfoo@....eu>,
        Luo Jiaxing <luojiaxing@...wei.com>,
        Javier Martinez Canillas <javierm@...hat.com>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:INTEL DRM DRIVERS" <intel-gfx@...ts.freedesktop.org>
Subject: Re: [RESEND RFC 18/18] drm/display/dp_mst: Move all payload info
 into the atomic state

On Tue, 2022-07-05 at 09:10 +0000, Lin, Wayne wrote:
> > +struct drm_dp_mst_port;
> > +
> >   /* DP MST stream allocation (payload bandwidth number) */
> >   struct dc_dp_mst_stream_allocation {
> >    uint8_t vcp_id;
> >    /* number of slots required for the DP stream in
> >    * transport packet */
> >    uint8_t slot_count;
> > + /* The MST port this is on, this is used to associate DC MST payloads
> > with their
> > + * respective DRM payloads allocations, and can be ignored on non-
> > Linux.
> > + */
> 
> Is it necessary for adding this new member? Since this is for setting the DC
> HW and not relating to drm.

I don't entirely know, honestly. The reasons I did it:

 * Mapping things from DRM to DC and from DC to DRM is really confusing for
   outside contributors like myself, so it wasn't even really clear to me if
   there was another way to reconstruct the DRM context from the spots where
   we call from DC up to DM (not a typo, see next point).
 * These DC structs for MST are already layer mixing as far as I can tell,
   just not in an immediately obvious way. While this struct itself is for DC,
   there's multiple spots where we pass the DC payload structs down from DM to
   DC, then pass them back up from DC to DM and have to figure out how to
   reconstruct the DRM context that we actually need to use the MST helpers
   from that. So, that kind of further complicates the confusion of where
   layers should be separated.
 * As far as I'm aware with C there shouldn't be any issue with adding a
   pointer to a struct whose contents are undefined. IMHO, this is also
   preferable to just using void* because then at least you get some hint as
   to the actual type of the data and avoid the possibility of casting it to
   the wrong type. So tl;dr, on any platform even outside of Linux with a
   reasonably compliant compiler this should still build just fine. It'll even
   give you the added bonus of warning people if they try to access the
   contents of this member in DC on non-Linux platforms. If void* is preferred
   though I'm fine with switching it to that.

-- 
Cheers, Lyude Paul (she/her) Software Engineer at Red Hat