On Fri, Oct 13, 2006 at 12:34:20PM -0400, Adam Belay wrote: > I agree this needs to be fixed. However, as I previously mentioned, > this isn't the right place to attack the problem. Remember, this wasn't > originally a kernel regression. Rather it's a workaround for a known > X/lspci/whatever bug. It's not the kernel's job to babysit userspace. > If a userspace app that has the proper permissions decides to take a > course of action that could potentially crash the system, then it has a > right to do so. There are probably dozens of vectors for these sorts of > problems (e.g. mmap as Arjan has mentioned) so why stop at the pci > config sysfs interface? The patch I posted (to deny user access while the device is transitioning D-states) is to fix a bug where *any* local user can bring the system into undefined territory, simply by typing lspci at the right moment. No special permission is needed. I hadn't realised that pci_block_user_cfg_access() would call pci_save_state(). There's only one other user of pci_block_user_cfg_access() -- drivers/scsi/ipr.c and I think it could be induced to call pci_save_state() itself. It's an odd asymmetry anyway -- block calls save state, but unblock doesn't call restore_state.
