[Devel] [PATCH 3/6] proc connector: proc listeners helpers added

Andrey Ryabinin aryabinin at virtuozzo.com
Tue Aug 15 17:13:48 MSK 2017



On 08/15/2017 04:58 PM, Stanislav Kinsburskiy wrote:
> 
> 
> 15.08.2017 16:52, Andrey Ryabinin пишет:
>> On 08/15/2017 03:42 PM, Stanislav Kinsburskiy wrote:
>>> These are precursor helpers, which will hide all the containerization magic.
>>>
>>> Signed-off-by: Stanislav Kinsburskiy <skinsbursky at virtuozzo.com>
>>> ---
>>>  drivers/connector/cn_proc.c |   57 +++++++++++++++++++++++++++++++++----------
>>>  1 file changed, 44 insertions(+), 13 deletions(-)
>>>
>>
>>>  void proc_fork_connector(struct task_struct *task)
>>>  {
>>>  	struct cn_msg *msg;
>>> @@ -73,8 +95,9 @@ void proc_fork_connector(struct task_struct *task)
>>>  	__u8 buffer[CN_PROC_MSG_SIZE] __aligned(8);
>>>  	struct timespec ts;
>>>  	struct task_struct *parent;
>>> +	struct net *net = task_net(task);
>>>  
>>> -	if (atomic_read(&proc_event_num_listeners) < 1)
>>> +	if (get_listeners(net) < 1)
>>
>> And now the listener on host won't receive anything, because the forked task has different net namespace.
> 
> Makes sense. Looks like get_exec_enc()->ve_netns has to be used instead.
> The structure is created for containers init net anyways.
> 
>> This should remain the global counter.
>>
> 
> Why?
> 
>> Also you need to craft and send multiple messages for every listener with pid of tasks in the *listener's* pid namespace.
>> And same for all other connectors.
>>
> 
> Didn't get it.
> 

E.g. we have listener on host, i.e. with all init namespaces. And we also have listener in some container.
Let's say we have task "A" in the container which have global pid 10 and pid 3 in container.
So if "A" forks, the host listener must receive message that task 10 forked, and the containers listener must receive message that task 3 forked.


More information about the Devel mailing list