From: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: John Fastabend <john.fastabend-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Daniel Wagner <wagi-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>,
John Fastabend
<john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>,
Daniel Wagner
<daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [BUG] Bug in netprio_cgroup and netcls_cgroup ?
Date: Mon, 21 Jan 2013 17:52:45 +0800 [thread overview]
Message-ID: <50FD0FED.7070204@huawei.com> (raw)
In-Reply-To: <50FD0893.1050805-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 2013/1/21 17:21, John Fastabend wrote:
> On 01/21/2013 01:01 AM, 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?
>>
>>
>
> Hi Zefan,
>
> Neil and I discusses this here, http://patchwork.ozlabs.org/patch/172343/
> look towards the bottom of the thread. Quoted here.
>
So this is a known issue. Why not document this behavior in
Documentation/cgroups/netprio.txt?
WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan@huawei.com>
To: John Fastabend <john.fastabend@gmail.com>
Cc: Daniel Wagner <wagi@monom.org>,
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:52:45 +0800 [thread overview]
Message-ID: <50FD0FED.7070204@huawei.com> (raw)
In-Reply-To: <50FD0893.1050805@gmail.com>
On 2013/1/21 17:21, John Fastabend wrote:
> On 01/21/2013 01:01 AM, 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?
>>
>>
>
> Hi Zefan,
>
> Neil and I discusses this here, http://patchwork.ozlabs.org/patch/172343/
> look towards the bottom of the thread. Quoted here.
>
So this is a known issue. Why not document this behavior in
Documentation/cgroups/netprio.txt?
WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: John Fastabend <john.fastabend-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Daniel Wagner <wagi-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>,
John Fastabend
<john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>,
Daniel Wagner
<daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [BUG] Bug in netprio_cgroup and netcls_cgroup ?
Date: Mon, 21 Jan 2013 17:52:45 +0800 [thread overview]
Message-ID: <50FD0FED.7070204@huawei.com> (raw)
In-Reply-To: <50FD0893.1050805-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 2013/1/21 17:21, John Fastabend wrote:
> On 01/21/2013 01:01 AM, 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?
>>
>>
>
> Hi Zefan,
>
> Neil and I discusses this here, http://patchwork.ozlabs.org/patch/172343/
> look towards the bottom of the thread. Quoted here.
>
So this is a known issue. Why not document this behavior in
Documentation/cgroups/netprio.txt?
next prev parent reply other threads:[~2013-01-21 9:52 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 [this message]
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
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=50FD0FED.7070204@huawei.com \
--to=lizefan-hv44wf8li93qt0dzr+alfa@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org \
--cc=john.fastabend-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org \
--cc=wagi-kQCPcA+X3s7YtjvyW6yDsg@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.