On Thu, Aug 25, 2016 at 11:56:27AM -0700, Mahesh Bandewar (महेश बंडेवार) wrote:
> On Thu, Aug 25, 2016 at 11:04 AM, Alexei Starovoitov
> wrote:
> > On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार)
> > wrote:
> >> On Wed, Aug 24, 2016 at 2:03 PM, Tejun Heo wrote:
> >> > He
On Thu, Aug 25, 2016 at 11:04 AM, Alexei Starovoitov
wrote:
> On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार)
> wrote:
>> On Wed, Aug 24, 2016 at 2:03 PM, Tejun Heo wrote:
>> > Hello, Anoop.
>> >
>> > On Wed, Aug 10, 2016 at 05:53:13PM -0700, Anoop Naravaram wrote:
>> >>
On Thu, Aug 25, 2016 at 9:09 AM, Tejun Heo wrote:
> Hello, Mahesh.
>
> On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार)
> wrote:
>> In short most of the associated problems are handled by the
>> cgroup-infra / APIs while all that need separate solution in
>> alternatives.
On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) wrote:
> On Wed, Aug 24, 2016 at 2:03 PM, Tejun Heo wrote:
> > Hello, Anoop.
> >
> > On Wed, Aug 10, 2016 at 05:53:13PM -0700, Anoop Naravaram wrote:
> >> This patchset introduces a cgroup controller for the networking subsys
On Thu, Aug 25, 2016 at 12:09:20PM -0400, Tejun Heo wrote:
> ebpf approach does have its shortcomings for sure but mending them
> seems a lot more manageable and future-proof than going with fixed but
> constantly expanding set of operations. e.g. We can add per-cgroup
> bpf programs which are cal
Hello, Mahesh.
On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) wrote:
> In short most of the associated problems are handled by the
> cgroup-infra / APIs while all that need separate solution in
> alternatives. Tejun, feels like I'm advocating cgroup approach to you
> ;)
On Wed, Aug 24, 2016 at 2:03 PM, Tejun Heo wrote:
> Hello, Anoop.
>
> On Wed, Aug 10, 2016 at 05:53:13PM -0700, Anoop Naravaram wrote:
>> This patchset introduces a cgroup controller for the networking subsystem as
>> a
>> whole. As of now, this controller will be used for:
>>
>> * Limiting the s
On Tue, Aug 23, 2016 at 1:49 AM, Parav Pandit wrote:
> Hi Anoop,
>
> Regardless of usecase, I think this functionality is best handled as
> LSM functionality instead of cgroup.
>
I'm not so sure about that. Cgroup APIs are useful and this is just an
extension to it.
> Tasks which are proposed in
Hello, Anoop.
On Wed, Aug 10, 2016 at 05:53:13PM -0700, Anoop Naravaram wrote:
> This patchset introduces a cgroup controller for the networking subsystem as a
> whole. As of now, this controller will be used for:
>
> * Limiting the specific ports that a process in a cgroup is allowed to bind
>
Hi Anoop,
Regardless of usecase, I think this functionality is best handled as
LSM functionality instead of cgroup.
Tasks which are proposed in this patch are related to access control checks.
LSM already has required hooks for socket operations such as bind(),
listen() as few small examples.
Re
Hi Anoop,
On Thu, Aug 11, 2016 at 6:23 AM, Anoop Naravaram wrote:
> This patchset introduces a cgroup controller for the networking subsystem as a
> whole. As of now, this controller will be used for:
>
> * Limiting the specific ports that a process in a cgroup is allowed to bind
> to or liste
This patchset introduces a cgroup controller for the networking subsystem as a
whole. As of now, this controller will be used for:
* Limiting the specific ports that a process in a cgroup is allowed to bind
to or listen on. For example, you can say that all the processes in a
cgroup can only b
12 matches
Mail list logo
