mdadm: sending ioctl 1261 to a partition!

mdadm: sending ioctl 1261 to a partition!

[Steven Haigh]

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

I've noticed that recently I've managed to get a ton of messages like 
this at boot:

mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 800c0910 to a partition!

Not quite sure what is causing them - but everything still seems to work ok.

# mdadm --version
mdadm - v3.2.2 - 17th June 2011

Distro is Scientific Linux 6.2 - kernel is a custom build of 2.6.32.56.

My arrays are set up as such:
ARRAY /dev/md0 level=raid1 num-devices=2 
UUID=9f19116a:d2808216:cc87af34:eae68242

ARRAY /dev/md1 level=raid1 num-devices=2 
UUID=afb92c19:b9b1e3ae:07af315d:738e38be

ARRAY /dev/md2 level=raid6 num-devices=4 
UUID=8a5de4d9:ea754e76:89b64059:c12cb374

md0 and md1 are using partitions, md2 is using whole disks. Anybody got 
any insight into what causes this and how I could go about correcting it?

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4952 bytes --]

Re: mdadm: sending ioctl 1261 to a partition!

[John Robinson]

On 05/03/2012 13:03, Steven Haigh wrote:
> I've noticed that recently I've managed to get a ton of messages like
> this at boot:
>
> mdadm: sending ioctl 1261 to a partition!
> mdadm: sending ioctl 800c0910 to a partition!

It's probably harmless.

http://lists.debian.org/debian-kernel/2012/01/msg01105.html says "This 
warning was introduced as part of the fix for CVE-2011-4127"

https://bugzilla.redhat.com/show_bug.cgi?id=783955#c4 says "Actually, 
the warning seems a false positive to me"

Cheers,

John.

Re: mdadm: sending ioctl 1261 to a partition!

[Steven Haigh]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

On 6/03/2012 1:52 AM, John Robinson wrote:
> On 05/03/2012 13:03, Steven Haigh wrote:
>> I've noticed that recently I've managed to get a ton of messages like
>> this at boot:
>>
>> mdadm: sending ioctl 1261 to a partition!
>> mdadm: sending ioctl 800c0910 to a partition!
>
> It's probably harmless.
>
> http://lists.debian.org/debian-kernel/2012/01/msg01105.html says "This
> warning was introduced as part of the fix for CVE-2011-4127"
>
> https://bugzilla.redhat.com/show_bug.cgi?id=783955#c4 says "Actually,
> the warning seems a false positive to me"

I did see these - and I probably should have mentioned it in the 
original post. Naughty me for posting at times I should really be asleep.

The general jist of it seemed to be "it always failed before, now we 
just know about it". What makes me wonder is that if it always failed 
before, why do we do it in the first place?

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4952 bytes --]

Re: mdadm: sending ioctl 1261 to a partition!

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

On Tue, 06 Mar 2012 05:53:28 +1100 Steven Haigh <netwiz@crc.id.au> wrote:

> On 6/03/2012 1:52 AM, John Robinson wrote:
> > On 05/03/2012 13:03, Steven Haigh wrote:
> >> I've noticed that recently I've managed to get a ton of messages like
> >> this at boot:
> >>
> >> mdadm: sending ioctl 1261 to a partition!
> >> mdadm: sending ioctl 800c0910 to a partition!
> >
> > It's probably harmless.
> >
> > http://lists.debian.org/debian-kernel/2012/01/msg01105.html says "This
> > warning was introduced as part of the fix for CVE-2011-4127"
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=783955#c4 says "Actually,
> > the warning seems a false positive to me"
> 
> I did see these - and I probably should have mentioned it in the 
> original post. Naughty me for posting at times I should really be asleep.
> 
> The general jist of it seemed to be "it always failed before, now we 
> just know about it". What makes me wonder is that if it always failed 
> before, why do we do it in the first place?
> 

800c0910 is 'are you an md device'.  So failure is a valid response.

1261 is flush-bufs.  I hope that does still work on partitions....

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mdadm: sending ioctl 1261 to a partition!

[Steven Haigh]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

On 6/03/2012 7:01 AM, NeilBrown wrote:
> On Tue, 06 Mar 2012 05:53:28 +1100 Steven Haigh<netwiz@crc.id.au>  wrote:
>
>> On 6/03/2012 1:52 AM, John Robinson wrote:
>>> On 05/03/2012 13:03, Steven Haigh wrote:
>>>> I've noticed that recently I've managed to get a ton of messages like
>>>> this at boot:
>>>>
>>>> mdadm: sending ioctl 1261 to a partition!
>>>> mdadm: sending ioctl 800c0910 to a partition!
>>>
>>> It's probably harmless.
>>>
>>> http://lists.debian.org/debian-kernel/2012/01/msg01105.html says "This
>>> warning was introduced as part of the fix for CVE-2011-4127"
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=783955#c4 says "Actually,
>>> the warning seems a false positive to me"
>>
>> I did see these - and I probably should have mentioned it in the
>> original post. Naughty me for posting at times I should really be asleep.
>>
>> The general jist of it seemed to be "it always failed before, now we
>> just know about it". What makes me wonder is that if it always failed
>> before, why do we do it in the first place?
>>
>
> 800c0910 is 'are you an md device'.  So failure is a valid response.
>
> 1261 is flush-bufs.  I hope that does still work on partitions....

Thanks Neil, Any ideas how I can test this to check if flush-bufs is 
working? While I'm not a code junkie these days - I'm great at picking 
holes in thing ;)

I picked it up as it only seemed to be visible in 2.6.32.56. I don't 
recall seeing it in any previous 2.6.32.x kernel.

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4952 bytes --]

Re: mdadm: sending ioctl 1261 to a partition!

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2402 bytes --]

On Tue, 06 Mar 2012 13:00:01 +1100 Steven Haigh <netwiz@crc.id.au> wrote:

> On 6/03/2012 7:01 AM, NeilBrown wrote:
> > On Tue, 06 Mar 2012 05:53:28 +1100 Steven Haigh<netwiz@crc.id.au>  wrote:
> >
> >> On 6/03/2012 1:52 AM, John Robinson wrote:
> >>> On 05/03/2012 13:03, Steven Haigh wrote:
> >>>> I've noticed that recently I've managed to get a ton of messages like
> >>>> this at boot:
> >>>>
> >>>> mdadm: sending ioctl 1261 to a partition!
> >>>> mdadm: sending ioctl 800c0910 to a partition!
> >>>
> >>> It's probably harmless.
> >>>
> >>> http://lists.debian.org/debian-kernel/2012/01/msg01105.html says "This
> >>> warning was introduced as part of the fix for CVE-2011-4127"
> >>>
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=783955#c4 says "Actually,
> >>> the warning seems a false positive to me"
> >>
> >> I did see these - and I probably should have mentioned it in the
> >> original post. Naughty me for posting at times I should really be asleep.
> >>
> >> The general jist of it seemed to be "it always failed before, now we
> >> just know about it". What makes me wonder is that if it always failed
> >> before, why do we do it in the first place?
> >>
> >
> > 800c0910 is 'are you an md device'.  So failure is a valid response.
> >
> > 1261 is flush-bufs.  I hope that does still work on partitions....
> 
> Thanks Neil, Any ideas how I can test this to check if flush-bufs is 
> working? While I'm not a code junkie these days - I'm great at picking 
> holes in thing ;)

Read the code....

In block/ioctl.c
	case BLKFLSBUF:
		if (!capable(CAP_SYS_ADMIN))
			return -EACCES;

		ret = __blkdev_driver_ioctl(bdev, mode, cmd, arg);
		/* -EINVAL to handle old uncorrected drivers */
		if (ret != -EINVAL && ret != -ENOTTY)
			return ret;

		lock_kernel();
		fsync_bdev(bdev);
		invalidate_bdev(bdev);
		unlock_kernel();
		return 0;


So it is still called fsync_bdev and invalidate_bdev as long as the ioctl
function for the underlying disk returns -EINVAL or -ENOTTY.

The function that shows that warning is scsi_verify_blk_ioctl in
block/scsi_ioctl.c
The worst it can do is return -ENOTTY, and that is safe.

So the warning is bogus, the code still works.

NeilBrown



> 
> I picked it up as it only seemed to be visible in 2.6.32.56. I don't 
> recall seeing it in any previous 2.6.32.x kernel.
> 


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mdadm: sending ioctl 1261 to a partition!

[Steven Haigh]

[-- Attachment #1: Type: text/plain, Size: 3227 bytes --]

On 6/03/2012 1:27 PM, NeilBrown wrote:
> On Tue, 06 Mar 2012 13:00:01 +1100 Steven Haigh<netwiz@crc.id.au>  wrote:
>
>> On 6/03/2012 7:01 AM, NeilBrown wrote:
>>> On Tue, 06 Mar 2012 05:53:28 +1100 Steven Haigh<netwiz@crc.id.au>   wrote:
>>>
>>>> On 6/03/2012 1:52 AM, John Robinson wrote:
>>>>> On 05/03/2012 13:03, Steven Haigh wrote:
>>>>>> I've noticed that recently I've managed to get a ton of messages like
>>>>>> this at boot:
>>>>>>
>>>>>> mdadm: sending ioctl 1261 to a partition!
>>>>>> mdadm: sending ioctl 800c0910 to a partition!
>>>>>
>>>>> It's probably harmless.
>>>>>
>>>>> http://lists.debian.org/debian-kernel/2012/01/msg01105.html says "This
>>>>> warning was introduced as part of the fix for CVE-2011-4127"
>>>>>
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=783955#c4 says "Actually,
>>>>> the warning seems a false positive to me"
>>>>
>>>> I did see these - and I probably should have mentioned it in the
>>>> original post. Naughty me for posting at times I should really be asleep.
>>>>
>>>> The general jist of it seemed to be "it always failed before, now we
>>>> just know about it". What makes me wonder is that if it always failed
>>>> before, why do we do it in the first place?
>>>>
>>>
>>> 800c0910 is 'are you an md device'.  So failure is a valid response.
>>>
>>> 1261 is flush-bufs.  I hope that does still work on partitions....
>>
>> Thanks Neil, Any ideas how I can test this to check if flush-bufs is
>> working? While I'm not a code junkie these days - I'm great at picking
>> holes in thing ;)
>
> Read the code....

Easier said than done.

> In block/ioctl.c
> 	case BLKFLSBUF:
> 		if (!capable(CAP_SYS_ADMIN))
> 			return -EACCES;
>
> 		ret = __blkdev_driver_ioctl(bdev, mode, cmd, arg);
> 		/* -EINVAL to handle old uncorrected drivers */
> 		if (ret != -EINVAL&&  ret != -ENOTTY)
> 			return ret;
>
> 		lock_kernel();
> 		fsync_bdev(bdev);
> 		invalidate_bdev(bdev);
> 		unlock_kernel();
> 		return 0;

You know that look when peoples eyes glaze over - commonly referred to 
in the BOFH stories as *IDIOT MODE ON*. Thats what I get when I look at 
that code ;)

>
> So it is still called fsync_bdev and invalidate_bdev as long as the ioctl
> function for the underlying disk returns -EINVAL or -ENOTTY.
>
> The function that shows that warning is scsi_verify_blk_ioctl in
> block/scsi_ioctl.c
> The worst it can do is return -ENOTTY, and that is safe.

I recognise a lot of those words, but I have no idea what they mean in 
that sequence. This proves that this list is great for people 
understanding that code. It also means that I can trust exactly what is 
going on :) I don't want to burden you with trying to explain it to 
someone like me, but its comforting to know all is right :)

> So the warning is bogus, the code still works.

Awesome! Means I can safely ignore it, and this gets archived for proper 
reference on the archive lists and should probably appear in googles 
searches on the subject soon to stop it from being asked here again :)

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4952 bytes --]

Re: mdadm: sending ioctl 1261 to a partition!

[H. Peter Anvin]

On 03/05/2012 06:27 PM, NeilBrown wrote:
> 
> So it is still called fsync_bdev and invalidate_bdev as long as the
> ioctl function for the underlying disk returns -EINVAL or -ENOTTY.
> 
> The function that shows that warning is scsi_verify_blk_ioctl in 
> block/scsi_ioctl.c The worst it can do is return -ENOTTY, and that
> is safe.
> 
> So the warning is bogus, the code still works.
> 

We should whitelist ioctls if they are legitimately used and harmless.
 Do we have a specific list?

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: mdadm: sending ioctl 1261 to a partition!

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

On Mon, 05 Mar 2012 21:29:59 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:

> On 03/05/2012 06:27 PM, NeilBrown wrote:
> > 
> > So it is still called fsync_bdev and invalidate_bdev as long as the
> > ioctl function for the underlying disk returns -EINVAL or -ENOTTY.
> > 
> > The function that shows that warning is scsi_verify_blk_ioctl in 
> > block/scsi_ioctl.c The worst it can do is return -ENOTTY, and that
> > is safe.
> > 
> > So the warning is bogus, the code still works.
> > 
> 
> We should whitelist ioctls if they are legitimately used and harmless.
>  Do we have a specific list?
> 
> 	-hpa
> 
> 

We had the following in our SLES kernel for a while, though it seems it
disappeared when we pulled in 3.0.18.
Jan: should we put this stuff back?

NeilBrown




@@ -78,11 +83,19 @@ Index: linux-3.0-SLE11-SP2/block/scsi_ioctl.c
 +      case SG_GET_RESERVED_SIZE:
 +      case SG_SET_RESERVED_SIZE:
 +      case SG_EMULATED_HOST:
++      case BLKFLSBUF:
++      case BLKROSET:
 +              return 0;
 +      case CDROM_GET_CAPABILITY:
-+              /* Keep this until we remove the printk below.  udev sends it
-+               * and we do not want to spam dmesg about it.   CD-ROMs do
-+               * not have partitions, so we get here only for disks.
++      case CDROM_DRIVE_STATUS:
++      case FDGETPRM:
++      case RAID_VERSION:
++      case MTIOCGET:
++#ifdef CONFIG_COMPAT
++      case 0x801c6d02:        /* MTIOCGET32 */
++#endif
++              /* Keep this until we remove the printk below. udev/dd sends
++               * these and we do not want to spam dmesg about it. CD-ROMs
++               * & tapes do not have partitions, so we get here only for
++               * disks.
 +               */
 +              return -ENOTTY;
 +      default:


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mdadm: sending ioctl 1261 to a partition!

[Jan Kara]

On Thu 08-03-12 11:04:21, NeilBrown wrote:
> On Mon, 05 Mar 2012 21:29:59 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
> 
> > On 03/05/2012 06:27 PM, NeilBrown wrote:
> > > 
> > > So it is still called fsync_bdev and invalidate_bdev as long as the
> > > ioctl function for the underlying disk returns -EINVAL or -ENOTTY.
> > > 
> > > The function that shows that warning is scsi_verify_blk_ioctl in 
> > > block/scsi_ioctl.c The worst it can do is return -ENOTTY, and that
> > > is safe.
> > > 
> > > So the warning is bogus, the code still works.
> > > 
> > 
> > We should whitelist ioctls if they are legitimately used and harmless.
> >  Do we have a specific list?
> > 
> > 	-hpa
> > 
> > 
> 
> We had the following in our SLES kernel for a while, though it seems it
> disappeared when we pulled in 3.0.18.
> Jan: should we put this stuff back?
  Yeah, we should. I think it was removed by accident - partly because the
patch doing the change was tagged as in mainline but it actually differed
from mainline slightly.

								Honza

> @@ -78,11 +83,19 @@ Index: linux-3.0-SLE11-SP2/block/scsi_ioctl.c
>  +      case SG_GET_RESERVED_SIZE:
>  +      case SG_SET_RESERVED_SIZE:
>  +      case SG_EMULATED_HOST:
> ++      case BLKFLSBUF:
> ++      case BLKROSET:
>  +              return 0;
>  +      case CDROM_GET_CAPABILITY:
> -+              /* Keep this until we remove the printk below.  udev sends it
> -+               * and we do not want to spam dmesg about it.   CD-ROMs do
> -+               * not have partitions, so we get here only for disks.
> ++      case CDROM_DRIVE_STATUS:
> ++      case FDGETPRM:
> ++      case RAID_VERSION:
> ++      case MTIOCGET:
> ++#ifdef CONFIG_COMPAT
> ++      case 0x801c6d02:        /* MTIOCGET32 */
> ++#endif
> ++              /* Keep this until we remove the printk below. udev/dd sends
> ++               * these and we do not want to spam dmesg about it. CD-ROMs
> ++               * & tapes do not have partitions, so we get here only for
> ++               * disks.
>  +               */
>  +              return -ENOTTY;
>  +      default:
> 


-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR