The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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>

  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