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

[Robert Brown <rj@elilabs.com>]

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@redhat.com> 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)!