[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [patch] ioctl BLKGETSIZE64 fix




On Thu, 15 Dec 2005, Coywolf Qi Hunt wrote:
> 
> Two years ago, "[PATCH] use size_t for the broken ioctl numbers" brought in the problem.
> <http://lkml.org/lkml/2003/9/7/14> (also FYI: <https://lwn.net/Articles/48360/>)
> 
> The patch below fixes the bug on BLKGETSIZE64. typeof(size_t) == 32, but we expect 64. 
> The choice of `size_t' is also a mistake. We should have taken `int'.  This also affects
> userland linux-kernel-headers.
> 
> Or am I missing something? Thanks.

You're missing the fact that we can't just change existing numbers. It 
just makes the ioctl not work.

A lot of the "size_t"'s got added because people had mis-understood the 
_IOR/W macros, and had done a "sizeof()" by hand, when the macro itself 
did the sizeof. Which caused the macro to make the ioctl number be based 
on "sizeof(sizeof(realsize))", which is the same as "sizeof(size_t)".

And because we MUST NOT change the ioctl number (regardless of whether the 
number shows the correct size or not), those got changed to use "size_t" 
to match historical - if incorrect - numbering.

The _IOR/W macros got fixed so that you now _cannot_ use anything but a 
real type, so the bug shouldn't happen again, but we're stuck with the old 
broken numbers.

The number is just a number, after all. We shouldn't be using the size 
encoding in the ioctl number, afaik (since for a _lot_ of them we can't 
depend on it anyway).

		Linus



Reply to: