linux-kernel - RE: [PATCH 2/2] PCI: fix system hang issue of Marvell SATA host controller

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, 9 Mar 2013 06:49:12 -0800
From:	Xiangliang Yu <yuxiangl@...vell.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
CC:	yxlraid <yxlraid@...il.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/2] PCI: fix system hang issue of Marvell SATA host
 controller

Hi, Bjorn

>> >> > Fix system hang issue: if first accessed resource file of BAR0 ~ 
>> >> > BAR4, system will hang after executing lspci command
>> >>
>> >> This needs more explanation.  We've already read the BARs by the 
>> >> time header quirks are run, so apparently it's not just the mere 
>> >> act of accessing a BAR that causes a hang.
>> >>
>> >> We need to know exactly what's going on here.  For example, do 
>> >> BARs
>> >> 0-4 exist?  Does the device decode accesses to the regions 
>> >> described by the BARs?  The PCI core has to know what resources 
>> >> the device uses, so if the device decodes accesses, we can't just 
>> >> throw away the start/end information.
>> > The BARs 0-4 is exist and the PCI device is enable IO space, but 
>> > user access
>> the regions file by udevadm command with info parameter, the system will hang.
>> > Like this: udevadmin info --attribut-walk
>> --path=/sys/device/pci-device/000:*.
>> > Because the device is just AHCI host controller, don't need the 
>> > BAR0 ~ 4 region
>> file.
>> > Is my explanation ok for the patch?
>>
>> No, I still don't know what causes the hang; I only know that udevadm 
>> can trigger it.  I don't want to just paper over the problem until we 
>> know what the root cause is.
>>
>> Does "lspci -H1 -vv" also cause a hang?  What about "setpci -s<dev> 
>> BASE_ADDRESS_0"?  "setpci -H1 -s<dev> BASE_ADDRESS_0"?
> The commands are ok because the commands can't find the device after accessing IO port.
> The root cause is that accessing of IO port will make the chip go bad. So, the point of the patch is don't export capability of the IO accessing.

>Ah, so the problem is not with accessing the BAR in config space.  The problem is with accessing the I/O port space mapped by the BAR.  Is that right?

Yes...

>Does "udevadm info --attribute-walk" really access the device address space mapped by the BARs?  

The older version maybe will access the space, I just got the info from HP. And I simplify the issue by executing following command:
Cat /sys/devices/pci-device/**/resourceX

I want to set the resources of BAR0 ~ 4 to 0 to avoid the IO accessing by user.

Any question? Thanks!


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