On Thu 19-12-13 13:47:33, Vladimir Davydov wrote:
[...]
> Yeah, you're right, this longs for a documentation. I'm going to check
We desparately need a documentation for the life cycle of all involved
objects and description of which locks are used at which stage.
> this code a bit more and try t
On 12/19/2013 01:43 PM, Michal Hocko wrote:
> On Thu 19-12-13 13:36:42, Vladimir Davydov wrote:
>> On 12/19/2013 01:28 PM, Michal Hocko wrote:
>>> On Wed 18-12-13 17:16:57, Vladimir Davydov wrote:
> [...]
diff --git a/mm/slab.h b/mm/slab.h
index 1d8b53f..53b81a9 100644
--- a/mm/slab.
On Thu 19-12-13 13:36:42, Vladimir Davydov wrote:
> On 12/19/2013 01:28 PM, Michal Hocko wrote:
> > On Wed 18-12-13 17:16:57, Vladimir Davydov wrote:
[...]
> >> diff --git a/mm/slab.h b/mm/slab.h
> >> index 1d8b53f..53b81a9 100644
> >> --- a/mm/slab.h
> >> +++ b/mm/slab.h
> >> @@ -164,10 +164,16 @@
On 12/19/2013 01:28 PM, Michal Hocko wrote:
> On Wed 18-12-13 17:16:57, Vladimir Davydov wrote:
>> We update root cache's memcg_params whenever we need to grow the
>> memcg_caches array to accommodate all kmem-active memory cgroups.
>> Currently we free the old version immediately then, which can l
On Wed 18-12-13 17:16:57, Vladimir Davydov wrote:
> We update root cache's memcg_params whenever we need to grow the
> memcg_caches array to accommodate all kmem-active memory cgroups.
> Currently we free the old version immediately then, which can lead to
> use-after-free, because the memcg_caches
We update root cache's memcg_params whenever we need to grow the
memcg_caches array to accommodate all kmem-active memory cgroups.
Currently we free the old version immediately then, which can lead to
use-after-free, because the memcg_caches array is accessed lock-free.
This patch fixes this by mak
