v4:
  - Add ack and review tags
  - Simplify put_fs_pwd_pool() in patch 1 as suggested by Paul Moore

 v3:
  - https://lore.kernel.org/lkml/20260206201918.1988344-1-longman@redhat.com/

When the audit subsystem is enabled, it can do a lot of get_fs_pwd()
calls to get references to fs->pwd and then releasing those references
back with path_put() later. That may cause a lot of spinlock contention
on a single pwd's dentry lock because of the constant changes to the
reference count when there are many processes on the same working
directory actively doing open/close system calls. This can cause
noticeable performance regresssion when compared with the case where
the audit subsystem is turned off especially on systems with a lot of
CPUs which is becoming more common these days.

This patch series aim to avoid this type of performance regression caused
by audit by adding a new set of fs_struct helpers to reduce unncessary
path_get() and path_put() calls and the audit code is modified to use
these new helpers.

Waiman Long (2):
  fs: Add a pool of extra fs->pwd references to fs_struct
  audit: Use the new {get,put}_fs_pwd_pool() APIs to get/put pwd
    references

 fs/fs_struct.c            | 26 +++++++++++++++++++++-----
 fs/namespace.c            |  8 ++++++++
 include/linux/fs_struct.h | 28 +++++++++++++++++++++++++++-
 kernel/auditsc.c          |  7 +++++--
 4 files changed, 61 insertions(+), 8 deletions(-)

-- 
2.53.0

On Sat, Feb 28, 2026 at 01:27:55PM -0500, Waiman Long wrote:
>  v4:
>   - Add ack and review tags
>   - Simplify put_fs_pwd_pool() in patch 1 as suggested by Paul Moore
> 
>  v3:
>   - https://lore.kernel.org/lkml/20260206201918.1988344-1-longman@redhat.com/
> 
> When the audit subsystem is enabled, it can do a lot of get_fs_pwd()
> calls to get references to fs->pwd and then releasing those references
> back with path_put() later. That may cause a lot of spinlock contention
> on a single pwd's dentry lock because of the constant changes to the
> reference count when there are many processes on the same working
> directory actively doing open/close system calls. This can cause
> noticeable performance regresssion when compared with the case where
> the audit subsystem is turned off especially on systems with a lot of
> CPUs which is becoming more common these days.
> 
> This patch series aim to avoid this type of performance regression caused
> by audit by adding a new set of fs_struct helpers to reduce unncessary
> path_get() and path_put() calls and the audit code is modified to use
> these new helpers.

Tbh, the open-coding everywhere is really not very tasteful and makes me
not want to do this at all. Ideally we'd have a better mechanism that
avoids all this new spaghetti in various codepaths.

In it's current form I don't find it palatable. I added a few cleanups
on top that make it at least somewhat ok.

On 3/5/26 4:46 PM, Christian Brauner wrote:
> On Sat, Feb 28, 2026 at 01:27:55PM -0500, Waiman Long wrote:
>>   v4:
>>    - Add ack and review tags
>>    - Simplify put_fs_pwd_pool() in patch 1 as suggested by Paul Moore
>>
>>   v3:
>>    - https://lore.kernel.org/lkml/20260206201918.1988344-1-longman@redhat.com/
>>
>> When the audit subsystem is enabled, it can do a lot of get_fs_pwd()
>> calls to get references to fs->pwd and then releasing those references
>> back with path_put() later. That may cause a lot of spinlock contention
>> on a single pwd's dentry lock because of the constant changes to the
>> reference count when there are many processes on the same working
>> directory actively doing open/close system calls. This can cause
>> noticeable performance regresssion when compared with the case where
>> the audit subsystem is turned off especially on systems with a lot of
>> CPUs which is becoming more common these days.
>>
>> This patch series aim to avoid this type of performance regression caused
>> by audit by adding a new set of fs_struct helpers to reduce unncessary
>> path_get() and path_put() calls and the audit code is modified to use
>> these new helpers.
> Tbh, the open-coding everywhere is really not very tasteful and makes me
> not want to do this at all. Ideally we'd have a better mechanism that
> avoids all this new spaghetti in various codepaths.
>
> In it's current form I don't find it palatable. I added a few cleanups
> on top that make it at least somewhat ok.

Thanks for the cleanup patches. They all look good to me.

Reviewed-by: Waiman Long <longman@redhat.com>