All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: "Krzysztof Olędzki" <ole@ans.pl>,
	"Sinan Kaya" <sinan.kaya@microsoft.com>,
	"Karel Zak" <kzak@redhat.com>
Cc: util-linux@vger.kernel.org, linux-block@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Commit d5fd456c88aba4fcf77d35fe38024a8d5c814686 - "loopdev: use LOOP_CONFIG ioctl" broke loop on x86-64 w/ 32 bit userspace
Date: Tue, 27 Jul 2021 19:24:18 -0600	[thread overview]
Message-ID: <c1c9d728-c4d9-eaf4-63c3-d13b99da3a3d@kernel.dk> (raw)
In-Reply-To: <7de1bd0b-b8ea-daf0-b677-f92db1c1cdff@ans.pl>

On 7/27/21 4:56 PM, Krzysztof Olędzki wrote:
> On 2021-07-27 at 15:39, Krzysztof Olędzki wrote:
>> On 2021-07-27 at 14:53, Krzysztof Olędzki wrote:
>>> Hi,
>>>
>>> I have a number of (older) systems that are still based on 32 bit
>>> userspace but are running a relatively modern 64 bit kernel -
>>> 5.4-stable, where BTW - LOOP_CONFIGURE is not yet available.
>>>
>>> I noticed that starting with util-linux-2.37 it is no longer possible to
>>> mount images using loop:
>>>
>>> # mount /usr/install/iso/systemrescue-8.04-amd64.iso /mnt/cdrom
>>> mount: /mnt/cdrom: failed to setup loop device for
>>> /usr/install/iso/systemrescue-8.04-amd64.iso.
>>>
>>> Reverting d5fd456c88aba4fcf77d35fe38024a8d5c814686 fixes the problem:
>>>
>>> /tmp/util-linux-2.37# ./mount
>>> /usr/install/iso/systemrescue-8.04-amd64.iso /mnt/cdrom
>>> mount: /mnt/cdrom: WARNING: source write-protected, mounted read-only.
>>>
>>> I have not tested if 32 bit kernel + 32 bit userspace is also affected,
>>> but 64 bit kernel + 64 bit userspace works.
>>
>> Some debugging data:
>>
>> 30399: loopdev:      CXT: [0xff8d0f98]: using loop-control
>> 30399: loopdev:      CXT: [0xff8d0f98]: loop0 name assigned
>> 30399: loopdev:      CXT: [0xff8d0f98]: find_unused by loop-control [rc=0]
>> 30399: libmount:     LOOP: [0x57cbbcb0]: trying to use /dev/loop0
>> 30399: loopdev:      CXT: [0xff8d0f98]: set backing file=/usr/install/iso/systemrescue-8.04-amd64.iso
>> 30399: loopdev:      CXT: [0xff8d0f98]: set flags=4
>> 30399: loopdev:    SETUP: [0xff8d0f98]: device setup requested
>> 30399: loopdev:    SETUP: [0xff8d0f98]: backing file open: OK
>> 30399: loopdev:      CXT: [0xff8d0f98]: open /dev/loop0 [rw]: Success
>> 30399: loopdev:    SETUP: [0xff8d0f98]: device open: OK
>> 30399: loopdev:    SETUP: [0xff8d0f98]: LOOP_CONFIGURE failed: Inappropriate ioctl for device
>> 30399: loopdev:    SETUP: [0xff8d0f98]: failed [rc=-25]
>> 30399: libmount:     LOOP: [0x57cbbcb0]: failed to setup device
>> 30399: loopdev:      CXT: [0xff8d0f98]: de-initialize
>> 30399: loopdev:      CXT: [0xff8d0f98]: closing old open fd
>> 30399: loopdev:     ITER: [0xff8d1168]: de-initialize
>> 30399: libmount:      CXT: [0x57cbbcb0]: mount: preparing failed
>> 30399: libmount:      CXT: [0x57cbbcb0]: excode: rc=32 message="failed to setup loop device for /usr/install/iso/systemrescue-8.04-amd64.iso"
>> mount: /mnt/cdrom: failed to setup loop device for /usr/install/iso/systemrescue-8.04-amd64.iso.
>> 30399: libmount:      CXT: [0x57cbbcb0]: <---- reset [status=0] ---->
>>
>> Seems like the code expects EINVAL (-22) but gets ENOTTY (-25), confirmed with strace:
>> ioctl(4, LOOP_CONFIGURE, {fd=3, block_size=0, info={lo_offset=0, lo_number=0, lo_flags=LO_FLAGS_AUTOCLEAR, lo_file_name="/usr/install/iso/systemrescue-8.04-amd64.iso", ...}}) = -1 ENOTTY (Inappropriate ioctl for device)
>>
>> Indeed, changing the code from:
>>     if (errno != EINVAL)
>> to:
>>     if (errno != EINVAL && errno != ENOTTY)
>> allows it to work.
>>
>> Not that with 64-bit userspace, kernel returns EINVAL:
>>
>> ioctl(4, LOOP_CONFIGURE, {fd=3, block_size=0, info={lo_offset=0, lo_number=0, lo_flags=LO_FLAGS_AUTOCLEAR, lo_file_name="/usr/src/PACKAGES/systemrescue-8.04-amd64.iso", ...}}) = -1 EINVAL (Invalid argument)
> 
> ... which is because lo_compat_ioctl returns -ENOIOCTLCMD for 
> unsupported cmds, while lo_ioctl returns -EINVAL via lo_simple_ioctl.
> 
> And vfs_ioctl returns -ENOTTY for -ENOIOCTLCMD.
> 
> Now the question is if this inconsistency is intended? :)

That's unfortunate, but probably not something that can get corrected at
this time. The correct return value for an unknown ioctl is -ENOTTY
(ENOIOCTLCMD isn't user visible, should get turned into that). But
current behavior is set in stone at this point, even if it is
technically incorrect.

-- 
Jens Axboe


  reply	other threads:[~2021-07-28  1:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-27 21:53 Commit d5fd456c88aba4fcf77d35fe38024a8d5c814686 - "loopdev: use LOOP_CONFIG ioctl" broke loop on x86-64 w/ 32 bit userspace Krzysztof Olędzki
2021-07-27 22:39 ` Krzysztof Olędzki
2021-07-27 22:56   ` Krzysztof Olędzki
2021-07-28  1:24     ` Jens Axboe [this message]
2021-07-28  5:46       ` Krzysztof Olędzki
2021-07-28  9:14         ` Karel Zak
2021-07-28 18:00           ` Sinan Kaya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c1c9d728-c4d9-eaf4-63c3-d13b99da3a3d@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=kzak@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ole@ans.pl \
    --cc=sinan.kaya@microsoft.com \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.