public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Julian Sun <sunjunchao2870@gmail.com>
Cc: Baokun Li <libaokun1@huawei.com>,
	linux-ext4@vger.kernel.org, adilger.kernel@dilger.ca,
	jack@suse.cz, Yang Erkun <yangerkun@huawei.com>
Subject: Re: [PATCH] ext4: remove unnecessary checks for __GFP_NOFAIL allocation.
Date: Fri, 28 Feb 2025 08:34:40 -0500	[thread overview]
Message-ID: <20250228133440.GB15240@mit.edu> (raw)
In-Reply-To: <CAHB1NaigQx0HW3Oxd2P9uujGk221WjxeKOgaNj-p2WqMJaQZiA@mail.gmail.com>

On Fri, Feb 28, 2025 at 05:30:06PM +0800, Julian Sun wrote:
> > Actually, even with __GFP_NOFAIL set, kcalloc() can still return NULL,
> > such as when the input parameters overflow.
> >
> Yeah, agreed. But IMO an overflow shouldn’t happen in this situation.
> 
> If there's something I'm missing, please let me know.

It's not a matter of missing something; or even Right vs Wrong.
Different maintainers have different tastes about this sort of thing.

The mm folks have changed the meaning of __GFP_NOFAIL in the past
(TL;DR: they *hate* that concept, and I wouldn't be surprised if they
try to change its behavior in the future) and especially in large code
bases such as the Linux Kernel, I'm a big believer in defensive
programming.

As Linus has said in a different thread, when a compiler adds warnings
because of what it thinks are "unnecessary" range checks, that's a bad
warning.  Adding extra range checks is never a bad thing, and compiler
behaviour that whine about that sort of thing are.... unfortunate.
Similarly, I'd much rather keep the extra check.

(Also, there exist static program checkers, such as Coverity, that
don't know about the semantics of the GFP_* flags, and so removing the
check would actually cause those tools to complain.)

Cheers,

					- Ted

  reply	other threads:[~2025-02-28 13:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-28  8:11 [PATCH] ext4: remove unnecessary checks for __GFP_NOFAIL allocation Julian Sun
2025-02-28  8:44 ` Baokun Li
2025-02-28  9:30   ` Julian Sun
2025-02-28 13:34     ` Theodore Ts'o [this message]
2025-03-01 14:32       ` Julian Sun
2025-02-28 10:19 ` Zhang Yi

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=20250228133440.GB15240@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.cz \
    --cc=libaokun1@huawei.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sunjunchao2870@gmail.com \
    --cc=yangerkun@huawei.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