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

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

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.