linux-kernel - Re: [PATCH v4 5/7] drm/gpuvm: Add a flags field to drm_gpuvm_map_req/drm_gpuva_op

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: <20250821142150.48250375@fedora>
Date: Thu, 21 Aug 2025 14:21:50 +0200
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Adrian Larumbe <adrian.larumbe@...labora.com>
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>, Danilo Krummrich <dakr@...nel.org>, 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 5/7] drm/gpuvm: Add a flags field to
 drm_gpuvm_map_req/drm_gpuva_op_map

On Tue, 22 Jul 2025 20:21:25 +0100
Adrian Larumbe <adrian.larumbe@...labora.com> wrote:

> >  /**
> > @@ -1074,6 +1079,9 @@ struct drm_gpuvm_map_req {
> >  		/** @offset: offset in the GEM */
> >  		u64 offset;
> >  	} gem;
> > +
> > +	/** @flags: combination of DRM_GPUVA_ flags describing the mapping properties. */
> > +	enum drm_gpuva_flags flags;  
> 
> Wouldn't this be better expressed as a u32 combination of enum drm_gpuva_flags flags?
> Calling it 'flags' makes me feel like any OR'd combination of enum values would be possible.

I agree, but it's how other flags field are defined in gpuvm so I went
for the same definition to keep things consistent. Luckily (or
unfortunately, depending on where you place yourself), C is pretty lax
about what can be assigned to an enum type.