From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: zhoumin <teczm@foxmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] vfat:avoid unnecessary check
Date: Sat, 06 Sep 2025 01:37:06 +0900 [thread overview]
Message-ID: <87plc4n9e5.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <tencent_F5322517AD2A723568849905CF474A7D6C07@qq.com>
zhoumin <teczm@foxmail.com> writes:
>>> Remove redundant and unreachable name check code in dir.c.
>
>> Looks like you changed the logic, but no explanation.
>
> 1. In fat_parse_long:
> If (*de)->name[0] equals DELETED_FLAG, the function returns immediately.
> Consequently, the subsequent IS_FREE check can never evaluate to true.
> Therefore, retaining only the ATTR_VOLUME verification should be sufficient.
>
> 2. In fat_search_long:
> If (*de)->name[0] equals DELETED_FLAG, the loop skips to the next iteration.
> This makes the subsequent checks for IS_FREE and ATTR_EXT unreachable.These
> checks should therefore be removed.
>
> 3. In __fat_readdir:
> The same reasoning as in fat_search_long applies here.
Hm, IS_FREE() checks 0 and DELETED_FLAG, isn't it?
>>> Remove flags check in fat_update_time since fat does not support
>>> inode version.
>>>
>>> Optimize fat_truncate_time to return a meaningful value, allowing
>>> the removal of redundant inode checks in fat_update_time. This
>>> ensures non-root inodes are validated only once.
>
>> Also changed the logic, you removed the check of flags.
>
> Changing the return value of fat_truncate_time and removing the ino check in
> fat_update_time is a minor optimization, as mentioned in my previous patch email.
>
> The reason for removing the flags check is that the enum file_time_flags has
> only four values. Since vfat does not support SB_I_VERSION, higher-level
> functions such as inode_needs_update_time or inode_update_timestamps will never
> set flags with S_VERSION. Thus, checking the flags is unnecessary.
>
> Note that __mark_inode_dirty will not be called only for the root inode. This
> logic remains consistent with the previous version.
OK, thanks. I got the reason.
However I would prefer to keep the current code, for readability and
future changes, and explicitly check those time flags if there is no
measurable improvement.
Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
next prev parent reply other threads:[~2025-09-05 16:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-04 16:17 [RFC PATCH] vfat:avoid unnecessary check zhoumin
2025-09-04 19:01 ` OGAWA Hirofumi
2025-09-05 15:49 ` zhoumin
2025-09-05 16:37 ` OGAWA Hirofumi [this message]
2025-09-06 15:13 ` zhoumin
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=87plc4n9e5.fsf@mail.parknet.co.jp \
--to=hirofumi@mail.parknet.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=teczm@foxmail.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