All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Zefan <lizefan@huawei.com>
To: Daniel Wagner <wagi@monom.org>
Cc: John Fastabend <john.r.fastabend@intel.com>,
	Neil Horman <nhorman@tuxdriver.com>,
	Daniel Wagner <daniel.wagner@bmw-carit.de>,
	LKML <linux-kernel@vger.kernel.org>,
	netdev@vger.kernel.org, Cgroups <cgroups@vger.kernel.org>
Subject: Re: [BUG] Bug in netprio_cgroup and netcls_cgroup ?
Date: Mon, 21 Jan 2013 17:57:39 +0800	[thread overview]
Message-ID: <50FD1113.6010402@huawei.com> (raw)
In-Reply-To: <50FD09FD.4010804@monom.org>

On 2013/1/21 17:27, Daniel Wagner wrote:
> On 21.01.2013 10:01, Li Zefan wrote:
>> On 2013/1/21 16:50, Daniel Wagner wrote:
>>> Hi Li,
>>>
>>> On 21.01.2013 07:08, Li Zefan wrote:
>>>> I'm not a network developer, so correct me if I'm wrong.
>>>>
>>>> Since commit 7955490f732c2b8
>>>> ("net: netprio_cgroup: rework update socket logic"), sock->sk->sk_cgrp_prioidx
>>>> is set when the socket is created, and won't be updated unless the task is
>>>> moved to another cgroup.
>>>>
>>>> Now the problem is, a socket can be _shared_ by multiple processes (fork, SCM_RIGHT).
>>>> If we place those processes in different cgroups, and each cgroup has
>>>> different configs, but all of the processes will send data via this socket
>>>> with the same network priority.
>>>
>>> Wouldn't that be addressed by 48a87cc26c13b68f6cce4e9d769fcb17a6b3e4b8
>>>
>>>     net: netprio: fd passed in SCM_RIGHTS datagram not set correctly
>>>
>>>      A socket fd passed in a SCM_RIGHTS datagram was not getting
>>>      updated with the new tasks cgrp prioidx. This leaves IO on
>>>      the socket tagged with the old tasks priority.
>>>
>>>      To fix this add a check in the scm recvmsg path to update the
>>>      sock cgrp prioidx with the new tasks value.
>>>
>>> As I read this this should work for net_prio.
>>>
>>
>> But after process A passed the socket fd to B, both A and B can use the
>> same socket to send data, right? Then if A and B were placed in different
>> cgroups with differnt configs, A's config won't take effect anymore.
>>
>> Am I missing something?
> 
> I don't know. I guess at one point the socket resources are shared and then
> one configuration is taking preference. As you can see I am far away of
> being
> an expert in this field. Hopefully someone who understands this bits
> can chip in.
> 
> BTW, isn't this a similar to what should happen with the block io cgroup?
> What is the behavior with a fd writing to a file in the scenario you
> describe above?
> 

It forbids task moving in this case:

/*
 * We cannot support shared io contexts, as we have no mean to support
 * two tasks with the same ioc in two different groups without major rework
 * of the main cic data structures.  For now we allow a task to change
 * its cgroup only if it's the only owner of its ioc.
 */
static int blkcg_can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)

WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan@huawei.com>
To: Daniel Wagner <wagi@monom.org>
Cc: John Fastabend <john.r.fastabend@intel.com>,
	Neil Horman <nhorman@tuxdriver.com>,
	Daniel Wagner <daniel.wagner@bmw-carit.de>,
	LKML <linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
	Cgroups <cgroups@vger.kernel.org>
Subject: Re: [BUG] Bug in netprio_cgroup and netcls_cgroup ?
Date: Mon, 21 Jan 2013 17:57:39 +0800	[thread overview]
Message-ID: <50FD1113.6010402@huawei.com> (raw)
In-Reply-To: <50FD09FD.4010804@monom.org>

On 2013/1/21 17:27, Daniel Wagner wrote:
> On 21.01.2013 10:01, Li Zefan wrote:
>> On 2013/1/21 16:50, Daniel Wagner wrote:
>>> Hi Li,
>>>
>>> On 21.01.2013 07:08, Li Zefan wrote:
>>>> I'm not a network developer, so correct me if I'm wrong.
>>>>
>>>> Since commit 7955490f732c2b8
>>>> ("net: netprio_cgroup: rework update socket logic"), sock->sk->sk_cgrp_prioidx
>>>> is set when the socket is created, and won't be updated unless the task is
>>>> moved to another cgroup.
>>>>
>>>> Now the problem is, a socket can be _shared_ by multiple processes (fork, SCM_RIGHT).
>>>> If we place those processes in different cgroups, and each cgroup has
>>>> different configs, but all of the processes will send data via this socket
>>>> with the same network priority.
>>>
>>> Wouldn't that be addressed by 48a87cc26c13b68f6cce4e9d769fcb17a6b3e4b8
>>>
>>>     net: netprio: fd passed in SCM_RIGHTS datagram not set correctly
>>>
>>>      A socket fd passed in a SCM_RIGHTS datagram was not getting
>>>      updated with the new tasks cgrp prioidx. This leaves IO on
>>>      the socket tagged with the old tasks priority.
>>>
>>>      To fix this add a check in the scm recvmsg path to update the
>>>      sock cgrp prioidx with the new tasks value.
>>>
>>> As I read this this should work for net_prio.
>>>
>>
>> But after process A passed the socket fd to B, both A and B can use the
>> same socket to send data, right? Then if A and B were placed in different
>> cgroups with differnt configs, A's config won't take effect anymore.
>>
>> Am I missing something?
> 
> I don't know. I guess at one point the socket resources are shared and then
> one configuration is taking preference. As you can see I am far away of
> being
> an expert in this field. Hopefully someone who understands this bits
> can chip in.
> 
> BTW, isn't this a similar to what should happen with the block io cgroup?
> What is the behavior with a fd writing to a file in the scenario you
> describe above?
> 

It forbids task moving in this case:

/*
 * We cannot support shared io contexts, as we have no mean to support
 * two tasks with the same ioc in two different groups without major rework
 * of the main cic data structures.  For now we allow a task to change
 * its cgroup only if it's the only owner of its ioc.
 */
static int blkcg_can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)


  reply	other threads:[~2013-01-21  9:57 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-21  6:08 [BUG] Bug in netprio_cgroup and netcls_cgroup ? Li Zefan
2013-01-21  6:08 ` Li Zefan
2013-01-21  6:08 ` Li Zefan
     [not found] ` <50FCDB5C.4050608-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-01-21  8:50   ` Daniel Wagner
2013-01-21  8:50     ` Daniel Wagner
     [not found]     ` <50FD0144.1000401-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>
2013-01-21  9:01       ` Li Zefan
2013-01-21  9:01         ` Li Zefan
2013-01-21  9:01         ` Li Zefan
     [not found]         ` <50FD0402.6060400-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-01-21  9:21           ` John Fastabend
2013-01-21  9:21             ` John Fastabend
     [not found]             ` <50FD0893.1050805-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-21  9:52               ` Li Zefan
2013-01-21  9:52                 ` Li Zefan
2013-01-21  9:52                 ` Li Zefan
2013-01-21  9:27           ` Daniel Wagner
2013-01-21  9:27             ` Daniel Wagner
2013-01-21  9:57             ` Li Zefan [this message]
2013-01-21  9:57               ` Li Zefan
2013-01-21 17:18               ` John Fastabend
     [not found]                 ` <50FD786E.4050108-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-22 10:09                   ` Daniel Wagner
2013-01-22 10:09                     ` Daniel Wagner
2013-01-22 10:09                     ` Daniel Wagner
2013-01-23  0:02                     ` John Fastabend
     [not found]                       ` <50FF287C.70906-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-23  9:24                         ` Daniel Wagner
2013-01-23  9:24                           ` Daniel Wagner
2013-01-25  8:39                     ` Li Zefan
2013-01-25  8:39                       ` Li Zefan

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=50FD1113.6010402@huawei.com \
    --to=lizefan@huawei.com \
    --cc=cgroups@vger.kernel.org \
    --cc=daniel.wagner@bmw-carit.de \
    --cc=john.r.fastabend@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=wagi@monom.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.