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

[Pasha Tatashin]

> > > 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'm excited to be convinced that the memory and performance overhead
> matters for luo file descriptors in any shape or form. Userspace manages
> processes using file descriptors via pidfs - systemd exclusively so. So
> even if luo session fds are created at the same rate and amount like
> processes you can rest assured that it will be fine.

That is fair, I do not mind having an inode per-session.

> Let me turn the argument around: You are adding a full-fledged
> filesystem to the kernel for the sole purpose of providing a separate
> filesystem type. Why are you bloating the whole kernel for this? Use
> the anonymous inode api that allocates a separate inode, use your own
> inode operations and then add an ioctl on top of luo if that's all you
> need. If this is a proper fs, please do it properly and with foresight.

That's exactly what we added initially: an anonymous inode, and a way to 
identify if it is a session by poking /proc/ for the [luo_session] 
prefix. However, I understand that is not ideal. I originally thought a 
luo agent would never need to verify if an FD belongs to a LUO session, 
but since userspace will need this capability, I am ok with doing it the 
right way.

> This whole patchset is based on an idea of mine and I don't need to see
> it twisted into oblivion otherwise I'll just do it myself and properly.

I do not think that is happening.

> I definitely want to be able to compare luo session by fd sooner or
> later and retroactively bolting this on with the next hack because you
> have userspace depend on the single inode stuff is not going to fly.

Sounds good.

> You also need to have LSM filtering on what may be persisted and LUO in
> general. All of that falls out for free _trivially_ if you modify the
> code to what I did. It is incredibly easy to do. To me this is ducking
> behind questionable arguments to get something merged as quickly as
> possible.

+1.

Pasha