linux-kernel - Re: [PATCH v2] drm/ttm: Silence randstruct warning about casting struct file

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: <aBRPeLVgG5J5P8SL@lstrano-desk.jf.intel.com>
Date: Thu, 1 May 2025 21:52:08 -0700
From: Matthew Brost <matthew.brost@...el.com>
To: Al Viro <viro@...iv.linux.org.uk>
CC: Kees Cook <kees@...nel.org>, Thomas Hellström
	<thomas.hellstrom@...ux.intel.com>, Christian Koenig
	<christian.koenig@....com>, Somalapuram Amaranath
	<Amaranath.Somalapuram@....com>, Huang Rui <ray.huang@....com>, Matthew Auld
	<matthew.auld@...el.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>, <dri-devel@...ts.freedesktop.org>,
	<linux-kernel@...r.kernel.org>, <linux-hardening@...r.kernel.org>,
	<linux-fsdevel@...r.kernel.org>, Christian Brauner <brauner@...nel.org>, "Jan
 Kara" <jack@...e.cz>
Subject: Re: [PATCH v2] drm/ttm: Silence randstruct warning about casting
 struct file

On Fri, May 02, 2025 at 05:31:49AM +0100, Al Viro wrote:
> On Thu, May 01, 2025 at 09:26:25PM -0700, Matthew Brost wrote:
> 
> > I;m fairly certain is just aliasing... but I do understand a file cannot
> > be embedded. Would comment help here indicating no other fields should
> > be added to ttm_backup without struct file be converted to pointer or
> > that just to risky?
> 
> What exactly are you trying to do there?  IOW, is that always supposed to
> be a struct file, or something dependent upon something in struct ttm_tt
> instance, or...?

Create an opaque ttm_backup object for the rest of TTM / drivers to view
- it could change if the backup implementation changed.

> 
> And what is the lifecycle of that thing?  E.g. what is guaranteed about
> ttm_backup_fini() vs. functions accessing the damn thing?  Are they
> serialized on something/tied to lifecycle stages of struct ttm_tt?

I believe the life cycle is when ttm_tt is destroyed or api allows
overriding the old backup with a new one (currently unused).

Matt