btrfs: add extra error messages to cover non-ENOMEM errors from device_add_list()
authorQu Wenruo <wqu@suse.com>
Mon, 12 Dec 2022 02:19:37 +0000 (10:19 +0800)
committerDavid Sterba <dsterba@suse.com>
Wed, 11 Jan 2023 19:04:12 +0000 (20:04 +0100)
commited02363fbbed52a3f5ea0d188edd09045a806eb5
treeb0cda55eea3a3748666ff07c2b5810045d7d8d5a
parent2ba48b20049b5a76f34a85f853c9496d1b10533a
btrfs: add extra error messages to cover non-ENOMEM errors from device_add_list()

[BUG]
When test case btrfs/219 (aka, mount a registered device but with a lower
generation) failed, there is not any useful information for the end user
to find out what's going wrong.

The mount failure just looks like this:

  #  mount -o loop /tmp/219.img2 /mnt/btrfs/
  mount: /mnt/btrfs: mount(2) system call failed: File exists.
         dmesg(1) may have more information after failed mount system call.

While the dmesg contains nothing but the loop device change:

  loop1: detected capacity change from 0 to 524288

[CAUSE]
In device_list_add() we have a lot of extra checks to reject invalid
cases.

That function also contains the regular device scan result like the
following prompt:

  BTRFS: device fsid 6222333e-f9f1-47e6-b306-55ddd4dcaef4 devid 1 transid 8 /dev/loop0 scanned by systemd-udevd (3027)

But unfortunately not all errors have their own error messages, thus if
we hit something wrong in device_add_list(), there may be no error
messages at all.

[FIX]
Add errors message for all non-ENOMEM errors.

For ENOMEM, I'd say we're in a much worse situation, and there should be
some OOM messages way before our call sites.

CC: stable@vger.kernel.org # 6.0+
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/volumes.c