[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87lijns84s.fsf@nemi.mork.no>
Date: Sat, 16 Jun 2012 15:23:31 +0200
From: Bjørn Mork <bjorn@...k.no>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
USB list <linux-usb@...r.kernel.org>,
linux-kernel@...r.kernel.org,
Linux-Next <linux-next@...r.kernel.org>,
linux-kbuild <linux-kbuild@...r.kernel.org>,
Linux/m68k <linux-m68k@...r.kernel.org>
Subject: Re: [-next] FATAL: drivers/gpu/drm/udl/udl: sizeof(struct usb_device_id)=24 is not a modulo of the size of section __mod_usb_device_table=44.
Greg Kroah-Hartman <gregkh@...uxfoundation.org> writes:
> On Fri, Jun 15, 2012 at 11:02:55PM +0200, Geert Uytterhoeven wrote:
>
>> As "kernel_ulong_t driver_info" is no longer naturally aligned, the
>> compiler will
>> add implicit padding. But the padding depends on the architecture.
>
> Ah, so we were "lucky" before, nice.
I don't really believe in luck :-) I think someone has been really
smart here. Maybe too smart...
>> It can be fixed by adding explicit padding. Probably it should be padded by
>> 7 bytes (not 3), as kernel_ulong_t may require 8-byte alignment on some 64-bit
>> platforms. Or by an explicit alignment attribute.
>>
>> See also
>> * commit 8175fe2dda1c93a9c596921c8ed4a0b4baccdefe ("HID: fix
>> hid_device_id for cross compiling")
>> * commit 7492d4a416d68ab4bd254b36ffcc4e0138daa8ff ("sdio: fix module
>> device table definition for m68k")
>> * commit 9e2d3cd34a159948dc753a14573e16bffc04dba8 ("[PATCH]
>> mod_devicetable.h fixes")
>
> So would the patch below fix this? It should force alignment of the
> driver_data field, which is all you want here, right?
>
>> Still, there's a bug in file2alias (which is compiled by the host
>> compiler), in that
>> it may use different padding than the target platform when cross-compiling.
>
> That's not good, but outside of this specific issue, right? Have we
> just been fortunate it hasn't really hit us yet?
>
> thanks,
>
> greg k-h
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 7771d45..6955045 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -122,7 +122,8 @@ struct usb_device_id {
> __u8 bInterfaceNumber;
>
> /* not matched against */
> - kernel_ulong_t driver_info;
> + kernel_ulong_t driver_info
> + __attribute__((aligned(sizeof(kernel_ulong_t))));
> };
This feels a lot like papering over the real problem. It will solve
this instance, but the list of such previous "paper work" that Geert
provided should be enough evidence that this will happen again the next
time someone modifies a device id struct for some subsystem.
And adding forced aligment here feels wrong since there is no good
reason why the (target) compiler shouldn't know the proper alignment for
this structure, is there? OK, "feels wrong" is not a good argument. But
it would be better to solve this problem once and for all.
AFAIK (which admittedly is not much wrt cross building) there is no way
we can make the host built file2alias know the proper aligment for the
structure in the target built modules. That's the background for this
fix:
commit 4ce6efed48d736e3384c39ff87bda723e1f8e041
Author: Sam Ravnborg <sam@...nus.ravnborg.org>
Date: Sun Mar 23 21:38:54 2008 +0100
kbuild: soften modpost checks when doing cross builds
The module alias support in the kernel have a consistency
check where it is checked that the size of a structure
in the kernel and on the build host are the same.
For cross builds this check does not make sense so detect
when we do cross builds and silently skip the check in these
situations.
This fixes a build bug for a wireless driver when cross building
for arm.
What I'm now wondering is why didn't this kick in? I believe we should
find and fix that instead of playing around with the in-kernel structure
alignments. If that's possible.
BTW, thanks for finding and reporting this at such an early stage,
Geert.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists