Andy Whitcroft wrote: > Andy Whitcroft wrote: >> Getting a link failure on a ppc64 system: >> >> LD .tmp_vmlinux1 >> init/built-in.o(.init.text+0x32e4): In function `.rd_load_image': >> : undefined reference to `.__kmalloc_size_too_large' >> fs/built-in.o(.text+0xa6fe0): In function `.ext3_fill_super': >> : undefined reference to `.__kmalloc_size_too_large' >> fs/built-in.o(.text+0xc1fe0): In function `.ext2_fill_super': >> : undefined reference to `.__kmalloc_size_too_large' >> fs/built-in.o(.text+0xf6a1c): In function `.nfs4_proc_lookup': >> : undefined reference to `.__kmalloc_size_too_large' >> fs/built-in.o(.text+0x104104): In function `.nfs_idmap_new': >> : undefined reference to `.__kmalloc_size_too_large' >> fs/built-in.o(.text+0x105520): more undefined references to >> `.__kmalloc_size_too_large' follow >> make: *** [.tmp_vmlinux1] Error 1 > > Ok, this is a SLUB related link failure. Am investigating if PPC simply > needs larger allocs and needs CONFIG_LARGE_ALLOCS, of if this is an > inlining issue.
Ok this is confirmed as an inlining issue. With the compiler below on ppc64 we get the above link failure: gcc version 3.3.3 (SuSE Linux) What seems to happen is that although the optimiser is capable of collapsing the kmalloc_index() call it then fails to collapse kmalloc_slab(). This leads to the never used reference to __kmalloc_size_too_large() and the link failure. From my testing this seems to occur at sizes >= 32k. At 16k all of the code collapses correctly, at 32k it does not. I am not entirely sure what to think at this point, it is cirtainly not at all clear why the 32k version fails and the 16k succeeds they are almost identical. Either way it seems to me that assuming the optimiser will remove the code is perhaps over optimistic. Perhaps it would make more sense to put a BUG() in here. Though that points out the anomaly that the kmalloc() for constants has different semantics to that for variable values? Comments? -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
