linux-hardening - 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 for Android: free password hash cracker in your pocket

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

Message-ID: <9c8dbbafdaf9f3f089da2cde5a772d69579b3795.camel@linux.intel.com>
Date: Fri, 02 May 2025 12:44:26 +0200
From: Thomas Hellström <thomas.hellstrom@...ux.intel.com>
To: Christian König <christian.koenig@....com>, Al Viro
	 <viro@...iv.linux.org.uk>, Matthew Brost <matthew.brost@...el.com>
Cc: Kees Cook <kees@...nel.org>, 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, 2025-05-02 at 09:49 +0200, Christian König wrote:
> On 5/2/25 07:33, Al Viro wrote:
> > On Thu, May 01, 2025 at 09:52:08PM -0700, Matthew Brost wrote:
> > > 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:
> > 
> > > > 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).
> > 
> > Umm...  So can ttm_tt_setup_backup() be called in the middle of
> > e.g. ttm_backup_drop() or ttm_backup_{copy,backup}_page(), etc.?
> > 
> > I mean, if they had been called by ttm_backup.c internals, it would
> > be an internal business of specific implementation, with all
> > serialization, etc. warranties being its responsibility;
> > but if it's called by other code that is supposed to be isolated
> > from details of what ->backup is pointing to...
> > 
> > Sorry for asking dumb questions, but I hadn't seen the original
> > threads.  Basically, what prevents the underlying shmem file
> > getting
> > torn apart while another operation is using it?  It might very well
> > be simple, but I had enough "it's because of... oh, bugger" moments
> > on the receiving end of such questions...
> 
> It's the outside logic which makes sure that the backup structure
> stays around as long as the BO or the device which needs it is
> around.
> 
> But putting that aside I was not very keen about the whole idea of
> never defining the ttm_backup structure and just casting it to a file
> in the backend either.
> 
> So I would just completely nuke that unnecessary abstraction and just
> use a pointer to a file all around.

Hmm, yes there were early the series a number of different
implementations of the struct ttm_backup. Initially because previous
attempts of using a shmem object failed but now that we've landed on a
shmem object, We should be able to replace it with a struct file
pointer.

Let me take a look at this. 

/Thomas

> 
> Regards,
> Christian.