linux-kernel - Re: [PATCH] btrfs: Add the nlink annotation in btrfs_inode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <adda6065-26a2-4d31-b4f0-ccb20e0fadeb@gmx.com>
Date: Fri, 26 Sep 2025 18:04:57 +0930
From: Qu Wenruo <quwenruo.btrfs@....com>
To: Youling Tang <youling.tang@...ux.dev>, Chris Mason <clm@...com>,
 Josef Bacik <josef@...icpanda.com>, David Sterba <dsterba@...e.com>
Cc: linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
 Youling Tang <tangyouling@...inos.cn>
Subject: Re: [PATCH] btrfs: Add the nlink annotation in btrfs_inode_item



在 2025/9/26 17:15, Youling Tang 写道:
> From: Youling Tang <tangyouling@...inos.cn>
> 
> When I created a directory, I found that its hard link count was
> 1 (unlike other file system phenomena, including the "." directory,
> which defaults to an initial count of 2).
> 
> By analyzing the code, it is found that the nlink of the directory
> in btrfs has always been kept at 1, which is a deliberate design.
> 
> Adding its comments can prevent it from being mistakenly regarded
> as a BUG.
> 
> Signed-off-by: Youling Tang <tangyouling@...inos.cn>
> ---
>   include/uapi/linux/btrfs_tree.h | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tree.h
> index fc29d273845d..b4f7da90fd0e 100644
> --- a/include/uapi/linux/btrfs_tree.h
> +++ b/include/uapi/linux/btrfs_tree.h
> @@ -876,6 +876,7 @@ struct btrfs_inode_item {
>   	__le64 size;
>   	__le64 nbytes;
>   	__le64 block_group;
> +	/* nlink in directories is fixed at 1 */

nlink of what?

Shouldn't be "nlink of directories" or "nlink of directory inodes"?


There are better location like 
btrfs-progs/Documentation/dev/On-disk-format.rst for this.

And you're only adding one single comment for a single member?
Even this is a different behavior compared to other fses, why not 
explain what the impact of the change?


If you really want to add proper comments, spend more time and effort 
like commit 9c6b1c4de1c6 ("btrfs: document device locking") to do it 
correctly.

Thanks,
Qu

>   	__le32 nlink;
>   	__le32 uid;
>   	__le32 gid;