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:	Fri, 26 Oct 2012 10:28:52 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Chris Metcalf <cmetcalf@...era.com>
Cc:	Cyberman Wu <cypher.w@...il.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 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]

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

Powered by blists - more mailing lists