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 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
On Mon, Apr 8, 2013 at 8:07 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Apr 8, 2013 at 7:59 AM, Steven Rostedt srost...@redhat.com wrote:
+/* This is only a barrier to other asms. Notably get_user/put_user */
Probably should add in the comment:
or anything
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 { \
>
>
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
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
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
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
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
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 Mon, Apr 8, 2013 at 7:31 AM, Steven Rostedt srost...@redhat.com 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
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:59 AM, Steven Rostedt srost...@redhat.com 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
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
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
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(),
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(), not
On Sun, Apr 7, 2013 at 9:20 PM, Vineet Gupta vineet.gup...@synopsys.com 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
On Sun, Apr 7, 2013 at 9:20 PM, Vineet Gupta vineet.gup...@synopsys.com 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
] [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,
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
> 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
>
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
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
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,
] [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
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
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
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
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
34 matches
Mail list logo
