[Devel] [PATCH 1/6] slab: cleanup kmem_cache_create_memcg()
Vladimir Davydov
vdavydov at parallels.com
Thu Dec 19 00:39:00 PST 2013
On 12/19/2013 12:17 PM, Vasily Averin wrote:
> On 12/18/2013 05:16 PM, Vladimir Davydov wrote:
>> --- a/mm/slab_common.c
>> +++ b/mm/slab_common.c
>> @@ -176,8 +176,9 @@ kmem_cache_create_memcg(struct mem_cgroup *memcg, const char *name, size_t size,
>> get_online_cpus();
>> mutex_lock(&slab_mutex);
>>
>> - if (!kmem_cache_sanity_check(memcg, name, size) == 0)
>> - goto out_locked;
>> + err = kmem_cache_sanity_check(memcg, name, size);
>> + if (err)
>> + goto out_unlock;
>>
>> /*
>> * Some allocators will constraint the set of valid flags to a subset
> Theoretically in future kmem_cache_sanity_check() can return positive value.
> Probably it's better to check (err < 0) in caller ?
Hmm, why? What information could positive retval carry here? We have
plenty of places throughout the code where we check for (err), not
(err<0), simply because it looks clearer, e.g. look at
__kmem_cache_create() calls. If it returns a positive value one day, we
will have to parse every place where it's called. Anyway, if someone
wants to change a function behavior, he must check every place where
this function is called and fix them accordingly.
Thanks.
More information about the Devel
mailing list