[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260207073948.48144-1-adarshdas950@gmail.com>
Date: Sat, 7 Feb 2026 13:09:48 +0530
From: Adarsh Das <adarshdas950@...il.com>
To: Zhihao Cheng <chengzhihao1@...wei.com>
Cc: dwmw2@...radead.org,
richard@....at,
linux-mtd@...ts.infradead.org,
linux-kernel@...r.kernel.org,
Adarsh Das <adarshdas950@...il.com>
Subject: Re: [PATCH] jffs2: use fs_umode_to_dtype() for dirent type
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
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.
Powered by blists - more mailing lists