On Fri, 27 Nov 2015, Jiang Liu wrote:
Please trim your replies.
> On 2015/11/26 5:12, Thomas Gleixner wrote:
> > Looks a bit overkill with the extra cpumask. I tried a simple counter
> > but that does not work versus cpu unplug as we do not know whether the
> > outgoing cpu is involved in the
On 2015/11/26 5:12, Thomas Gleixner wrote:
> On Wed, 25 Nov 2015, Thomas Gleixner wrote:
>> So if CPU1 gets the IPI _BEFORE_ move_in_progress is set to 0, and
>> does not get another IPI before the next move . That has been that
>> way forever.
>>
>> Duh. Working on a real fix this time.
>
On 2015/11/26 5:12, Thomas Gleixner wrote:
> On Wed, 25 Nov 2015, Thomas Gleixner wrote:
>> So if CPU1 gets the IPI _BEFORE_ move_in_progress is set to 0, and
>> does not get another IPI before the next move . That has been that
>> way forever.
>>
>> Duh. Working on a real fix this time.
>
On Fri, 27 Nov 2015, Jiang Liu wrote:
Please trim your replies.
> On 2015/11/26 5:12, Thomas Gleixner wrote:
> > Looks a bit overkill with the extra cpumask. I tried a simple counter
> > but that does not work versus cpu unplug as we do not know whether the
> > outgoing cpu is involved in the
On 11/25/2015 04:12 PM, Thomas Gleixner wrote:
On Wed, 25 Nov 2015, Thomas Gleixner wrote:
So if CPU1 gets the IPI _BEFORE_ move_in_progress is set to 0, and
does not get another IPI before the next move . That has been that
way forever.
Duh. Working on a real fix this time.
Here you go.
On Wed, 25 Nov 2015, Thomas Gleixner wrote:
> So if CPU1 gets the IPI _BEFORE_ move_in_progress is set to 0, and
> does not get another IPI before the next move . That has been that
> way forever.
>
> Duh. Working on a real fix this time.
Here you go. Completely untested of course.
Larger
On Wed, 25 Nov 2015, Thomas Gleixner wrote:
> The problem is actually in the vector assignment code.
>
> > [001]22.936764: __assign_irq_vector : cpu 44 : vector=134 ->
> > 0x88102a8196f8
>
> No interrupt happened so far. So nothing cleans up the vector on cpu 1
>
> > [044]
Joe,
On Mon, 23 Nov 2015, Joe Lawrence wrote:
Nice detective work!
> The irq_desc is in R15: 88102a8196f8
>
> This irq_desc is no longer allocated, it's been filled with the slub debug
> poison pattern (hence the spinlock is stuck):
>
> The irq vector is in RBX: 0091
>
> But
Joe,
On Mon, 23 Nov 2015, Joe Lawrence wrote:
Nice detective work!
> The irq_desc is in R15: 88102a8196f8
>
> This irq_desc is no longer allocated, it's been filled with the slub debug
> poison pattern (hence the spinlock is stuck):
>
> The irq vector is in RBX: 0091
>
> But
On Wed, 25 Nov 2015, Thomas Gleixner wrote:
> The problem is actually in the vector assignment code.
>
> > [001]22.936764: __assign_irq_vector : cpu 44 : vector=134 ->
> > 0x88102a8196f8
>
> No interrupt happened so far. So nothing cleans up the vector on cpu 1
>
> > [044]
On 11/25/2015 04:12 PM, Thomas Gleixner wrote:
On Wed, 25 Nov 2015, Thomas Gleixner wrote:
So if CPU1 gets the IPI _BEFORE_ move_in_progress is set to 0, and
does not get another IPI before the next move . That has been that
way forever.
Duh. Working on a real fix this time.
Here you go.
On Wed, 25 Nov 2015, Thomas Gleixner wrote:
> So if CPU1 gets the IPI _BEFORE_ move_in_progress is set to 0, and
> does not get another IPI before the next move . That has been that
> way forever.
>
> Duh. Working on a real fix this time.
Here you go. Completely untested of course.
Larger
Hi Thomas,
I've been chasing down a use-after-free on an irq_desc structure during
repeated device removal testing that crashes 4.3 in
smp_irq_move_cleanup_interrupt. So far I have a bunch of crashes and some
data gleaned from instrumenting the kernel with trace logging. Details to
follow, but
Hi Thomas,
I've been chasing down a use-after-free on an irq_desc structure during
repeated device removal testing that crashes 4.3 in
smp_irq_move_cleanup_interrupt. So far I have a bunch of crashes and some
data gleaned from instrumenting the kernel with trace logging. Details to
follow, but
14 matches
Mail list logo
