Messages in this thread |  | | Date | Fri, 10 Feb 2012 09:17:22 +0100 | From | Paolo Bonzini <> | Subject | Re: scsi_id: sending ioctl 2285 to a partition |
| |
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<willy@linux.intel.com> 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
|  |