Message ID | 20220614083939.13508-1-renyu@nfschina.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | mm: check the function kmalloc_slab return value | expand |
On 6/14/22 10:39, Ren Yu wrote: > As the possible failure of the kmalloc_slab, > it should be better to check it. AFAIK failure is not possible, kmalloc_slab() is not an allocation function, it just returns a member of kmalloc_caches array, which is initialized elsewhere and shouldn't contain NULLs. So the patch seems unnecessary to me. > Signed-off-by: Ren Yu <renyu@nfschina.com> > Reported-by: kernel test robot <lkp@intel.com> > --- > v2: > - fix build waring integer from pointer without a cast > --- > --- > mm/slab.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/slab.c b/mm/slab.c > index f8cd00f4ba13..72135e555827 100644 > --- a/mm/slab.c > +++ b/mm/slab.c > @@ -2064,6 +2064,8 @@ int __kmem_cache_create(struct kmem_cache *cachep, slab_flags_t flags) > if (OFF_SLAB(cachep)) { > cachep->freelist_cache = > kmalloc_slab(cachep->freelist_size, 0u); > + if (unlikely(ZERO_OR_NULL_PTR(cachep->freelist_cache))) The usual way is "if (!cachep->freelist_cache)". Not sure why check for ZERO. > + return cachep->freelist_cache; So in case of NULL this would return NULL, thus 0, but __kmem_cache_create() return 0 on success, so it's wrong. You would have to return e.g. -ENOMEM. > } > > err = setup_cpu_cache(cachep, gfp);
在 2022年06月14日 16:48, Vlastimil Babka 写道: > On 6/14/22 10:39, Ren Yu wrote: >> As the possible failure of the kmalloc_slab, >> it should be better to check it. > AFAIK failure is not possible, kmalloc_slab() is not an allocation function, > it just returns a member of kmalloc_caches array, which is initialized > elsewhere and shouldn't contain NULLs. So the patch seems unnecessary to me. > >> Signed-off-by: Ren Yu <renyu@nfschina.com> >> Reported-by: kernel test robot <lkp@intel.com> >> --- >> v2: >> - fix build waring integer from pointer without a cast >> --- >> --- >> mm/slab.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/mm/slab.c b/mm/slab.c >> index f8cd00f4ba13..72135e555827 100644 >> --- a/mm/slab.c >> +++ b/mm/slab.c >> @@ -2064,6 +2064,8 @@ int __kmem_cache_create(struct kmem_cache *cachep, slab_flags_t flags) >> if (OFF_SLAB(cachep)) { >> cachep->freelist_cache = >> kmalloc_slab(cachep->freelist_size, 0u); >> + if (unlikely(ZERO_OR_NULL_PTR(cachep->freelist_cache))) > The usual way is "if (!cachep->freelist_cache)". Not sure why check for ZERO. > >> + return cachep->freelist_cache; > So in case of NULL this would return NULL, thus 0, but __kmem_cache_create() > return 0 on success, so it's wrong. You would have to return e.g. -ENOMEM. Thanks for the advice ,I'll be re-patching > >> } >> >> err = setup_cpu_cache(cachep, gfp); >
On 6/14/22 11:26, tury wrote: > > > 在 2022年06月14日 16:48, Vlastimil Babka 写道: >> On 6/14/22 10:39, Ren Yu wrote: >>> As the possible failure of the kmalloc_slab, >>> it should be better to check it. >> AFAIK failure is not possible, kmalloc_slab() is not an allocation function, >> it just returns a member of kmalloc_caches array, which is initialized >> elsewhere and shouldn't contain NULLs. So the patch seems unnecessary to me. >> >>> Signed-off-by: Ren Yu <renyu@nfschina.com> >>> Reported-by: kernel test robot <lkp@intel.com> >>> --- >>> v2: >>> - fix build waring integer from pointer without a cast >>> --- >>> --- >>> mm/slab.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/mm/slab.c b/mm/slab.c >>> index f8cd00f4ba13..72135e555827 100644 >>> --- a/mm/slab.c >>> +++ b/mm/slab.c >>> @@ -2064,6 +2064,8 @@ int __kmem_cache_create(struct kmem_cache *cachep, >>> slab_flags_t flags) >>> if (OFF_SLAB(cachep)) { >>> cachep->freelist_cache = >>> kmalloc_slab(cachep->freelist_size, 0u); >>> + if (unlikely(ZERO_OR_NULL_PTR(cachep->freelist_cache))) >> The usual way is "if (!cachep->freelist_cache)". Not sure why check for ZERO. >> >>> + return cachep->freelist_cache; >> So in case of NULL this would return NULL, thus 0, but __kmem_cache_create() >> return 0 on success, so it's wrong. You would have to return e.g. -ENOMEM. > Thanks for the advice ,I'll be re-patching However that was meant just for your information/learning, the patch is still unecessary as I wrote above, so I will not merge it so we don't complicate the code needlessly. >> >>> } >>> err = setup_cpu_cache(cachep, gfp); >> >
diff --git a/mm/slab.c b/mm/slab.c index f8cd00f4ba13..72135e555827 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -2064,6 +2064,8 @@ int __kmem_cache_create(struct kmem_cache *cachep, slab_flags_t flags) if (OFF_SLAB(cachep)) { cachep->freelist_cache = kmalloc_slab(cachep->freelist_size, 0u); + if (unlikely(ZERO_OR_NULL_PTR(cachep->freelist_cache))) + return cachep->freelist_cache; } err = setup_cpu_cache(cachep, gfp);
As the possible failure of the kmalloc_slab, it should be better to check it. Signed-off-by: Ren Yu <renyu@nfschina.com> Reported-by: kernel test robot <lkp@intel.com> --- v2: - fix build waring integer from pointer without a cast --- --- mm/slab.c | 2 ++ 1 file changed, 2 insertions(+)