Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files

From: Robert Brown
Date: Mon Mar 18 2013 - 14:35:45 EST


On 03/18/13 13:54, Alex Williamson wrote:
> On Mon, 2013-03-18 at 18:20 +0100, Bjørn Mork wrote:
>> Alex Williamson <alex.williamson@xxxxxxxxxx> writes:
>>
>>> At least for KVM the kernel fix is the addition of the vfio driver which
>>> gives us a non-sysfs way to do this. If this problem was found a few
>>> years later and we were ready to make the switch I'd support just
>>> removing these resource files. In the meantime we have userspace that
>>> depends on this interface, so I'm open to suggestions how to fix it.
>> I am puzzled by a couple of things in this discussion:
>>
>> 1) do you seriously mean that a userspace application (any, not just
>> udevadm or qemu or whatever) should be able to read and write these
>> registers while the device is owned by a driver? How is that ever
>> going to work?
> The expectation is that the user doesn't mess with the device through
> pci-sysfs while it's running. This is really no different than config
> space or MMIO space in that respect. You can use setpci to break your
> PCI card while it's used by the driver today. The difference is that
> MMIO spaces side-step the issue by only allowing mmap and config space
> is known not to have read side-effects.
>
>> 2) is it really so that a device can be so fundamentally screwed up by
>> reading some registers, that a later driver probe cannot properly
>> reinitialize it?
> Never underestimate how broken hardware can be, though in this case
> reading a device register seems to be causing a system hang/reset.
The real problem is that PCI devices can be bus masters, which means
they can screw up *ANYTHING* (almost)!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/