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 BDDED1A285 for ; Fri, 6 Feb 2026 04:11:56 +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=1770351117; cv=none; b=dO1GHgCtHMScKvkCkpxX2rFzKLUkK9vfY5TuJ6VbjGNZcI81wQXeR0WU9RHOcKL9KCgTTYM9TjXmjdSlcqfxWifNq1Um6K9cM/LfeoA1582K4zXIvynoTe5hkgvJVIf8PaoQ6uuNowMuTI9fFGoMEtE7wXAcO6PHzkWEPrprGnc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770351117; c=relaxed/simple; bh=CqNvcZdgbnxnxEFIdy8rb7bQtmODIxBiyT4JV8C9dzI=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=UVd+GlXQIBD4tq0jL/zugYjCPMylAtkQiEPEqgZB/k198PleMA4hgShtnatkUbu9xdABVaad0ess/O9ybKonIAlybdpZfSDQsuzxzZggzC8dcAGaGLTBbZrctwCwOquDq9N4RMJUZU6qvbut8dibQxENH8zCLQ5Qwd0JqQdwIto= 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=dsq1X0h3; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=YT9Sf2Kr; 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="dsq1X0h3"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="YT9Sf2Kr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770351115; 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=xMjRxnp/naG1oRSEXueH5gSgIvo1mJhYDvUVqD1MzTU=; b=dsq1X0h3hToP7BGcyPRhyvZ1ulhhMWEU+LLoFkeQ1FvGYun32q7WfyRGl2UZoDmunuBj1r nG5LckGOeXMoBtqSutGGRLyTUpt8gEVyiZAImScbGWrZxa/DWJb3nA/Hxq7uZcHnPlFAD8 lhsiCNZwy73byoEkmqQbBuK52etx4eo= 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-421-8iD4Gw0iPi66oWhGSLoIhg-1; Thu, 05 Feb 2026 23:11:54 -0500 X-MC-Unique: 8iD4Gw0iPi66oWhGSLoIhg-1 X-Mimecast-MFC-AGG-ID: 8iD4Gw0iPi66oWhGSLoIhg_1770351114 Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-88a2cc5b548so84785766d6.0 for ; Thu, 05 Feb 2026 20:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770351114; x=1770955914; 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=xMjRxnp/naG1oRSEXueH5gSgIvo1mJhYDvUVqD1MzTU=; b=YT9Sf2Kr58oz+rcbkkW3+Vt4qD0ZFk2tvwnsJ7w58G97oMDZQaPj1BKpxo8Ol6IJm1 2joU6MY38NC0bfHhz1yBRV58uzx0U7LKuVjELAgPjbq/TWei1sNEatMaRkTh12ZCJdRr 2CjqV7QMDyK5a6gPeXj6SgkDPb++s+G091rCmCscAe7V8J7dOL/AREScLkaOb0KPBuDE 7kaoiWWImpdC1PpEUnc8fjljjBVxjuHuGusXcW0yPX+4Gg3f5Yk1H4QKriX1/Ht+IWqO wYyjJeG09LxGFLS5Aqy89UyIjxbjm0ene9UvDYblWgYyF6GNvX4JQ7Z61qohMIhIOisV 0eQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770351114; x=1770955914; 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=xMjRxnp/naG1oRSEXueH5gSgIvo1mJhYDvUVqD1MzTU=; b=TIGBxqldRVksvXU8FWr8tmtFBTAb1s0bNdL3x01Plez2RkrlBFWgvtvPShZxRNXV4q s0m0xkA5NRBh8oeSDzGSkCmVqXAvruanhgNsqL7EE5xk3iE51Tw9O8bobqBhALypZbvZ EN8/Vy4qLjdKs97xDsMQW9x5EJLgyyvcBbP/Y0ectFe4i2keTSxu7Dgt7X0jRkYN9kMQ EUBbWevULPz0u2QNWySoarhf9CzdTPjH9+tq6KBLzqO2Xm5cZ23e1AmVwxBt5UTP3863 SsfSHH8RdczPois+AUWS/Xl5S3JJbsq2yhIwKvX0AMbGyuU2JvQ6YK6H01qbwNTofkIi 4b/A== X-Forwarded-Encrypted: i=1; AJvYcCXHG3/6b3d04f7IOzGF1NLGWGE+bXrQEcH9xhCWHr88aRJqtDc3cRtOjtAZZusAVXd94nkqnftakx9AV44=@vger.kernel.org X-Gm-Message-State: AOJu0YzThflPVPWT+Qx+gOADxg+2Jo08TeLvpmeoPaNuWaVn1cPbAwjY +tQnSVJRaIL57TVj+LSn1fRHcAAo+uQKNeUcOa79biw1MzM9rNjK5hieFn49WeMOE6apzeuZyQP M4hidZ/AtU0PByJrJkKCP3+NwuVx3C6lxLN77Q/yn5aZMfiQJmoWwJ4E7CHlIIj/bTA== X-Gm-Gg: AZuq6aJW4HJknoZGK1GYytgcI0QoF3YkywhUBDoqJQQY4H9sZDhmo2/ILVko45MgEGy GJmyWqhRHPYT1Jdk5Z06T8A/HlbLrAZdu0IeilHYXXG00o7PSFL1ojZ4YaCdzx2rMS8f4LXghnb gISaakXji7I/ar2AYkF4KTOw7kROgBIug+SkM7Xxg0k5HxV6GZRpBQoeMHGEECS0YZHC0nuIg3W oE5oU6Ld0v3IjeAxmC+EftEQGvha/1OmHeThMceP9vdeOyDuwLZ12NavroBjXzsV0vEqcY5sjXD SwOHLIhYqdL8sfzbZCKuPQr8zqOtQyLf8tASbyRNGlFRiCv87I2fhpIzRZKju8ulSiTc7JairXq 5QDWFfl9sj9qhFsS30VDnEFnB+vNooNNQ+CBHrGSI2e+YQE4CX3L9Sc1J X-Received: by 2002:a05:620a:488e:b0:8b2:62ae:acba with SMTP id af79cd13be357-8ca40c19340mr594443185a.26.1770351113816; Thu, 05 Feb 2026 20:11:53 -0800 (PST) X-Received: by 2002:a05:620a:488e:b0:8b2:62ae:acba with SMTP id af79cd13be357-8ca40c19340mr594441085a.26.1770351113364; Thu, 05 Feb 2026 20:11:53 -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-8953c0759cbsm9628386d6.50.2026.02.05.20.11.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Feb 2026 20:11:52 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <3a5f84fc-5c4e-4ce1-b2dd-6e07b109ce78@redhat.com> Date: Thu, 5 Feb 2026 23:11:51 -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> Content-Language: en-US In-Reply-To: <8a456257-6f7e-4d0a-b38d-3c2aefee76bb@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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? Thanks in advance for your advice. Cheers, Longman