linux-kernel - Re: [tip:x86/urgent] x86/quirks: Add early quirk to reset Apple AirPort card

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20160608200929.GA18981@wunner.de>
Date:	Wed, 8 Jun 2016 22:09:29 +0200
From:	Lukas Wunner <lukas@...ner.de>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>, cmilsted@...hat.com,
	Rafa?? Mi??ecki <zajec5@...il.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Peter Zijlstra <peterz@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Matthew Garrett <mjg59@...f.ucam.org>, m@...s.ch,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:x86/urgent] x86/quirks: Add early quirk to reset Apple
 AirPort card

On Wed, Jun 08, 2016 at 11:56:14AM -0700, Yinghai Lu wrote:
> On Wed, Jun 8, 2016 at 7:23 AM, tip-bot for Lukas Wunner <tipbot@...or.com> wrote:
> > --- a/arch/x86/kernel/early-quirks.c
> > +++ b/arch/x86/kernel/early-quirks.c
> ...
> 
> Extend bus scan range part should be in separated patch?
> 
> and put apple_airport_reset() related in second patch.

I had considered that but decided against it as it would make things
a bit more complicated for stable maintainers.

Nevertheless I'll be happy to split in two if this is the consensus?
I'm not sure though if x86/urgent is a rebasing branch?


> > +
> > +       if ((type & 0x7f) == PCI_HEADER_TYPE_BRIDGE) {
> > +               sec = read_pci_config_byte(num, slot, func, PCI_SECONDARY_BUS);
> > +               early_pci_scan_bus(sec);
> 
> How do you know that sec is valid ?
> 
> How about on the system that have one bridge that still have sec num register 0?
> 
> it will be get into dead loop.

Good point. I've just checked pci_scan_bridge() and it does verify that
and avoids recursing to a child bus if it's number is zero. It also
ensures that sec > num before recursing.

I can provide a follow-up patch to fix that, will wait a bit though to
see if there are further comments.


> > -void __init early_quirks(void)
> > +static void __init early_pci_scan_bus(int bus)
> >  {
> >         int slot, func;
> >
> > -       if (!early_pci_allowed())
> > -               return;
> > -
> >         /* Poor man's PCI discovery */
> > -       /* Only scan the root bus */
> >         for (slot = 0; slot < 32; slot++)
> >                 for (func = 0; func < 8; func++) {
> >                         /* Only probe function 0 on single fn devices */
> > -                       if (check_dev_quirk(0, slot, func))
> > +                       if (check_dev_quirk(bus, slot, func))
> >                                 break;
> >                 }
> >  }
> > +
> > +void __init early_quirks(void)
> > +{
> > +       if (!early_pci_allowed())
> > +               return;
> > +
> > +       early_pci_scan_bus(0);
> > +}
> 
> Would just revert to scan domain 0, bus 0 to 255.

The commit message of 8659c406ade3 sounds like this would lengthen
boot time noticeably, so I expected significant backlash had I just
gone back to this old algorithm.

Thanks,

Lukas