From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout11.his.huawei.com (canpmsgout11.his.huawei.com [113.46.200.226]) (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 E469A1FE47B for ; Sat, 7 Feb 2026 02:36:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.226 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770431801; cv=none; b=mIR+amvXdxyHyvbPp27nH0PQY8/VLiyciEZi+YwNL72w2smiM/UjycQJUtWTQ67DsGXoCt2xZgifr4dGM5AGOw+Iwgbw++qobITHw2C9LQdMw2RGs4ioeWfNfAnT5XoGfDJ7dK0IDnxbGploqQv1xw/gnWaCiCXvJ/oNwoTiZwY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770431801; c=relaxed/simple; bh=ox4s4HpdP8BYwiwafiiOxk6BObkYBok9uE0nAgeJqcQ=; h=Subject:To:CC:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=cjoJkq5EfYInrdpd8QOX5B2R+3iMFYKHIb0TubBs867azAyie/6S7rrLx4v+B1X2aX+ZCpuKA9pM0uxvhqCe8ev5h1rSIdfqbanZSXFyi5PH3/Q595H4CSBTjUai7M3/soEakBwfRw9NmLMAQHdpvILHtMyIIrHD8al+luD1shQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=pHdd7CtM; arc=none smtp.client-ip=113.46.200.226 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="pHdd7CtM" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=wfqvc3BXrGKiR4wiQAq3dq087OBHYWgm5FyBM0o1zqU=; b=pHdd7CtMBE+Pyp6R7lFfBDivBhuvfbpjF6C52PrCIj6lwXNllHIYNHYJeS8i24cIRDZRY1F0d homzgMAuXmQwiaZyzcDXCJ6xW/YFZDff0aX1Qvd6Q81LNfYhv2ys7uo2oRhY+CWjWjDCkP8fj5J AHwREK7j2GIWKcs5DeP2NaU= Received: from mail.maildlp.com (unknown [172.19.163.15]) by canpmsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4f7FMt6JTbzKm4t; Sat, 7 Feb 2026 10:31:54 +0800 (CST) Received: from kwepemk500005.china.huawei.com (unknown [7.202.194.90]) by mail.maildlp.com (Postfix) with ESMTPS id 3E9004056D; Sat, 7 Feb 2026 10:36:31 +0800 (CST) Received: from [10.174.178.46] (10.174.178.46) by kwepemk500005.china.huawei.com (7.202.194.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sat, 7 Feb 2026 10:36:30 +0800 Subject: Re: [PATCH] jffs2: use fs_umode_to_dtype() for dirent type To: Adarsh Das , , CC: , References: <20260206115100.84852-1-adarshdas950@gmail.com> From: Zhihao Cheng Message-ID: <134dec36-3bcf-89a4-2817-a880afa4280f@huawei.com> Date: Sat, 7 Feb 2026 10:36:29 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20260206115100.84852-1-adarshdas950@gmail.com> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemk500005.china.huawei.com (7.202.194.90) ÔÚ 2026/2/6 19:51, Adarsh Das дµÀ: > Use fs_umode_to_dtype() instead of direct bit shifting when > setting directory entry type. > > Signed-off-by: Adarsh Das > --- > fs/jffs2/dir.c | 11 +++-------- > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git a/fs/jffs2/dir.c b/fs/jffs2/dir.c > index dd91f725ded6..185cf76a061e 100644 > --- a/fs/jffs2/dir.c > +++ b/fs/jffs2/dir.c > @@ -261,8 +261,7 @@ static int jffs2_link (struct dentry *old_dentry, struct inode *dir_i, struct de > if (d_is_dir(old_dentry)) > return -EPERM; > > - /* XXX: This is ugly */ > - type = (d_inode(old_dentry)->i_mode & S_IFMT) >> 12; > + type = fs_umode_to_dtype(d_inode(old_dentry)->i_mode); > if (!type) type = DT_REG; Hi Adarsh, The convertion result is wrong for jffs2_do_link. The i_mode of old_dentry is 'S_IFIFO', the jffs2 gets type DT_FIFO(1) and pass it to 'rd->type' by jffs2_do_link. However, after the patch applied, jffs2 gets type FT_FIFO(5), which will confuse other 'rd->type' accessing processes(eg. jffs2_scan_dirent_node[rd->type], jffs2_build_filesystem[fd->type]). > > now = JFFS2_NOW(); > @@ -730,10 +729,7 @@ static int jffs2_mknod (struct mnt_idmap *idmap, struct inode *dir_i, > rd->ino = cpu_to_je32(inode->i_ino); > rd->mctime = cpu_to_je32(JFFS2_NOW()); > rd->nsize = namelen; > - > - /* XXX: This is ugly. */ > - rd->type = (mode & S_IFMT) >> 12; > - > + rd->type = fs_umode_to_dtype(mode); > rd->node_crc = cpu_to_je32(crc32(0, rd, sizeof(*rd)-8)); > rd->name_crc = cpu_to_je32(crc32(0, dentry->d_name.name, namelen)); > > @@ -811,8 +807,7 @@ static int jffs2_rename (struct mnt_idmap *idmap, > > /* Make a hard link */ > > - /* XXX: This is ugly */ > - type = (d_inode(old_dentry)->i_mode & S_IFMT) >> 12; > + type = fs_umode_to_dtype(d_inode(old_dentry)->i_mode); > if (!type) type = DT_REG; > > now = JFFS2_NOW(); >