From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935190AbbI2RR6 (ORCPT ); Tue, 29 Sep 2015 13:17:58 -0400 Received: from h1446028.stratoserver.net ([85.214.92.142]:44991 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934382AbbI2RRu (ORCPT ); Tue, 29 Sep 2015 13:17:50 -0400 Subject: Re: AMD-IOMMU and problem with __init(data)? To: Joerg Roedel References: <56027D60.3070903@ahsoftware.de> <20150923114358.GA3036@8bytes.org> <5602CA2B.5000106@ahsoftware.de> <5602F7BF.4020009@ahsoftware.de> <20150929150658.GJ3036@8bytes.org> Cc: linux-kernel@vger.kernel.org From: Alexander Holler Message-ID: <560AC7B5.4010009@ahsoftware.de> Date: Tue, 29 Sep 2015 19:17:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150929150658.GJ3036@8bytes.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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