From: linuxtestproject.agent@gmail.com
To: Jan Polensky <japo@linux.ibm.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] kill11: Skip with pipe-based core dump handlers
Date: Wed, 8 Jul 2026 15:26:34 +0000 [thread overview]
Message-ID: <20260708152634.3782-1-linuxtestproject.agent@gmail.com> (raw)
In-Reply-To: <20260708133726.223095-1-japo@linux.ibm.com>
Hi Jan,
On Wed, 08 Jul 2026 15:37:26 +0200, Jan Polensky wrote:
> kill11: Skip with pipe-based core dump handlers
> + SAFE_FILE_SCANF("/proc/sys/kernel/core_pattern", "%255s", core_pattern);
> + if (core_pattern[0] == '|') {
> + tst_brk(TCONF,
> + "Pipe-based core dumps detected (e.g., systemd-coredump). "
> + "Test requires direct filesystem core dumps. "
> + "Set kernel.core_pattern to a file path (e.g., /tmp/core.%%p) "
> + "or disable systemd-coredump for proper testing.");
> + }
The check is in setup(), which aborts all iterations when it triggers.
The hang described in the commit message can only occur when the child
receives a signal that actually generates a core dump -- i.e. the cases
with dumps_core == 1 (SIGQUIT, SIGILL, SIGABRT, SIGBUS, etc.).
For the 12+ cases with dumps_core == 0 (SIGHUP, SIGKILL, SIGTERM,
SIGPIPE, etc.) the child exits immediately without touching the core
dump path, so SAFE_WAIT() returns right away and the pipe handler is
never involved.
Placing the skip in setup() discards over half the test coverage on any
system running systemd-coredump, with no benefit for those cases.
Would it work to keep the core_pattern detection in setup() (store the
result in a static bool), then check it per-iteration in verify_kill()
only when tc->dumps_core is set?
static bool pipe_based_coredump;
static void setup(void)
{
char core_pattern[256];
...
SAFE_FILE_SCANF("/proc/sys/kernel/core_pattern",
"%255s", core_pattern);
pipe_based_coredump = (core_pattern[0] == '|');
}
static void verify_kill(unsigned int n)
{
struct tcase *tc = &tcases[n];
if (tc->dumps_core && pipe_based_coredump) {
tst_res(TCONF, "%s: pipe-based core dump handler active",
tst_strsig(tc->sig));
return;
}
...
}
That way the non-core-dumping signal cases still run.
Verdict - Needs revision
---
Note:
The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.
Regards,
LTP AI Reviewer
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-07-08 15:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 13:37 [LTP] [PATCH v1 1/1] kill11: Skip with pipe-based core dump handlers Jan Polensky
2026-07-08 15:26 ` linuxtestproject.agent [this message]
2026-07-09 10:07 ` [LTP] " Jan Polensky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260708152634.3782-1-linuxtestproject.agent@gmail.com \
--to=linuxtestproject.agent@gmail.com \
--cc=japo@linux.ibm.com \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox