From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0CD903E9F96 for ; Thu, 5 Feb 2026 13:59:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770299957; cv=none; b=atkXMze9PR5TU7gIgGTEBCe9uThORyH0tt1B/WGmzEb6Tyvj0z1RjxmlBkT2SjJkyXhD5cYstyX976qdSrPs82YxhKpQ6BgioRRT+0uSzXEClZ3e0kpyyzDaNYIUdAOT4oe3dW+jjFOkfVM9axDGqpOeTTmvfb0H6p+YRkalUgo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770299957; c=relaxed/simple; bh=nDUImYwv3xbBLPKMXbwxRdbKJATnW3Ud/fc7GGcNKWc=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=kRuktxBim9yLbfrnAhxM77b9G36aztbaYw7tY2dskzfQScNX63ebPne2qwLjjiEES8Avn0f2dWenaWidT/7wxt6ykmsfAjbS2gU2DGQmm7mJ8Ob6iWVAbWA6wsmd8/nBwNApG39YOcUapfV/C/Y+TvhTapV/c6CEHHeqm0qpKZU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=gOZn4s3X; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=M0A+fiFj; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="gOZn4s3X"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="M0A+fiFj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770299956; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JAdYEapv7lODz+jvkHCW5ylaWbeiRic5ErFk+82ErKM=; b=gOZn4s3XpPwvA08IlB/Msdi8+pZBBKBBSh2OU3mbHL2Ku6q1vtsnFoVli+3CebRjM/K4cn 2qkPl0fDE9D+eRk60gKZX1nDrxq66s97rZLELfmNS7o4L6AAThZncbDjCYZWsbKPPTsa2i lG2ZiOusyE0G5oOkvHIPRzlPSXMEmVo= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-630-ELRrbuFLPsqHzA9_GxRCng-1; Thu, 05 Feb 2026 08:59:15 -0500 X-MC-Unique: ELRrbuFLPsqHzA9_GxRCng-1 X-Mimecast-MFC-AGG-ID: ELRrbuFLPsqHzA9_GxRCng_1770299954 Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-89502dfd7b4so29374686d6.1 for ; Thu, 05 Feb 2026 05:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770299954; x=1770904754; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:from:to :cc:subject:date:message-id:reply-to; bh=JAdYEapv7lODz+jvkHCW5ylaWbeiRic5ErFk+82ErKM=; b=M0A+fiFjInn44VQeWBg4laLNSsAPZHaZGwgLkRz2pIXeClP96GrB5xFAOdT9Yo2CNm zdCG9j3hu8l/CCrIbBZ3G4Abe44gNwB+TJ353mWVlV2njLfoJdq8zmsnLYd4GAO5yLKq 3n6iWCAixwTduTyLOFKBNXSjfPRNK5p4bWEKJ0bb7Jax3Iv8rChJXXuZwK2xBV/bemJt xEUKrD8a2fRtetRfzmWyabVutd2JoCeY6TQn2BpfWCx7oGvA/Kr6Hm4ws0L57qYYoGny gGnP7H8yZ0EInbxzpitgAuj+DJxOLgulcF2kd2JBSquqa3D9BAxzZKFFsbbjnhf4Bn8e FA0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770299954; x=1770904754; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JAdYEapv7lODz+jvkHCW5ylaWbeiRic5ErFk+82ErKM=; b=Eg3RrpjXDX5gVM68MRwAUps5vqp8AiY/fmknFFy6mDbg9m2z5HM6Vg8zjhB9dvtM7J eTwQTNADbvt4CxGaiDZqF7T+nLjTO46jmL91qi0y3Po+djEN21oKlrgpkhzLnM5dAphG 5m7bfdRCw1wkwkbeedkCCDR5nmgLtpvK/8pa2uPaZlfFT6+A0PMj64JQHx5C8zdYC0Kl xDe+YyrOX5OP8qD32dtf8kYDstAYJr8XnDs3Yv6N32PCjCfDyirJ8S7v5YKlKHBFLtfn 5Ajdp9tMMCXhHXh6ODc1RAtmvgrQ+ufhGe8psvjlVFYW3pRVWr2KQolS28pJU/avOhvI nIWQ== X-Forwarded-Encrypted: i=1; AJvYcCVzxGij2TItSXosFonFLzKwcWAiwRCnLjPt+5Oh3QPDKfGJ0vLalTmKHbw3GHA68O7bAdqzQAw57eogVp8=@vger.kernel.org X-Gm-Message-State: AOJu0Yx1safRLfAt1dIpRSxHZOyuGH13wbhPRpFEH/xX05tzBKuqFSJI o0/VZNqPCoA2RcGYA2zwOJCHyHmQD0ENSG9zWNw/pV0ia8E0dK1l8MSvtEmtu+CMC+5EHXyeTea keMgYLLeEO3Nk4NjsdWjG7TtT/pAikQNms38e5lM4PPn3czu2e29uOGAkdR5KeIPQKaI7xU9Tcw == X-Gm-Gg: AZuq6aIxsSpm9zNJo20nsi8BQFa4WMTVzacqE8mm4w+LpdCITSLGzoO06O6n64s3EKM 4c44bXHgxtXcjN2amRfoDrLBJWTfUeG3EeVcelAmCgP64wtYabuXJkQ3zukyPuUKKO+2gAlk63+ 2xKGhlM5HLOWYqPdi1d3xK3ci9Q37ylrhLay5U9ykZiKK+jVyDekBQSD9lmZZN8HIq2A0aEir1z xorHr9N88V0nR0766yvTRrJ58ZZ8JreCbdBCNyyc8U7dXKm8As9m5uqLPWYuFwTTdn9GktbY8kS /3H9ZzlJAl99cIjaZ2mmzM8KggjAbLtdnFy4AMbTd/Fw0eY7264A+19ozrCtytv6q9mWBj2Oewo zoulizyLVv5aAK5vak5Eik4NnwfzO1OUcOBwORkRlInB1uhDlIQ+FJQng X-Received: by 2002:a05:6214:1d09:b0:894:61c8:930c with SMTP id 6a1803df08f44-895220f1304mr96893276d6.6.1770299953848; Thu, 05 Feb 2026 05:59:13 -0800 (PST) X-Received: by 2002:a05:6214:1d09:b0:894:61c8:930c with SMTP id 6a1803df08f44-895220f1304mr96892996d6.6.1770299953448; Thu, 05 Feb 2026 05:59:13 -0800 (PST) Received: from ?IPV6:2601:188:c102:b180:1f8b:71d0:77b1:1f6e? ([2601:188:c102:b180:1f8b:71d0:77b1:1f6e]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-89521bfe8c4sm42408926d6.2.2026.02.05.05.59.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Feb 2026 05:59:12 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <9e794b81-3a16-4380-a397-5e58dd5fab78@redhat.com> Date: Thu, 5 Feb 2026 08:59:11 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] audit: Avoid excessive dput/dget in audit_context setup and reset paths To: Al Viro , Waiman Long Cc: Paul Moore , Eric Paris , Christian Brauner , linux-kernel@vger.kernel.org, audit@vger.kernel.org, Richard Guy Briggs , Ricardo Robaina , Mateusz Guzik References: <20260203194433.1738162-1-longman@redhat.com> <20260203200505.GH3183987@ZenIV> <590a36e6-8d11-411a-8fcd-d93eef96f0e9@redhat.com> <20260203215002.GI3183987@ZenIV> <20260203232634.GJ3183987@ZenIV> <6661f966-5235-49ca-bf1f-d1ae2ae32f0d@redhat.com> <20260204062614.GK3183987@ZenIV> <46d5c480-87d0-4f6a-bcc2-6c936c87e216@redhat.com> <20260204201815.GP3183987@ZenIV> <20260205052202.GQ3183987@ZenIV> Content-Language: en-US In-Reply-To: <20260205052202.GQ3183987@ZenIV> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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