Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1231788 > unrolled thread
| Started by | Aleksa Sarai <cyphar@cyphar.com> |
|---|---|
| First post | 2015-09-24 01:50 +0200 |
| Last post | 2015-09-29 08:20 +0200 |
| Articles | 5 — 3 participants |
Back to article view | Back to linux.kernel
PIDs Controller Limit Aleksa Sarai <cyphar@cyphar.com> - 2015-09-24 01:50 +0200
Re: PIDs Controller Limit Tejun Heo <tj@kernel.org> - 2015-09-25 17:40 +0200
Re: PIDs Controller Limit Aleksa Sarai <cyphar@cyphar.com> - 2015-09-26 01:20 +0200
Re: PIDs Controller Limit Tejun Heo <tj@kernel.org> - 2015-09-28 18:00 +0200
Re: PIDs Controller Limit Nikolay Borisov <kernel@kyup.com> - 2015-09-29 08:20 +0200
| From | Aleksa Sarai <cyphar@cyphar.com> |
|---|---|
| Date | 2015-09-24 01:50 +0200 |
| Subject | PIDs Controller Limit |
| Message-ID | <qc1Xs-2Cd-9@gated-at.bofh.it> |
Does it make sense for the PIDs controller to allow a user to set a limit of 0? Since we don't cancel attaches, a limit of 0 doesn't affect anything (nothing stops attaches, and you need to have a process in the PIDs cgroup in order for fork()s to be affected by the limit). So I think that attempting to set pid.limit to 0 should return an -EINVAL. -- Aleksa Sarai (cyphar) www.cyphar.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2015-09-25 17:40 +0200 |
| Message-ID | <qcDgl-5xb-9@gated-at.bofh.it> |
| In reply to | #1231788 |
Hello, Aleksa. On Thu, Sep 24, 2015 at 09:42:38AM +1000, Aleksa Sarai wrote: > Does it make sense for the PIDs controller to allow a user to set a > limit of 0? Since we don't cancel attaches, a limit of 0 doesn't > affect anything (nothing stops attaches, and you need to have a > process in the PIDs cgroup in order for fork()s to be affected by the > limit). So I think that attempting to set pid.limit to 0 should return > an -EINVAL. I don't know. Why does it matter? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Aleksa Sarai <cyphar@cyphar.com> |
|---|---|
| Date | 2015-09-26 01:20 +0200 |
| Message-ID | <qcKrv-7uN-5@gated-at.bofh.it> |
| In reply to | #1232893 |
> On Thu, Sep 24, 2015 at 09:42:38AM +1000, Aleksa Sarai wrote: >> Does it make sense for the PIDs controller to allow a user to set a >> limit of 0? Since we don't cancel attaches, a limit of 0 doesn't >> affect anything (nothing stops attaches, and you need to have a >> process in the PIDs cgroup in order for fork()s to be affected by the >> limit). So I think that attempting to set pid.limit to 0 should return >> an -EINVAL. > > I don't know. Why does it matter? Well, it might be confusing that a limit of `0` is not different from a limit of `1`. Especially since someone might think that a limit of `0` means "no processes AT ALL", which is wrong. Although, I guess they should've just RTFM'd in that case. -- Aleksa Sarai (cyphar) www.cyphar.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2015-09-28 18:00 +0200 |
| Message-ID | <qdJ0l-3Un-3@gated-at.bofh.it> |
| In reply to | #1233106 |
Hello, On Sat, Sep 26, 2015 at 09:11:02AM +1000, Aleksa Sarai wrote: > Well, it might be confusing that a limit of `0` is not different from > a limit of `1`. Especially since someone might think that a limit of > `0` means "no processes AT ALL", which is wrong. Although, I guess > they should've just RTFM'd in that case. I really don't think it matters. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Nikolay Borisov <kernel@kyup.com> |
|---|---|
| Date | 2015-09-29 08:20 +0200 |
| Message-ID | <qdWqC-6Bt-7@gated-at.bofh.it> |
| In reply to | #1233106 |
On 09/26/2015 02:11 AM, Aleksa Sarai wrote: >> On Thu, Sep 24, 2015 at 09:42:38AM +1000, Aleksa Sarai wrote: >>> Does it make sense for the PIDs controller to allow a user to set a >>> limit of 0? Since we don't cancel attaches, a limit of 0 doesn't >>> affect anything (nothing stops attaches, and you need to have a >>> process in the PIDs cgroup in order for fork()s to be affected by the >>> limit). So I think that attempting to set pid.limit to 0 should return >>> an -EINVAL. >> >> I don't know. Why does it matter? > > Well, it might be confusing that a limit of `0` is not different from > a limit of `1`. Especially since someone might think that a limit of > `0` means "no processes AT ALL", which is wrong. Although, I guess > they should've just RTFM'd in that case. I personally would have parsed a value of 0 as "unlimited" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web