From: Enke Chen
TCP keepalive does not timeout under the condition that network connection
is lost and data remain undelivered (incl. retransmit). A very simple
scenarios of the failure is to write data to a tcp socket after the network
connection is lost.
Under the specified condition
Hi, Neal:
What you described is more accurate, and is correct.
Thanks. -- Enke
On Sat, Jan 23, 2021 at 07:19:13PM -0500, Neal Cardwell wrote:
> On Fri, Jan 22, 2021 at 9:45 PM Enke Chen wrote:
> >
> > Hi, Jakub:
> >
> > On Fri, Jan 22, 2021 at 06:34:24PM
Hi, Jakub:
On Fri, Jan 22, 2021 at 06:34:24PM -0800, Jakub Kicinski wrote:
> On Fri, 22 Jan 2021 18:28:23 -0800 Enke Chen wrote:
> > Hi, Jakub:
> >
> > In terms of backporting, this patch should go together with:
> >
> > 9d9b1ee0b2d1 tcp: fix
Hi, Jakub:
In terms of backporting, this patch should go together with:
9d9b1ee0b2d1 tcp: fix TCP_USER_TIMEOUT with zero window
Thanks. -- Enke
On Fri, Jan 22, 2021 at 05:43:25PM -0800, Jakub Kicinski wrote:
> On Fri, 22 Jan 2021 11:13:06 -0800 Enke Chen wrote:
> > From:
Hi, Folks:
Please ignore this patch. I will split it into separate ones as suggested
off-list by Neal Cardwell .
Thanks. -- Enke
On Tue, Jan 12, 2021 at 11:25:44AM -0800, Enke Chen wrote:
> From: Enke Chen
>
> In this patch two issues with TCP keepalives are fixed:
>
> 1) TCP
From: Enke Chen
The TCP_USER_TIMEOUT is checked by the 0-window probe timer. As the
timer has backoff with a max interval of about two minutes, the
actual timeout for TCP_USER_TIMEOUT can be off by up to two minutes.
In this patch the TCP_USER_TIMEOUT is made more accurate by taking
On Mon, Jan 18, 2021 at 08:02:21PM -0800, Jakub Kicinski wrote:
> On Fri, 15 Jan 2021 14:30:58 -0800 Enke Chen wrote:
> > From: Enke Chen
> >
> > The TCP session does not terminate with TCP_USER_TIMEOUT when data
> > remain untransmitted due to zero window.
> >
From: Enke Chen
The TCP session does not terminate with TCP_USER_TIMEOUT when data
remain untransmitted due to zero window.
The number of unanswered zero-window probes (tcp_probes_out) is
reset to zero with incoming acks irrespective of the window size,
as described in tcp_probe_timer
Hi, Eric:
Yes, that is a good point! I have been discussing with Neal and Yuchung also
and will work on revising the patch.
Thanks. -- Enke
On Wed, Jan 13, 2021 at 09:44:11PM +0100, Eric Dumazet wrote:
> On Wed, Jan 13, 2021 at 9:12 PM Enke Chen wrote:
> >
> >
Yes, I am convinced :-) Thanks to Eric, Neal and Yuchung for their help.
-- Enke
On Wed, Jan 13, 2021 at 01:20:55PM -0800, Yuchung Cheng wrote:
> On Wed, Jan 13, 2021 at 12:49 PM Eric Dumazet wrote:
> >
> > On Wed, Jan 13, 2021 at 9:12 PM Enke Chen wrote:
> > &g
that the probes_nzw
> patch relies on tcp_model_timeout(), which assumes exponential backoff, and
> exponential backoff does not happen in the tcp_send_probe0() code path that
> sets timeout = TCP_RESOURCE_PROBE_INTERVAL.
>
> best,
> neal
>
>
> On Wed, Jan 13, 20
On Wed, Jan 13, 2021 at 12:06:27PM -0800, Enke Chen wrote:
> Hi, Eric:
>
> Just to clarify: the issues for tcp keepalive and TCP_USER_TIMEOUT are
> separate isues, and the fixes would not conflict afaik.
>
> Thanks. -- Enke
I have posted patches for both issues, and th
From: Enke Chen
The TCP session does not terminate with TCP_USER_TIMEOUT when data
remain untransmitted due to zero window.
The number of unanswered zero-window probes (tcp_probes_out) is
reset to zero with incoming acks irrespective of the window size,
as described in tcp_probe_timer
On Tue, Jan 12, 2021 at 2:31 PM Enke Chen wrote:
> > >
> > > From: Enke Chen
> > >
> > > In this patch two issues with TCP keepalives are fixed:
> > >
> > > 1) TCP keepalive does not timeout when there are data waiting to be
>
is configured, and not the user timeout.
Thanks. -- Enke
On Tue, Jan 12, 2021 at 02:48:01PM -0800, Yuchung Cheng wrote:
> On Tue, Jan 12, 2021 at 2:31 PM Enke Chen wrote:
> >
> > From: Enke Chen
> >
> > In this patch two issues with TCP keepalives are fixed:
&g
From: Enke Chen
In this patch two issues with TCP keepalives are fixed:
1) TCP keepalive does not timeout when there are data waiting to be
delivered and then the connection got broken. The TCP keepalive
timeout is not evaluated in that condition.
The fix is to remove the code
Cardwell wrote:
> On Fri, Jan 8, 2021 at 11:38 PM Enke Chen wrote:
> >
> > From: Enke Chen
> >
> > This reverts commit 9721e709fa68ef9b860c322b474cfbd1f8285b0f.
> >
> > With the commit 9721e709fa68 ("tcp: simplify window probe aborting
> > on
From: Enke Chen
This reverts commit 9721e709fa68ef9b860c322b474cfbd1f8285b0f.
With the commit 9721e709fa68 ("tcp: simplify window probe aborting
on USER_TIMEOUT"), the TCP session does not terminate with
TCP_USER_TIMEOUT when data remain untransmitted due to zero window.
Hi, David:
Do you still have concerns about backward compatibility of the fix?
I really do not see how existing, working applications would be negatively
impacted
by the fix.
Thanks. -- Enke
-Original Message-
From: "Enke Chen (enkechen)"
Date: Friday, September 6, 201
ection of the source address would be more accurate and
reliable based on the up-to-date routing table.
---
Thanks. -- Enke
-Original Message-
From: on behalf of David Miller
Date: Friday, September 6, 2019 at 12:14 AM
To: "Enke Chen (enkechen)"
Cc: "kuz...@ms2.in
ection when the source address
is explicitly specified by "bind()", or by the "IP_PKTINFO" option.
- In the case that the source address is not explicitly specified,
the selection of the source address would be more accurate and
reliable based on the up-to-date routi
t; reliable data transport: if you need 100% reliability, you need to be
> using another mechanism, either in combination with a signal, or by
> itself.
Given the right signo, e.g., a RT signal for both models, or SIGUSR1/SIGUSR2
for 1:1 model, the pre-coredump signal notification is 1
t; reliable data transport: if you need 100% reliability, you need to be
> using another mechanism, either in combination with a signal, or by
> itself.
Given the right signo, e.g., a RT signal for both models, or SIGUSR1/SIGUSR2
for 1:1 model, the pre-coredump signal notification is 1
Hi, Dave:
Thanks for your comments. You have indeed missed some of the prior reviews
and discussions. But that is OK.
Please see my replies inline.
On 11/28/18 7:19 AM, Dave Martin wrote:
> On Tue, Nov 27, 2018 at 10:54:41PM +0000, Enke Chen wrote:
>> [Repost as a series, as suggested
Hi, Dave:
Thanks for your comments. You have indeed missed some of the prior reviews
and discussions. But that is OK.
Please see my replies inline.
On 11/28/18 7:19 AM, Dave Martin wrote:
> On Tue, Nov 27, 2018 at 10:54:41PM +0000, Enke Chen wrote:
>> [Repost as a series, as suggested
[Repost as a series, as suggested by Andrew Morton]
Selftest for the pre-coredump signal notification
Signed-off-by: Enke Chen
---
tools/testing/selftests/prctl/Makefile | 2 +-
tools/testing/selftests/prctl/predump-sig-test.c | 160 +++
2 files changed, 161
[Repost as a series, as suggested by Andrew Morton]
Selftest for the pre-coredump signal notification
Signed-off-by: Enke Chen
---
tools/testing/selftests/prctl/Makefile | 2 +-
tools/testing/selftests/prctl/predump-sig-test.c | 160 +++
2 files changed, 161
-by: Enke Chen
Reviewed-by: Oleg Nesterov
---
v4 -> v5:
Addressed review comments from Oleg Nesterov:
o use rcu_read_lock instead.
o revert back to notify the real_parent.
fs/coredump.c| 23 +++
fs/exec.c| 3 +++
include/linux/sched/signa
-by: Enke Chen
Reviewed-by: Oleg Nesterov
---
v4 -> v5:
Addressed review comments from Oleg Nesterov:
o use rcu_read_lock instead.
o revert back to notify the real_parent.
fs/coredump.c| 23 +++
fs/exec.c| 3 +++
include/linux/sched/signa
that it should be submitted
separately
from the code.
Thanks. -- Enke
On 11/21/18 5:33 PM, Andrew Morton wrote:
> On Wed, 21 Nov 2018 17:09:50 -0800 Enke Chen wrote:
>
>> Hi, Andrew:
>>
>> On 11/21/18 4:37 PM, Andrew Morton wrote:
>>> On Tue, 30 Oct 2018 17
that it should be submitted
separately
from the code.
Thanks. -- Enke
On 11/21/18 5:33 PM, Andrew Morton wrote:
> On Wed, 21 Nov 2018 17:09:50 -0800 Enke Chen wrote:
>
>> Hi, Andrew:
>>
>> On 11/21/18 4:37 PM, Andrew Morton wrote:
>>> On Tue, 30 Oct 2018 17
Hi, Andrew:
On 11/21/18 5:09 PM, Enke Chen wrote:
> Hi, Andrew:
>
> On 11/21/18 4:37 PM, Andrew Morton wrote:
>> Do we have other linux-specific signal extensions which could piggyback onto
>> that?
>
> No. There are enough existing signals that an application ca
Hi, Andrew:
On 11/21/18 5:09 PM, Enke Chen wrote:
> Hi, Andrew:
>
> On 11/21/18 4:37 PM, Andrew Morton wrote:
>> Do we have other linux-specific signal extensions which could piggyback onto
>> that?
>
> No. There are enough existing signals that an application ca
Hi, Andrew:
On 11/21/18 4:37 PM, Andrew Morton wrote:
> On Tue, 30 Oct 2018 17:46:29 +0100 Oleg Nesterov wrote:
>
>> On 10/29, Enke Chen wrote:
>>>
>>> Reviewed-by: Oleg Nesterov
>>
>> Hmm. I didn't say this ;)
>>
>> But OK, feel fr
Hi, Andrew:
On 11/21/18 4:37 PM, Andrew Morton wrote:
> On Tue, 30 Oct 2018 17:46:29 +0100 Oleg Nesterov wrote:
>
>> On 10/29, Enke Chen wrote:
>>>
>>> Reviewed-by: Oleg Nesterov
>>
>> Hmm. I didn't say this ;)
>>
>> But OK, feel fr
Hi, Folks:
Could you please take care of this patch [PATCH 5]?
Thanks. -- Enke
On 10/29/18 3:31 PM, Enke Chen wrote:
> For simplicity and consistency, this patch provides an implementation
> for signal-based fault notification prior to the coredump of a child
> process. A new prct
Hi, Folks:
Could you please take care of this patch [PATCH 5]?
Thanks. -- Enke
On 10/29/18 3:31 PM, Enke Chen wrote:
> For simplicity and consistency, this patch provides an implementation
> for signal-based fault notification prior to the coredump of a child
> process. A new prct
Hi, Oleg:
On 10/30/18 9:46 AM, Oleg Nesterov wrote:
> On 10/29, Enke Chen wrote:
>>
>> Reviewed-by: Oleg Nesterov
>
> Hmm. I didn't say this ;)
>
> But OK, feel free to keep this tag.
Thanks.
>
> I do not like this feauture. But I see no technical probl
Hi, Oleg:
On 10/30/18 9:46 AM, Oleg Nesterov wrote:
> On 10/29, Enke Chen wrote:
>>
>> Reviewed-by: Oleg Nesterov
>
> Hmm. I didn't say this ;)
>
> But OK, feel free to keep this tag.
Thanks.
>
> I do not like this feauture. But I see no technical probl
a connector-based notification
can be quite complicated (e.g., when a process manager is written in shell
scripts and thus is subject to certain inherent limitations), and a
signal-based notification would be simpler and better suited.
Signed-off-by: Enke Chen
Reviewed-by: Oleg Nesterov
---
v4
a connector-based notification
can be quite complicated (e.g., when a process manager is written in shell
scripts and thus is subject to certain inherent limitations), and a
signal-based notification would be simpler and better suited.
Signed-off-by: Enke Chen
Reviewed-by: Oleg Nesterov
---
v4
t;real_parent);
+ sig = parent->signal->predump_signal;
+ if (sig != 0)
+ do_send_sig_info(sig, SEND_SIG_NOINFO, parent, PIDTYPE_TGID);
+ rcu_read_unlock();
+}
Thanks. -- Enke
On 10/29/18 4:18 AM, Oleg Nesterov wrote:
> Hi,
>
> On 10/26, Enke Chen wrote:
t;real_parent);
+ sig = parent->signal->predump_signal;
+ if (sig != 0)
+ do_send_sig_info(sig, SEND_SIG_NOINFO, parent, PIDTYPE_TGID);
+ rcu_read_unlock();
+}
Thanks. -- Enke
On 10/29/18 4:18 AM, Oleg Nesterov wrote:
> Hi,
>
> On 10/26, Enke Chen wrote:
GID);
rcu_read_unlock();
}
Thank you so much for your help during this review. I would like to ack your
contribution in the "Reviewed-by:" field.
-- Enke
On 10/26/18 1:28 AM, Oleg Nesterov wrote:
> On 10/25, Enke Chen wrote:
>>
>> +static void do_notify_parent_
GID);
rcu_read_unlock();
}
Thank you so much for your help during this review. I would like to ack your
contribution in the "Reviewed-by:" field.
-- Enke
On 10/26/18 1:28 AM, Oleg Nesterov wrote:
> On 10/25, Enke Chen wrote:
>>
>> +static void do_notify_parent_
Dependency: [PATCH] kernel/signal: Signal-based pre-coredump notification
Signed-off-by: Enke Chen
---
tools/testing/selftests/prctl/Makefile | 2 +-
tools/testing/selftests/prctl/predump-sig-test.c | 160 +++
2 files changed, 161 insertions(+), 1 deletion
Dependency: [PATCH] kernel/signal: Signal-based pre-coredump notification
Signed-off-by: Enke Chen
---
tools/testing/selftests/prctl/Makefile | 2 +-
tools/testing/selftests/prctl/predump-sig-test.c | 160 +++
2 files changed, 161 insertions(+), 1 deletion
a connector-based notification
can be quite complicated (e.g., when a process manager is written in shell
scripts and thus is subject to certain inherent limitations), and a
signal-based notification would be simpler and better suited.
Signed-off-by: Enke Chen
---
v3 -> v4:
Addressed rev
a connector-based notification
can be quite complicated (e.g., when a process manager is written in shell
scripts and thus is subject to certain inherent limitations), and a
signal-based notification would be simpler and better suited.
Signed-off-by: Enke Chen
---
v3 -> v4:
Addressed rev
Hi, Eric:
Please see my replied inline.
On 10/25/18 5:23 AM, Eric W. Biederman wrote:
> Enke Chen writes:
>
>> Hi, Eric:
>>
>> Thanks for your comments. Please see my replies inline.
>>
>> On 10/24/18 6:29 AM, Eric W. Biederman wrote:
>>&g
Hi, Eric:
Please see my replied inline.
On 10/25/18 5:23 AM, Eric W. Biederman wrote:
> Enke Chen writes:
>
>> Hi, Eric:
>>
>> Thanks for your comments. Please see my replies inline.
>>
>> On 10/24/18 6:29 AM, Eric W. Biederman wrote:
>>&g
Hi, Eric:
I have a couple comments inlined.
>> On Wed, Oct 24, 2018 at 3:30 PM Eric W. Biederman
>> wrote:
>>> Enke Chen writes:
>>>> For simplicity and consistency, this patch provides an implementation
>>>> for signal-based fault notification
Hi, Eric:
I have a couple comments inlined.
>> On Wed, Oct 24, 2018 at 3:30 PM Eric W. Biederman
>> wrote:
>>> Enke Chen writes:
>>>> For simplicity and consistency, this patch provides an implementation
>>>> for signal-based fault notification
PE_TGID);
+ read_unlock(_lock);
+}
I will follow up with your other comments.
Thanks. -- Enke
On 10/25/18 5:23 AM, Eric W. Biederman wrote:
> Enke Chen writes:
>
>> Hi, Eric:
>>
>> Thanks for your comments. Please see my replies inline.
>>
>> On
PE_TGID);
+ read_unlock(_lock);
+}
I will follow up with your other comments.
Thanks. -- Enke
On 10/25/18 5:23 AM, Eric W. Biederman wrote:
> Enke Chen writes:
>
>> Hi, Eric:
>>
>> Thanks for your comments. Please see my replies inline.
>>
>> On
Hi, Eric:
Thanks for your comments. Please see my replies inline.
On 10/24/18 6:29 AM, Eric W. Biederman wrote:
> Enke Chen writes:
>
>> For simplicity and consistency, this patch provides an implementation
>> for signal-based fault notification prior to the coredump of
Hi, Eric:
Thanks for your comments. Please see my replies inline.
On 10/24/18 6:29 AM, Eric W. Biederman wrote:
> Enke Chen writes:
>
>> For simplicity and consistency, this patch provides an implementation
>> for signal-based fault notification prior to the coredump of
Hi, Oleg:
On 10/24/18 7:02 AM, Oleg Nesterov wrote:
> On 10/23, Enke Chen wrote:
>>
>> --- a/fs/coredump.c
>> +++ b/fs/coredump.c
>> @@ -590,6 +590,12 @@ void do_coredump(const kernel_siginfo_t *siginfo)
>> if (retval < 0)
>> goto
Hi, Oleg:
On 10/24/18 7:02 AM, Oleg Nesterov wrote:
> On 10/23, Enke Chen wrote:
>>
>> --- a/fs/coredump.c
>> +++ b/fs/coredump.c
>> @@ -590,6 +590,12 @@ void do_coredump(const kernel_siginfo_t *siginfo)
>> if (retval < 0)
>> goto
Hi, Olge:
On 10/24/18 6:52 AM, Oleg Nesterov wrote:
> On 10/23, Enke Chen wrote:
>>
>>>> + /*
>>>> + * Send the pre-coredump signal to the parent if requested.
>>>> + */
>>>> + read_lock(_lock);
>>>> +
Hi, Olge:
On 10/24/18 6:52 AM, Oleg Nesterov wrote:
> On 10/23, Enke Chen wrote:
>>
>>>> + /*
>>>> + * Send the pre-coredump signal to the parent if requested.
>>>> + */
>>>> + read_lock(_lock);
>>>> +
a connector-based notification
can be quite complicated (e.g., when a process manager is written in shell
scripts and thus is subject to certain inherent limitations), and a
signal-based notification would be simpler and better suited.
Signed-off-by: Enke Chen
---
v2 -> v3:
Addressed review comments f
a connector-based notification
can be quite complicated (e.g., when a process manager is written in shell
scripts and thus is subject to certain inherent limitations), and a
signal-based notification would be simpler and better suited.
Signed-off-by: Enke Chen
---
v2 -> v3:
Addressed review comments f
Hi, Oleg:
On 10/23/18 12:43 PM, Enke Chen wrote:
>>
>>> --- a/fs/coredump.c
>>> +++ b/fs/coredump.c
>>> @@ -546,6 +546,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
>>> struct cred *cred;
>>> int retval = 0;
>>>
Hi, Oleg:
On 10/23/18 12:43 PM, Enke Chen wrote:
>>
>>> --- a/fs/coredump.c
>>> +++ b/fs/coredump.c
>>> @@ -546,6 +546,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
>>> struct cred *cred;
>>> int retval = 0;
>>>
Hi, Oleg:
Thanks for your review. Please see my replies inline.
On 10/23/18 2:23 AM, Oleg Nesterov wrote:
> On 10/22, Enke Chen wrote:
>>
>> As the coredump of a process may take time, in certain time-sensitive
>> applications it is necessary for a parent process (e.g.,
Hi, Oleg:
Thanks for your review. Please see my replies inline.
On 10/23/18 2:23 AM, Oleg Nesterov wrote:
> On 10/22, Enke Chen wrote:
>>
>> As the coredump of a process may take time, in certain time-sensitive
>> applications it is necessary for a parent process (e.g.,
available. In some cases using a connector-based notification
can be quite complicated (e.g., when a process manager is written in shell
scripts and thus is subject to certain inherent limitations), and a
signal-based notification would be simpler and better suited.
Signed-off-by: Enke Chen
---
v1
available. In some cases using a connector-based notification
can be quite complicated (e.g., when a process manager is written in shell
scripts and thus is subject to certain inherent limitations), and a
signal-based notification would be simpler and better suited.
Signed-off-by: Enke Chen
---
v1
preserved
across execve(2).
-- Enke
On 10/22/18 8:40 AM, Jann Horn wrote:
> On Sat, Oct 20, 2018 at 1:01 AM Enke Chen wrote:
>> Regarding the security considerations, it seems simpler and more secure to
>> just clear the "pre-coredump signal" cross execve(2)
preserved
across execve(2).
-- Enke
On 10/22/18 8:40 AM, Jann Horn wrote:
> On Sat, Oct 20, 2018 at 1:01 AM Enke Chen wrote:
>> Regarding the security considerations, it seems simpler and more secure to
>> just clear the "pre-coredump signal" cross execve(2)
of the pre-coredump signal for the
calling process, in the location pointed to by (int *) arg2.
---
Thanks. -- Enke
On 10/15/18 11:54 AM, Jann Horn wrote:
> On Mon, Oct 15, 2018 at 8:36 PM Enke Chen wrote:
>> On 10/13/18 11:27 AM, Jann Horn wrote:
>>> On Sat, Oct 13, 2018
of the pre-coredump signal for the
calling process, in the location pointed to by (int *) arg2.
---
Thanks. -- Enke
On 10/15/18 11:54 AM, Jann Horn wrote:
> On Mon, Oct 15, 2018 at 8:36 PM Enke Chen wrote:
>> On 10/13/18 11:27 AM, Jann Horn wrote:
>>> On Sat, Oct 13, 2018
Hi, Oleg:
On 10/16/18 7:14 AM, Oleg Nesterov wrote:
> On 10/15, Enke Chen wrote:
>>
>>> I don't understand why we need valid_predump_signal() at all.
>>
>> Most of the signals have well-defined semantics, and would not be appropriate
>> for this purpose.
&g
Hi, Oleg:
On 10/16/18 7:14 AM, Oleg Nesterov wrote:
> On 10/15, Enke Chen wrote:
>>
>>> I don't understand why we need valid_predump_signal() at all.
>>
>> Most of the signals have well-defined semantics, and would not be appropriate
>> for this purpose.
&g
Hi, Eric:
On 10/15/18 4:28 PM, Eric W. Biederman wrote:
> Enke Chen writes:
>
>> For simplicity and consistency, this patch provides an implementation
>> for signal-based fault notification prior to the coredump of a child
>> process. A new prctl command, PR_SET_PREDUMP_
Hi, Eric:
On 10/15/18 4:28 PM, Eric W. Biederman wrote:
> Enke Chen writes:
>
>> For simplicity and consistency, this patch provides an implementation
>> for signal-based fault notification prior to the coredump of a child
>> process. A new prctl command, PR_SET_PREDUMP_
Hi, Alan:
As I replied earlier, I will remove the logic that allows setting on others.
This function "set_predump_signal_perm()" will be gone too.
Thanks. -- Enke
On 10/15/18 2:21 PM, Alan Cox wrote:
>> +/*
>> + * Returns true if current's euid is same as p's uid or euid,
>> + * or has
Hi, Alan:
As I replied earlier, I will remove the logic that allows setting on others.
This function "set_predump_signal_perm()" will be gone too.
Thanks. -- Enke
On 10/15/18 2:21 PM, Alan Cox wrote:
>> +/*
>> + * Returns true if current's euid is same as p's uid or euid,
>> + * or has
Hi, Olge:
>> probably ->predump_signal should be cleared on exec?
As I replied to Jann, will do.
Thanks. -- Enke
On 10/15/18 12:17 PM, Enke Chen wrote:
> Hi, Oleg:
>
> I missed some of your comments in my previous reply.
>
> On 10/15/18 5:05 AM, Oleg Nesterov wrote
Hi, Olge:
>> probably ->predump_signal should be cleared on exec?
As I replied to Jann, will do.
Thanks. -- Enke
On 10/15/18 12:17 PM, Enke Chen wrote:
> Hi, Oleg:
>
> I missed some of your comments in my previous reply.
>
> On 10/15/18 5:05 AM, Oleg Nesterov wrote
Hi, Jann:
Thanks for your detail explanation. Will take care of it.
-- Enke
On 10/15/18 11:54 AM, Jann Horn wrote:
> On Mon, Oct 15, 2018 at 8:36 PM Enke Chen wrote:
>> On 10/13/18 11:27 AM, Jann Horn wrote:
>>> On Sat, Oct 13, 2018 at 2:33 AM Enke Chen wrote:
&
Hi, Jann:
Thanks for your detail explanation. Will take care of it.
-- Enke
On 10/15/18 11:54 AM, Jann Horn wrote:
> On Mon, Oct 15, 2018 at 8:36 PM Enke Chen wrote:
>> On 10/13/18 11:27 AM, Jann Horn wrote:
>>> On Sat, Oct 13, 2018 at 2:33 AM Enke Chen wrote:
&
Hi, Oleg:
I missed some of your comments in my previous reply.
On 10/15/18 5:05 AM, Oleg Nesterov wrote:
> On 10/12, Enke Chen wrote:
>>
>> For simplicity and consistency, this patch provides an implementation
>> for signal-based fault notification prior to the coredump
Hi, Oleg:
I missed some of your comments in my previous reply.
On 10/15/18 5:05 AM, Oleg Nesterov wrote:
> On 10/12, Enke Chen wrote:
>>
>> For simplicity and consistency, this patch provides an implementation
>> for signal-based fault notification prior to the coredump
Hi, Oleg:
On 10/15/18 5:05 AM, Oleg Nesterov wrote:
> On 10/12, Enke Chen wrote:
>>
>> For simplicity and consistency, this patch provides an implementation
>> for signal-based fault notification prior to the coredump of a child
>> process. A new prctl command, PR_
Hi, Oleg:
On 10/15/18 5:05 AM, Oleg Nesterov wrote:
> On 10/12, Enke Chen wrote:
>>
>> For simplicity and consistency, this patch provides an implementation
>> for signal-based fault notification prior to the coredump of a child
>> process. A new prctl command, PR_
Hi, Greg:
On 10/15/18 11:43 AM, Greg Kroah-Hartman wrote:
> On Mon, Oct 15, 2018 at 11:16:36AM -0700, Enke Chen wrote:
>> Hi, Greg:
>>
>>> Shouldn't there also be a manpage update, and a kselftest added for this
>>> new user/kernel api that is being created
Hi, Greg:
On 10/15/18 11:43 AM, Greg Kroah-Hartman wrote:
> On Mon, Oct 15, 2018 at 11:16:36AM -0700, Enke Chen wrote:
>> Hi, Greg:
>>
>>> Shouldn't there also be a manpage update, and a kselftest added for this
>>> new user/kernel api that is being created
Hi, Jann:
Thanks a lot for you detailed review. Please see my replied/comments inline.
On 10/13/18 11:27 AM, Jann Horn wrote:
> On Sat, Oct 13, 2018 at 2:33 AM Enke Chen wrote:
>> For simplicity and consistency, this patch provides an implementation
>> for signal-based fault not
Hi, Jann:
Thanks a lot for you detailed review. Please see my replied/comments inline.
On 10/13/18 11:27 AM, Jann Horn wrote:
> On Sat, Oct 13, 2018 at 2:33 AM Enke Chen wrote:
>> For simplicity and consistency, this patch provides an implementation
>> for signal-based fault not
Hi, Christian:
As I replied to Jann, I will remove the code that does the setting on others
to make the code simpler and more secure.
Thanks. -- Enke
>> +static bool set_predump_signal_perm(struct task_struct *p)
>> +{
>> +const struct cred *cred = current_cred(), *pcred = __task_cred(p);
Hi, Christian:
As I replied to Jann, I will remove the code that does the setting on others
to make the code simpler and more secure.
Thanks. -- Enke
>> +static bool set_predump_signal_perm(struct task_struct *p)
>> +{
>> +const struct cred *cred = current_cred(), *pcred = __task_cred(p);
I will do), the logic would be pretty straightforward. Not
sure if the selftest would add much value.
Thanks. -- Enke
On 10/12/18 11:40 PM, Greg Kroah-Hartman wrote:
> On Fri, Oct 12, 2018 at 05:33:35PM -0700, Enke Chen wrote:
>> For simplicity and consistency, this patch provides
I will do), the logic would be pretty straightforward. Not
sure if the selftest would add much value.
Thanks. -- Enke
On 10/12/18 11:40 PM, Greg Kroah-Hartman wrote:
> On Fri, Oct 12, 2018 at 05:33:35PM -0700, Enke Chen wrote:
>> For simplicity and consistency, this patch provides
., when a process manager is written in shell
scripts and thus is subject to certain inherent limitations), and a
signal-based notification would be simpler and better suited.
Signed-off-by: Enke Chen
---
arch/x86/kernel/signal_compat.c| 2 +-
include/linux/sched.h | 4
., when a process manager is written in shell
scripts and thus is subject to certain inherent limitations), and a
signal-based notification would be simpler and better suited.
Signed-off-by: Enke Chen
---
arch/x86/kernel/signal_compat.c| 2 +-
include/linux/sched.h | 4
Hi, Miklos:
Thanks for your reply and explanation. Please see my comments below.
On 8/15/16 2:36 AM, Miklos Szeredi wrote:
> On Wed, Aug 10, 2016 at 6:50 PM, Enke Chen <enkec...@cisco.com> wrote:
>> Hi, Miklos:
>>
>> On 8/9/16 11:52 PM, Miklos Szeredi wrote:
>>
Hi, Miklos:
Thanks for your reply and explanation. Please see my comments below.
On 8/15/16 2:36 AM, Miklos Szeredi wrote:
> On Wed, Aug 10, 2016 at 6:50 PM, Enke Chen wrote:
>> Hi, Miklos:
>>
>> On 8/9/16 11:52 PM, Miklos Szeredi wrote:
>>> On Wed, Aug 10, 201
Hi, Miklos:
On 8/9/16 11:52 PM, Miklos Szeredi wrote:
> On Wed, Aug 10, 2016 at 5:26 AM, Enke Chen <enkec...@cisco.com> wrote:
>> Hi, Miklos:
>>
>> This patch adds the async option for the flush/release operation in FUSE.
>>
>> The async flush/release
1 - 100 of 103 matches
Mail list logo
