Hi Christian and Paul, Thanks for your replies.
On Mon, Sep 28, 2026 at 8:46 AM Paul Moore <[email protected]> wrote: > > On Mon, Sep 28, 2026 at 10:13 AM Christian Brauner <[email protected]> wrote: > > On Thu, Jul 23, 2026 at 11:19:30AM -0700, Song Liu wrote: > > > Hi Christian and folks, > > > > > > Could you please help review this set? Does this set address > > > concerns from earlier versions? > > > > I just realized something while looking at this. This doesn't cover the > > new mount api at all fsopen, fsconfig, fsmount, fspick, open_tree, > > open_tree_attr and mount_setattr. Without this the series is not very > > useful imho. Yes, I am fully aware that this does not cover the new mount APIs. I think those are orthogonal to the optimization here. This series is very useful without covering the new APIs. Users from multiple companies have repeatedly requested this change. ([1] and users requested this set). If we can land this set without covering the new APIs, I am more than happy to draft new patch set that covers the new APIs as a follow-up work. Therefore, could you please review this set as-is, and see whether we can land it without the orthogonal work covering the new mount APIs? > Thanks Christian. > > Song, I'm still open to reworking the LSM mount hooks, but any rework > should really take into account everything. There is another question here. These new hooks do not have any in-tree user at the moment. This appears to violate the "New LSM Hooks" policy in [2]. Could you please give more specific guidance on this? Do we need at least one in-tree user hook that uses the new mount APIs? Or will we make an exception for these new hooks? Or will we revise the "New LSM hooks" policy to allow reasonable hooks without an in-tree user? Thanks, Song [1] https://lore.kernel.org/all/[email protected]/ [2] https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-hooks
