Received-SPF: pass (google.com: domain of linux-kernel+bounces-212934-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 13 Jun 2024 10:19:52 +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: <Zmq5uK0RfvgVKFdO@finisterre.sirena.org.uk>
References: <20240611075650.814397-1-dev.jain@arm.com>
 <20240611075650.814397-3-dev.jain@arm.com>
 <Zmg0GoGnJFbPysfK@finisterre.sirena.org.uk>
 <ec1973ee-909d-41a2-8b32-256302d190b4@arm.com>
 <ZmmfkbuCl61rEPs-@finisterre.sirena.org.uk>
 <920f2e27-39ee-4c53-9c90-63d67e7d7586@arm.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="YUY1zS9czf83kEFd"
Content-Disposition: inline
In-Reply-To: <920f2e27-39ee-4c53-9c90-63d67e7d7586@arm.com>


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

On Thu, Jun 13, 2024 at 10:21:39AM +0530, Dev Jain wrote:

> I guess we agree on the same thing; so, how about I rephrase the delivery
> and blocking code comments this way:
> "A process can request blocking of a signal by masking it into its set of
> blocked signals; such a signal, when sent to the process by the kernel, will
> get blocked by the process and it may later unblock it and take an action.
> At that point, the signal will be "delivered".

Yes.

> A signal sent by the kernel to the process, is said to be delivered to the
> process when the process takes an action upon receipt of the signal: such
> action may include termination, or jumping to a signal handler."

I'd just drop this last paragraph.

> > TBH I'm not sure what you mean there by real time signals, I can't see
> > a reference to real time in the copies of signal(2), signal(7) or
> > sigaction(2) on my system.  I suspect SA_NODEFER is the actual thing
> > here.

> Real-time signals get a mention on signal(7), under the heading
> "Real-time signals":

Ah, it's got a - in there so it doesn't show up in searches.

> > I still don't follow what the above means.  When you say "invariant" you
> > don't specify with respect to what, and it's not clear to me why the
> > saved context in ucontext would have changed without the handler writing
> > to it.  For clarity I think this needs to say what the ucontext is
> > expected to be the same as/different to.

> The ucontext at this stage is supposed to be empty, I guess I'll replace
> the word "invariant" then.
> "it's not clear to me why the saved context in ucontext would have changed
> without the handler writing to it" - by invariant I meant, the set of blocked
> signals before invocation of handler is exactly the set of signals blocked in
> ucontext, which, in this case, is the empty set. I'll just write that ucontext
> is empty.

Yes, or like I say in general it's the the interrupted context (there's
other parts of the signal frame which are changed).

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

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

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmZqubMACgkQJNaLcl1U
h9AXLQf/aNzj6GO0tVDsn4lAZgwmn9+i5bZOPoYs2VUX+xjqGAgxXGaBHZYGTtQv
x6p5xqPIKZMH0IqOL2t6GjyQsvuxFLZqXSiTgTKUpGQBYzt5yG9HtHIWkQdDBelM
3hXcZHCqYaqIh0eDTcJZcrMfHb4QUJIVXqsa1i2/Oz8oJNDVYTs+NeXtO8V5Z9dp
rpJjtQF61pCwH3H6KaBlAUWcy8qnkA+WrwfgIgBU1lG1UFgmUp4FOTadg45JlBne
zKHGSw9N74vmrNfrCxZp6961JbMxDWFRaHOVNlHlwpjkQwJiDHvWcYjED1L+32YO
7Kp1Dq+eoxoW8dmF1uLF3VVYnyXXzg==
=/g6T
-----END PGP SIGNATURE-----

--YUY1zS9czf83kEFd--