mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Waiman Long <llong@redhat.com>
To: Al Viro <viro@zeniv.linux.org.uk>, Waiman Long <llong@redhat.com>
Cc: Paul Moore <paul@paul-moore.com>, Eric Paris <eparis@redhat.com>,
	Christian Brauner <brauner@kernel.org>,
	linux-kernel@vger.kernel.org, audit@vger.kernel.org,
	Richard Guy Briggs <rgb@redhat.com>,
	Ricardo Robaina <rrobaina@redhat.com>,
	Mateusz Guzik <mjguzik@gmail.com>
Subject: Re: [PATCH v2] audit: Avoid excessive dput/dget in audit_context setup and reset paths
Date: Thu, 5 Feb 2026 08:59:11 -0500	[thread overview]
Message-ID: <9e794b81-3a16-4380-a397-5e58dd5fab78@redhat.com> (raw)
In-Reply-To: <20260205052202.GQ3183987@ZenIV>

On 2/5/26 12:22 AM, Al Viro wrote:
> On Wed, Feb 04, 2026 at 10:03:33PM -0500, Waiman Long wrote:
>
>> Now I realize that there is indeed a deadlock problem. Scrap that. Now I
>> have a simpler idea that shouldn't have this type of deadlock problem. So
>> what do you think about the sample code below?
> That it's rather bizarre, TBH.  Basically, you are allowing to park
> a number of (identical) references in there instead of dropping them,
> with your 'xrefs' being the count of skipped drops.  get_share either
> clones a reference or uses up one of those skipped drops; put_share parks
> the reference if possible.  And set discards everything not used up...
The basic idea is to have a pool of extra pwd references inside 
fs_struct. When a user needs a reference, it can borrow one, if 
available, with the get call and then return it back later with a put 
call. I envision that the pool can grow to the maximum number of 
outstanding get's that have ever happen. When it is time to let them go, 
we could implement some low level put_many functions to get rid of them 
in one go instead releasing them one-by-one which could take a while if 
the pool grow big. I am not good in naming, so please let me know if you 
have suggestion of what naming convention should be used.
>
> It could be made to work, but... ouch.  It looks like a special-cased
> variant of something fairly generic, with really confusing calling
> conventions.  Let me poke around and see if we have any other candidates
> for something similar; if nothing else, current->fs->root is interesting
> and not just for audit pathologies...
>
> Note, BTW, that there's chroot_fs_refs() to deal with, along with
> free_fs_struct() (at least).  This stuff is encapsulated in
> fs/fs_struct.c and include/linux/fs_struct.h...  Oh, hell.

I have sent a follow up patch with changes made to other part of 
fs_struct.c AFAICS. Of course, I will go over it again when I am making 
an official patch. However, I haven't looked elsewhere outside of 
fs_struct.[ch]. I believe the change should be pretty self-contained. 
Please let me know if there are other places where I should look.

Cheers,
Longman


  reply	other threads:[~2026-02-05 13:59 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-03 19:44 Waiman Long
2026-02-03 19:59 ` Al Viro
2026-02-03 20:18   ` Waiman Long
2026-02-03 20:05 ` Al Viro
2026-02-03 20:32   ` Waiman Long
2026-02-03 21:50     ` Al Viro
2026-02-03 23:26       ` Al Viro
2026-02-04  4:21         ` Waiman Long
2026-02-04  6:26           ` Al Viro
2026-02-04 18:16             ` Waiman Long
2026-02-04 20:18               ` Al Viro
2026-02-05  3:03                 ` Waiman Long
2026-02-05  4:45                   ` Waiman Long
2026-02-05 23:53                     ` Al Viro
2026-02-06  1:20                       ` Waiman Long
2026-02-06  4:11                         ` Waiman Long
2026-02-06  4:19                           ` Waiman Long
2026-02-06  5:22                           ` Al Viro
2026-02-06  6:31                             ` Al Viro
2026-02-06  6:38                               ` Al Viro
2026-02-06  7:13                             ` Al Viro
2026-02-06 19:16                             ` Waiman Long
2026-02-06 20:04                               ` Waiman Long
2026-02-06 20:38                                 ` Al Viro
2026-02-07  8:25                                 ` [PATCH][RFC] bug in unshare(2) failure recovery Al Viro
2026-02-07 23:06                                   ` Waiman Long
2026-02-17 12:49                                   ` Christian Brauner
2026-02-17 12:49                                   ` Christian Brauner
2026-02-06 20:29                               ` [PATCH v2] audit: Avoid excessive dput/dget in audit_context setup and reset paths Al Viro
2026-02-06 20:58                                 ` setns(2) vs. pivot_root(2) (was Re: [PATCH v2] audit: Avoid excessive dput/dget in audit_context setup and reset paths) Al Viro
2026-02-06 21:09                                   ` Al Viro
2026-02-17 13:12                                     ` Christian Brauner
2026-02-06  8:15                       ` [PATCH v2] audit: Avoid excessive dput/dget in audit_context setup and reset paths Al Viro
2026-02-05  5:22                   ` Al Viro
2026-02-05 13:59                     ` Waiman Long [this message]
2026-02-05 17:53                     ` Mateusz Guzik
2026-02-17 13:33                       ` Christian Brauner
2026-02-17 13:44                         ` Mateusz Guzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9e794b81-3a16-4380-a397-5e58dd5fab78@redhat.com \
    --to=llong@redhat.com \
    --cc=audit@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=eparis@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjguzik@gmail.com \
    --cc=paul@paul-moore.com \
    --cc=rgb@redhat.com \
    --cc=rrobaina@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®