On Tue, May 30, 2023 at 07:55:17AM -0700, Casey Schaufler wrote: > On 5/30/2023 7:28 AM, Christoph Hellwig wrote: > > On Tue, May 30, 2023 at 03:58:35PM +0200, Christian Brauner wrote: > >> The main concern which was expressed on other patchsets before is that > >> modifying inode operations to take struct path is not the way to go. > >> Passing struct path into individual filesystems is a clear layering > >> violation for most inode operations, sometimes downright not feasible, > >> and in general exposing struct vfsmount to filesystems is a hard no. At > >> least as far as I'm concerned. > > Agreed. Passing struct path into random places is not how the VFS works. > > > >> So the best way to achieve the landlock goal might be to add new hooks > > What is "the landlock goal", and why does it matter? > > > >> or not. And we keep adding new LSMs without deprecating older ones (A > >> problem we also face in the fs layer.) and then they sit around but > >> still need to be taken into account when doing changes. > > Yes, I'm really worried about th amount of LSMs we have, and the weird > > things they do. > > Which LSM(s) do you think ought to be deprecated? I only see one that I I don't have a good insight into what LSMs are actively used or are effectively unused but I would be curious to hear what LSMs are considered actively used/maintained from the LSM maintainer's perspective. > might consider a candidate. As for weird behavior, that's what LSMs are > for, and the really weird ones proposed (e.g. pathname character set limitations) If this is effectively saying that LSMs are licensed to step outside the rules of the subsystem they're a guest in then it seems unlikely subsystems will be very excited to let new LSM changes go in important codepaths going forward. In fact this seems like a good argument against it. -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-cachefs
