From: Vasily Averin <vvs-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: Vladimir Davydov <vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Cc: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>,
Glauber Costa <glommer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pekka Enberg <penberg-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
Subject: Re: [Devel] [PATCH 1/6] slab: cleanup kmem_cache_create_memcg()
Date: Thu, 19 Dec 2013 13:26:12 +0400 [thread overview]
Message-ID: <52B2BBB4.3090209@parallels.com> (raw)
In-Reply-To: <52B2B0A4.8050009-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
On 12/19/2013 12:39 PM, Vladimir Davydov wrote:
> 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.
I believe expected semantic of function -- return negative in case of error.
So correct error cheek should be (err < 0).
(err) check is semantically incorrect, and it can lead to troubles in future.
WARNING: multiple messages have this Message-ID (diff)
From: Vasily Averin <vvs@parallels.com>
To: Vladimir Davydov <vdavydov@parallels.com>
Cc: Michal Hocko <mhocko@suse.cz>, Glauber Costa <glommer@gmail.com>,
linux-kernel@vger.kernel.org, Pekka Enberg <penberg@kernel.org>,
linux-mm@kvack.org, Johannes Weiner <hannes@cmpxchg.org>,
cgroups@vger.kernel.org, Christoph Lameter <cl@linux.com>,
Andrew Morton <akpm@linux-foundation.org>,
devel@openvz.org
Subject: Re: [Devel] [PATCH 1/6] slab: cleanup kmem_cache_create_memcg()
Date: Thu, 19 Dec 2013 13:26:12 +0400 [thread overview]
Message-ID: <52B2BBB4.3090209@parallels.com> (raw)
In-Reply-To: <52B2B0A4.8050009@parallels.com>
On 12/19/2013 12:39 PM, Vladimir Davydov wrote:
> 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.
I believe expected semantic of function -- return negative in case of error.
So correct error cheek should be (err < 0).
(err) check is semantically incorrect, and it can lead to troubles in future.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Vasily Averin <vvs@parallels.com>
To: Vladimir Davydov <vdavydov@parallels.com>
Cc: Michal Hocko <mhocko@suse.cz>, Glauber Costa <glommer@gmail.com>,
linux-kernel@vger.kernel.org, Pekka Enberg <penberg@kernel.org>,
linux-mm@kvack.org, Johannes Weiner <hannes@cmpxchg.org>,
cgroups@vger.kernel.org, Christoph Lameter <cl@linux.com>,
Andrew Morton <akpm@linux-foundation.org>,
devel@openvz.org
Subject: Re: [Devel] [PATCH 1/6] slab: cleanup kmem_cache_create_memcg()
Date: Thu, 19 Dec 2013 13:26:12 +0400 [thread overview]
Message-ID: <52B2BBB4.3090209@parallels.com> (raw)
In-Reply-To: <52B2B0A4.8050009@parallels.com>
On 12/19/2013 12:39 PM, Vladimir Davydov wrote:
> 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.
I believe expected semantic of function -- return negative in case of error.
So correct error cheek should be (err < 0).
(err) check is semantically incorrect, and it can lead to troubles in future.
next prev parent reply other threads:[~2013-12-19 9:26 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-18 13:16 [PATCH 1/6] slab: cleanup kmem_cache_create_memcg() Vladimir Davydov
2013-12-18 13:16 ` Vladimir Davydov
2013-12-18 13:16 ` Vladimir Davydov
2013-12-18 13:16 ` [PATCH 2/6] memcg, slab: kmem_cache_create_memcg(): free memcg params on error Vladimir Davydov
2013-12-18 13:16 ` Vladimir Davydov
[not found] ` <9420ad797a2cfa14c23ad1ba6db615a2a51ffee0.1387372122.git.vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-12-18 17:06 ` Michal Hocko
2013-12-18 17:06 ` Michal Hocko
2013-12-18 17:06 ` Michal Hocko
[not found] ` <20131218170649.GC31080-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-12-19 6:32 ` Vladimir Davydov
2013-12-19 6:32 ` Vladimir Davydov
2013-12-19 6:32 ` Vladimir Davydov
2013-12-19 8:48 ` Michal Hocko
2013-12-19 8:48 ` Michal Hocko
2013-12-19 9:01 ` Vladimir Davydov
2013-12-19 9:01 ` Vladimir Davydov
2013-12-19 9:19 ` Michal Hocko
2013-12-19 9:19 ` Michal Hocko
2013-12-18 13:16 ` [PATCH 3/6] memcg, slab: cleanup barrier usage when accessing memcg_caches Vladimir Davydov
2013-12-18 13:16 ` Vladimir Davydov
2013-12-18 17:14 ` Michal Hocko
2013-12-18 17:14 ` Michal Hocko
2013-12-19 6:37 ` Vladimir Davydov
2013-12-19 6:37 ` Vladimir Davydov
2013-12-19 9:10 ` Michal Hocko
2013-12-19 9:10 ` Michal Hocko
2013-12-19 9:16 ` Vladimir Davydov
2013-12-19 9:16 ` Vladimir Davydov
2013-12-19 9:21 ` Michal Hocko
2013-12-19 9:21 ` Michal Hocko
[not found] ` <20131219092137.GG9331-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-12-19 9:29 ` Vladimir Davydov
2013-12-19 9:29 ` Vladimir Davydov
2013-12-19 9:29 ` Vladimir Davydov
2013-12-19 9:36 ` Michal Hocko
2013-12-19 9:36 ` Michal Hocko
[not found] ` <20131219093619.GA10855-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-12-19 9:53 ` Vladimir Davydov
2013-12-19 9:53 ` Vladimir Davydov
2013-12-19 9:53 ` Vladimir Davydov
2013-12-18 13:16 ` [PATCH 4/6] memcg, slab: check and init memcg_cahes under slab_mutex Vladimir Davydov
2013-12-18 13:16 ` Vladimir Davydov
2013-12-18 17:41 ` Michal Hocko
2013-12-18 17:41 ` Michal Hocko
[not found] ` <20131218174105.GE31080-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-12-19 7:07 ` Vladimir Davydov
2013-12-19 7:07 ` Vladimir Davydov
2013-12-19 7:07 ` Vladimir Davydov
[not found] ` <52B29B2F.7050909-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-12-19 8:00 ` Glauber Costa
2013-12-19 8:00 ` Glauber Costa
2013-12-19 8:00 ` Glauber Costa
2013-12-19 9:12 ` Michal Hocko
2013-12-19 9:12 ` Michal Hocko
2013-12-19 9:17 ` Vladimir Davydov
2013-12-19 9:17 ` Vladimir Davydov
2013-12-19 9:21 ` Vladimir Davydov
2013-12-19 9:21 ` Vladimir Davydov
2013-12-18 13:16 ` [PATCH 5/6] memcg: clear memcg_params after removing cache from memcg_slab_caches list Vladimir Davydov
2013-12-18 13:16 ` Vladimir Davydov
2013-12-18 13:16 ` [PATCH 6/6] memcg, slab: RCU protect memcg_params for root caches Vladimir Davydov
2013-12-18 13:16 ` Vladimir Davydov
2013-12-19 9:28 ` Michal Hocko
2013-12-19 9:28 ` Michal Hocko
2013-12-19 9:36 ` Vladimir Davydov
2013-12-19 9:36 ` Vladimir Davydov
[not found] ` <52B2BE2A.2080509-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-12-19 9:43 ` Michal Hocko
2013-12-19 9:43 ` Michal Hocko
2013-12-19 9:43 ` Michal Hocko
[not found] ` <20131219094333.GB10855-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-12-19 9:47 ` Vladimir Davydov
2013-12-19 9:47 ` Vladimir Davydov
2013-12-19 9:47 ` Vladimir Davydov
2013-12-19 10:06 ` Michal Hocko
2013-12-19 10:06 ` Michal Hocko
2013-12-18 16:56 ` [PATCH 1/6] slab: cleanup kmem_cache_create_memcg() Michal Hocko
2013-12-18 16:56 ` Michal Hocko
[not found] ` <20131218165603.GB31080-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-12-19 6:31 ` Vladimir Davydov
2013-12-19 6:31 ` Vladimir Davydov
2013-12-19 6:31 ` Vladimir Davydov
2013-12-19 8:44 ` Michal Hocko
2013-12-19 8:44 ` Michal Hocko
[not found] ` <20131219084447.GA9331-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-12-19 8:51 ` Vladimir Davydov
2013-12-19 8:51 ` Vladimir Davydov
2013-12-19 8:51 ` Vladimir Davydov
2013-12-19 9:16 ` Michal Hocko
2013-12-19 9:16 ` Michal Hocko
[not found] ` <6f02b2d079ffd0990ae335339c803337b13ecd8c.1387372122.git.vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-12-19 7:27 ` Pekka Enberg
2013-12-19 7:27 ` Pekka Enberg
2013-12-19 7:27 ` Pekka Enberg
2013-12-19 8:17 ` [Devel] " Vasily Averin
2013-12-19 8:17 ` Vasily Averin
[not found] ` <52B2AB7C.1010803-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-12-19 8:39 ` Vladimir Davydov
2013-12-19 8:39 ` Vladimir Davydov
2013-12-19 8:39 ` Vladimir Davydov
[not found] ` <52B2B0A4.8050009-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-12-19 9:26 ` Vasily Averin [this message]
2013-12-19 9:26 ` Vasily Averin
2013-12-19 9:26 ` Vasily Averin
2013-12-19 9:42 ` Vladimir Davydov
2013-12-19 9:42 ` Vladimir Davydov
2013-12-19 9:45 ` Michal Hocko
2013-12-19 9:45 ` Michal Hocko
2013-12-19 10:23 ` Pekka Enberg
2013-12-19 10:23 ` Pekka Enberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52B2BBB4.3090209@parallels.com \
--to=vvs-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org \
--cc=devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=glommer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=mhocko-AlSwsSmVLrQ@public.gmane.org \
--cc=penberg-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.