Re: AMD-IOMMU and problem with __init(data)?

[Alexander Holler <holler@ahsoftware.de>]

Am 29.09.2015 um 17:06 schrieb Joerg Roedel:
> As expected it is no bug in the AMD IOMMU driver, but in your code.
>
> On Wed, Sep 23, 2015 at 09:04:31PM +0200, Alexander Holler wrote:
>> struct _annotated_initcall {
>> 	initcall_t initcall;
>> 	unsigned driver_id;
>> 	unsigned *dependencies;
>> 	struct device_driver *driver;
>> };
>
> This struct gets aligned on a 32 bytes boundary.
>
>> +#define ANNOTATED_INITCALLS						\
>> +		VMLINUX_SYMBOL(__annotated_initcall_start) = .;		\
>> +		*(.annotated_initcall.init)				\
>> +		VMLINUX_SYMBOL(__annotated_initcall_end) = .;
>
> But this section does not.
>
>> +	ac = __annotated_initcall_start;
>> +	pr_info("ac %p ID %u\n", ac, ac->driver_id);
>> +	BUG_ON(ac->driver_id != 23);
>
> So when you access __annotated_initcall_start here, you don't access the
> first element of your array, but actually the zero padding before your
> struct.
>
> On my system the section was aligned on an 8 bytes boundary, which means
> there were 24 bytes of padding before the symbol you try to access.

Hmm. Thanks a lot. Also I've checked the alignment (at least twice) and 
remember it was 32bit. But maybe I've checked something different or 
looked at some file for ARM or x86(_32) or was confused or similar. But 
now, when I look at ARM the initcall section seems to be aligned to 8 
too. So I wonder why the stuff works on ARM (v5 and v7) and on an Intel 
Atom (32bit). I think at least the armv5 box should have trapped (fatal) 
too, but maybe that changed.

Sorry for not having looked at the alignment at least once more. 
Alignment bugs are always hard to see and I've already assumed such, 
especially because any other kernel seems to work, but I was obviously 
unable to see it.

Again, thanks a lot.

Regards,

Alexander Holler