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

[Stanislav Kinsburskiy]

15.08.2017 17:13, Andrey Ryabinin пишет:
> 
> 
> 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.
> 

Hmm. This also makes sense. But painful.
Sending one message for both ve#0 and CT initial pid namespaces should be enough, what do you think?