BLKSECTGET userland API breakage (2.4 and 2.6 incompatible)

BLKSECTGET userland API breakage (2.4 and 2.6 incompatible)

[Alexander Viro]

[that had started as "BLKSECTGET 32bit compat is broken"]

Situation:

all 2.4:      BLKSECTGET takes long * and is supported by several block drivers
bio-14-pre9:  Takes BLKSECTGET to drivers/block/blkpg.c, defining it for all
              block drivers *AND* making it take unsigned short *
2.5.1-pre2:   bio merge
all 2.[56] kernels since then: BLKSECTGET takes unsigned short *
32bit compat: unchanged since 2.4 and thus broken on 2.[56]
applications: we have seen ones using 2.6 ABI and getting buggered in
              32bit compat.  Most likely there are some using 2.4 ABI...

IMO the least painful variant is to switch 2.6 compat code to match
2.6 native (i.e. use COMPATIBLE_IOCTL()), leave 2.4 as-is and live
with the fact of userland ABI change between 2.4 and 2.6...

Re: BLKSECTGET userland API breakage (2.4 and 2.6 incompatible)

[David S. Miller]

From: Alexander Viro <aviro@redhat.com>
Date: Thu, 13 Oct 2005 19:49:34 -0400

> all 2.4:      BLKSECTGET takes long * and is supported by several block drivers
> bio-14-pre9:  Takes BLKSECTGET to drivers/block/blkpg.c, defining it for all
>               block drivers *AND* making it take unsigned short *
> 2.5.1-pre2:   bio merge
> all 2.[56] kernels since then: BLKSECTGET takes unsigned short *
> 32bit compat: unchanged since 2.4 and thus broken on 2.[56]
> applications: we have seen ones using 2.6 ABI and getting buggered in
>               32bit compat.  Most likely there are some using 2.4 ABI...
> 
> IMO the least painful variant is to switch 2.6 compat code to match
> 2.6 native (i.e. use COMPATIBLE_IOCTL()), leave 2.4 as-is and live
> with the fact of userland ABI change between 2.4 and 2.6...

Well, what's the userland state and why in the world did this
happen in the first place?

I guess you're right that keeping the 2.6.x ABI for this ioctl
and fixing up the compat code is probably the least painful
thing to do.

Re: BLKSECTGET userland API breakage (2.4 and 2.6 incompatible)

[Jens Axboe]

On Thu, Oct 13 2005, Alexander Viro wrote:
> [that had started as "BLKSECTGET 32bit compat is broken"]
> 
> Situation:
> 
> all 2.4:      BLKSECTGET takes long * and is supported by several block drivers
> bio-14-pre9:  Takes BLKSECTGET to drivers/block/blkpg.c, defining it for all
>               block drivers *AND* making it take unsigned short *
> 2.5.1-pre2:   bio merge
> all 2.[56] kernels since then: BLKSECTGET takes unsigned short *
> 32bit compat: unchanged since 2.4 and thus broken on 2.[56]
> applications: we have seen ones using 2.6 ABI and getting buggered in
>               32bit compat.  Most likely there are some using 2.4 ABI...

Unfortunate situation :(

> IMO the least painful variant is to switch 2.6 compat code to match
> 2.6 native (i.e. use COMPATIBLE_IOCTL()), leave 2.4 as-is and live
> with the fact of userland ABI change between 2.4 and 2.6...

Agree.

-- 
Jens Axboe

Re: BLKSECTGET userland API breakage (2.4 and 2.6 incompatible)

[Jens Axboe]

On Thu, Oct 13 2005, David S. Miller wrote:
> From: Alexander Viro <aviro@redhat.com>
> Date: Thu, 13 Oct 2005 19:49:34 -0400
> 
> > all 2.4:      BLKSECTGET takes long * and is supported by several block drivers
> > bio-14-pre9:  Takes BLKSECTGET to drivers/block/blkpg.c, defining it for all
> >               block drivers *AND* making it take unsigned short *
> > 2.5.1-pre2:   bio merge
> > all 2.[56] kernels since then: BLKSECTGET takes unsigned short *
> > 32bit compat: unchanged since 2.4 and thus broken on 2.[56]
> > applications: we have seen ones using 2.6 ABI and getting buggered in
> >               32bit compat.  Most likely there are some using 2.4 ABI...
> > 
> > IMO the least painful variant is to switch 2.6 compat code to match
> > 2.6 native (i.e. use COMPATIBLE_IOCTL()), leave 2.4 as-is and live
> > with the fact of userland ABI change between 2.4 and 2.6...
> 
> Well, what's the userland state and why in the world did this
> happen in the first place?

Given that this change happened over 4 years ago, I cannot remember the
details of it. But it wasn't a conscious decision to change it, must
have been an unfortunate typo when killing maxsectors[].

-- 
Jens Axboe