On 03/12/14 16:21, Alexander Gordeev wrote:
> While 'remote->nr_free' could be dropped on another CPU it still does not
> explain how steal_tags() enters the loop, but fails to locate 'cpus_have_tags'
> count of bits.
>
> So although v2 of your patch fixes the crash it does not address the root
>
On Wed, Mar 12, 2014 at 08:22:22AM +0100, Bart Van Assche wrote:
> On 03/11/14 21:48, Alexander Gordeev wrote:
> > On Tue, Mar 11, 2014 at 07:10:18PM +0100, Bart Van Assche wrote:
> >>> I assume the BUG() above hits? If so, I am failing to understand how
> >>> the code gets here. Mind elaborate?
>
On 03/12/14 09:41, Alexander Gordeev wrote:
> Still the hunk below (a) breaks the 'pool->percpu_max_size' threshold
> and (b) somehow suboptimal, because you wake another thread while a
> free tag was/is on this CPU. If it is still here we would better to
> grab it. If not, it was stolen by
On Wed, Mar 12, 2014 at 08:22:22AM +0100, Bart Van Assche wrote:
> > Function steal_tags() is entered with disabled interrupts and
> > pool->lock taken. Then the 'for' cycle enters/loops while 'cpus_have_tags'
> > is not zero. Which means we can not end up with no set bits at all -
> > and that is
On 03/11/14 21:48, Alexander Gordeev wrote:
> On Tue, Mar 11, 2014 at 07:10:18PM +0100, Bart Van Assche wrote:
>>> I assume the BUG() above hits? If so, I am failing to understand how
>>> the code gets here. Mind elaborate?
>>
>> You are correct, the BUG() mentioned in the call stack in the
>>
On Wed, Mar 12, 2014 at 08:22:22AM +0100, Bart Van Assche wrote:
On 03/11/14 21:48, Alexander Gordeev wrote:
On Tue, Mar 11, 2014 at 07:10:18PM +0100, Bart Van Assche wrote:
I assume the BUG() above hits? If so, I am failing to understand how
the code gets here. Mind elaborate?
You are
On 03/12/14 16:21, Alexander Gordeev wrote:
While 'remote-nr_free' could be dropped on another CPU it still does not
explain how steal_tags() enters the loop, but fails to locate 'cpus_have_tags'
count of bits.
So although v2 of your patch fixes the crash it does not address the root
cause
On 03/11/14 21:48, Alexander Gordeev wrote:
On Tue, Mar 11, 2014 at 07:10:18PM +0100, Bart Van Assche wrote:
I assume the BUG() above hits? If so, I am failing to understand how
the code gets here. Mind elaborate?
You are correct, the BUG() mentioned in the call stack in the
description of
On Wed, Mar 12, 2014 at 08:22:22AM +0100, Bart Van Assche wrote:
Function steal_tags() is entered with disabled interrupts and
pool-lock taken. Then the 'for' cycle enters/loops while 'cpus_have_tags'
is not zero. Which means we can not end up with no set bits at all -
and that is the
On 03/12/14 09:41, Alexander Gordeev wrote:
Still the hunk below (a) breaks the 'pool-percpu_max_size' threshold
and (b) somehow suboptimal, because you wake another thread while a
free tag was/is on this CPU. If it is still here we would better to
grab it. If not, it was stolen by another
On Tue, Mar 11, 2014 at 07:10:18PM +0100, Bart Van Assche wrote:
> > I assume the BUG() above hits? If so, I am failing to understand how
> > the code gets here. Mind elaborate?
>
> Hello Alexander,
>
> You are correct, the BUG() mentioned in the call stack in the
> description of this patch
On 03/11/14 14:51, Alexander Gordeev wrote:
> On Mon, Mar 10, 2014 at 03:12:33PM +0100, Bart Van Assche wrote:
>> Avoid that percpu_ida_alloc() hangs or crashes if there are still
>> tags are available. Wait until a tag becomes available instead of
>> giving up when running out of tags
On Mon, Mar 10, 2014 at 03:12:33PM +0100, Bart Van Assche wrote:
> Avoid that percpu_ida_alloc() hangs or crashes if there are still
> tags are available. Wait until a tag becomes available instead of
> giving up when running out of tags temporarily. This patch fixes
> the following kernel bug:
On Mon, Mar 10, 2014 at 03:12:33PM +0100, Bart Van Assche wrote:
Avoid that percpu_ida_alloc() hangs or crashes if there are still
tags are available. Wait until a tag becomes available instead of
giving up when running out of tags temporarily. This patch fixes
the following kernel bug:
Hi
On 03/11/14 14:51, Alexander Gordeev wrote:
On Mon, Mar 10, 2014 at 03:12:33PM +0100, Bart Van Assche wrote:
Avoid that percpu_ida_alloc() hangs or crashes if there are still
tags are available. Wait until a tag becomes available instead of
giving up when running out of tags temporarily. This
On Tue, Mar 11, 2014 at 07:10:18PM +0100, Bart Van Assche wrote:
I assume the BUG() above hits? If so, I am failing to understand how
the code gets here. Mind elaborate?
Hello Alexander,
You are correct, the BUG() mentioned in the call stack in the
description of this patch does indeed
16 matches
Mail list logo