MIPS ASID type conflicts

MIPS ASID type conflicts

[Jean-Christophe PINCE]

Hi,

I am analyzing Linux MIPS tasks memory spaces and found out what I
think is a bug in the ASID management.

The structure "struct cpuinfo_mips" defined in
arch/mips/include/asm/cpu-info.h uses a "unsigned int" field for
asid_cache while the context field defined in
arch/mips/include/asm/mmu.h is a "unsigned long".

This is ok with 32bits kernel but leads to 4bytes vs 8bytes fields
with a 64bits kernel. And when the scheduler checks if the ASID is of
an older ASID_VERSION, the test will always return that the version
differs when the context bits above bit31 will be set.

I imagine this should be a quite rare issue but could likely happen on
devices running for very long and starting processes very often (or
running more than 256 processes per cpu). When this condition (bit 32
or above of asid_cache is set), the effect should be that the TLB will
be flushed on each context_switch required by the scheduler but there
shouldn't be any crash.

Hope this helps,
Thanks and regards,
JC

Re: MIPS ASID type conflicts

[Ralf Baechle]

On Mon, Apr 23, 2012 at 01:49:26PM +0200, Jean-Christophe PINCE wrote:

> I am analyzing Linux MIPS tasks memory spaces and found out what I
> think is a bug in the ASID management.
> 
> The structure "struct cpuinfo_mips" defined in
> arch/mips/include/asm/cpu-info.h uses a "unsigned int" field for
> asid_cache while the context field defined in
> arch/mips/include/asm/mmu.h is a "unsigned long".
> 
> This is ok with 32bits kernel but leads to 4bytes vs 8bytes fields
> with a 64bits kernel. And when the scheduler checks if the ASID is of
> an older ASID_VERSION, the test will always return that the version
> differs when the context bits above bit31 will be set.
> 
> I imagine this should be a quite rare issue but could likely happen on
> devices running for very long and starting processes very often (or
> running more than 256 processes per cpu). When this condition (bit 32
> or above of asid_cache is set), the effect should be that the TLB will
> be flushed on each context_switch required by the scheduler but there
> shouldn't be any crash.

A full flush of the TLB can be implemented by picking a fresh ASID as
long as there are still fresh ASIDs available.  This happens fairly
frequently; a typical system has burned through the first 256 ASIDs
somewhen during bootup.

There is not much advantage to be gained from having the ASID and generation
counter in a 64-bit variable so I think I'm just going to change
mmu_context_t to:

typedef struct {
        unsigned int asid[NR_CPUS];
        void *vdso;
} mm_context_t;

  Ralf