On Mon, Nov 5, 2018 at 11:18 AM, Vlastimil Babka <vbabka@xxxxxxx> wrote:
> +CC Dmitry
>
> On 11/4/18 1:50 PM, Yangtao Li wrote:
>> WARN_ON() already contains an unlikely(), so it's not necessary to use
>> unlikely.
>>
>> Signed-off-by: Yangtao Li <tiny.windzz@xxxxxxxxx>
>
> Acked-by: Vlastimil Babka <vbabka@xxxxxxx>
>
> Maybe also change it back to WARN_ON_ONCE? I already considered it while
> reviewing Dmitry's patch and wasn't sure. Now I think that what can
> happen is that either a kernel bug is introduced that _ONCE is enough to
> catch (two separate bugs introduced to both hit this would be rare, and
> in that case the second one will be reported after the first one is
> fixed), or this gets called with a user-supplied value, and then we want
> to avoid spamming dmesg with multiple warnings that the user could
> trigger at will.
If you asking me, I am fine both changes.
I was mainly interested in removing the bogus warnings that actually fire.
>> ---
>> mm/slab_common.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/mm/slab_common.c b/mm/slab_common.c
>> index 7eb8dc136c1c..4f54684f5435 100644
>> --- a/mm/slab_common.c
>> +++ b/mm/slab_common.c
>> @@ -1029,10 +1029,8 @@ struct kmem_cache *kmalloc_slab(size_t size, gfp_t flags)
>>
>> index = size_index[size_index_elem(size)];
>> } else {
>> - if (unlikely(size > KMALLOC_MAX_CACHE_SIZE)) {
>> - WARN_ON(1);
>> + if (WARN_ON(size > KMALLOC_MAX_CACHE_SIZE))
>> return NULL;
>> - }
>> index = fls(size - 1);
>> }
>>
>>
>
