All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jack Steiner <steiner@sgi.com>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] - Fix memory ordering problem in wake_futex()
Date: Fri, 23 Dec 2005 21:45:04 -0600	[thread overview]
Message-ID: <20051224034504.GC24614@sgi.com> (raw)
In-Reply-To: <43AC78CF.9090407@colorfullife.com>

On Fri, Dec 23, 2005 at 11:23:11PM +0100, Manfred Spraul wrote:
> Jack wrote:
> 
> >On IA64, locks are released using a "st.rel" instruction. This ensures that
> >preceding "stores" are visible before the lock is released but does NOT 
> >prevent
> >a "store" that follows the "st.rel" from becoming visible before the 
> >"st.rel".
> >The result is that the task that owns the futex_q continues prematurely. 
> >
> >The failure I saw is the task that owned the futex_q resumed prematurely 
> >and
> >was context-switch off of the cpu. The task's switch_stack occupied the 
> >same
> >space of the futex_q. The store to q->lock_ptr overwrote the ar.bspstore 
> >in the
> >switch_stack.
> >
> Bad race.
> Unfortuantely the scenario that you describe is quite frequent:
> - autoremove_wake_function()
> - ipc/sem.c (search for IN_WAKEUP)
> - ipc/msg.c appears to be correct, there are smp_wmb() calls.

Yuck. I agree - both of these look incorrect.

Also, I should have used smp_wmb(), not wmb(). Thanks for
pointing that out.

I wonder how many other spots have the same problem. IIRC, we ran into
similar problems in the tty driver a few years ago but I have not
seen any problems recently.

> 
> --
>    Manfred

-- 
Thanks

Jack Steiner (steiner@sgi.com)          651-683-5302
Principal Engineer                      SGI - Silicon Graphics, Inc.



  parent reply	other threads:[~2005-12-24  3:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-23 22:23 [PATCH] - Fix memory ordering problem in wake_futex() Manfred Spraul
2005-12-23 22:52 ` Manfred Spraul
2005-12-24  3:45 ` Jack Steiner [this message]
2005-12-25 16:02   ` Manfred Spraul
  -- strict thread matches above, loose matches on Subject: below --
2005-12-23 16:38 Jack Steiner
2005-12-23 16:38 ` Jack Steiner
2005-12-23 17:05 ` Joe Seigh
2005-12-23 20:48 ` Olof Johansson
2005-12-23 20:48   ` Olof Johansson
2005-12-23 21:32   ` Jack Steiner
2005-12-23 21:32     ` Jack Steiner
2005-12-23 21:59     ` Olof Johansson
2005-12-23 21:59       ` Olof Johansson
2005-12-23 23:48       ` Robin Holt
2005-12-23 23:48         ` Robin Holt
2005-12-24 13:45 ` Jack Steiner
2005-12-24 13:45   ` Jack Steiner
2005-12-24 18:13   ` Olof Johansson
2005-12-24 18:13     ` Olof Johansson
2005-12-27 16:30     ` Jack Steiner
2005-12-27 16:30       ` Jack Steiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051224034504.GC24614@sgi.com \
    --to=steiner@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.