Re: [PATCH 11/13] Changes to show virtual ids to user

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eric W. Biederman wrote:
> Pavel Emelianov <xemul@xxxxxxxxxx> writes:
> 
>> Pavel Emelianov wrote:
>>> Cedric Le Goater wrote:
>>>> Hello !
>>>>
>>>>>>> The worst case I can see with pid == 0.  Is that it would be a bug
>>>>>>> that we can fix later.  For other cases it would seem to be a user
>>>>>>> space API thing that we get stuck with for all time.
>>>>>> We cannot trust userspace application to expect some pid other than
>>>>>> positive. All that we can is either use some always-absent pid or
>>>>>> send the signal as SI_KERNEL.
>>>>>>
>>>>>> Our experience show that making decisions like above causes random
>>>> <>> applications failures that are hard (or even impossible) to debug.
>>>>
>>>>> Ok.  So I guess I see what you are proposing is picking an arbitrary
>>>>> pid, say pid == 2, and reserving that in all pid namespaces and using
>>>>> it when we have a pid that does not map to a specific namespace. I'm
>>>>> fine with that.
>>>>>
>>>>> All I care about is that we have a solution, preferably simple,
>>>>> to the non-mapped pid problem.
>>>> Pavel, are you against using pid == 0 and setting si_code to SI_KERNEL ? 
>>> I think I am. A quick grep through the code revealed one place where
>> Sorry. I have misprinted. I meant "I think I am *NOT*". My bad :(
>>
>>> this can happen, so I believe application are (have to be) somehow
>>> prepared to this.
> 
> Where was this.  I'd like to follow your complete line of thinking.

The line concerning why I think that sending a signal from
SI_KERNEL is good solution?

> Eric
> 

_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers

[Index of Archives]     [Cgroups]     [Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux