Re: [PATCH] coredump: fix wrong comments on core limits of pipe coredump case

Re: [PATCH] coredump: fix wrong comments on core limits of pipe coredump case

[Oleg Nesterov]

Ah, I thought you are going to re-do this patch...

On 08/22, bookjovi@gmail.com wrote:
>
> Only core limit 1 can skip dump in ispipe case, not 0.

Yes, but this is (almost) internal hack we use to avoid the recursive
crashes.

> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -2163,7 +2163,7 @@ void do_coredump(long signr, int exit_code, struct pt_regs *regs)
>  			 * we're not writing to the file system, but we use
>  			 * cprm.limit of 1 here as a speacial value. Any
>  			 * non-1 limit gets set to RLIM_INFINITY below, but
> -			 * a limit of 0 skips the dump.  This is a consistent
> +			 * a limit of 1 skips the dump.  This is a consistent

I'd suggest to simple remove the "skips the dump" part.

To me, we can also remove the "Note that we use task_tgid_vnr" part,
but feel free to ignore. Every user of task_tgid_vnr() could have the
same comment.

Oleg.

[PATCH] coredump: fix wrong comments on core limits of pipe coredump case

[bookjovi]

From: Jovi Zhang <bookjovi@gmail.com>

In commit 898b374a, core limits recursive check vaule changed from 0 to 1,
but the corresponding comments was not changed correctly.

Only core limit 1 can skip dump in ispipe case, not 0.

Signed-off-by: Jovi Zhang <bookjovi@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
 fs/exec.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 25dcbe5..da60703 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -2163,7 +2163,7 @@ void do_coredump(long signr, int exit_code, struct pt_regs *regs)
 			 * we're not writing to the file system, but we use
 			 * cprm.limit of 1 here as a speacial value. Any
 			 * non-1 limit gets set to RLIM_INFINITY below, but
-			 * a limit of 0 skips the dump.  This is a consistent
+			 * a limit of 1 skips the dump.  This is a consistent
 			 * way to catch recursive crashes.  We can still crash
 			 * if the core_pattern binary sets RLIM_CORE =  !1
 			 * but it runs as root, and can do lots of stupid things
-- 
1.7.2.3