On Tue, May 29, 2018 at 9:51 AM Michal Hocko <mhocko@xxxxxxxxxx> wrote:
> In other words, what about the following?
> + WARN_ON_ONCE((flags & (__GFP_FS|__GFP_IO)) !=
(__GFP_FS|__GFP_IO));
I still don't understand the point of this warning.
It's only stupid. It basically says "this function is garbage, so let me
warn about the fact that I'm a moron".
If we all needed to warn about ourselves being morons, there would be a
hell of a lot of big blinking signs everywhere.
And the *ONLY* thing that warning has ever caused is just stupid code that
does
if (flags == GFP_KERNEL)
.. do kvmalloc ..
else
.. do kmalloc() ..
which is a *STUPID* pattern.
In other words, the WARN_ON() is bogus garbage. It's bogus exactly because
NOBODY CARES and all everybody will ever do is to just avoid it by writing
worse code.
The whole and ONLY point of "kvmalloc()" and friends is to make it easy to
write code and _not_ have those idiotic "let's do kmalloc or kvmalloc
depending on the phase of the moon" garbage. So the warning has literally
destroyed the only value that function has!
> + if (!gfpflags_allow_blocking(flags))
> + return NULL;
> +
And no. Now all the code *above* this check is just wrong. All the code
that modifies the gfp_flags with the intention of falling back on vmalloc()
is just wrong, since we're not falling back on vmalloc any more.
So I really think the semantics should be simple:
- if we don't allow GFP_KERNEL, then the code becomes just "kmalloc()",
since there is no valid fallback to vmalloc. vmalloc does GFP_KERNEL.
- otherwise, we do what we used to do (except now the warning is gone,
because we already handled the case it warned about).
Nothing else. No stupid other cases. The *only* thing that function should
ask itself is "can I fall back on vmalloc or not", and if it can't then it
should just be a kmalloc.
Because otherwise we'll continue to have people that just check in the
caller instead.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
