Hello,
On 03/05/2010 03:09 PM, Tejun Heo wrote:
> On 03/05/2010 03:08 PM, Tejun Heo wrote:
>> Hmmm... this means that on one of the chunks, chunk->list.next was
>> NULL (BTW, the disassembly is from unlinked object, right?). The main
>> allocation code hasn't seen much change lately. The only changes are,
>>
>> 22b737f4c75197372d64afc6ed1bccd58c00e549 : just refactoring
>> 833af8427be4b217b5bc522f61afdbd3f1d282c2 : possible but isn't very new
>
> Can you also please try reverting the above two commits?
Sorry about all the fuss but I think this could be it. It looks like
I forgot to update need_to_extend logic while adding simultaneous
head/tail split for alignment, so the array might be overrun by one
entry. Can you please try this one first?
Thanks.
diff --git a/mm/percpu.c b/mm/percpu.c
index 768419d..f1ed9ea 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -373,11 +373,11 @@ static int pcpu_need_to_extend(struct pcpu_chunk *chunk)
{
int new_alloc;
- if (chunk->map_alloc >= chunk->map_used + 2)
+ if (chunk->map_alloc >= chunk->map_used + 3)
return 0;
new_alloc = PCPU_DFL_MAP_ALLOC;
- while (new_alloc < chunk->map_used + 2)
+ while (new_alloc < chunk->map_used + 3)
new_alloc *= 2;
return new_alloc;
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
