|Subject:||Re: Lots of bugs with current->state = TASK_*INTERRUPTIBLE|
|From:||David Daney <email@example.com>|
|Date:||Thu, 21 Jan 2010 12:21:45 -0800|
|Cc:||LKML <firstname.lastname@example.org>, kernel-janitors <email@example.com>, Peter Zijlstra <firstname.lastname@example.org>, Andrew Morton <email@example.com>, firstname.lastname@example.org, Greg KH <email@example.com>, Andy Whitcroft <firstname.lastname@example.org>, Ralf Baechle <email@example.com>, linux-mips <firstname.lastname@example.org>|
|References:||<email@example.com> <4B58A89A.firstname.lastname@example.org> <email@example.com> <4B58B1B3.firstname.lastname@example.org> <email@example.com>|
|User-agent:||Thunderbird 220.127.116.11 (X11/20090320)|
This is what I thought.My cpu (Cavium Octeon) does not have out of order reads, so my wmb() isCan you have reads that are out of order wrt writes? Because the above does not have out of order reads. It just had a read that came before a write. The above code could look like: (hypothetical assembly language) ld r2, TASK_UNINTERRUPTIBLE st r2, (current->state) wmb ld r1, (x) cmp r1, 0 Is it possible for the CPU to do the load of r1 before storing r2? If so, then the bug still exists.
Indeed it is. Lockless operations make my head hurt. Thanks for clarifying. David Daney
-- Stevein fact a full mb() from the point of view of the current CPU. So I think I could weaken my bariers in set_current_state() and still get correct operation. However as you say...
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [PATCH 1/3] resources: introduce generic page_is_ram(), Xiaotian Feng|
|Next by Date:||Re: Lots of bugs with current->state = TASK_*INTERRUPTIBLE, David Daney|
|Previous by Thread:||Re: Lots of bugs with current->state = TASK_*INTERRUPTIBLE, Steven Rostedt|
|Next by Thread:||[PATCH 1/3] resources: introduce generic page_is_ram(), Wu Fengguang|
|Indexes:||[Date] [Thread] [Top] [All Lists]|