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
d sockets in Process
A can be closed without being blocked, which in turn would un-block the
operation in Process B using the UNIX-domain socket.
---
Signed-off-by: Enke Chen <enkec...@cisco.com>
Version: 4.7.0_next_20160805
fs/fuse/file.c| 39 ++
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:
>>
., 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
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
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, 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, 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, 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, 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, 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, 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, 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
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)
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
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:
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, 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/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, 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, 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
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:
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
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, 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
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
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
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
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_
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, 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
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
[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
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
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 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, 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
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, 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
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:
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
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
>
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
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
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
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, 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
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
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 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
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
-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
[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
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
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, 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
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:
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:
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
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
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
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_
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:
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
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/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
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
., 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
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
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, 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, 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, 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:
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, 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, 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, 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, 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_
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)
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
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:
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;
>>>
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, 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, 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, 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, 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
d sockets in Process
A can be closed without being blocked, which in turn would un-block the
operation in Process B using the UNIX-domain socket.
---
Signed-off-by: Enke Chen
Version: 4.7.0_next_20160805
fs/fuse/file.c| 39 +++--
Hi, Miklos:
On 8/9/16 11:52 PM, Miklos Szeredi wrote:
> On Wed, Aug 10, 2016 at 5:26 AM, Enke Chen wrote:
>> Hi, Miklos:
>>
>> This patch adds the async option for the flush/release operation in FUSE.
>>
>> The async flush/release option allows a FUSE-based
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
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
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.
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
1 - 100 of 103 matches
Mail list logo
