All of lore.kernel.org
 help / color / mirror / Atom feed
* [LTP] [PATCH] waitid10: Fix when coredumps are piped
@ 2022-03-21 13:38 Cyril Hrubis
  2022-03-21 15:17 ` Richard Palethorpe
  0 siblings, 1 reply; 4+ messages in thread
From: Cyril Hrubis @ 2022-03-21 13:38 UTC (permalink / raw)
  To: ltp

When coredumps are piped into a stdin of a program (the core_pattern
starts with '|') the RLIMIT_CORE limits are not enforced.

This fixes the test expectation in the corner case that rlim_cur and
rlim_max for RLIMIT_CORE are both set to 0 but the core pattern is set
to dump core into a pipe where we previously assumed the core wouldn't
be dumped.

Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
---
 testcases/kernel/syscalls/waitid/waitid10.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/testcases/kernel/syscalls/waitid/waitid10.c b/testcases/kernel/syscalls/waitid/waitid10.c
index 869ef18bd..e75edd07e 100644
--- a/testcases/kernel/syscalls/waitid/waitid10.c
+++ b/testcases/kernel/syscalls/waitid/waitid10.c
@@ -45,14 +45,17 @@ static void run(void)
 static void setup(void)
 {
 	struct rlimit rlim;
+	char c;
 
 	SAFE_GETRLIMIT(RLIMIT_CORE, &rlim);
+	SAFE_FILE_SCANF("/proc/sys/kernel/core_pattern", "%c", &c);
 
 	if (rlim.rlim_cur)
 		return;
 
 	if (!rlim.rlim_max) {
-		core_dumps = 0;
+		if (c != '|')
+			core_dumps = 0;
 		return;
 	}
 
-- 
2.34.1


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [LTP] [PATCH] waitid10: Fix when coredumps are piped
  2022-03-21 13:38 [LTP] [PATCH] waitid10: Fix when coredumps are piped Cyril Hrubis
@ 2022-03-21 15:17 ` Richard Palethorpe
  2022-03-21 15:29   ` Cyril Hrubis
  2022-03-22 12:21   ` Cyril Hrubis
  0 siblings, 2 replies; 4+ messages in thread
From: Richard Palethorpe @ 2022-03-21 15:17 UTC (permalink / raw)
  To: Cyril Hrubis; +Cc: ltp

Hello

Cyril Hrubis <chrubis@suse.cz> writes:

> When coredumps are piped into a stdin of a program (the core_pattern
> starts with '|') the RLIMIT_CORE limits are not enforced.
>
> This fixes the test expectation in the corner case that rlim_cur and
> rlim_max for RLIMIT_CORE are both set to 0 but the core pattern is set
> to dump core into a pipe where we previously assumed the core wouldn't
> be dumped.
>
> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
> ---
>  testcases/kernel/syscalls/waitid/waitid10.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/testcases/kernel/syscalls/waitid/waitid10.c b/testcases/kernel/syscalls/waitid/waitid10.c
> index 869ef18bd..e75edd07e 100644
> --- a/testcases/kernel/syscalls/waitid/waitid10.c
> +++ b/testcases/kernel/syscalls/waitid/waitid10.c
> @@ -45,14 +45,17 @@ static void run(void)
>  static void setup(void)
>  {
>  	struct rlimit rlim;
> +	char c;
>  
>  	SAFE_GETRLIMIT(RLIMIT_CORE, &rlim);
> +	SAFE_FILE_SCANF("/proc/sys/kernel/core_pattern", "%c", &c);
>  
>  	if (rlim.rlim_cur)
>  		return;
>  
>  	if (!rlim.rlim_max) {
> -		core_dumps = 0;
> +		if (c != '|')
> +			core_dumps = 0;
>  		return;
>  	}
>  
> -- 
> 2.34.1

Reviewed-by: Richard Palethorpe <rpalethorpe@suse.com>

BTW I thought that division by zero actually just resulted in zero or
INT_MAX on some platforms? (e.g. ARM)

It's undefined behaviour, so I fail to see how this test has ever worked
on some architectures. Perhaps we should dereference a null/invalid
pointer instead?


-- 
Thank you,
Richard.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [LTP] [PATCH] waitid10: Fix when coredumps are piped
  2022-03-21 15:17 ` Richard Palethorpe
@ 2022-03-21 15:29   ` Cyril Hrubis
  2022-03-22 12:21   ` Cyril Hrubis
  1 sibling, 0 replies; 4+ messages in thread
From: Cyril Hrubis @ 2022-03-21 15:29 UTC (permalink / raw)
  To: Richard Palethorpe; +Cc: ltp

Hi!
> Reviewed-by: Richard Palethorpe <rpalethorpe@suse.com>
> 
> BTW I thought that division by zero actually just resulted in zero or
> INT_MAX on some platforms? (e.g. ARM)
> 
> It's undefined behaviour, so I fail to see how this test has ever worked
> on some architectures. Perhaps we should dereference a null/invalid
> pointer instead?

That wouldn't work since we are trying to get SIGFPE not SIGSEGV.

See:

http://patchwork.ozlabs.org/project/ltp/patch/20220310105533.3012-1-chrubis@suse.cz/

Also if you can review this patch as well...

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [LTP] [PATCH] waitid10: Fix when coredumps are piped
  2022-03-21 15:17 ` Richard Palethorpe
  2022-03-21 15:29   ` Cyril Hrubis
@ 2022-03-22 12:21   ` Cyril Hrubis
  1 sibling, 0 replies; 4+ messages in thread
From: Cyril Hrubis @ 2022-03-22 12:21 UTC (permalink / raw)
  To: Richard Palethorpe; +Cc: ltp

Hi!
Pushed, thanks.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-03-22 12:19 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-03-21 13:38 [LTP] [PATCH] waitid10: Fix when coredumps are piped Cyril Hrubis
2022-03-21 15:17 ` Richard Palethorpe
2022-03-21 15:29   ` Cyril Hrubis
2022-03-22 12:21   ` Cyril Hrubis

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.