Control: tags -1 + moreinfo
Hi James,
On Thu, Oct 05, 2017 at 03:24:12PM +0100, James Cowgill wrote:
> Source: linux
> Version: 4.12.13-1
> Severity: normal
>
> Hi,
>
> I recently attempted to install an out-of-tree module (an old version of
> the octeon mmc driver) on an octeon machine running big endian 32-bit
> mips. In this configuration, the kernel is 64-bit, but userspace is 32-bit.
>
> The module build failed with this error:
> > LD [M] /var/lib/dkms/octeon-mmc/9/build/octeon-mmc.o
> > Building modules, stage 2.
> > MODPOST 1 modules
> > FATAL: /var/lib/dkms/octeon-mmc/9/build/octeon-mmc: sizeof(struct
> > of_device_id)=196 is not a modulo of the size of section
> > __mod_of__<identifier>_device_table=600.
> > Fix definition of struct of_device_id in mod_devicetable.h
>
> of_device_id is defined like this in mod_devicetable.h:
> > struct of_device_id {
> > char name[32];
> > char type[32];
> > char compatible[128];
> > const void *data;
> > };
>
> The size of this structure is 200 bytes and not 196 byte as modpost
> claims because the kernel is compiled as 64-bit (so the pointer at the
> end is 8 bytes instead of 4).
>
> I think there is a bug in the way Debian compiles modpost, because using
> upstream's modpost works correctly. I see that the
> real-XXX/devicetable-offsets.s file gets compiled with the target
> compiler, but not with the target flags so flags such as "-mabi=64
> -mnoabicalls" which are used in 64-bit MIPS kernels are not used. This
> will cause the compiler to default to the userspace ABI which is 32-bit
> in this case.
>
> I'm not sure what the correct solution is here. Using the target flags
> directly might make modpost specific to a kernel flavour. Hacking in
> some special flags for mips* doesn't sound great either.
>
> I have not tested any other platforms, but I am guessing this issue will
> affect other platforms when the size of pointers in userspace and the
> kernel differ.
Going through some older bugreports for src:linux found the above; Is
this still an issue? I have not digged deeper at all.
Regards,
Salvatore
