[LTP] kill11: Skip with pipe-based core dump handlers

[linuxtestproject.agent@gmail.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