public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joel Becker <jlbec@evilplan.org>
To: Zijun Hu <zijun_hu@icloud.com>
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-kernel@vger.kernel.org, Zijun Hu <quic_zijuhu@quicinc.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 4/4] configfs: Correct condition for returning -EEXIST in configfs_symlink()
Date: Tue, 8 Apr 2025 15:49:27 -0700	[thread overview]
Message-ID: <Z_Wn978o-kwscN29@google.com> (raw)
In-Reply-To: <20250408-fix_configfs-v1-4-5a4c88805df7@quicinc.com>

On Tue, Apr 08, 2025 at 09:26:10PM +0800, Zijun Hu wrote:
> From: Zijun Hu <quic_zijuhu@quicinc.com>
> 
> configfs_symlink() returns -EEXIST under condition d_unhashed(), but the
> condition often means the dentry does not exist.
> 
> Fix by changing the condition to !d_unhashed().

I don't think this is quite right.

viro put this together in 351e5d869e5ac, which was a while ago.  Read
his comment on 351e5d869e5ac.  Because I unlock the parent directory to
look up the target, we can't trust our symlink dentry hasn't been
changed underneath us.

* If there is now dentry->d_inode, some other inode has been put here.
  -EEXIST.
* If the dentry was unhashed, somehow the dentry we are creating was
  removed from the dcache, and adding things to our dentry will at best
  go nowhere, and at worst dangle in space.  I'm pretty sure viro
  returns -EEXIST because if this dentry is unhashed, some *other*
  dentry has entered the dcache in its place (another file type,
  perhaps).

If you instead check for !d_unhashed(), you're discovering our candidate
dentry is still live in the dcache, which is what we expect and want.

How did you identify this as a problem?  Perhaps we need a more nuanced
check than d_unhashed() these days (for example, d_is_positive/negative
didn't exist back then).

Thanks,
Joel

PS: I enjoyed the trip down memory lane to Al reaming me quite
    thoroughly for this API.

> 
> Fixes: 351e5d869e5a ("configfs: fix a deadlock in configfs_symlink()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
> ---
>  fs/configfs/symlink.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/configfs/symlink.c b/fs/configfs/symlink.c
> index 69133ec1fac2a854241c2a08a3b48c4c2e8d5c24..cccf61fb8317d739643834e1810b7f136058f56c 100644
> --- a/fs/configfs/symlink.c
> +++ b/fs/configfs/symlink.c
> @@ -193,7 +193,7 @@ int configfs_symlink(struct mnt_idmap *idmap, struct inode *dir,
>  	if (ret)
>  		goto out_put;
>  
> -	if (dentry->d_inode || d_unhashed(dentry))
> +	if (dentry->d_inode || !d_unhashed(dentry))
>  		ret = -EEXIST;
>  	else
>  		ret = inode_permission(&nop_mnt_idmap, dir,
> 
> -- 
> 2.34.1
> 

-- 

"We will have to repent in this generation not merely for the
 vitriolic words and actions of the bad people, but for the 
 appalling silence of the good people."
	- Rev. Dr. Martin Luther King, Jr.

			http://www.jlbec.org/
			jlbec@evilplan.org

  reply	other threads:[~2025-04-08 22:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-08 13:26 [PATCH 0/4] configfs: fix bugs Zijun Hu
2025-04-08 13:26 ` [PATCH 1/4] configfs: Delete semicolon from macro type_print() definition Zijun Hu
2025-04-08 22:12   ` Joel Becker
2025-04-17 14:38   ` Breno Leitao
2025-04-17 14:47     ` Zijun Hu
2025-04-08 13:26 ` [PATCH 2/4] configfs: Do not override creating attribute file failure in populate_attrs() Zijun Hu
2025-04-08 22:14   ` Joel Becker
2025-04-08 13:26 ` [PATCH 3/4] configfs: Correct error value returned by API config_item_set_name() Zijun Hu
2025-04-08 22:26   ` Joel Becker
2025-04-08 13:26 ` [PATCH 4/4] configfs: Correct condition for returning -EEXIST in configfs_symlink() Zijun Hu
2025-04-08 22:49   ` Joel Becker [this message]
2025-04-10  1:17     ` Zijun Hu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z_Wn978o-kwscN29@google.com \
    --to=jlbec@evilplan.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pantelis.antoniou@konsulko.com \
    --cc=quic_zijuhu@quicinc.com \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zijun_hu@icloud.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox