Re: system lockup with 2.6.29 on Cavium/Octeon

[Greg Ungerer <gerg@snapgear.com>]

Hi Atsushi,

Atsushi Nemoto wrote:
> On Wed, 20 May 2009 15:26:04 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
>>> Now the vmalloc area starts at 0xc000000000000000 and the kernel code
>>> and data is all at 0xffffffff80000000 and above. I don't know if the
>>> start and end are reasonable values, but I can see some logic as to
>>> where they come from. The code path that leads to this is via
>>> __vunmap() and __purge_vmap_area_lazy(). So it is not too difficult
>>> to see how we end up with values like this.
>> Either start or end address is sensible but not the combination - both
>> addresses should be in the same segment.  Start is in XKSEG, end in CKSEG2
>> and in between there are vast wastelands of unused address space exabytes
>> in size.
>>
>>> But the size calculation above with these types of values will result
>>> in still a large number. Larger than the 32bit "int" that is "size".
>>> I see large negative values fall out as size, and so the following
>>> tlbsize check becomes true, and the code spins inside the loop inside
>>> that if statement for a _very_ long time trying to flush tlb entries.
>>>
>>> This is of course easily fixed, by making that size "unsigned long".
>>> The patch below trivially does this.
>>>
>>> But is this analysis correct?
>> Yes - but I think we have two issues here.  The one is the calculation
>> overflowing int for the arguments you're seeing.  The other being that
>> the arguments simply are looking wrong.
> 
> The wrong combination comes from lazy vunmapping which was introduced
> in 2.6.28 cycle.  Maybe we can add new API (non-lazy version of
> vfree()) to vmalloc.c to implement module_free(), but I suppose
> fallbacking to local_flush_tlb_all() in local_flush_tlb_kernel_range()
> is enough().

Is there any performance impact on falling back to that?

The flushing due to lazy vunmapping didn't seem to happen
often in the tests I was running.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com