linux-kernel - Re: [PATCH 1/5, resend] PCI: adjust quirk handler section annotations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAErSpo5Aidio0a6SjeYu=-9gXJU1aALMi5mUjg2aEB5pTsr8=Q@mail.gmail.com>
Date:	Wed, 9 May 2012 09:08:41 -0700
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Jan Beulich <JBeulich@...e.com>
Cc:	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [PATCH 1/5, resend] PCI: adjust quirk handler section annotations

On Wed, May 9, 2012 at 9:02 AM, Jan Beulich <JBeulich@...e.com> wrote:
>>>> On 09.05.12 at 17:54, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
>> On Wed, May 9, 2012 at 1:43 AM, Jan Beulich <JBeulich@...e.com> wrote:
>>> This is in preparation to adjust modpost to check section mismatches
>>> on most of the .pci_fixup* sections:
>>>
>>> .pci_fixup_final is only used from .init.text, and hence can (along
>>> with the respective handler functions) reside in .init.*.
>>
>> pci_apply_final_quirks() is currently __init, so this probably
>> wouldn't break anything.   But the fact that it's all __init means
>> that pci_fixup_final quirks are only run for devices present at boot,
>> and they don't apply to hot-added devices.  That seems like a bug to
>> me.
>>
>>> Several other .pci_fixup_* sections are needed only during boot and
>>> suspend/resume, and can therefore be moved into .init.* if
>>> !CONFIG_PM.
>>
>> My inclination is that all PCI fixups should work the same for
>> hot-added devices as for those present at boot, which would suggest
>> that we should always use __devinit, not __init.  If I'm missing
>> something, please educate me :)
>
> That's certainly possible - I simply based the patch on what is there
> currently.

Yep, your patch makes perfect sense considering the tree as it is
today.  But if you agree with my sense of what it *should* be, I think
we should leave things as they are, or work on moving everything
towards __devinit (I'd be thrilled if you wanted to work on that :)).
Otherwise we'd just be changing things to __init that we'd have to
change back later.

Bjorn
--
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/