Re: [git pull] PCI changes for 2.6.30

[Sam Ravnborg]

On Wed, Apr 01, 2009 at 04:23:10PM -0600, Alex Chiang wrote:
> * Sam Ravnborg <sam@xxxxxxxxxxxx>:
> > On Wed, Apr 01, 2009 at 12:37:49PM -0600, Alex Chiang wrote:
> > > * Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>:
> > > > On Wed, 1 Apr 2009 10:01:12 -0700 (PDT)
> > > > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > > > > On Tue, 31 Mar 2009, Jesse Barnes wrote:
> > > > > >
> > > > > > Please consider pulling my PCI tree from
> > > > > >   git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
> > > > > > linux-next
> > > > > 
> > > > > This produces
> > > > > 
> > > > >   WARNING: drivers/built-in.o(.text+0x69a1): Section mismatch in
> > > > > reference from the function dev_rescan_store() to the
> > > > > function .devinit.text:pci_rescan_bus() The function
> > > > > dev_rescan_store() references the function __devinit
> > > > > pci_rescan_bus(). This is often because dev_rescan_store lacks a
> > > > > __devinit annotation or the annotation of pci_rescan_bus is wrong.
> > > > > 
> > > > > Hmm?
> > > > 
> > > > Arg how did I miss that?  Maybe the last build I did was missing
> > > > hotplug support or something... Anyway looking now (at first glance I
> > > > think pci_rescan_bus needs to drop __devinit).
> > > 
> > > This was my fault. pci_rescan_bus() definitely does not want
> > > __devinit.
> > > 
> > > But I'm confused -- didn't we used to have an option in
> > > menuconfig under Kernel Hacking that would turn on section
> > > mismatch warnings? I used to have that turned on, and don't
> > > remember turning it off, and I can't find it now.
> > > 
> > > I'm told that we're supposed to set it on the make command line,
> > > like:
> > > 
> > > 	make CONFIG_DEBUG_SECTION_MISMATCH=y -j16
> > > 
> > > or something. Has this changed recently or am I just imagining
> > > things (or just plain stupid?)
> > 
> > That was maybe one year ago we had it in menuconfig.
> > When I get on top of things I will enable it and try to
> > help fixing the remaining warnings.
> 
> Ah, ok.
> 
> > I have resisted enabling it for now as I cannot support the people
> > that see the warnings atm.
> 
> Nod, makes sense.
> 
> I took a look at the warning that Linus mentioned, and I'm not
> entirely sure how to fix it. The problem is this:
> 
> http://git.kernel.org/?p=linux/kernel/git/jbarnes/pci-2.6.git;a=commit;h=3ed4fd96b3188406ac5357d9290bcffa08c65cf6
> 
> I initially annoted pci_rescan_bus as __devinit, which it
> shouldn't have. Removing the annotation though, produces these
> other warnings:
> 
> WARNING: vmlinux.o(.text+0x1b9be6): Section mismatch in reference from the function pci_rescan_bus() to the function .devinit.text:pci_scan_child_bus()
> The function pci_rescan_bus() references
> the function __devinit pci_scan_child_bus().
> This is often because pci_rescan_bus lacks a __devinit 
> annotation or the annotation of pci_scan_child_bus is wrong.
> 
> Reading through Documentation/PCI/pci.txt says that under
> CONFIG_HOTPLUG, __devinit should be a nop?
The documentation is not up-to-date in this respect.

Annotating a function __devinit will no matter the configuration
locate the code in a section named .devinit.text

We then postprocess this section for illegal references using modpost.

The PCI_HOTPLUG code has often been troublesome with respect to these checks
as this code is only relevant if CONFIG_HOTPLUG is enabled
and will often not even be included in the kernel if not enabled.
This is true for pci_rescan_bus() for example.

And we would like to export these symbols too. But we do not allow exported
symbols to be annotated __devinit as this code will be blown away in some configurations.

So the correct solution which you also used in your patch is to tell
modpost to ignore references to *init sections from this specific funtion
as they are OK.

	Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/