Re: Oops in percpu_modalloc in 2.6.9-rc1-mm1

[Rusty Russell <rusty@rustcorp.com.au>]

On Thu, 2004-09-02 at 16:35, Pete Zaitcev wrote:
> On Wed, 01 Sep 2004 15:21:45 +1000
> Rusty Russell <rusty@rustcorp.com.au> wrote:
> 
> > Pete, can you figure out what module it is which goes boom, send me the
> > .ko file, and tell me the value of CONFIG_X86_L1_CACHE_SHIFT?
> 
> Two modules have percpu data segment: net/ipv4/netfilter/ipchains.o
> and net/ipv4/netfilter/ip_conntrack_core.o.
> The CONFIG_X86_L1_CACHE_SHIFT is 4.

...

>  12 .data         000006e4  00000000  00000000  0000ba20  2**5
>                   CONTENTS, ALLOC, LOAD, RELOC, DATA
>  13 .data.percpu  0000003c  00000000  00000000  0000c120  2**5
>                   CONTENTS, ALLOC, LOAD, DATA

Well, here's the problem.  alloc_bootmem will return something
SMP_CACHE_BYTES aligned, so we can't meet this.  If we knew in advance
what the alignment requirements were, we could do so.

Note also, that archs currently use vmalloc() or variants for
module_alloc, but they could easily use kmalloc() for small sizes.  This
would make your life painful, since kmalloc() also returns L1
cache-aligned memory.

I'd suggest that for a 486 configuration, GCC shouldn't be asking for
32-byte alignment for anything.  Still, we probably have to remove the
BUG_ON and simply accept that alignment > SMP_CACHE_BYTES is actually
taking pot luck (depends if the original allocation was aligned).

Rusty.
-- 
Anyone who quotes me in their signature is an idiot -- Rusty Russell