Received-SPF: pass (google.com: domain of linux-kernel+bounces-209730-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Tue, 11 Jun 2024 12:25:14 +0100
From: Mark Brown <broonie@kernel.org>
To: Dev Jain <dev.jain@arm.com>
Cc: shuah@kernel.org, oleg@redhat.com, stsp2@yandex.ru, mingo@kernel.org,
	tglx@linutronix.de, mark.rutland@arm.com, ryan.roberts@arm.com,
	suzuki.poulose@arm.com, Anshuman.Khandual@arm.com,
	DeepakKumar.Mishra@arm.com, AneeshKumar.KizhakeVeetil@arm.com,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] selftests: Add a test mangling with uc_sigmask
Message-ID: <Zmg0GoGnJFbPysfK@finisterre.sirena.org.uk>
References: <20240611075650.814397-1-dev.jain@arm.com>
 <20240611075650.814397-3-dev.jain@arm.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="A2hm2y1BJ1qa3PqU"
Content-Disposition: inline
In-Reply-To: <20240611075650.814397-3-dev.jain@arm.com>


--A2hm2y1BJ1qa3PqU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Jun 11, 2024 at 01:26:50PM +0530, Dev Jain wrote:

> + * A signal is said to be delivered, when the program takes action on the
> + * signal: such action may involve termination of the process, ignoring the
> + * signal, terminating with core dump, stopping the process, or continuing the
> + * process if it was currently stopped. A signal is said to be blocked when the
> + * program refuses to take any of the above actions; note that, this is not the
> + * same as ignoring the signal. At a later time, the program may unblock the
> + * signal and then it will have to take one of the five actions
> + * described above.

I'm not sure that's what my understanding of a blocked signal is, I
would interpret "blocked" as a signal being masked (this usage can be
seen in for example sigaction(2)).  I'd also interpret delivery of the
signal as happening when the signal handler is invoked rather than
something that the handler has control over (the comment later on says
that so I think it's just an issue here).  Perhaps I'm confused about
terminology though, this is just usage I've picked up and ICBW.

> + * For standard signals (also see real-time signals in the man page), multiple
> + * blocked instances of the same signal are not queued; such a signal will
> + * be delivered just once.

See also SA_NODEFER.

> +	/* SEGV has been blocked in sa_mask, but ucontext is invariant */
> +	ret = sigismember(&(((ucontext_t *)uc)->uc_sigmask), SIGSEGV);
> +	ksft_test_result(ret == 0, "SEGV not blocked in ucontext\n");
> +
> +	/* USR1 has been blocked, but ucontext is invariant */
> +	ret = sigismember(&(((ucontext_t *)uc)->uc_sigmask), SIGUSR1);
> +	ksft_test_result(ret == 0, "USR1 not blocked in ucontext\n");

We're not manipulating the masks outside of main() so it's a bit unclear
what the mention of ucontext being invariant is all about here?

> +	/* Mangled ucontext implies USR2 is blocked for current thread */
> +	if (raise(SIGUSR2))
> +		ksft_exit_fail_perror("raise");
> +
> +	ksft_print_msg("USR2 bypassed successfully\n");
> +
> +	act.sa_sigaction = &handler_verify_ucontext;
> +	if (sigaction(SIGUSR1, &act, NULL))
> +		ksft_exit_fail_perror("Cannot install handler");
> +
> +	if (raise(SIGUSR1))
> +		ksft_exit_fail_perror("raise");
> +
> +	ksft_print_msg("USR2 still blocked on return from handler\n");

But we just raised SIGUSR1 rather than SIGUSR2?  If nothing else this
bit is a little unclear.

--A2hm2y1BJ1qa3PqU
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmZoNBkACgkQJNaLcl1U
h9B9qQf+Iaz95T4ZrcXyk/EoddifPmCyDYbb1mz4TrQEknVIMBwwWCvczzuST0K1
v/cTJQLIYlfs+0Re2vg2R9W3dsyuVO7TGpuvG6ovnEUys98RS+2vhtCl367VUR5E
2bkmSvuedTSCkKlw+HoXF4nPnFuD2+KJqrvXRRNhV343J57uiDYi+Co8sI78+tH9
gR4bijyAAtKGDze2UwhHvtGVn3zAdov4o/rzlDGzpyjMO4W6dbB5d19kZ7rhgY0m
lZ2kTGYMxC6C+7MqgKK44iJolIJVDMmUhekN+zvJHxFgJN42FjgXnJgN8K8pmK/Q
M/j144QaRMb7d6QBDM5xmaxzH+pPqQ==
=+KZa
-----END PGP SIGNATURE-----

--A2hm2y1BJ1qa3PqU--