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 701C72D9EF0 for ; Fri, 6 Feb 2026 04:20:02 +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=1770351602; cv=none; b=TQxOlYOjgL7CxBJUkf+5Zwy+eZpjOsIwoE4q9/EDGwWAvbKnOodG3fUk5oR/RIJKbONmj7DesM5EXiA9YSkD3tPq636QOtKECNDBJRg/aDdN7UQxX1kc77hx3dFunc4VJsX70BGq7IrK5jqe1GuVN86mkxreida/SPmmqkTJSUY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770351602; c=relaxed/simple; bh=o/siDAMDFeybMNav05zlB+FG9dYQgIQoLHR0jcIDqps=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=fll55iD7UZuKUl1mYgv8SXmty0v9wQVen8k6VXaqX8JxtZe7AWm1UcUWBOg0FV/KVt5sCtG8LOcLXXiu73a6kyUsaD9Lvi2eLYnKXMcEqvZW+P+W1Hu+gWoylf1sy8iezgr1Fi5Vp9vnUX8TdWdGH38xIvlv5iBnhdfwV51cGiw= 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=P7ZDOHKE; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=WmIeqNpe; 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="P7ZDOHKE"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="WmIeqNpe" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770351601; 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=r5FsNubkCMbpQGFmT9U+rlcEe2nNrmz/u6Yd1lqWSF0=; b=P7ZDOHKEsPb4wAqE12V3F7rOJAhJMephTTlj/FpOYMA1hhhuwy56Nd/L2uJRTEP6vSc7NV KiUVVkVNLiCvNVU9wTGRxsHzmqaCX1KioGxZk1OHUyC4VXC3/XHPrqsU9HbJQAv9FBhERV 1VPKRPTl4MRJt5FbJC9ADeSXDOjQMeI= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-10-Q5Upm2ziOnScwu0Epad9Ng-1; Thu, 05 Feb 2026 23:20:00 -0500 X-MC-Unique: Q5Upm2ziOnScwu0Epad9Ng-1 X-Mimecast-MFC-AGG-ID: Q5Upm2ziOnScwu0Epad9Ng_1770351599 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-5014ad65e3eso64977091cf.1 for ; Thu, 05 Feb 2026 20:19:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770351599; x=1770956399; 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=r5FsNubkCMbpQGFmT9U+rlcEe2nNrmz/u6Yd1lqWSF0=; b=WmIeqNpevEeb/gFbNgJiKTOQQFRkkj6p+9MGmhAlFzyLoPunbv993eAXuiXr/jA4SJ qofXSARFGpnLA3qsT4S/eGurtHsbQvE9t94KcULYk7UpCgYd9dU4l+M2sNMYN5d/zHRW +rexhyRnK/mNA6+vmZUZLxtp+hBENsEvBKU7M5XZaAh5uy1w+Vlr++tWrgCVHAfFjNQI BYHAb7Dwv8AalvjFiU52XGgYIfi+S/WsLMQKhH2C7bAPkSKiLgCH/pk3Wj7tasMveg8g Cmcq0k8ZucuaLMJh3s8ACGhLqVNenKeOkFkvrPlYZKPhaU8ejGAcdfYs5EAxZZDoW5oq pxbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770351599; x=1770956399; 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=r5FsNubkCMbpQGFmT9U+rlcEe2nNrmz/u6Yd1lqWSF0=; b=fOhRhkckDCW4I5URnW1Mc1smbqFw00M4gwY562yvkawCLqohcisc8SooaZKo0c4/vh y5R8WXZPFAJF7oDuH6EFTdpTiFFVnrUocl7MAWB+sd+VV8Uon73Avc/4/Xb0mx+fM7RD uGjNOaomfUHeMPqrd3VmXGiAHDfGsTtI6KqAd0z+o9J2SNP5tyCQtRG4O1apnJoUWCbc hBIdZzhwzW1DSuYvwodOh8cxbO41EfHJMaqwXCJ0jnzM9YWDMJL2pmUhotB0ZxzwLidA nnDBTyds3CaggFMpbmF+jLV79XSmFjyECyylwaHto6NUfWYpYZdNm4QbQDTGa/o9bS3d NT3g== X-Forwarded-Encrypted: i=1; AJvYcCWJhCxy9pD3aQSV/OOG40/Iiuh1Qgy7Z8x7UL3aWxiy34OJ+CskAz7tU6ywTlGSZFKVeXS5asmn8x8QRIc=@vger.kernel.org X-Gm-Message-State: AOJu0YyzRjqX1b2hl1yCyDZudHV5rpiWL7/Zx6EW0L7ftMNo6lDLma0D is84XK76/vjFjh10ScPSRMqw3UDTF6YT+Y+0thuugrdaTP0OOYGhFEQ1CFWUbUzuw0nauro3lL2 4qA5BfxNaF/hgbbiYfFa3FfafO2HT31TiscsIgB8r3NaWeEZtIMW0hXxXouUlYzL5gg== X-Gm-Gg: AZuq6aIOadLcqFO40RbxmGiVmAwHP3Lo0Kw2Oo/zAnCAwwVpxSVF0cm1gAnTltaLWCW VEBEezxNeAsw2yYdx3WIvSqwddyJP/3UyzKg8/+CTrQr5GInciFNgsnuMeLfvtLUck+dcILUx8u P3t69SpK1l8qgxNMUqjGa5Abz9zcPzEiQeNMuuJbSfHU4ho8bCdT6nw5SiqlksUeidQPhzKDipu CH78QU69VAywUflPfsynamTFBqFErLQNWZLYZHTAilzb48Y892DFD/P1ZbWj8WyBnPGk+m09klh lDssbez5p025uHftflYldXsT6yQoO0FM8LlbvYVSNmufnTK7lO+nRpIbQdvCMI0nzsywIaJPZ1u zraShoL9MohT+U0eOntUE66mZCSOcc+qNpoFixgN4ME9x3qLPDIrxsQFe X-Received: by 2002:ac8:5705:0:b0:501:452b:7f5b with SMTP id d75a77b69052e-506393b6928mr19531731cf.32.1770351599395; Thu, 05 Feb 2026 20:19:59 -0800 (PST) X-Received: by 2002:ac8:5705:0:b0:501:452b:7f5b with SMTP id d75a77b69052e-506393b6928mr19531521cf.32.1770351599004; Thu, 05 Feb 2026 20:19:59 -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 d75a77b69052e-5063929099asm8347111cf.22.2026.02.05.20.19.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Feb 2026 20:19:58 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: Date: Thu, 5 Feb 2026 23:19:56 -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: Waiman Long , Al Viro Cc: Paul Moore , Eric Paris , Christian Brauner , linux-kernel@vger.kernel.org, audit@vger.kernel.org, Richard Guy Briggs , Ricardo Robaina References: <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> <50054d23-0a89-41ec-b28b-b1ed77d93b00@redhat.com> <20260205235351.GU3183987@ZenIV> <8a456257-6f7e-4d0a-b38d-3c2aefee76bb@redhat.com> <3a5f84fc-5c4e-4ce1-b2dd-6e07b109ce78@redhat.com> Content-Language: en-US In-Reply-To: <3a5f84fc-5c4e-4ce1-b2dd-6e07b109ce78@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/5/26 11:11 PM, Waiman Long wrote: > On 2/5/26 8:20 PM, Waiman Long wrote: >> On 2/5/26 6:53 PM, Al Viro wrote: >>> On Wed, Feb 04, 2026 at 11:45:17PM -0500, Waiman Long wrote: >>> >>>> @@ -70,6 +74,8 @@ void chroot_fs_refs(const struct path *old_root, >>>> const >>>> struct> >>>>                                  count++; >>>>                                  path_get(new_root); >>>>                          } >>>> +                       count += fs->pwd_xrefs; >>>> +                       fs->pwd_xrefs = 0; >>>>                          write_sequnlock(&fs->seq); >>> Nope - you only need that for threads that have ->pwd equal to >>> old_root. >>> Incidentally, I'd forgotten about that sucker - it kills the idea of >>> fdget-like tricks dead, more's the pity.  Third-party modification of >>> task->fs->pwd (under task->lock and task->fs->seq), possible even with >>> task->fs->users == 1. >> >> Yes, I am aware of that when I took a further look at the patch that >> I sent out yesterday. I am testing the updated patch now and is >> trying to figure out why I get a warning from >> mntput_no_expire_slowpath() with a count of -1 when doing an umount. >> It is off by 1 somewhere. I will post the patch once I resolve this bug. > > I now know why there are warnings. The problem is in the copy_mnt_ns() > function in fs/namespace.c: > > __latent_entropy > struct mnt_namespace *copy_mnt_ns(u64 flags, struct mnt_namespace *ns, >                 struct user_namespace *user_ns, struct fs_struct *new_fs) > { >   : >                 if (new_fs) { >                         if (&p->mnt == new_fs->root.mnt) { >                                 new_fs->root.mnt = mntget(&q->mnt); >                                 rootmnt = &p->mnt; >                         } >                         if (&p->mnt == new_fs->pwd.mnt) { >                                 new_fs->pwd.mnt = mntget(&q->mnt); >                                 pwdmnt = &p->mnt; >                         } >                 } > > It is replacing the fs->pwd.mnt with a new one while pwd_refs is 1. I > can make this work with the new fs_struct field. I do have one > question though. Do we need to acquire write_seqlock(&new_fs->seq) if > we are changing root or pwd here or if the new_fs are in such a state > that it will never change when this copying operation is in progress? Ah, there are comment above saying         /*          * Second pass: switch the tsk->fs->* elements and mark new vfsmounts          * as belonging to new namespace.  We have already acquired a private          * fs_struct, so tsk->fs->lock is not needed.          */ So I guess it is safe to make change without taking the lock. Cheers, Longman