All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marian Marinov <mm-108MBtLGafw@public.gmane.org>
To: Dwight Engen
	<dwight.engen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
	Marian Marinov <mm-NV7Lj0SOnH0@public.gmane.org>
Cc: Richard Davies <richard-li8END47hbdWk0Htik3J/w@public.gmane.org>,
	Vladimir Davydov
	<vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>,
	Max Kellermann <mk-xMchvyqCc6DQT0dZR+AlfA@public.gmane.org>,
	Tim Hockin <thockin-Rl2oBbRerpQdnm+yROfE0A@public.gmane.org>,
	Frederic Weisbecker
	<fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Daniel Walsh <dwalsh-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>,
	Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	William Dauchy <wdauchy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
	Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Subject: Re: Protection against container fork bombs [WAS: Re: memcg with kmem limit doesn't recover after disk i/o causes limit to be hit]
Date: Thu, 08 May 2014 01:39:34 +0300	[thread overview]
Message-ID: <536AB626.9070005@1h.com> (raw)
In-Reply-To: <20140507131514.43716518-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>

On 05/07/2014 08:15 PM, Dwight Engen wrote:
> On Tue, 06 May 2014 14:40:55 +0300
> Marian Marinov <mm-NV7Lj0SOnH0@public.gmane.org> wrote:
>
>> On 04/23/2014 03:49 PM, Dwight Engen wrote:
>>> On Wed, 23 Apr 2014 09:07:28 +0300
>>> Marian Marinov <mm-NV7Lj0SOnH0@public.gmane.org> wrote:
>>>
>>>> On 04/22/2014 11:05 PM, Richard Davies wrote:
>>>>> Dwight Engen wrote:
>>>>>> Richard Davies wrote:
>>>>>>> Vladimir Davydov wrote:
>>>>>>>> In short, kmem limiting for memory cgroups is currently broken.
>>>>>>>> Do not use it. We are working on making it usable though.
>>>>> ...
>>>>>>> What is the best mechanism available today, until kmem limits
>>>>>>> mature?
>>>>>>>
>>>>>>> RLIMIT_NPROC exists but is per-user, not per-container.
>>>>>>>
>>>>>>> Perhaps there is an up-to-date task counter patchset or similar?
>>>>>>
>>>>>> I updated Frederic's task counter patches and included Max
>>>>>> Kellermann's fork limiter here:
>>>>>>
>>>>>> http://thread.gmane.org/gmane.linux.kernel.containers/27212
>>>>>>
>>>>>> I can send you a more recent patchset (against 3.13.10) if you
>>>>>> would find it useful.
>>>>>
>>>>> Yes please, I would be interested in that. Ideally even against
>>>>> 3.14.1 if you have that too.
>>>>
>>>> Dwight, do you have these patches in any public repo?
>>>>
>>>> I would like to test them also.
>>>
>>> Hi Marian, I put the patches against 3.13.11 and 3.14.1 up at:
>>>
>>> git://github.com/dwengen/linux.git cpuacct-task-limit-3.13
>>> git://github.com/dwengen/linux.git cpuacct-task-limit-3.14
>>>
>> Guys I tested the patches with 3.12.16. However I see a problem with
>> them.
>>
>> Trying to set the limit to a cgroup which already have processes in
>> it does not work:
>
> This is a similar check/limitation to the one for kmem in memcg, and is
> done here to keep the res_counters consistent and from going negative.
> It could probably be relaxed slightly by using res_counter_set_limit()
> instead, but you would still need to initially set a limit before
> adding tasks to the group.

I have removed the check entirely and still receive the EBUSY... I just don't understand what is returning it. If you 
have any pointers, I would be happy to take a look.

I'll look at set_limit(), thanks for pointing that one.

What I'm proposing is the following checks:

     if (val > RES_COUNTER_MAX || val < 0)
         return -EBUSY;
     if (val != 0 && val <= cgroup_task_count(cgrp))
         return -EBUSY;

     res_counter_write_u64(&ca->task_limit, type, val);

This way we ensure that val is within the limits > 0 and < RES_COUNTER_MAX. And also allow only values of 0 or greater 
then the current task count.

Marian
>
>> [root@sp2 lxc]# echo 50 > cpuacct.task_limit
>> -bash: echo: write error: Device or resource busy
>> [root@sp2 lxc]# echo 0 > cpuacct.task_limit
>> -bash: echo: write error: Device or resource busy
>> [root@sp2 lxc]#
>>
>> I have even tried to remove this check:
>> +               if (cgroup_task_count(cgrp)
>> || !list_empty(&cgrp->children))
>> +                       return -EBUSY;
>> But still give me 'Device or resource busy'.
>>
>> Any pointers of why is this happening ?
>>
>> Marian
>>
>>>> Marian
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Richard.
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe cgroups"
>>>>> in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe cgroups"
>>> in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>
>
> _______________________________________________
> Containers mailing list
> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
>


-- 
Marian Marinov
Founder & CEO of 1H Ltd.
Jabber/GTalk: hackman-/eSpBmjxGS4dnm+yROfE0A@public.gmane.org
ICQ: 7556201
Mobile: +359 886 660 270

WARNING: multiple messages have this Message-ID (diff)
From: Marian Marinov <mm@1h.com>
To: Dwight Engen <dwight.engen@oracle.com>, Marian Marinov <mm@yuhu.biz>
Cc: Richard Davies <richard@arachsys.com>,
	Vladimir Davydov <vdavydov@parallels.com>,
	Daniel Walsh <dwalsh@redhat.com>, Max Kellermann <mk@cm4all.com>,
	Tim Hockin <thockin@hockin.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	containers@lists.linux-foundation.org,
	Johannes Weiner <hannes@cmpxchg.org>,
	Glauber Costa <glommer@parallels.com>,
	Michal Hocko <mhocko@suse.cz>,
	linux-mm@kvack.org, William Dauchy <wdauchy@gmail.com>,
	David Rientjes <rientjes@google.com>, Tejun Heo <tj@kernel.org>,
	cgroups@vger.kernel.org
Subject: Re: Protection against container fork bombs [WAS: Re: memcg with kmem limit doesn't recover after disk i/o causes limit to be hit]
Date: Thu, 08 May 2014 01:39:34 +0300	[thread overview]
Message-ID: <536AB626.9070005@1h.com> (raw)
In-Reply-To: <20140507131514.43716518@oracle.com>

On 05/07/2014 08:15 PM, Dwight Engen wrote:
> On Tue, 06 May 2014 14:40:55 +0300
> Marian Marinov <mm@yuhu.biz> wrote:
>
>> On 04/23/2014 03:49 PM, Dwight Engen wrote:
>>> On Wed, 23 Apr 2014 09:07:28 +0300
>>> Marian Marinov <mm@yuhu.biz> wrote:
>>>
>>>> On 04/22/2014 11:05 PM, Richard Davies wrote:
>>>>> Dwight Engen wrote:
>>>>>> Richard Davies wrote:
>>>>>>> Vladimir Davydov wrote:
>>>>>>>> In short, kmem limiting for memory cgroups is currently broken.
>>>>>>>> Do not use it. We are working on making it usable though.
>>>>> ...
>>>>>>> What is the best mechanism available today, until kmem limits
>>>>>>> mature?
>>>>>>>
>>>>>>> RLIMIT_NPROC exists but is per-user, not per-container.
>>>>>>>
>>>>>>> Perhaps there is an up-to-date task counter patchset or similar?
>>>>>>
>>>>>> I updated Frederic's task counter patches and included Max
>>>>>> Kellermann's fork limiter here:
>>>>>>
>>>>>> http://thread.gmane.org/gmane.linux.kernel.containers/27212
>>>>>>
>>>>>> I can send you a more recent patchset (against 3.13.10) if you
>>>>>> would find it useful.
>>>>>
>>>>> Yes please, I would be interested in that. Ideally even against
>>>>> 3.14.1 if you have that too.
>>>>
>>>> Dwight, do you have these patches in any public repo?
>>>>
>>>> I would like to test them also.
>>>
>>> Hi Marian, I put the patches against 3.13.11 and 3.14.1 up at:
>>>
>>> git://github.com/dwengen/linux.git cpuacct-task-limit-3.13
>>> git://github.com/dwengen/linux.git cpuacct-task-limit-3.14
>>>
>> Guys I tested the patches with 3.12.16. However I see a problem with
>> them.
>>
>> Trying to set the limit to a cgroup which already have processes in
>> it does not work:
>
> This is a similar check/limitation to the one for kmem in memcg, and is
> done here to keep the res_counters consistent and from going negative.
> It could probably be relaxed slightly by using res_counter_set_limit()
> instead, but you would still need to initially set a limit before
> adding tasks to the group.

I have removed the check entirely and still receive the EBUSY... I just don't understand what is returning it. If you 
have any pointers, I would be happy to take a look.

I'll look at set_limit(), thanks for pointing that one.

What I'm proposing is the following checks:

     if (val > RES_COUNTER_MAX || val < 0)
         return -EBUSY;
     if (val != 0 && val <= cgroup_task_count(cgrp))
         return -EBUSY;

     res_counter_write_u64(&ca->task_limit, type, val);

This way we ensure that val is within the limits > 0 and < RES_COUNTER_MAX. And also allow only values of 0 or greater 
then the current task count.

Marian
>
>> [root@sp2 lxc]# echo 50 > cpuacct.task_limit
>> -bash: echo: write error: Device or resource busy
>> [root@sp2 lxc]# echo 0 > cpuacct.task_limit
>> -bash: echo: write error: Device or resource busy
>> [root@sp2 lxc]#
>>
>> I have even tried to remove this check:
>> +               if (cgroup_task_count(cgrp)
>> || !list_empty(&cgrp->children))
>> +                       return -EBUSY;
>> But still give me 'Device or resource busy'.
>>
>> Any pointers of why is this happening ?
>>
>> Marian
>>
>>>> Marian
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Richard.
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe cgroups"
>>>>> in the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe cgroups"
>>> in the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>
>
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
>


-- 
Marian Marinov
Founder & CEO of 1H Ltd.
Jabber/GTalk: hackman@jabber.org
ICQ: 7556201
Mobile: +359 886 660 270

--
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>

  parent reply	other threads:[~2014-05-07 22:39 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-16 15:46 memcg with kmem limit doesn't recover after disk i/o causes limit to be hit Richard Davies
2014-04-18 15:59 ` Michal Hocko
     [not found]   ` <20140418155939.GE4523-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2014-04-18 17:57     ` Vladimir Davydov
2014-04-18 17:57       ` Vladimir Davydov
     [not found]       ` <5351679F.5040908-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2014-04-18 18:20         ` Michal Hocko
2014-04-18 18:20           ` Michal Hocko
2014-04-18 18:37           ` Vladimir Davydov
2014-04-20 14:28         ` Protection against container fork bombs [WAS: Re: memcg with kmem limit doesn't recover after disk i/o causes limit to be hit] Richard Davies
2014-04-20 14:28       ` Richard Davies
     [not found]         ` <20140420142830.GC22077-2oeHp4OYwSjPZs67QiJbJtBPR1lH4CV8@public.gmane.org>
2014-04-20 18:35           ` Tim Hockin
2014-04-22 18:39           ` Dwight Engen
2014-04-20 18:35         ` Tim Hockin
2014-04-22 18:39         ` Dwight Engen
2014-04-22 20:05           ` Richard Davies
2014-04-22 20:13             ` Tim Hockin
     [not found]             ` <20140422200531.GA19334-2oeHp4OYwSjPZs67QiJbJtBPR1lH4CV8@public.gmane.org>
2014-04-22 20:13               ` Tim Hockin
2014-04-23  6:07               ` Marian Marinov
2014-04-23  6:07               ` Marian Marinov
2014-04-23  6:07                 ` Marian Marinov
2014-04-23 12:49                 ` Dwight Engen
2014-05-06 11:40                   ` Marian Marinov
2014-05-07 17:15                     ` Dwight Engen
     [not found]                       ` <20140507131514.43716518-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-05-07 22:39                         ` Marian Marinov [this message]
2014-05-07 22:39                           ` Marian Marinov
     [not found]                           ` <536AB626.9070005-108MBtLGafw@public.gmane.org>
2014-05-08 15:25                             ` Richard Davies
2014-05-08 15:25                               ` Richard Davies
     [not found]                     ` <5368CA47.7030007-NV7Lj0SOnH0@public.gmane.org>
2014-05-07 17:15                       ` Dwight Engen
     [not found]                   ` <20140423084942.560ae837-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-04-28 18:00                     ` Serge Hallyn
2014-04-28 18:00                       ` Serge Hallyn
2014-04-29  7:25                       ` Michal Hocko
2014-04-29  7:25                         ` Michal Hocko
     [not found]                         ` <20140429072515.GB15058-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2014-04-29 13:03                           ` Serge Hallyn
2014-04-29 13:03                           ` Serge Hallyn
2014-04-29 13:03                             ` Serge Hallyn
2014-04-29 13:57                             ` Marian Marinov
2014-04-29 13:57                               ` Marian Marinov
2014-04-29 13:57                             ` Marian Marinov
2014-04-29 14:04                             ` Tim Hockin
2014-04-29 14:04                             ` Tim Hockin
2014-04-29 15:43                             ` Michal Hocko
2014-04-29 15:43                             ` Michal Hocko
2014-04-29 15:43                               ` Michal Hocko
2014-04-29 16:06                               ` Tim Hockin
     [not found]                                 ` <CAO_RewYZDGLBAKit4CudTbqVk+zfDRX8kP0W6Zz90xJh7abM9Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-04-29 16:51                                   ` Frederic Weisbecker
2014-04-29 16:51                                 ` Frederic Weisbecker
     [not found]                                   ` <20140429165114.GE6129-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2014-04-29 16:59                                     ` Tim Hockin
2014-04-29 16:59                                     ` Tim Hockin
2014-04-29 16:59                                       ` Tim Hockin
     [not found]                                       ` <CAO_Rewa20dneL8e3T4UPnu2Dkv28KTgFJR9_YSmRBKp-_yqewg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-04-29 17:06                                         ` Michal Hocko
2014-04-29 17:06                                         ` Michal Hocko
2014-04-29 17:06                                           ` Michal Hocko
     [not found]                                           ` <20140429170639.GA25609-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2014-04-29 17:30                                             ` Dwight Engen
2014-04-29 17:30                                           ` Dwight Engen
     [not found]                                             ` <20140429133039.162d9dd7-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-04-29 18:09                                               ` Richard Davies
2014-04-29 18:09                                             ` Richard Davies
     [not found]                                               ` <20140429180927.GB29606-2oeHp4OYwSjPZs67QiJbJtBPR1lH4CV8@public.gmane.org>
2014-04-29 18:27                                                 ` Michal Hocko
2014-04-29 18:27                                                   ` Michal Hocko
     [not found]                                                   ` <20140429182742.GB25609-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2014-04-29 18:39                                                     ` Richard Davies
2014-04-29 18:39                                                       ` Richard Davies
     [not found]                                                       ` <20140429183928.GF29606-2oeHp4OYwSjPZs67QiJbJtBPR1lH4CV8@public.gmane.org>
2014-04-29 19:03                                                         ` Michal Hocko
2014-04-29 19:03                                                       ` Michal Hocko
2014-04-29 21:36                                                     ` Marian Marinov
2014-04-29 21:36                                                       ` Marian Marinov
     [not found]                                                       ` <53601B68.60906-NV7Lj0SOnH0@public.gmane.org>
2014-04-30 13:31                                                         ` Michal Hocko
2014-04-30 13:31                                                         ` Michal Hocko
2014-04-30 13:31                                                           ` Michal Hocko
2014-04-29 18:27                                                 ` Michal Hocko
2014-04-29 21:44                                         ` Frederic Weisbecker
2014-04-29 21:44                                         ` Frederic Weisbecker
2014-04-29 21:44                                           ` Frederic Weisbecker
2014-04-30 13:12                                           ` Daniel J Walsh
     [not found]                                             ` <5360F6B4.9010308-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-04-30 13:28                                               ` Frederic Weisbecker
2014-04-30 13:28                                                 ` Frederic Weisbecker
2014-04-30 13:28                                               ` Frederic Weisbecker
     [not found]                                           ` <20140429214454.GF6129-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2014-04-30 13:12                                             ` Daniel J Walsh
     [not found]                               ` <20140429154345.GH15058-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2014-04-29 16:06                                 ` Tim Hockin
2014-05-06 11:40                     ` Marian Marinov
2014-06-10 14:50                     ` Marian Marinov
2014-06-10 14:50                       ` Marian Marinov
2014-06-10 14:50                     ` Marian Marinov
     [not found]                 ` <535758A0.5000500-NV7Lj0SOnH0@public.gmane.org>
2014-04-23 12:49                   ` Dwight Engen
2014-06-10 12:18               ` Alin Dobre
2014-06-10 12:18                 ` Alin Dobre
     [not found]           ` <20140422143943.20609800-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-04-22 20:05             ` Richard Davies

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=536AB626.9070005@1h.com \
    --to=mm-108mbtlgafw@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=dwalsh-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=dwight.engen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
    --cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=mhocko-AlSwsSmVLrQ@public.gmane.org \
    --cc=mk-xMchvyqCc6DQT0dZR+AlfA@public.gmane.org \
    --cc=mm-NV7Lj0SOnH0@public.gmane.org \
    --cc=richard-li8END47hbdWk0Htik3J/w@public.gmane.org \
    --cc=rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=thockin-Rl2oBbRerpQdnm+yROfE0A@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
    --cc=wdauchy-Re5JQEeQqe8AvxtiuMwx3w@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.