LOOP_CONFIGURE ioctl doesn't work if lo_offset/lo_sizelimit are set

LOOP_CONFIGURE ioctl doesn't work if lo_offset/lo_sizelimit are set

[Lennart Poettering]

Hi!

Even with fe6a8fc5ed2f0081f17375ae2005718522c392c6 the LOOP_CONFIGURE
ioctl doesn't work correctly. It gets confused if the
lo_offset/lo_sizelimit fields are set to non-zero.

In a quick test I ran (on Linux 5.8.3) I call LOOP_CONFIGURE with
.lo_offset=3221204992 and .lo_sizelimit=50331648 and immediately
verify the size of the block device with BLKGETSIZE64. It should of
course return 50331648, but actually returns 3271557120. (the precise
values have no particular relevance, it's just what I happened to use
in my test.) If I instead use LOOP_SET_STATUS64 with the exact same
parameters, everything works correctly. In either case, if I use
LOOP_GET_STATUS64 insted of BLKGETSIZE64 to verify things, everything
looks great.

My guess is that the new ioctl simply doesn't properly propagate the
size limit into the underlying block device like it should. I didn't
have the time to investigate further though.

Lennart

Re: LOOP_CONFIGURE ioctl doesn't work if lo_offset/lo_sizelimit are set

[Martijn Coenen]

Hi Lennart,

Thanks for the report, I'll look into it. FWIW, we've been using
LOOP_CONFIGURE on Android with lo_offset/lo_sizelimit without issues,
but it may be a particular configuration that's causing issues.

Thanks,
Martijn

On Mon, Aug 24, 2020 at 5:44 PM Lennart Poettering <mzxreary@0pointer.de> wrote:
>
> Hi!
>
> Even with fe6a8fc5ed2f0081f17375ae2005718522c392c6 the LOOP_CONFIGURE
> ioctl doesn't work correctly. It gets confused if the
> lo_offset/lo_sizelimit fields are set to non-zero.
>
> In a quick test I ran (on Linux 5.8.3) I call LOOP_CONFIGURE with
> .lo_offset=3221204992 and .lo_sizelimit=50331648 and immediately
> verify the size of the block device with BLKGETSIZE64. It should of
> course return 50331648, but actually returns 3271557120. (the precise
> values have no particular relevance, it's just what I happened to use
> in my test.) If I instead use LOOP_SET_STATUS64 with the exact same
> parameters, everything works correctly. In either case, if I use
> LOOP_GET_STATUS64 insted of BLKGETSIZE64 to verify things, everything
> looks great.
>
> My guess is that the new ioctl simply doesn't properly propagate the
> size limit into the underlying block device like it should. I didn't
> have the time to investigate further though.
>
> Lennart

Re: LOOP_CONFIGURE ioctl doesn't work if lo_offset/lo_sizelimit are set

[Martijn Coenen]

Hi,

I just sent a patch to fix the issue. The loop device would have
respected the configuration, but indeed the size of the underlying
block device was not set correctly, so reading back the size would
give the wrong result.

Thanks,
Martijn

On Mon, Aug 24, 2020 at 8:24 PM Martijn Coenen <maco@android.com> wrote:
>
> Hi Lennart,
>
> Thanks for the report, I'll look into it. FWIW, we've been using
> LOOP_CONFIGURE on Android with lo_offset/lo_sizelimit without issues,
> but it may be a particular configuration that's causing issues.
>
> Thanks,
> Martijn
>
> On Mon, Aug 24, 2020 at 5:44 PM Lennart Poettering <mzxreary@0pointer.de> wrote:
> >
> > Hi!
> >
> > Even with fe6a8fc5ed2f0081f17375ae2005718522c392c6 the LOOP_CONFIGURE
> > ioctl doesn't work correctly. It gets confused if the
> > lo_offset/lo_sizelimit fields are set to non-zero.
> >
> > In a quick test I ran (on Linux 5.8.3) I call LOOP_CONFIGURE with
> > .lo_offset=3221204992 and .lo_sizelimit=50331648 and immediately
> > verify the size of the block device with BLKGETSIZE64. It should of
> > course return 50331648, but actually returns 3271557120. (the precise
> > values have no particular relevance, it's just what I happened to use
> > in my test.) If I instead use LOOP_SET_STATUS64 with the exact same
> > parameters, everything works correctly. In either case, if I use
> > LOOP_GET_STATUS64 insted of BLKGETSIZE64 to verify things, everything
> > looks great.
> >
> > My guess is that the new ioctl simply doesn't properly propagate the
> > size limit into the underlying block device like it should. I didn't
> > have the time to investigate further though.
> >
> > Lennart