Re: [PATCH v8 3/6] liveupdate: add LUO_SESSION_MAGIC magic inode type

[Luca Boccassi]

On Mon, 20 Apr 2026 at 15:55, Pasha Tatashin <pasha.tatashin@xxxxxxxxxx> wrote:
>
> On 04-20 14:26, Christian Brauner wrote:
> > On Sat, Apr 18, 2026 at 05:28:20PM +0100, luca.boccassi@xxxxxxxxx wrote:
> > > From: Luca Boccassi <luca.boccassi@xxxxxxxxx>
> > >  {
> > > -   char name_buf[128];
> > > +   char name_buf[LIVEUPDATE_SESSION_NAME_LENGTH + 1];
> > >     struct file *file;
> > >
> > >     lockdep_assert_held(&session->mutex);
> > > -   snprintf(name_buf, sizeof(name_buf), "[luo_session] %s", session->name);
> > > -   file = anon_inode_getfile(name_buf, &luo_session_fops, session, O_RDWR);
> > > -   if (IS_ERR(file))
> > > +
> > > +   ihold(luo_session_inode);
> >
> > Right, you're now sharing the same inode among all luo sessions. So
> > you've gained the ability to recognize luo inodes via fstatfs() but you
> > still can't compare two luo session file descriptors for equality using
> > stat() which is a major win and if you're doing this work anyway, let's
>
> Luca, is there a specific use case in userspace where we need to compare
> LUO sessions for equality?
>
> Christian's proposed solution of using unique inodes provides a standard
> VFS interface, but it introduces some memory overhead and, more
> importantly, a performance overhead due to the extra metadata
> allocations required during the performance-critical kexec blackout
> window.
>
> I do not mind adding it, but I want to verify if this equality check is
> actually needed for your userspace agents, once we extend this, there is
> no way back.

I don't have any use for this comparison as of now, and cannot think
of any future one either. So I agree with you and I think we should
postpone until there's an actual use case for it, to avoid the
downsides.