linux-kernel - Re: [PATCH 1/2] PCI: Prevent 64-bit resources from being counted in 32-bit bridge region

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: <CAErSpo5icDM2VgYoLdEp8C-CV5XEMThABMA8RBq64grhRSkRWA@mail.gmail.com>
Date:   Mon, 4 Mar 2019 14:29:22 -0600
From:   Bjorn Helgaas <bhelgaas@...gle.com>
To:     Logan Gunthorpe <logang@...tatee.com>
Cc:     Bjorn Helgaas <helgaas@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux PCI <linux-pci@...r.kernel.org>,
        Kit Chow <kchow@...aio.com>, Yinghai Lu <yinghai@...nel.org>
Subject: Re: [PATCH 1/2] PCI: Prevent 64-bit resources from being counted in
 32-bit bridge region

On Mon, Mar 4, 2019 at 2:21 PM Logan Gunthorpe <logang@...tatee.com> wrote:
> On 2019-03-04 1:11 p.m., Bjorn Helgaas wrote:
> > On Mon, Mar 4, 2019 at 1:21 PM Logan Gunthorpe <logang@...tatee.com> wrote:
> >> On 2019-03-03 5:23 p.m., Bjorn Helgaas wrote:
> >>> Sorry for the delay.  This code gives a headache.  I still remember
> >>> my headache from the last time we touched it.  Help me understand
> >>> what's going on here.
> >>
> >> Yes, this code gave me a headache debugging it too. And it's not the
> >> first time I've tried to figure out what's going on with it because it
> >> often just prints noisy messages that look like errors. I think I
> >> understand it better now but it's something that's a bit fleeting and
> >> easy to forget the details of. There may also be other solutions to this
> >> problem.
> >
> > Thanks for the explanation below.  I haven't worked through it yet, but I will.
> >
> > Obviously it would be far better than an explanation if we could
> > simplify the code (and the noisy messages) such that it didn't
> > *require* so much explanation.
>
> I agree, but reworking this code scares me and I suspect it was designed
> this way for a reason. I'm guessing there are a lot of corner cases and
> unusual bios issues this stuff works around. We might end up fixing a
> some cases and breaking a bunch of other cases.

Scares me too, which is one reason I haven't done anything about it.

I didn't mean to suggest that you should rework it for *this* issue.
I just keep hoping that we can chip away at teensy pieces and in ten
or twenty years maybe make some headway.

Bjorn