On Wed, Dec 6, 2023 at 6:04 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Wed, Dec 06, 2023 at 04:52:42PM -0500, Paul Moore wrote: > > On Wed, Dec 6, 2023 at 1:07 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > > > Because it's a horrible point of lock contention under heavily > > > concurrent directory traversals... > > > > > > - 12.14% d_instantiate > > > - 12.06% security_d_instantiate > > > - 12.13% selinux_d_instantiate > > > - 12.16% inode_doinit_with_dentry > > > - 15.45% _raw_spin_lock > > > - do_raw_spin_lock > > > 14.68% __pv_queued_spin_lock_slowpath > > > > > > > > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> > > > --- > > > include/linux/dlock-list.h | 9 ++++ > > > security/selinux/hooks.c | 72 +++++++++++++++---------------- > > > security/selinux/include/objsec.h | 6 +-- > > > 3 files changed, 47 insertions(+), 40 deletions(-) > > > > In the cover letter you talk about testing, but I didn't see any > > mention of testing with SELinux enabled. Given the lock contention > > stats in the description above I'm going to assume you did test this > > and pass along my ACK, but if you haven't tested the changes below > > please do before sending this anywhere important. > > AFAIA, I've been testing with selinux enabled - I'm trying to run > these tests in an environment as close to typical production systems > as possible and that means selinux needs to be enabled. > > As such, all the fstests and perf testing has been done with selinux > in permissive mode using "-o context=system_u:object_r:root_t:s0" as > the default context for the mount. > > I see this sort of thing in the profiles: > > - 87.13% path_lookupat > - 86.46% walk_component > - 84.20% lookup_slow > - 84.05% __lookup_slow > - 80.81% xfs_vn_lookup > - 77.84% xfs_lookup > .... > - 2.91% d_splice_alias > - 1.52% security_d_instantiate > - 1.50% selinux_d_instantiate > - 1.47% inode_doinit_with_dentry > - 0.83% inode_doinit_use_xattr > 0.52% __vfs_getxattr > > Which tells me that selinux is definitely doing -something- on every > inode being instantiated, so I'm pretty sure the security and > selinux paths are getting exercised... That's great, thanks for the confirmation. FWIW, for these patches it doesn't really matter if the system is in enforcing or permissive mode, or what label you use, the important bit is that you've got a system with SELinux enabled in the kernel and you have a reasonable policy loaded. -- paul-moore.com