From: Jan Kara <jack@suse.cz>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jan Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org
Subject: Re: [GIT PULL] fsnotify changes for 6.10-rc1
Date: Tue, 21 May 2024 13:58:58 +0200 [thread overview]
Message-ID: <20240521115858.mohqrlbzprdisc5i@quack3> (raw)
In-Reply-To: <CAHk-=whPmdZS5sNE3k4CUYOu79kE88VsfW0hyMBkVE9Wk-UjZw@mail.gmail.com>
On Mon 20-05-24 12:46:44, Linus Torvalds wrote:
> On Mon, 20 May 2024 at 04:22, Jan Kara <jack@suse.cz> wrote:
> >
> > * A few small cleanups
>
> This IS NOT A CLEANUP! It's a huge mistake:
>
> > Nikita Kiryushin (1):
> > fanotify: remove unneeded sub-zero check for unsigned value
>
> The old code did
>
> WARN_ON_ONCE(len < 0 || len >= FANOTIFY_EVENT_ALIGN);
>
> and that is very legible and very understandable to humans.
>
> The new code is
>
> WARN_ON_ONCE(len >= FANOTIFY_EVENT_ALIGN);
>
> and now a human that reads that line needs to go back and check what
> the type of 'len' is to notice that it's unsigned. It is not at all
> clear from the context, and the declaration of 'len' is literally 80
> lines up. Not very close at all, in other words.
So I was hesitating whether to take this or not because I liked the len < 0
check as well. Then I've convinced myself that the impression this check
gives that "if we miscomputed and used more than we should, the
WARN_ON_ONCE() would trigger" is incorrect because of underflow so better
delete it. But now that I've written it down and looked again that
impression is actually correct because the len >= FANOTIFY_EVENT_ALIGN
check will catch that situation instead. Long story short, I agree with
your revert.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2024-05-21 11:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-20 11:22 [GIT PULL] fsnotify changes for 6.10-rc1 Jan Kara
2024-05-20 19:46 ` Linus Torvalds
2024-05-21 11:58 ` Jan Kara [this message]
2024-05-20 20:30 ` pr-tracker-bot
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=20240521115858.mohqrlbzprdisc5i@quack3 \
--to=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).