linux-kernel - Re: [PATCH v4 3/7] drm/gpuvm: Pass map arguments through a struct

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]

Message-ID: <20250821135320.670f2409@fedora>
Date: Thu, 21 Aug 2025 13:53:20 +0200
From: Boris Brezillon <boris.brezillon@...labora.com>
To: "Danilo Krummrich" <dakr@...nel.org>
Cc: "Caterina Shablia" <caterina.shablia@...labora.com>, "Maarten Lankhorst"
 <maarten.lankhorst@...ux.intel.com>, "Maxime Ripard" <mripard@...nel.org>,
 "Thomas Zimmermann" <tzimmermann@...e.de>, "David Airlie"
 <airlied@...il.com>, "Simona Vetter" <simona@...ll.ch>, "Frank Binns"
 <frank.binns@...tec.com>, "Matt Coster" <matt.coster@...tec.com>, "Karol
 Herbst" <kherbst@...hat.com>, "Lyude Paul" <lyude@...hat.com>, "Steven
 Price" <steven.price@....com>, "Liviu Dudau" <liviu.dudau@....com>, "Lucas
 De Marchi" <lucas.demarchi@...el.com>, Thomas Hellström
 <thomas.hellstrom@...ux.intel.com>, "Rodrigo Vivi"
 <rodrigo.vivi@...el.com>, <dri-devel@...ts.freedesktop.org>,
 <linux-kernel@...r.kernel.org>, <nouveau@...ts.freedesktop.org>,
 <intel-xe@...ts.freedesktop.org>, <asahi@...ts.linux.dev>, "Asahi Lina"
 <lina@...hilina.net>
Subject: Re: [PATCH v4 3/7] drm/gpuvm: Pass map arguments through a struct

On Mon, 07 Jul 2025 20:44:49 +0200
"Danilo Krummrich" <dakr@...nel.org> wrote:

> On Mon Jul 7, 2025 at 7:04 PM CEST, Caterina Shablia wrote:
> > +/**
> > + * struct drm_gpuvm_map_req - arguments passed to drm_gpuvm_sm_map[_ops_create]()
> > + */
> > +struct drm_gpuvm_map_req {
> > +	/** @va: virtual address related fields */
> > +	struct {
> > +		/** @va.addr: start of the virtual address range to map to */
> > +		u64 addr;
> > +
> > +		/** @va.size: size of the virtual address range to map to */
> > +		u64 range;
> > +	} va;
> > +
> > +	/** @gem: GEM related fields */
> > +	struct {
> > +		/**
> > +		 * @obj: GEM object to map.
> > +		 *
> > +		 * Can be NULL if the virtual range is not backed by a GEM object.
> > +		 */
> > +		struct drm_gem_object *obj;
> > +
> > +		/** @offset: offset in the GEM */
> > +		u64 offset;
> > +	} gem;
> > +};  
> 
> Can't we just use struct drm_gpuva_op_map instead? The structure is identical
> and represents exactly what we want, a map operation.

Sure, we can do that. The only reason I didn't is because I thought it
was preferable to distinguish a map request from the sub-operation it
might be split into (the latter being described by drm_gpuva_op_map).

> 
> Let's use that instead of redefining an identical structure.
> 
> With that,
> 
> 	Acked-by: Danilo Krummrich <dakr@...nel.org>