Re: mdadm: sending ioctl 1261 to a partition!

[Steven Haigh <netwiz@crc.id.au>]

[-- 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 --]