Re: [PATCH] signal handlers: volatile sigatomic_t, not volatile OR sigatomic_t

["Paul E. McKenney" <paulmck@kernel.org>]

On Wed, Mar 20, 2024 at 08:25:23PM +0000, Guilherme Janczak wrote:
> Variables shared with signal handlers must be of type `volatile
> sigatomic_t`, not `volatile` or `sigatomic_t` as the current text says,
> according to a C11 draft:
> 
>     When ... interrupted by ... a signal, values of objects that are
>     neither lock-free atomic objects nor of type volatile sig_atomic_t
>     are unspecified.
> 
> Ref: https://www.iso-9899.info/n1570.html#5.1.2.3p5
> Signed-off-by: Guilherme Janczak <guilherme.janczak@yandex.com>
> ---
>  memorder/memorder.tex | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/memorder/memorder.tex b/memorder/memorder.tex
> index 5c50d42d..873c3424 100644
> --- a/memorder/memorder.tex
> +++ b/memorder/memorder.tex
> @@ -1317,8 +1317,8 @@ from the viewpoint of the interrupted thread, at least at the
>  assembly-language level.
>  However, the C and C++ languages do not define the results of handlers
>  and interrupted threads sharing plain variables.
> -Instead, such shared variables must be \co{sig_atomic_t}, lock-free
> -atomics, or \co{volatile}.
> +Instead, such shared variables must be \co{volatile sig_atomic_t} or
> +lock-free atomics.

You might be right about "sig_atomic_t" needing to also be "volatile"
(I will let you and Elad settle your differences on this one), but if
device drivers are to work correctly, then volatile variables that are
machine-word sized and aligned must necessarily work for communication
between process-level code and interrupt/signal handlers.

							Thanx, Paul

>  On the other hand, because the handler executes within the interrupted
>  thread's context, the memory ordering used to synchronize communication
> -- 
> 2.42.0
> 
>