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.
Oh, userspace is RHEL 6.2 and the kernel in use is 3.2.3.
On Thu, Feb 9, 2012 at 12:29 PM, Matthew Wilcox <[email protected]> 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)?
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?
Linus
On Thu, Feb 09, 2012 at 12:42:00PM -0800, Linus Torvalds wrote:
> On Thu, Feb 9, 2012 at 12:29 PM, Matthew Wilcox <[email protected]> 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.
> 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?
On Thu, Feb 9, 2012 at 1:00 PM, Matthew Wilcox <[email protected]> wrote:
>> 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?
No. The original patch actually disallowed it for everybody, including
root. The "let them through with a warning"
So part of the point of the printk was to see if these things happened
at all. We should have made the root'ness explicit in the printk,
though, to see that part too.
Linus
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<[email protected]> 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
On Fri, Feb 10, 2012 at 12:17 AM, Paolo Bonzini <[email protected]> wrote:
>
> At the time the printk is removed, access also will be disallowed to root.
Well, that's clearly not going to be the case, since the printk is
finding way more cases than the initial expectation was.
Linus
On 02/10/2012 05:10 PM, Linus Torvalds wrote:
>> > At the time the printk is removed, access also will be disallowed to root.
> Well, that's clearly not going to be the case, since the printk is
> finding way more cases than the initial expectation was.
This is the only interesting case so far, i.e. the patch is actually
changing the behavior (but it's still unclear why it happens; it may be
misconfiguration or even fixing a bug).
That said, yeah, 1 _is_ way more than 0.
Paolo
On 02/10/2012 12:17 AM, Paolo Bonzini wrote:
> 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<[email protected]> 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"
The rule I had was not excluding partitions. I'll fix that and try again.
thanks,
doug
>
> 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
On 02/10/2012 06:23 PM, Nelson, Doug wrote:
>> # scsi devices
>> KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*",
>> IMPORT{program}="scsi_id --export --whitelisted -d $tempnode",
>> ENV{ID_BUS}="scsi"
>
> The rule I had was not excluding partitions. I'll fix that and try again.
So was it a custom rule, or it came with the distro?
Paolo
On 02/10/2012 08:40 PM, Paolo Bonzini wrote:
>>> # scsi devices
>>> KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*",
>>> IMPORT{program}="scsi_id --export --whitelisted -d $tempnode",
>>> ENV{ID_BUS}="scsi"
>>
>> The rule I had was not excluding partitions. I'll fix that and try
>> again.
>
> So was it a custom rule, or it came with the distro?
More important: did you have something like this:
# for partitions import parent information
ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
?
Paolo
On 02/10/2012 11:40 AM, Paolo Bonzini wrote:
> On 02/10/2012 06:23 PM, Nelson, Doug wrote:
>>> # scsi devices
>>> KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*",
>>> IMPORT{program}="scsi_id --export --whitelisted -d $tempnode",
>>> ENV{ID_BUS}="scsi"
>>
>> The rule I had was not excluding partitions. I'll fix that and try
>> again.
>
> So was it a custom rule, or it came with the distro?
>
It's a custom rule we've been using for a long time to rename our 672 x
ssd's.
> Paolo
On Fri, 10 Feb 2012, "Nelson, Doug" wrote:
> On 02/10/2012 11:40 AM, Paolo Bonzini wrote:
> > On 02/10/2012 06:23 PM, Nelson, Doug wrote:
> >>> # scsi devices
> >>> KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*",
> >>> IMPORT{program}="scsi_id --export --whitelisted -d $tempnode",
> >>> ENV{ID_BUS}="scsi"
> >>
> >> The rule I had was not excluding partitions. I'll fix that and try
> >> again.
> >
> > So was it a custom rule, or it came with the distro?
> >
>
> It's a custom rule we've been using for a long time to rename our 672 x
> ssd's.
By the way, I see the same sort of thing happening with mdadm. Maybe I
haven't gotten things configured quite right...
Anyway, here's an example extracted from the system log (this is under
Fedora 16's 3.2.3 kernel):
Feb 10 11:19:52 netrider kernel: [ 2.803184] mdadm: sending ioctl 800c0910 to a partition!
Feb 10 11:19:52 netrider kernel: [ 2.803191] mdadm: sending ioctl 800c0910 to a partition!
Feb 10 11:19:52 netrider kernel: [ 2.803194] mdadm: sending ioctl 800c0910 to a partition!
Feb 10 11:19:52 netrider kernel: [ 2.803201] mdadm: sending ioctl 1261 to a partition!
Feb 10 11:19:52 netrider kernel: [ 2.803203] mdadm: sending ioctl 1261 to a partition!
Feb 10 11:19:52 netrider kernel: [ 2.803382] mdadm: sending ioctl 800c0910 to a partition!
Feb 10 11:19:52 netrider kernel: [ 2.803385] mdadm: sending ioctl 800c0910 to a partition!
Feb 10 11:19:52 netrider kernel: [ 2.803389] mdadm: sending ioctl 800c0910 to a partition!
Feb 10 11:19:52 netrider kernel: [ 2.803390] mdadm: sending ioctl 800c0910 to a partition!
Feb 10 11:19:52 netrider kernel: [ 2.803393] mdadm: sending ioctl 1261 to a partition!
Feb 10 11:19:52 netrider kernel: [ 2.975991] md: bind<sdb3>
Feb 10 11:19:52 netrider kernel: [ 3.104305] md: bind<sda3>
Feb 10 11:19:52 netrider kernel: [ 3.106372] md: raid1 personality registered for level 1
Feb 10 11:19:52 netrider kernel: [ 3.106567] bio: create slab <bio-1> at 1
Feb 10 11:19:52 netrider kernel: [ 3.106728] md/raid1:md1: active with 2 out of 2 mirrors
Feb 10 11:19:52 netrider kernel: [ 3.106841] md1: detected capacity change from 0 to 4301717504
Feb 10 11:19:52 netrider kernel: [ 3.108360] md1: unknown partition table
Alan Stern
On 02/10/2012 09:43 PM, Alan Stern wrote:
> By the way, I see the same sort of thing happening with mdadm. Maybe I
> haven't gotten things configured quite right...
These are just probing ioctls, that would have failed the same way with
or without the patch.
Paolo
On 02/10/2012 08:47 PM, Nelson, Doug wrote:
>>>> # scsi devices
>>>> KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*",
>>>> IMPORT{program}="scsi_id --export --whitelisted -d $tempnode",
>>>> ENV{ID_BUS}="scsi"
>>>
>>> The rule I had was not excluding partitions. I'll fix that and try
>>> again.
>>
>> So was it a custom rule, or it came with the distro?
>>
>
> It's a custom rule we've been using for a long time to rename our 672 x
> ssd's.
Can you post the whole snippet?
Paolo
On 02/10/2012 12:57 PM, Paolo Bonzini wrote:
> On 02/10/2012 08:47 PM, Nelson, Doug wrote:
>>>>> # scsi devices
>>>>> KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*",
>>>>> IMPORT{program}="scsi_id --export --whitelisted -d $tempnode",
>>>>> ENV{ID_BUS}="scsi"
>>>>
>>>> The rule I had was not excluding partitions. I'll fix that and try
>>>> again.
>>>
>>> So was it a custom rule, or it came with the distro?
>>>
>>
>> It's a custom rule we've been using for a long time to rename our 672 x
>> ssd's.
>
> Can you post the whole snippet?
Here's what I had in 20-local.rules
KERNEL=="sd*", BUS=="scsi", PROGRAM="scsi_id --whitelisted -d
$tempnode", ENV{ID_BUS}="scsi"
BUS=="scsi", RESULT=="3500151795924153d", NAME="disk-r1e1-d1s%n",
GROUP:="dba", OWNER:="oracle"
BUS=="scsi", RESULT=="35001517959269241", NAME="disk-r1e1-d2s%n",
GROUP:="dba", OWNER:="oracle"
BUS=="scsi", RESULT=="3500151795926930d", NAME="disk-r1e1-d3s%n",
GROUP:="dba", OWNER:="oracle"
>
> Paolo
On 02/11/2012 12:47 AM, Nelson, Doug wrote:
>
> Here's what I had in 20-local.rules
>
> KERNEL=="sd*", BUS=="scsi", PROGRAM="scsi_id --whitelisted -d
> $tempnode", ENV{ID_BUS}="scsi"
>
> BUS=="scsi", RESULT=="3500151795924153d", NAME="disk-r1e1-d1s%n",
> GROUP:="dba", OWNER:="oracle"
> BUS=="scsi", RESULT=="35001517959269241", NAME="disk-r1e1-d2s%n",
> GROUP:="dba", OWNER:="oracle"
> BUS=="scsi", RESULT=="3500151795926930d", NAME="disk-r1e1-d3s%n",
> GROUP:="dba", OWNER:="oracle"
>
Thanks. I think we could fix scsi_id to strip a partition number and
print itself a warning if passed a partition number.
That said, the above rules alone would have failed with latest udev due
to the use of BUS= (removed in udev 174).
Paolo
On Fri, Feb 10, 2012 at 09:17, Paolo Bonzini <[email protected]> wrote:
> On 02/09/2012 10:00 PM, Matthew Wilcox wrote:
>> 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:
I don't think "sd*[!0-9]" matches partition devices.
Kay