Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-12 Thread Bart Van Assche
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 >

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-12 Thread Alexander Gordeev
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? >

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-12 Thread Bart Van Assche
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

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-12 Thread Alexander Gordeev
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

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-12 Thread Bart Van Assche
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 >>

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-12 Thread Alexander Gordeev
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

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-12 Thread Bart Van Assche
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

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-12 Thread Bart Van Assche
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

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-12 Thread Alexander Gordeev
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

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-12 Thread Bart Van Assche
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

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-11 Thread Alexander Gordeev
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

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-11 Thread Bart Van Assche
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

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-11 Thread Alexander Gordeev
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:

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-11 Thread Alexander Gordeev
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

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-11 Thread Bart Van Assche
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

Re: [PATCH] percpu_ida: Handle out-of-tags gracefully

2014-03-11 Thread Alexander Gordeev
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