Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758495Ab2BJIRb (ORCPT ); Fri, 10 Feb 2012 03:17:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:64388 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758462Ab2BJIR3 (ORCPT ); Fri, 10 Feb 2012 03:17:29 -0500 Message-ID: <4F34D292.4080404@redhat.com> Date: Fri, 10 Feb 2012 09:17:22 +0100 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: Matthew Wilcox CC: Linus Torvalds , linux-kernel@vger.kernel.org, Doug Nelson Subject: Re: scsi_id: sending ioctl 2285 to a partition References: <20120209202938.GA14342@linux.intel.com> <20120209210039.GB14342@linux.intel.com> In-Reply-To: <20120209210039.GB14342@linux.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1789 Lines: 45 On 02/09/2012 10:00 PM, Matthew Wilcox wrote: > On Thu, Feb 09, 2012 at 12:42:00PM -0800, Linus Torvalds wrote: >> On Thu, Feb 9, 2012 at 12:29 PM, Matthew Wilcox wrote: >>> >>> Commit 0bfc96cb77 adds this printk that triggers tens of thousands of >>> times during a run of "a well-known database benchmark". 0x2285 is SG_IO. >>> I'm not sure why scsi_id feels that it needs to repeatedly send a SCSI >>> INQUIRY to a partition, but there we are. >> >> So is it doing this as root (in which case we end up allowing it) or >> as a normal user (in which case we end up disallowing it)? > > I'm pretty sure it's doing it as root ... it'll be run by udev, after all. What does the rule look like? Here it is like this: # scsi devices KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", IMPORT{program}="scsi_id --export --whitelisted -d $tempnode", ENV{ID_BUS}="scsi" which should exclude partitions, and indeed I don't see any such message. I also have this rule: # for partitions import parent information ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*" which makes it clear that udev does not need to send INQUIRY to the partition. >> And does it all work well apart from the printk? Because the printk >> itself is scheduled to be removed, it's only there to hear about users >> that may be doing crazy things that got disallowed by the patches in >> question? > > If it is being run as root, then the printk is pointless, right? At the time the printk is removed, access also will be disallowed to root. Paolo -- 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/