Hi Christian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc5]
[cannot apply to next-20181207]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On Fri, Dec 07, 2018 at 02:54:25AM +0100, Christian Brauner wrote:
> On Thu, Dec 06, 2018 at 05:39:18PM -0800, Daniel Colascione wrote:
> > On Thu, Dec 6, 2018 at 4:59 PM Serge E. Hallyn wrote:
> > >
> > > On Thu, Dec 06, 2018 at 04:34:54PM -0800, Daniel Colascione wrote:
> > > > On Thu, Dec 6, 20
On Thu, Dec 06, 2018 at 01:18:58PM +0100, Christian Brauner wrote:
> The kill() syscall operates on process identifiers (pid). After a process
> has exited its pid can be reused by another process. If a caller sends a
> signal to a reused pid it will end up signaling the wrong process. This
> issue
On Thu, Dec 06, 2018 at 05:39:18PM -0800, Daniel Colascione wrote:
> On Thu, Dec 6, 2018 at 4:59 PM Serge E. Hallyn wrote:
> >
> > On Thu, Dec 06, 2018 at 04:34:54PM -0800, Daniel Colascione wrote:
> > > On Thu, Dec 6, 2018 at 4:31 PM Serge E. Hallyn wrote:
> > > >
> > > > On Fri, Dec 07, 2018 at
On Thu, Dec 6, 2018 at 4:59 PM Serge E. Hallyn wrote:
>
> On Thu, Dec 06, 2018 at 04:34:54PM -0800, Daniel Colascione wrote:
> > On Thu, Dec 6, 2018 at 4:31 PM Serge E. Hallyn wrote:
> > >
> > > On Fri, Dec 07, 2018 at 12:17:45AM +0100, Christian Brauner wrote:
> > > > On Thu, Dec 06, 2018 at 11:
On Thu, Dec 06, 2018 at 04:34:54PM -0800, Daniel Colascione wrote:
> On Thu, Dec 6, 2018 at 4:31 PM Serge E. Hallyn wrote:
> >
> > On Fri, Dec 07, 2018 at 12:17:45AM +0100, Christian Brauner wrote:
> > > On Thu, Dec 06, 2018 at 11:39:48PM +0100, Christian Brauner wrote:
> > > > On Thu, Dec 06, 201
On Thu, Dec 6, 2018 at 4:31 PM Serge E. Hallyn wrote:
>
> On Fri, Dec 07, 2018 at 12:17:45AM +0100, Christian Brauner wrote:
> > On Thu, Dec 06, 2018 at 11:39:48PM +0100, Christian Brauner wrote:
> > > On Thu, Dec 06, 2018 at 03:46:53PM -0600, Eric W. Biederman wrote:
> > > > Christian Brauner wr
On Fri, Dec 07, 2018 at 12:17:45AM +0100, Christian Brauner wrote:
> On Thu, Dec 06, 2018 at 11:39:48PM +0100, Christian Brauner wrote:
> > On Thu, Dec 06, 2018 at 03:46:53PM -0600, Eric W. Biederman wrote:
> > > Christian Brauner writes:
> > >
> > > >> Your intention is to add the thread case to
On Thu, Dec 06, 2018 at 11:39:48PM +0100, Christian Brauner wrote:
> On Thu, Dec 06, 2018 at 03:46:53PM -0600, Eric W. Biederman wrote:
> > Christian Brauner writes:
> >
> > >> Your intention is to add the thread case to support pthreads once the
> > >> process case is sorted out. So this is som
On Thu, Dec 6, 2018 at 2:22 PM Eric W. Biederman wrote:
>
> Daniel Colascione writes:
>
> > On Thu, Dec 6, 2018 at 12:29 PM Eric W. Biederman
> > wrote:
> >> Christian Brauner writes:
> >>
> >> > [1]: You cannot replicate certain aspects of kill *yet*. We have
> >> > established this before. I
On Thu, Dec 06, 2018 at 03:46:53PM -0600, Eric W. Biederman wrote:
> Christian Brauner writes:
>
> >> Your intention is to add the thread case to support pthreads once the
> >> process case is sorted out. So this is something that needs to be made
> >> clear. Did I miss how you plan to handle t
On Thu, Dec 06, 2018 at 10:30:40AM -0800, Kees Cook wrote:
> On Thu, Dec 6, 2018 at 9:41 AM Christian Brauner wrote:
> > I feel changing the name around by a single persons preferences is not
> > really a nice thing to do community-wise. So I'd like to hear other
> > people chime in first before I
Daniel Colascione writes:
> On Thu, Dec 6, 2018 at 12:29 PM Eric W. Biederman
> wrote:
>> Christian Brauner writes:
>>
>> > [1]: You cannot replicate certain aspects of kill *yet*. We have
>> > established this before. If we want process group support later we do
>> > have the flags argument t
On Thu, Dec 6, 2018 at 1:47 PM Eric W. Biederman wrote:
>
> Christian Brauner writes:
>
> >> Your intention is to add the thread case to support pthreads once the
> >> process case is sorted out. So this is something that needs to be made
> >> clear. Did I miss how you plan to handle threads?
>
Christian Brauner writes:
>> Your intention is to add the thread case to support pthreads once the
>> process case is sorted out. So this is something that needs to be made
>> clear. Did I miss how you plan to handle threads?
>
> Yeah, maybe you missed it in the commit message [2] which is base
On Thu, Dec 06, 2018 at 02:29:13PM -0600, Eric W. Biederman wrote:
> Christian Brauner writes:
>
> > On Thu, Dec 06, 2018 at 01:17:24PM -0600, Eric W. Biederman wrote:
> >> Christian Brauner writes:
> >>
> >> > On December 7, 2018 4:01:19 AM GMT+13:00, ebied...@xmission.com wrote:
> >> >>Christ
On Thu, Dec 6, 2018 at 12:29 PM Eric W. Biederman wrote:
> Christian Brauner writes:
>
> > On Thu, Dec 06, 2018 at 01:17:24PM -0600, Eric W. Biederman wrote:
> >> Christian Brauner writes:
> >>
> >> > On December 7, 2018 4:01:19 AM GMT+13:00, ebied...@xmission.com wrote:
> >> >>Christian Brauner
Christian Brauner writes:
> On Thu, Dec 06, 2018 at 01:17:24PM -0600, Eric W. Biederman wrote:
>> Christian Brauner writes:
>>
>> > On December 7, 2018 4:01:19 AM GMT+13:00, ebied...@xmission.com wrote:
>> >>Christian Brauner writes:
>> >>
>> >>> The kill() syscall operates on process identifi
On Thu, Dec 06, 2018 at 01:17:24PM -0600, Eric W. Biederman wrote:
> Christian Brauner writes:
>
> > On December 7, 2018 4:01:19 AM GMT+13:00, ebied...@xmission.com wrote:
> >>Christian Brauner writes:
> >>
> >>> The kill() syscall operates on process identifiers (pid). After a
> >>process
> >>>
Christian Brauner writes:
> On December 7, 2018 4:01:19 AM GMT+13:00, ebied...@xmission.com wrote:
>>Christian Brauner writes:
>>
>>> The kill() syscall operates on process identifiers (pid). After a
>>process
>>> has exited its pid can be reused by another process. If a caller
>>sends a
>>> sig
On Thu, Dec 6, 2018 at 9:41 AM Christian Brauner wrote:
> I feel changing the name around by a single persons preferences is not
> really a nice thing to do community-wise. So I'd like to hear other
> people chime in first before I make that change.
I don't think the name is hugely critical (but
On Thu, Dec 06, 2018 at 11:24:28AM -0600, Eric W. Biederman wrote:
> Daniel Colascione writes:
>
> > On Thu, Dec 6, 2018 at 7:02 AM Eric W. Biederman
> > wrote:
> >>
> >> Christian Brauner writes:
> >>
> >> > The kill() syscall operates on process identifiers (pid). After a process
> >> > has
Daniel Colascione writes:
> On Thu, Dec 6, 2018 at 7:02 AM Eric W. Biederman
> wrote:
>>
>> Christian Brauner writes:
>>
>> > The kill() syscall operates on process identifiers (pid). After a process
>> > has exited its pid can be reused by another process. If a caller sends a
>> > signal to a
On December 7, 2018 4:01:19 AM GMT+13:00, ebied...@xmission.com wrote:
>Christian Brauner writes:
>
>> The kill() syscall operates on process identifiers (pid). After a
>process
>> has exited its pid can be reused by another process. If a caller
>sends a
>> signal to a reused pid it will end up si
On Thu, Dec 6, 2018 at 7:02 AM Eric W. Biederman wrote:
>
> Christian Brauner writes:
>
> > The kill() syscall operates on process identifiers (pid). After a process
> > has exited its pid can be reused by another process. If a caller sends a
> > signal to a reused pid it will end up signaling th
Christian Brauner writes:
> The kill() syscall operates on process identifiers (pid). After a process
> has exited its pid can be reused by another process. If a caller sends a
> signal to a reused pid it will end up signaling the wrong process. This
> issue has often surfaced and there has been
Florian Weimer writes:
> * Eric W. Biederman:
>
>> Floriam are you seeing a problem with this behavior or the way Christian
>> was describing it?
>
> My hope is that you could use taskfd_send_signal one day to send a
> signal to a process which you *known* (based on how you've written your
> appl
On 2018-12-06, Florian Weimer wrote:
> > Floriam are you seeing a problem with this behavior or the way Christian
> > was describing it?
>
> My hope is that you could use taskfd_send_signal one day to send a
> signal to a process which you *known* (based on how you've written your
> application)
* Eric W. Biederman:
> Floriam are you seeing a problem with this behavior or the way Christian
> was describing it?
My hope is that you could use taskfd_send_signal one day to send a
signal to a process which you *known* (based on how you've written your
application) should be running and not in
Florian Weimer writes:
> * Jürg Billeter:
>
>> On Thu, 2018-12-06 at 13:30 +0100, Florian Weimer wrote:
>>> * Christian Brauner:
>>>
>>> > /* zombies */
>>> > Zombies can be signaled just as any other process. No special error will
>>> > be
>>> > reported since a zombie state is an unreliable s
* Jürg Billeter:
> On Thu, 2018-12-06 at 14:12 +0100, Florian Weimer wrote:
>> * Jürg Billeter:
>>
>> > On Thu, 2018-12-06 at 13:30 +0100, Florian Weimer wrote:
>> > > * Christian Brauner:
>> > >
>> > > > /* zombies */
>> > > > Zombies can be signaled just as any other process. No special error
On Thu, 2018-12-06 at 14:12 +0100, Florian Weimer wrote:
> * Jürg Billeter:
>
> > On Thu, 2018-12-06 at 13:30 +0100, Florian Weimer wrote:
> > > * Christian Brauner:
> > >
> > > > /* zombies */
> > > > Zombies can be signaled just as any other process. No special error
> > > > will be
> > > > re
* Christian Brauner:
> On Thu, Dec 06, 2018 at 01:30:19PM +0100, Florian Weimer wrote:
>> * Christian Brauner:
>>
>> > /* zombies */
>> > Zombies can be signaled just as any other process. No special error will be
>> > reported since a zombie state is an unreliable state (cf. [3]).
>>
>> I still
* Jürg Billeter:
> On Thu, 2018-12-06 at 13:30 +0100, Florian Weimer wrote:
>> * Christian Brauner:
>>
>> > /* zombies */
>> > Zombies can be signaled just as any other process. No special error will be
>> > reported since a zombie state is an unreliable state (cf. [3]).
>>
>> I still disagree w
On Thu, Dec 06, 2018 at 01:30:19PM +0100, Florian Weimer wrote:
> * Christian Brauner:
>
> > /* zombies */
> > Zombies can be signaled just as any other process. No special error will be
> > reported since a zombie state is an unreliable state (cf. [3]).
>
> I still disagree with this analysis.
On Thu, 2018-12-06 at 13:30 +0100, Florian Weimer wrote:
> * Christian Brauner:
>
> > /* zombies */
> > Zombies can be signaled just as any other process. No special error will be
> > reported since a zombie state is an unreliable state (cf. [3]).
>
> I still disagree with this analysis. If I kn
* Christian Brauner:
> /* zombies */
> Zombies can be signaled just as any other process. No special error will be
> reported since a zombie state is an unreliable state (cf. [3]).
I still disagree with this analysis. If I know that the target process
is still alive, and it is not, this is a per
37 matches
Mail list logo
