linux-kernel - Re: futex code and barriers

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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1209473376.13978.61.camel@twins>
Date:	Tue, 29 Apr 2008 14:49:36 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	Paul E McKenney <paulmck@...ux.vnet.ibm.com>,
	Oleg Nesterov <oleg@...sign.ru>, Nick Piggin <npiggin@...e.de>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: futex code and barriers

On Tue, 2008-04-29 at 14:43 +0200, Jiri Kosina wrote:
> On Tue, 29 Apr 2008, Peter Zijlstra wrote:
> 
> > While looking through the futex code I stumbled upon the following bit:
> > kernel/futex.c:
> > 	/* add_wait_queue is the barrier after __set_current_state. */
> > 	__set_current_state(TASK_INTERRUPTIBLE);
> > 	add_wait_queue(&q.waiters, &wait);
> > However,
> > void add_wait_queue(wait_queue_head_t *q, wait_queue_t *wait)
> > {
> > 	unsigned long flags;
> > 
> > 	wait->flags &= ~WQ_FLAG_EXCLUSIVE;
> > 	spin_lock_irqsave(&q->lock, flags);
> > 	__add_wait_queue(q, wait);
> > 	spin_unlock_irqrestore(&q->lock, flags);
> > }
> [ ... ]
> > Non of which implies a full barrier.
> 
> Well I am probably missing the point, but what about the lock and unlock 
> of the spinlock?

See Documentation/memory-barriers.txt

quoted:

---

 (1) LOCK operation implication:

     Memory operations issued after the LOCK will be completed after the LOCK
     operation has completed.

     Memory operations issued before the LOCK may be completed after the LOCK
     operation has completed.

 (2) UNLOCK operation implication:

     Memory operations issued before the UNLOCK will be completed before the
     UNLOCK operation has completed.

     Memory operations issued after the UNLOCK may be completed before the
     UNLOCK operation has completed.

 (3) LOCK vs LOCK implication:

     All LOCK operations issued before another LOCK operation will be completed
     before that LOCK operation.

 (4) LOCK vs UNLOCK implication:

     All LOCK operations issued before an UNLOCK operation will be completed
     before the UNLOCK operation.

     All UNLOCK operations issued before a LOCK operation will be completed
     before the LOCK operation.

 (5) Failed conditional LOCK implication:

     Certain variants of the LOCK operation may fail, either due to being
     unable to get the lock immediately, or due to receiving an unblocked
     signal whilst asleep waiting for the lock to become available.  Failed
     locks do not imply any sort of barrier.

Therefore, from (1), (2) and (4) an UNLOCK followed by an unconditional LOCK is
equivalent to a full barrier, but a LOCK followed by an UNLOCK is not.

[!] Note: one of the consequences of LOCKs and UNLOCKs being only one-way
    barriers is that the effects of instructions outside of a critical section
    may seep into the inside of the critical section.

A LOCK followed by an UNLOCK may not be assumed to be full memory barrier
because it is possible for an access preceding the LOCK to happen after the
LOCK, and an access following the UNLOCK to happen before the UNLOCK, and the
two accesses can themselves then cross:

        *A = a;
        LOCK
        UNLOCK
        *B = b;

may occur as:

        LOCK, STORE *B, STORE *A, UNLOCK

Locks and semaphores may not provide any guarantee of ordering on UP compiled
systems, and so cannot be counted on in such a situation to actually achieve
anything at all - especially with respect to I/O accesses - unless combined
with interrupt disabling operations.

See also the section on "Inter-CPU locking barrier effects".


As an example, consider the following:

        *A = a;
        *B = b;
        LOCK
        *C = c;
        *D = d;
        UNLOCK
        *E = e;
        *F = f;

The following sequence of events is acceptable:

        LOCK, {*F,*A}, *E, {*C,*D}, *B, UNLOCK

        [+] Note that {*F,*A} indicates a combined access.

But none of the following are:

        {*F,*A}, *B,    LOCK, *C, *D,   UNLOCK, *E
        *A, *B, *C,     LOCK, *D,       UNLOCK, *E, *F
        *A, *B,         LOCK, *C,       UNLOCK, *D, *E, *F
        *B,             LOCK, *C, *D,   UNLOCK, {*F,*A}, *E



--
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/