linux-kernel - Re: [RESEND PATCH v3] drm/cma-helper: Describe what a "contiguous chunk" actually means

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] [day] [month] [year] [list]

Date:   Thu, 9 Jun 2022 10:19:22 +0100
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...ux.ie>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        Lucas Stach <l.stach@...gutronix.de>
Subject: Re: [RESEND PATCH v3] drm/cma-helper: Describe what a "contiguous
 chunk" actually means

On Wed, Jun 08, 2022 at 05:37:50PM +0200, Daniel Vetter wrote:
> On Wed, Jun 08, 2022 at 02:58:21PM +0100, Daniel Thompson wrote:
> > Since it's inception in 2012 it has been understood that the DRM GEM CMA
> > helpers do not depend on CMA as the backend allocator. In fact the first
> > bug fix to ensure the cma-helpers work correctly with an IOMMU backend
> > appeared in 2014. However currently the documentation for
> > drm_gem_cma_create() talks about "a contiguous chunk of memory" without
> > making clear which address space it will be a contiguous part of.
> > Additionally the CMA introduction is actively misleading because it only
> > contemplates the CMA backend.
> > 
> > This matters because when the device accesses the bus through an IOMMU
> > (and don't use the CMA backend) then the allocated memory is contiguous
> > only in the IOVA space. This is a significant difference compared to the
> > CMA backend and the behaviour can be a surprise even to someone who does
> > a reasonable level of code browsing (but doesn't find all the relevant
> > function pointers ;-) ).
> > 
> > Improve the kernel doc comments accordingly.
> > 
> > Signed-off-by: Daniel Thompson <daniel.thompson@...aro.org>
> > Reviewed-by: Lucas Stach <l.stach@...gutronix.de>
> > ---
> > 
> > Notes:
> >     Am I Cc:ing the correct reviewers/maintainers with this patch? There
> >     has been no negative feedback but I've been rebasing and re-posting it
> >     for three kernel cycles now. Do I need to queue it somewhere special or
> >     get it in front of someone specific?
> 
> Occasionally stuff falls through a few too many cracks, that's all. We
> have tons of committers for drm-misc (and Lucas is one of them), but
> sometimes they shy away from pushing themselves and others see the r-b and
> assume it's already handled, and then it doesn't move :-/

No worries. Arguably I should have asked this question a little earlier
anyway.


Thanks for pushing it.


Daniel.