linux-kernel - Re: PCIe IO space support on Tilera GX: Is there any one who can confirm my modification to fix it is OK?

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]

Date:	Sat, 27 Oct 2012 09:39:37 +0800
From:	Cyberman Wu <cypher.w@...il.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Chris Metcalf <cmetcalf@...era.com>, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: PCIe IO space support on Tilera GX: Is there any one who can
 confirm my modification to fix it is OK?

On Sat, Oct 27, 2012 at 12:28 AM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
> On Fri, Oct 26, 2012 at 8:08 AM, Chris Metcalf <cmetcalf@...era.com> wrote:
>
>> Cyberman: it seems like your bias hack is working for you.  But, as Bjorn
>> says, this sounds like a driver bug.  What happens if you just revert your
>> changes, but then in mvsas.c change the "if (!res_start || !res_len)" to
>> just say "if (!res_len)"?  That seems like the true error test.  If that
>> works, you should submit that change to the community.
>
> I don't *think* that is going to be enough, even with the kernel that
> has some I/O space support, because both devices are assigned
> identical resources:
>
>   pci 0000:01:00.0: BAR 2: assigned [io  0x0000-0x007f]
>   pci 0001:01:00.0: BAR 2: assigned [io  0x0000-0x007f]
>
> The I/O space support that's there is broken because we think the same
> I/O range is available on both root buses, which is probably not the
> case:
>
>   pci_bus 0000:00: resource 0 [io  0x0000-0xffffffff]
>   pci_bus 0001:00: resource 0 [io  0x0000-0xffffffff]
>
That's the problem I want to confirm what I've changed is correct. I've split
the two RootComplex using separate I/O range, it seems works on our device,
but since I'm not very clear about Linux kernel, I want some some to check it.
For mvsas, I've already modified it some thing like Chris said when I began
using MDE-4.0.0 GA release. I bring it out to see if there have some ideas
about that issue.

> If mvsas really doesn't need the I/O BAR, I think it's likely that
> making it use pci_enable_device_mem() will make both devices work even
> without I/O space support in the kernel.
>
>> Bjorn et al: does it seem reasonable to add a bias to the mappings so that
>> we never report a zero value as valid?  This may be sufficiently defensive
>> programming that it's just the right thing to do regardless of whether
>> drivers are technically at fault or not.  If so, what's a good bias?  (I'm
>> inclined to think 64K rather than 4K.)
>
> I/O space is very limited to begin with (many architectures only
> *have* 64K), so I hesitate to add a bias in the PCI core.  But we do
> something similar in arch_remove_reservations(), and I think you could
> implement it that way if you wanted to.
>
> Bjorn



-- 
Cyberman Wu
--
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/