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: <alpine.DEB.2.21.2107030031550.33206@angie.orcam.me.uk>
Date:   Sat, 3 Jul 2021 01:09:45 +0200 (CEST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Nikolai Zhubr <zhubr.2@...il.com>
cc:     Bjorn Helgaas <bhelgaas@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, Arnd Bergmann <arnd@...nel.org>,
        x86@...nel.org, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/2] x86/PCI: SiS PIRQ router updates

Hello Nikolai,

> >   Nikolai, can you please give it a hit with the extra debug patch as
> > requested in my other message?
> 
> With
> linux-x86-pirq-router-sis85c503.diff applied
> linux-x86-pirq-router-sis85c497.diff applied
> and DEBUG 1 in arch/x86/include/asm/pci_x86.h
> here is new log:
> 
> https://pastebin.com/n3udQgcq
> 
> My feeling is that something went a bit wrong because:
> 
> 8139too 0000:00:0d.0: can't route interrupt

 More important is actually the previous line:

PCI: Attempting to find IRQ router for [0000:0000]

meaning that the PIRQ structure defined by the BIOS has not specified the 
vendor:device ID pair for the router [1039:0496] which we match against.

 I don't know where exactly the definition our `struct irq_routing_table' 
corresponds to comes from (I'll appreciate pointers!); it has not been 
given in the PCI BIOS 2.1 specification, only individual IRQ routing 
entries have.  It may well be that [0000:0000] is a legitimate blanket 
entry requesting the OS to figure out itself which device is the hardware 
router.

 Anyway it is something we can handle in a reasonably staightforward 
manner, so I'll spend some time to implement such wildcard matching.  Most 
importantly your system does have the router structure, so barring this 
minor snag it can be handled properly without horrible hacks.  We're very 
close now.

> Note: I still used 4.14 kernel for this test but your patches applied cleanly
> with no fuzz so I suppose it should be ok.

 Indeed, that does not matter.  This code is very old, dating back to 
1990s.

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ