On Thu, Sep 27, 2018 at 5:51 PM, Christopher Lameter <cl@xxxxxxxxx> wrote: > On Thu, 27 Sep 2018, Dmitry Vyukov wrote: > >> From: Dmitry Vyukov <dvyukov@xxxxxxxxxx> >> >> This warning does not seem to be useful. Most of the time it fires when >> allocation size depends on syscall arguments. We could add __GFP_NOWARN >> to these allocation sites, but having a warning only to suppress it >> does not make lots of sense. Moreover, this warnings never fires for >> constant-size allocations and never for slub, because there are >> additional checks and fallback to kmalloc_large() for large allocations >> and kmalloc_large() does not warn. So the warning only fires for >> non-constant allocations and only with slab, which is odd to begin with. >> The warning leads to episodic unuseful syzbot reports. Remote it. > > /Remove/ > > If its only for slab then KMALLOC_MAX_CACHE_SIZE and KMALLOC_MAX_SIZE are > the same value. > >> While we are here also fix the check. We should check against >> KMALLOC_MAX_CACHE_SIZE rather than KMALLOC_MAX_SIZE. It all kinda >> worked because for slab the constants are the same, and slub always >> checks the size against KMALLOC_MAX_CACHE_SIZE before kmalloc_slab(). >> But if we get there with size > KMALLOC_MAX_CACHE_SIZE anyhow >> bad things will happen. > > Then the WARN_ON is correct just change the constant used. Ensure that > SLAB does the same checks as SLUB. Mailed v2 which adds the checks to slab. I think the warning is still slightly wrong. It means a bug in slab code, it has nothing to do with user-passed flags.
