All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney@caviumnetworks.com>
To: rostedt@goodmis.org
Cc: LKML <linux-kernel@vger.kernel.org>,
	kernel-janitors <kernel-janitors@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-arch@vger.kernel.org, Greg KH <greg@kroah.com>,
	Andy Whitcroft <apw@canonical.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: Lots of bugs with current->state = TASK_*INTERRUPTIBLE
Date: Thu, 21 Jan 2010 20:21:45 +0000	[thread overview]
Message-ID: <4B58B759.8000002@caviumnetworks.com> (raw)
In-Reply-To: <1264105104.31321.298.camel@gandalf.stny.rr.com>

>>
>> This is what I thought.
>>
>> My cpu (Cavium Octeon) does not have out of order reads, so my wmb() is 
> 
> Can 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



> -- Steve
> 
> 
>> in 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...
>>
> 
> 
> 


WARNING: multiple messages have this Message-ID (diff)
From: David Daney <ddaney@caviumnetworks.com>
To: rostedt@goodmis.org
Cc: LKML <linux-kernel@vger.kernel.org>,
	kernel-janitors <kernel-janitors@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-arch@vger.kernel.org, Greg KH <greg@kroah.com>,
	Andy Whitcroft <apw@canonical.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: Lots of bugs with current->state = TASK_*INTERRUPTIBLE
Date: Thu, 21 Jan 2010 12:21:45 -0800	[thread overview]
Message-ID: <4B58B759.8000002@caviumnetworks.com> (raw)
In-Reply-To: <1264105104.31321.298.camel@gandalf.stny.rr.com>

>>
>> This is what I thought.
>>
>> My cpu (Cavium Octeon) does not have out of order reads, so my wmb() is 
> 
> Can 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



> -- Steve
> 
> 
>> in 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...
>>
> 
> 
> 

  reply	other threads:[~2010-01-21 20:21 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-19 20:29 Lots of bugs with current->state = TASK_*INTERRUPTIBLE Steven Rostedt
2010-01-19 20:29 ` Steven Rostedt
2010-01-19 20:29 ` Steven Rostedt
2010-01-19 20:58 ` Julia Lawall
2010-01-19 20:58   ` Julia Lawall
2010-01-19 21:08   ` Steven Rostedt
2010-01-19 21:08     ` Steven Rostedt
2010-01-21 10:47     ` Julia Lawall
2010-01-21 10:47       ` Julia Lawall
2010-01-21 10:53       ` Frederic Weisbecker
2010-01-21 10:53         ` Frederic Weisbecker
2010-01-21 10:56         ` Peter Zijlstra
2010-01-21 10:56           ` Peter Zijlstra
2010-01-21 10:59           ` Frederic Weisbecker
2010-01-21 10:59             ` Frederic Weisbecker
2010-01-21 17:31       ` Steven Rostedt
2010-01-21 17:31         ` Steven Rostedt
2010-01-21 18:12         ` Julia Lawall
2010-01-21 18:12           ` Julia Lawall
2010-01-21 19:18 ` David Daney
2010-01-21 19:18   ` David Daney
2010-01-21 19:34   ` Steven Rostedt
2010-01-21 19:34     ` Steven Rostedt
2010-01-21 19:57     ` David Daney
2010-01-21 19:57       ` David Daney
2010-01-21 20:18       ` Steven Rostedt
2010-01-21 20:18         ` Steven Rostedt
2010-01-21 20:21         ` David Daney [this message]
2010-01-21 20:21           ` David Daney

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=4B58B759.8000002@caviumnetworks.com \
    --to=ddaney@caviumnetworks.com \
    --cc=akpm@linux-foundation.org \
    --cc=apw@canonical.com \
    --cc=greg@kroah.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=peterz@infradead.org \
    --cc=ralf@linux-mips.org \
    --cc=rostedt@goodmis.org \
    /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.