Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751749AbWJMQgi (ORCPT ); Fri, 13 Oct 2006 12:36:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751754AbWJMQgi (ORCPT ); Fri, 13 Oct 2006 12:36:38 -0400 Received: from palinux.external.hp.com ([192.25.206.14]:19371 "EHLO mail.parisc-linux.org") by vger.kernel.org with ESMTP id S1751749AbWJMQgh (ORCPT ); Fri, 13 Oct 2006 12:36:37 -0400 Date: Fri, 13 Oct 2006 10:36:35 -0600 From: Matthew Wilcox To: Adam Belay Cc: Alan Cox , Arjan van de Ven , Alan Stern , Benjamin Herrenschmidt , Greg KH , linux-pci@atrey.karlin.mff.cuni.cz, Linux-pm mailing list , Kernel development list Subject: Re: [linux-pm] Bug in PCI core Message-ID: <20061013163635.GC11633@parisc-linux.org> References: <1160753187.25218.52.camel@localhost.localdomain> <1160753390.3000.494.camel@laptopd505.fenrus.org> <1160755562.25218.60.camel@localhost.localdomain> <1160757260.26091.115.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1160757260.26091.115.camel@localhost.localdomain> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1484 Lines: 26 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/