Re: mdadm: sending ioctl 1261 to a partition!

[NeilBrown <neilb@suse.de>]

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