From: "Theodore Ts'o" <tytso@mit.edu>
To: Matthew Wilcox <willy@infradead.org>
Cc: Tudor Ambarus <tudor.ambarus@linaro.org>,
adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org, joneslee@google.com,
linux-mm@kvack.org
Subject: Re: [PATCH] ext4: remove superfluous check that pointer is not NULL
Date: Tue, 9 May 2023 14:53:41 -0400 [thread overview]
Message-ID: <ZFqWtcmRwxhyem4p@mit.edu> (raw)
In-Reply-To: <ZFll93wsEUZIV/aI@casper.infradead.org>
On Mon, May 08, 2023 at 10:13:27PM +0100, Matthew Wilcox wrote:
> >
> > I was looking at this just a few weeks ago, and I couldn't find any
> > actual *documentation* that it was safe to call vfree(NIILL) or
> > kvfree(NULL). The problem is there are a lot of architecture-specific
> > functions, and unlike with kfree() there is no top-level "if (ptr ==
> > NULL) return;" in the top-level vfree() and kvfree().
>
> There doesn't need to be in kvfree(). is_vmalloc_addr() returns 'false'
> for NULL, so it calls kfree(), which as you note has an explicit check
> for ZERO_OR_NULL_PTR(). is_vmalloc_addr() also returns false for the
> ZERO pointer, fwiw.
>
> I agree that this should be explicitly documented as allowed, since it's
> not reasonable to expect users to dig through these functions to verify
> that such a change is safe.
I seem to recall at one point looking at kvfree_rcu (at least the one
argument variant), and I *thought* it would unconditionally allocate
memory so it could be put on a linked list to be freed after an RCU
grace period had elapsed. But I tried tracing through the huge
numbers of cpp macros and other layers of #ifdef's and other
abstractions, and in my conference-induced sleep depreviation, it
caused my head to spin, and I gave up trying to trace it down so I had
100% confidence.
So if someone could document *all* of the k[v]free_* variants whether
it is safe/optimal to pass NULL to them, that would be great, thanks.
- Ted
prev parent reply other threads:[~2023-05-09 18:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-08 15:13 [PATCH] ext4: remove superfluous check that pointer is not NULL Tudor Ambarus
2023-05-08 16:14 ` Theodore Ts'o
2023-05-08 21:13 ` Matthew Wilcox
2023-05-09 18:53 ` Theodore Ts'o [this message]
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=ZFqWtcmRwxhyem4p@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=joneslee@google.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tudor.ambarus@linaro.org \
--cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.