On Mon, Oct 14, 2024 at 10:45 AM Christian Brauner <brauner@xxxxxxxxxx> wrote: > On Sun, Oct 13, 2024 at 06:17:43AM -0400, Jeff Layton wrote: > > On Fri, 2024-10-11 at 17:30 +0200, Mickaël Salaün wrote: > > > On Fri, Oct 11, 2024 at 07:39:33AM -0700, Christoph Hellwig wrote: > > > > On Fri, Oct 11, 2024 at 03:52:42PM +0200, Mickaël Salaün wrote: ... > > A better solution here would be to make inode->i_ino a u64, and just > > fix up all of the places that touch it to expect that. Then, just > > I would like us to try and see to make this happen. I really dislike > that struct inode is full of non-explicity types. Presumably this would include moving all of the filesystems to use inode->i_ino instead of their own private file ID number, e.g. the NFS issue pointed out in the original patch? If not, I think most of us in the LSM/audit space still have a need for a filesystem agnostic way to determine the inode number from an inode struct. -- paul-moore.com
