Re: [PATCH v2 4/4] copy_signal cleanup: clean tty_audit_fork()

Re: [PATCH v2 4/4] copy_signal cleanup: clean tty_audit_fork()

[Miloslav Trmac]

----- "Oleg Nesterov" <oleg@redhat.com> wrote:
> On 12/05, Miloslav Trmac wrote:
> > > Off-topic question to this who understands this code.
> > >
> > > But afaics we can also remove ->siglock from this helper and make
> > > it really trivial for being inline. ->siglock buys nothing, we just
> > > read a boolean. In fact, after the quick grep I do not understand
> > > how ->siglock is connected to ->audit_tty. OK, it protects
> > > tty_audit_buf,
> > > but why we always take ->siglock to access ->audit_tty ?
> > AFAIK there is no explicit documentation of the atomicity semantics
> > expected by the Linux kernel (both from the hardware and from the compiler),
> > so every access to the boolean is protected by a lock, to be on the safe side.
> 
> Not sure I understand, but the kernel relies on fact it is always safe
> to load/store a word.
And is "word" an "unsigned", "unsigned long" or "intptr_t"?  Must it be suitably aligned, and if so, what is "suitably"?  Where is this documented?  

> What atomicity semantics do you mean and how ->siglock can help?
At the very least, "any access will read the last value stored and not result in undefined behavior, even if other threads attempt to access the value".  In user-space, per POSIX, the only way to guarantee this is using explicit synchronization primitives.

> I believe every spin_lock(siglock) around ->audit_tty is bogus.
It might very well be.  Again, I just wanted to be sure, given my limited understanding of the Linux memory model assumptions.
    Mirek

Re: [PATCH v2 4/4] copy_signal cleanup: clean tty_audit_fork()

[Oleg Nesterov]

On 12/06, Miloslav Trmac wrote:
>
> ----- "Oleg Nesterov" <oleg@redhat.com> wrote:
> > On 12/05, Miloslav Trmac wrote:
> > > > Off-topic question to this who understands this code.
> > > >
> > > > But afaics we can also remove ->siglock from this helper and make
> > > > it really trivial for being inline. ->siglock buys nothing, we just
> > > > read a boolean. In fact, after the quick grep I do not understand
> > > > how ->siglock is connected to ->audit_tty. OK, it protects
> > > > tty_audit_buf,
> > > > but why we always take ->siglock to access ->audit_tty ?
> > > AFAIK there is no explicit documentation of the atomicity semantics
> > > expected by the Linux kernel (both from the hardware and from the compiler),
> > > so every access to the boolean is protected by a lock, to be on the safe side.
> >
> > Not sure I understand, but the kernel relies on fact it is always safe
> > to load/store a word.
> And is "word" an "unsigned", "unsigned long" or "intptr_t"?  Must it be
> suitably aligned, and if so, what is "suitably"?

Sure, it must be aligned.

> Where is this documented?

Perhaps nowhere, I do not know. If this is not documented, probably
it would be nice to add a note.

> > What atomicity semantics do you mean and how ->siglock can help?
> At the very least, "any access will read the last value stored and not result
> in undefined behavior, even if other threads attempt to access the value".
> In user-space, per POSIX, the only way to guarantee this is using explicit
> synchronization primitives.

We have numerous examples in kernel code which rely on this fact.

If we are talking about copy_process() pathes, please look at, say,
sched_fork(). Say, we read current->normal_prio lockless, while another
thread could change ->normal_prio in parallel.

Oleg.

Re: [PATCH v2 4/4] copy_signal cleanup: clean tty_audit_fork()

[Oleg Nesterov]

On 12/05, Miloslav Trmac wrote:
>
> ----- "Oleg Nesterov" <oleg@redhat.com> wrote:
> > On 12/04, Veaceslav Falico wrote:
> > > diff --git a/drivers/char/tty_audit.c b/drivers/char/tty_audit.c
> > > index ac16fbe..283a15b 100644
> > > --- a/drivers/char/tty_audit.c
> > > +++ b/drivers/char/tty_audit.c
> > > @@ -148,7 +148,6 @@ void tty_audit_fork(struct signal_struct *sig)
> > >  	spin_lock_irq(&current->sighand->siglock);
> > >  	sig->audit_tty = current->signal->audit_tty;
> > >  	spin_unlock_irq(&current->sighand->siglock);
> > > -	sig->tty_audit_buf = NULL;
> > >  }
> >
> > Off-topic question to this who understands this code.
> >
> > But afaics we can also remove ->siglock from this helper and make
> > it really trivial for being inline. ->siglock buys nothing, we just
> > read a boolean. In fact, after the quick grep I do not understand
> > how ->siglock is connected to ->audit_tty. OK, it protects
> > tty_audit_buf,
> > but why we always take ->siglock to access ->audit_tty ?
> AFAIK there is no explicit documentation of the atomicity semantics
> expected by the Linux kernel (both from the hardware and from the compiler),
> so every access to the boolean is protected by a lock, to be on the safe side.

Not sure I understand, but the kernel relies on fact it is always safe
to load/store a word.

What atomicity semantics do you mean and how ->siglock can help? Sure,
we can race with AUDIT_TTY_SET, but this can happen with or without
this lock. This "race" is unavoidable and harmless.

I believe every spin_lock(siglock) around ->audit_tty is bogus.

Oleg.

Re: [PATCH v2 4/4] copy_signal cleanup: clean tty_audit_fork()

[Miloslav Trmac]

----- "Oleg Nesterov" <oleg@redhat.com> wrote:
> On 12/04, Veaceslav Falico wrote:
> > diff --git a/drivers/char/tty_audit.c b/drivers/char/tty_audit.c
> > index ac16fbe..283a15b 100644
> > --- a/drivers/char/tty_audit.c
> > +++ b/drivers/char/tty_audit.c
> > @@ -148,7 +148,6 @@ void tty_audit_fork(struct signal_struct *sig)
> >  	spin_lock_irq(&current->sighand->siglock);
> >  	sig->audit_tty = current->signal->audit_tty;
> >  	spin_unlock_irq(&current->sighand->siglock);
> > -	sig->tty_audit_buf = NULL;
> >  }
> 
> Off-topic question to this who understands this code.
> 
> But afaics we can also remove ->siglock from this helper and make
> it really trivial for being inline. ->siglock buys nothing, we just
> read a boolean. In fact, after the quick grep I do not understand
> how ->siglock is connected to ->audit_tty. OK, it protects
> tty_audit_buf,
> but why we always take ->siglock to access ->audit_tty ?
AFAIK there is no explicit documentation of the atomicity semantics expected by the Linux kernel (both from the hardware and from the compiler), so every access to the boolean is protected by a lock, to be on the safe side.
    Mirek

Re: [PATCH v2 4/4] copy_signal cleanup: clean tty_audit_fork()

[Oleg Nesterov]

On 12/04, Veaceslav Falico wrote:
>
> Remove unneeded initialization in tty_audit_fork().
> It is called only via copy_signal() and is useless after
> the kmem_cache_zalloc() was used.
>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
> ---
>
> diff --git a/drivers/char/tty_audit.c b/drivers/char/tty_audit.c
> index ac16fbe..283a15b 100644
> --- a/drivers/char/tty_audit.c
> +++ b/drivers/char/tty_audit.c
> @@ -148,7 +148,6 @@ void tty_audit_fork(struct signal_struct *sig)
>  	spin_lock_irq(&current->sighand->siglock);
>  	sig->audit_tty = current->signal->audit_tty;
>  	spin_unlock_irq(&current->sighand->siglock);
> -	sig->tty_audit_buf = NULL;
>  }

Can't comment the changes in audit code, but the patch looks obviously
correct.



Off-topic question to this who understands this code.

But afaics we can also remove ->siglock from this helper and make
it really trivial for being inline. ->siglock buys nothing, we just
read a boolean. In fact, after the quick grep I do not understand
how ->siglock is connected to ->audit_tty. OK, it protects tty_audit_buf,
but why we always take ->siglock to access ->audit_tty ?

Oleg.

[PATCH v2 4/4] copy_signal cleanup: clean tty_audit_fork()

[Veaceslav Falico]

Remove unneeded initialization in tty_audit_fork().
It is called only via copy_signal() and is useless after
the kmem_cache_zalloc() was used.

Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
---

diff --git a/drivers/char/tty_audit.c b/drivers/char/tty_audit.c
index ac16fbe..283a15b 100644
--- a/drivers/char/tty_audit.c
+++ b/drivers/char/tty_audit.c
@@ -148,7 +148,6 @@ void tty_audit_fork(struct signal_struct *sig)
 	spin_lock_irq(&current->sighand->siglock);
 	sig->audit_tty = current->signal->audit_tty;
 	spin_unlock_irq(&current->sighand->siglock);
-	sig->tty_audit_buf = NULL;
 }
 
 /**