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.129.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 784B934C830 for ; Wed, 4 Feb 2026 04:21:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770178889; cv=none; b=L/ABkaunbfZaj/YHXlbn9FWGRMT365DAD3OILz5ZdZQwA4IbFQpe/xNG5oTPO4/azTVW08FDAtq6DO9nQ1qDqPdDT8QVW5A8OuuD7BzSgOqkxxvXfEGbRZU5cIhqzHAfnzOVTyyvlpMLahM32SZhgBP3sZUfzaH8naCOq5Latmc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770178889; c=relaxed/simple; bh=PzQQ3B/+w7hS3/ALA88P5mujhAE3S+HZezzvrGHmRME=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=Q9plNoU9HwS1HE3iun4oPCq1EF59yztHLNXREm1JeZGZBKJ+SNoXONncszi77RJJy4xAUIpN55l2Jfp6nvVRwaJflBCYNc+bW6UEMC6mRzow685GXUCqjU0/hXua2B2AAhXCoAbeuapf0vWSAtknozofk1dT6Mg8aiUDEZ+r8EY= 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=RbYrLIIl; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=OtZcXijp; arc=none smtp.client-ip=170.10.129.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="RbYrLIIl"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="OtZcXijp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770178886; 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=wcBbuF5wJvFTL0tuao0MoCA5GeDjlAU8Fd2jJuLQGU8=; b=RbYrLIIlNzwg+hbUOZH+diAt41r1NcK1Ts3IAEDiBGu5OXwLRmscQBPzi81GZvkn7LWZpF /o10+04MNMR5OaFR0Ph2zWTvGq6AGcjO2r1+xT8koIZK1g1vZNwkrZdjcf6tYOYBXTmn0p BlNzsAw70ufyXzJXj5fi6+sIW9G+pvQ= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-83-sB-27JtlNXysPGuAZN4vHQ-1; Tue, 03 Feb 2026 23:21:25 -0500 X-MC-Unique: sB-27JtlNXysPGuAZN4vHQ-1 X-Mimecast-MFC-AGG-ID: sB-27JtlNXysPGuAZN4vHQ_1770178885 Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-8c882774f0dso500501485a.2 for ; Tue, 03 Feb 2026 20:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770178885; x=1770783685; 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=wcBbuF5wJvFTL0tuao0MoCA5GeDjlAU8Fd2jJuLQGU8=; b=OtZcXijpdVq0VXrnmT4VBnVvG2dz9B957C+vCXqhbklv0rtOIaQmUIvygsrh8nu4uZ 3HIHG+TcNpLyUSK4WP66c6f+vykkPfVleM88FZ21sdPC5rgQwIL3seffmZUdE7lC064T hS2YwOf7xv5yfZL1V1h0oyJH0O+tFDJUR07fu/km2J+YHaJ+2Mtjm5jHB0eFOXioIbxT lYIDhYaXCmGCmKaWxBnDse/KbhsTuO1QPh95dJmr0zyu4qmINdchzFCazG0NzOUMrEId I2mIwWTSdsCdYyOKLIA9E55CdzGoIxNBv5ZgC04arZniNHm+U5b5KL8PXdZ0oNcxQz8B K4OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770178885; x=1770783685; 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=wcBbuF5wJvFTL0tuao0MoCA5GeDjlAU8Fd2jJuLQGU8=; b=m2kOhR0rJvIksLXY7LoaEWt9eVL9SxSzEJ+PeWFpYa+qTTK5zYvKa/IhAPOskzb++A Xidv/NtJlyP0m3dcf6e/O8lfXNcszb77nflQxCUu1DF6AXm1gaaORg1N9tU/COXW8wSm xdBTkSxBb8uDpXBh0oGc4WfloMu0RneAUkr9xYzmDPC/8CM5KZL0T3oBdd9IEcXEWw2E TTcClKq17urxPFaU2mxVkJ2m4fwklMVfHxB2G29QfFduLRGwpZi4LMlDKoRTlHAuAXeL /tSX27yZ7OTvIbf91usV4URCKFkWnJCHbXaNGfeywG+/3cqmb2LrHVhgPrn7nuNbkoOE CZUg== X-Forwarded-Encrypted: i=1; AJvYcCXMMaxwu0V1G6uzfNT4xZbVOFwwFFCSC4sn+V2wC+fv58FgaGfJYFqTBWFzLHYDQhVy0xlEtjpBiJXK4ho=@vger.kernel.org X-Gm-Message-State: AOJu0YwZkIDhebfooN2hpf5OgtsIYEjAWMKB59xx9YHYzizx7xn0Mlj3 Tg8lVXGOjG78i9H4BFO6f1MKLoOU21KZGKenSrKHYREa3zEqJfCrxa/wBpTsLox/tRCpMr8oRnm PFOXNl1hu3jEKQX5Gr0sciGievqy6ZnOvK4EsFq5azThns407eVzmsJza7vImQhN21w== X-Gm-Gg: AZuq6aLi1CurSkenlPTXo9HuHgj0MqXHDimoZmh7mgIJFdgUlrzLVSLVQN+bHgmQ2YB Ecv5or7uiOOMxEhJ9xfhg/t/yAd7tXLOQEpWKSyQ4AzbVXZ4WRc/0T1kqSkN7MAAFGOKFyFsBvs Ne016HxWI0Aqwfqvh5D91Ln7X+aNqzSLGWiUVKVkQBDYeyPBRb0If6AVDhz3wMffoSZSadRns/C obyccvvqnPOGgyuZMMzUTlZYVafC+5oQ1urEkDqN96+JWa8XnPIjRetM5YLr634iai64iEInzQl nmUYbQmeKRwYyZObYQayRu92evXHntX/mALJFHw28V0iNaYcjN/pyQywPhcX4wtP4vao0b6qiZL vCWLFil5b82bJ32H+Zw7pogMYFSNz6RR8lZQXFdRqpGjBIH7SmAQDIbme X-Received: by 2002:a05:620a:31f3:b0:8ca:3854:8110 with SMTP id af79cd13be357-8ca38549dafmr1977585a.72.1770178884831; Tue, 03 Feb 2026 20:21:24 -0800 (PST) X-Received: by 2002:a05:620a:31f3:b0:8ca:3854:8110 with SMTP id af79cd13be357-8ca38549dafmr1976685a.72.1770178884482; Tue, 03 Feb 2026 20:21:24 -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 af79cd13be357-8ca2fd5382csm108055685a.50.2026.02.03.20.21.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Feb 2026 20:21:23 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <6661f966-5235-49ca-bf1f-d1ae2ae32f0d@redhat.com> Date: Tue, 3 Feb 2026 23:21:23 -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 References: <20260203194433.1738162-1-longman@redhat.com> <20260203200505.GH3183987@ZenIV> <590a36e6-8d11-411a-8fcd-d93eef96f0e9@redhat.com> <20260203215002.GI3183987@ZenIV> <20260203232634.GJ3183987@ZenIV> Content-Language: en-US In-Reply-To: <20260203232634.GJ3183987@ZenIV> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/3/26 6:26 PM, Al Viro wrote: > On Tue, Feb 03, 2026 at 09:50:02PM +0000, Al Viro wrote: >> On Tue, Feb 03, 2026 at 03:32:04PM -0500, Waiman Long wrote: >> >>> That is actually a concern that I have at the back of my mind. I can modify >>> the patch to cache only the dentry and do get/put the mount every time which >>> is much cheaper as it is a percpu counter.  In that way, a chdir(2) followed >>> by a umount(2) shouldn't cause a -EBUSY. Right? >> Quite - it will just retain a reference to dentry, with filesystem shutdown >> being very unhappy about somebody retaining references to objects on the >> filesystem about to be taken out... > Sarcasm aside, I wonder if we could do the following trick: > * a new primitive for "grab or borrow pwd", similar to what fdget() > does for struct file. If current->fs is shared, do what we do now and return > true; otherwise just copy the contents of current->fs->pwd return false. > * paired primitive that would take a boolean + struct path * and > do path_put() if boolean is true. > * syscalls that might alter ->fs, ->fs->pwd or add extra references to > ->fs would start with grabbing an extra ref on entry and drop it in the end; > that would make that primitive safe to use there. > * audit using that thing and storing the result along with the copy > of pwd; on the way out it would use the "put unless borrowed" primitive. > > Might or might not be useful - hard to tell without knowing the job mix of those > audit-afflicted production systems. > > I'll try to put something along those lines together... Interesting. So are you thinking about a reference on the pwd inside the fs_struct? I am thinking about instead of getting a reference to pwd.dentry and pwd.mnt, we can just get a reference to the pwd itself. We have to grab the fs lock in get_fs_pwd() anyway. This spinlock doesn't show up as being contended in the customer bug report as each process can has its own fs_struct instead of many processing sharing the same working directory. In the case of audit, fs->pwd is copied out at the beginning of the open* system call and then put back at the end of that system call. So it should last a pretty short time, i.e. the reference will be released shortly. However, that will make the set_fs_pwd() call a bit tricky to implement, but I think it is still doable. Cheers, Longman