linux-kernel - Re: [PATCH] jffs2: use fs_umode_to

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <6fed1bb5-7d9a-c60d-f243-4e06d29c8af8@huawei.com>
Date: Sat, 7 Feb 2026 15:59:44 +0800
From: Zhihao Cheng <chengzhihao1@...wei.com>
To: Adarsh Das <adarshdas950@...il.com>
CC: <dwmw2@...radead.org>, <richard@....at>, <linux-mtd@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] jffs2: use fs_umode_to_dtype() for dirent type

在 2026/2/7 15:39, Adarsh Das 写道:
> Hi Zhihao,
> 
> Thank you for taking the time to review my patch!
> 
> I'm trying to understand the issue you've identified. I looked at the
> fs_umode_to_dtype() implementation in fs/fs_types.c:
> 
>      unsigned char fs_umode_to_dtype(umode_t mode) {
>          return fs_ftype_to_dtype(fs_umode_to_ftype(mode));
>      }
> 
>>>From what I can see, it seems like the function does produce FT_FIFO (5) 
> as an intermediate value, but then converts it back before returning.
> Here's what I think happens for S_IFIFO (0010000):
> 
> Old bit-shift code:
>      type = (mode & S_IFMT) >> 12
>           = (0010000 & 00170000) >> 12
>           = 0010000 >> 12
>           = 1 (DT_FIFO)
> 
> New fs_umode_to_dtype() code:
>      Step 1: fs_umode_to_ftype(0010000)
>              = fs_ftype_by_dtype[S_DT(0010000)]
>              = fs_ftype_by_dtype[1]
>              = FT_FIFO = 5
> 
>      Step 2: fs_ftype_to_dtype(5)
>              = fs_dtype_by_ftype[5]
>              = DT_FIFO = 1
> 

Oh, that's fs_umode_to_dtype, sorry for the mistake, I saw it as 
'fs_umode_to_ftype'.

> I'm not sure how FT_FIFO (5) would remain after the function returns, since
> it seems to get converted back to DT_FIFO (1) in step 2.
> 
> If there's an issue with this approach, I can edit my patch and keep changes in only jffs2_mknod.
> .
>