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 9F3D070809 for ; Thu, 5 Feb 2026 03:03:38 +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=1770260618; cv=none; b=PaTjAbf3Ud/uyMxQ9IFjzyS6GDkgmZeIpA7edsjLEOyGbBSqaveyc9a7L223VkAB+JWZcLYQrt0O3RYxwp8tgcHfaOw7mGJ4fJTlkaXLQRmlht9CtDvP6M/2Hg29z4ejOPh+IdtsQUdskRlnPnyQ0lMtpy+BMEBFfL+Rbo4Y/lI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770260618; c=relaxed/simple; bh=YTuO9XOMYtQFSw91OdsurWUE3AwydW6ZsPKdxKOP4BQ=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=EHxGdMtfi5aUOwFtR92LARGGQcjilzewCKWLVCzGlSBW68bkFpGmp9irwEWBG5h3kYPyeO1hjdFYblL9/jFQIcTa43upZk9wcgYeOGekftMfuFtgBV5ngxQUItIYZpaj94J4pw/UyCak1Oh2OmfQdcq7YAHXB7nY7o0Q2SCdfmY= 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=acAthcJw; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=CwcII7E2; 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="acAthcJw"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="CwcII7E2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770260617; 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=IS3q9AjcgkzFfU3S4BSLVe3cPj6Y9pQ2xt5zDDWIl+Y=; b=acAthcJw276rVCFtV5yNJyJH1klcnLu5FMzl9fjsY1ZOQRIqsO+/Uy5iXAg7ckWkPuOfMp sxUV3wnqvih1sRo7i21lPmDAzIi6TlLU+cmdO0tHxzNeY95je3TNzv6vK0RekMJ4t8yCAR OFxY3YmWn47KnwP0j/mDuqdX8Qq+cVY= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-295-xelqCDvYOTuZp4vYliH9nw-1; Wed, 04 Feb 2026 22:03:36 -0500 X-MC-Unique: xelqCDvYOTuZp4vYliH9nw-1 X-Mimecast-MFC-AGG-ID: xelqCDvYOTuZp4vYliH9nw_1770260616 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-5014c472ad5so16259551cf.0 for ; Wed, 04 Feb 2026 19:03:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770260616; x=1770865416; 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=IS3q9AjcgkzFfU3S4BSLVe3cPj6Y9pQ2xt5zDDWIl+Y=; b=CwcII7E2CVYTLXeEHMS/liVjWLAC7TepT5HbeX/BbXCVkQDrgSp/nSgl38pffMhRpf C2LJYiVqhjR6BZBVEn23e6KFzxYbj8A3kM5WKRkLATvvvuuX0ZGnN3bHHYNVsEhnE3d7 1nFgM8SPhVxc3zmL4M1u0Tq6yspIFO/uJS1olNBGVh9MHN3qoBcDv4aJYbBuvjeiXybe Z+wRgEDLpMeOhJtmN8gmtfXqzYCXxd6NFvmmfAs6llJt2y2Gtj8+VDsunKeYSqCokJRv 5EhL+CNllWSPVe79B1LHPliUKTJbqNNgh8JZuVaPIn1O62bplawiQ0WRZ0Ti5o4x9wCj TLWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770260616; x=1770865416; 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=IS3q9AjcgkzFfU3S4BSLVe3cPj6Y9pQ2xt5zDDWIl+Y=; b=mjA2NFP3GImo99iGsXFMOlhFjkixcjyAOBK2HMqrMcg+WW3IM5onxEFEABuh/Ff8Dz KdrGVh6fUnFBFSY9Uv5j0EnIkGugCM0wNwQo8/vFHTisTDBzqSmKZBCbdAgmbNva7x9P jYimxNVBu3WedfBbCWlRSMPWg2+TnRl1S8VBO1FjPPlVN320OflM6VOoUGgHqfC+o/Yw Aj5f1omjVXDtBYGX4X3s+aJLylRHEofnPudbOHB0f/RUnoPncfzD7KHadNi3zqJaSkAb tB3oqpkRMGQZ+qFGBaLvnRJAko0lHuqJevpSbE+H+MDZ9ET1SMMjSwBPH2923G0i7Tkm kYuQ== X-Forwarded-Encrypted: i=1; AJvYcCUXrd+859SJyQ5nJNjFzxjUtEza4A6EYCN+r8f+RPv3/itN6tznjQmYh6x12Q+LnyesALIb65kAsUO0oic=@vger.kernel.org X-Gm-Message-State: AOJu0Yy5XqFZUBn3zQerj2DEuuJVvpSLab//IG3WjmHdFnPwdaylEHeX gClgWLuxGry32yHe2MKJ/9S9QzXcw7ht28vctA7Y4CONpGNnuvxKk4BNYTLeyUXVOvubdAUuvIX TVUgR9cx2ivf/lrHRKywmO1h64ws8FOp6oLsaCWnfCPB56COc+o+BVj3Sr0x2trF/dA== X-Gm-Gg: AZuq6aKSA4+yXAg+RoIGksGHrObAOm9TMznaYthjtzmaG/3WsXTQ+VjEh10uXScVj9d jNOKkrWkUfVimlXT2FUY9cbAZow7Q/Hxh5xDp/ZLXKHFMs9BRNQrtYyFgDBpzDJJE8YHhPTJp+F Zc484H1tYW/iD6VOSoicGVPm4cnBrhVQb/uSbyginAw6aRf+ZOyQj+yYM1VV29V5naSvlUJJd61 MzD0kIiRAmPloba09fAcr8Mrw+RYzT58xuQJaelLJrJLvECAtBYS8h8ipAxu38gA0XGax7fudKD Sw+mZFqk+BMJKj/HlwLP90uAV6+sBoPmHs1u0x21dWv7miNXYSm5l/B6eAIX60CXoJRj0c9skyq u3rYod/SqTP1nu7BFywDURs+Un254zEyjLCj9Ex1fQesscG6TkimqcoMy X-Received: by 2002:ac8:59d0:0:b0:4ee:441c:dfb2 with SMTP id d75a77b69052e-5061c15ec30mr58132641cf.32.1770260615639; Wed, 04 Feb 2026 19:03:35 -0800 (PST) X-Received: by 2002:ac8:59d0:0:b0:4ee:441c:dfb2 with SMTP id d75a77b69052e-5061c15ec30mr58132361cf.32.1770260615239; Wed, 04 Feb 2026 19:03:35 -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-5061c213fcbsm29866831cf.32.2026.02.04.19.03.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Feb 2026 19:03:34 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: Date: Wed, 4 Feb 2026 22:03:33 -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> <6661f966-5235-49ca-bf1f-d1ae2ae32f0d@redhat.com> <20260204062614.GK3183987@ZenIV> <46d5c480-87d0-4f6a-bcc2-6c936c87e216@redhat.com> <20260204201815.GP3183987@ZenIV> Content-Language: en-US In-Reply-To: <20260204201815.GP3183987@ZenIV> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/4/26 3:18 PM, Al Viro wrote: > On Wed, Feb 04, 2026 at 01:16:15PM -0500, Waiman Long wrote: > > >> Thanks for the detailed explanation. I am thinking about something like >> the code diff below. Of course, there are other corner cases like unshare(2) >> that still needs to be handled. Do you think something like this is viable? > Deadlocks aside, the immediate problem here is that consensus number is too > low. Take three threads sharing the same fs_struct instance. The first one > calls your get_fs_pwd_share(); then the remaining two threads call set_fs_pwd() > (e.g. by calling chdir(2) in userland code). The reference stored into > fs->pwd_waiter by the first of those two gets overwritten by that stored > by the second. When the caller of get_fs_pwd_share() gets to put_fs_pwd_share(), > only one of the sleepers gets woken up... > > And it's very easy to end up with something as simple as chdir("foo") deadlocking - > we start with resolving the relative pathname we'd been given, audit wants to > record the current directory, on the theory that relative pathname is none too > useful in logs without knowing what had it been relative to. Then, in the > same thread, you call set_fs_pwd() - after all, that's the main effect of chdir(2). > Deadlock... > > IOW, it's not just unshare(2) that needs to be taken care of - chdir(2) would need > to be treated differently. 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? Thanks, Longman =======================[ Cut here ]================================ diff --git a/fs/fs_struct.c b/fs/fs_struct.c index b8c46c5a38a0..daeeb80cf088 100644 --- a/fs/fs_struct.c +++ b/fs/fs_struct.c @@ -32,15 +32,19 @@ void set_fs_root(struct fs_struct *fs, const struct path *p>  void set_fs_pwd(struct fs_struct *fs, const struct path *path)  {         struct path old_pwd; +       int xrefs;         path_get(path);         write_seqlock(&fs->seq);         old_pwd = fs->pwd;         fs->pwd = *path; +       xrefs = fs->pwd_xrefs + 1; +       fs->pwd_xrefs = 0;         write_sequnlock(&fs->seq);         if (old_pwd.dentry) -               path_put(&old_pwd); +               while (xrefs--) +                       path_put(&old_pwd);  }  static inline int replace_path(struct path *p, const struct path *old, const s> diff --git a/include/linux/fs_struct.h b/include/linux/fs_struct.h index 0070764b790a..0d79d51de240 100644 --- a/include/linux/fs_struct.h +++ b/include/linux/fs_struct.h @@ -8,10 +8,11 @@  #include  struct fs_struct { -       int users;         seqlock_t seq; +       int users;         int umask;         int in_exec; +       int pwd_xrefs;  /* Extra references of pwd */         struct path root, pwd;  } __randomize_layout; @@ -40,6 +41,31 @@ static inline void get_fs_pwd(struct fs_struct *fs, struct p>         read_sequnlock_excl(&fs->seq);  } +static inline void get_fs_pwd_share(struct fs_struct *fs, struct path *pwd) +{ +       read_seqlock_excl(&fs->seq); +       *pwd = fs->pwd; +       if (fs->pwd_xrefs) +               fs->pwd_xrefs--; +       else +               path_get(pwd); +       read_sequnlock_excl(&fs->seq); +} + +static inline void put_fs_pwd_share(struct fs_struct *fs, struct path *pwd) +{ +       bool put = false; + +       read_seqlock_excl(&fs->seq); +       if ((fs->pwd.dentry == pwd->dentry) && (fs->pwd.mnt == pwd->mnt)) +               fs->pwd_xrefs++; +       else +               put = true; +       read_sequnlock_excl(&fs->seq); +       if (put) +               path_put(pwd); +} +  extern bool current_chrooted(void);  static inline int current_umask(void)