On Tue, 2013-04-09 at 07:32 -0700, Linus Torvalds wrote:
> Something like the attached (still untested, although it seems to at
> least compile) patch. Comments?
Yes, makes me feel far more comfortable than this "asm volatile"
business (which as you noted has holes in it).
--
To unsubscribe from
On Mon, Apr 8, 2013 at 8:07 AM, Linus Torvalds
wrote:
> On Mon, Apr 8, 2013 at 7:59 AM, Steven Rostedt wrote:
>>> +/* This is only a barrier to other asms. Notably get_user/put_user */
>>
>> Probably should add in the comment:
>>
>> " or anything else that can cause a hidden schedule.
On Mon, Apr 8, 2013 at 7:59 AM, Steven Rostedt wrote:
>> +/* This is only a barrier to other asms. Notably get_user/put_user */
>
> Probably should add in the comment:
>
> " or anything else that can cause a hidden schedule. "
>
Fair enough. And I just remembered why I thought UP was
On Mon, 2013-04-08 at 07:50 -0700, Linus Torvalds wrote:
> ---
> diff --git a/include/linux/preempt.h b/include/linux/preempt.h
> index 5a710b9c578e..465df1c13386 100644
> --- a/include/linux/preempt.h
> +++ b/include/linux/preempt.h
> @@ -93,14 +93,17 @@ do { \
>
> #else
On Mon, Apr 8, 2013 at 7:31 AM, Steven Rostedt wrote:
>
> It requires gcc reordering the code to where a preempt can happen inside
> preempt_disable. And also put in a position where the preempt_disable
> code it gets added matters.
>
> Then if gcc does this, we need a page fault to occur with a g
On Mon, 2013-04-08 at 15:37 +0200, Peter Zijlstra wrote:
> That said, I can't remember ever having seen a BUG like this, even
> though !PREEMPT is (or at least was) the most popular distro setting.
It requires gcc reordering the code to where a preempt can happen inside
preempt_disable. And also
On Sun, 2013-04-07 at 21:48 -0700, Linus Torvalds wrote:
> Ingo? Peter? I'm not sure anybody really uses UP+no-preempt on x86,
> but it does seem to be a bug.. Comments?
I believe a lot of people still use no-preempt. Well, at least voluntary
preemption, which would have the same bug.
I'm thinki
On Sun, 2013-04-07 at 21:48 -0700, Linus Torvalds wrote:
> That said, thinking about barriers and preemption made me realize that
> we do have a potential issue between: (a) non-preemption UP kernel
> (with no barriers in the preempt_enable/disable()) and (b)
> architectures that use inline asm wit
On Sun, Apr 7, 2013 at 9:20 PM, Vineet Gupta wrote:
>
> Would you be OK if I send the single patch to ARC by email (for 3.9-rc7) or
> you'd
> rather have the pull request.
I got distracted by thinking about user-accesses vs preemption, but
yes, sending the ARC patch to fix things by email as a p
On Sun, Apr 7, 2013 at 9:20 PM, Vineet Gupta wrote:
>
> Christian had already proposed that change - only I was reluctant to take it
> - as
> local_irq_* is used heavily in a configuration of ARC700 linux where (!SMP)
> cpu
> doesn't support load-locked/store-conditional instructions - hence ato
Hi Linus,
On 04/06/2013 09:43 PM, Linus Torvalds wrote:
> This is all *COMPLETELY* wrong.
>
> Neither the normal preempt macros, nor the plain spinlocks, should
> protect anything at all against interrupts.
>
> The real protection should come from the spin_lock_irqsave() in
> lock_timer_base(), n
] [PATCH] Gaurantee spinlocks implicit barrier for
!PREEMPT_COUNT
Looking around, it looks like c6x has the same bug.
Some other architectures (tile) have such subtle implementations (where is
__insn_mtspr() defined?) that I have a hard time judging.
And maybe I missed something, but the rest seem ok
Looking around, it looks like c6x has the same bug.
Some other architectures (tile) have such subtle implementations
(where is __insn_mtspr() defined?) that I have a hard time judging.
And maybe I missed something, but the rest seem ok.
Linus
On Sat, Apr 6, 2013 at 9:13 AM, Linus
This is all *COMPLETELY* wrong.
Neither the normal preempt macros, nor the plain spinlocks, should
protect anything at all against interrupts.
The real protection should come from the spin_lock_irqsave() in
lock_timer_base(), not from spinlocks, and not from preemption.
It sounds like ARC is co
> On 04/05/2013 10:06 AM, Vineet Gupta wrote:
> Hi Thomas,
>
> Given that we are closing on 3.9 release, and that one/more of these patches
> fix a
> real issue for us - can you please consider my earlier patch to fix
> timer_pending() only for 3.9
> [http://www.spinics.net/lists/kernel/msg15082
Hi Thomas,
On 04/04/2013 08:58 PM, Christian Ruppert wrote:
> Hi Vineet,
>
> Our stress testing campaign has just successfully completed on this
> patch. It seems to solve several issues we have seen in unpatched
> versions, amongst others the original timer issue, a crash in hrtimer
> rb-tree man
Hi Vineet,
Our stress testing campaign has just successfully completed on this
patch. It seems to solve several issues we have seen in unpatched
versions, amongst others the original timer issue, a crash in hrtimer
rb-tree manipulation etc.
Greetings,
Christian
On Wed, Apr 03, 2013 at 07:41:22
spinlocks built in a !PREEMPT_COUNT config don't have the compiler
barrier provided by preempt_* routines. This can break lot of code which
relies on barrier semantics.
This manifested as random crashes in timer code when stress testing
ARC Linux (3.9-rc3): !SMP && !PREEMPT_COUNT
Here's the exact
18 matches
Mail list logo