linux-kernel - Re: [PATCH v2 4/4] copy_signal cleanup: clean tty_audit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 6 Dec 2009 10:17:50 -0500 (EST)
From:	Miloslav Trmac <mitr@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	linux-kernel@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>,
	Al Viro <viro@...iv.linux.org.uk>,
	James Morris <jmorris@...ei.org>,
	Alan Cox <alan@...ux.intel.com>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Renaud Lottiaux <renaud.lottiaux@...labs.com>,
	Louis Rilling <louis.rilling@...labs.com>,
	David Howells <dhowells@...hat.com>,
	Stanislaw Gruszka <sgruszka@...hat.com>,
	Veaceslav Falico <vfalico@...hat.com>
Subject: Re: [PATCH v2 4/4] copy_signal cleanup: clean tty_audit_fork()

----- "Oleg Nesterov" <oleg@...hat.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/