hi Emil,
thank you for this investigation, this history.
for the moment, I simply reversed the function bio_check_ro and the
compilation is ok.
I will have to test to see if the blocking is well done...
$ diff -u linux-6.1.15.original/block/blk-core.c
linux-6.1.15.me/block/blk-core.c
--- linux-6.1.15.original/block/blk-core.c 2023-03-03 11:52:25.000000000
+0100
+++ linux-6.1.15.me/block/blk-core.c 2023-03-15 13:24:24.680237258 +0100
@@ -485,15 +485,17 @@
late_initcall(fail_make_request_debugfs);
#endif /* CONFIG_FAIL_MAKE_REQUEST */
-static inline void bio_check_ro(struct bio *bio)
+static inline bool bio_check_ro(struct bio *bio)
{
if (op_is_write(bio_op(bio)) && bdev_read_only(bio->bi_bdev)) {
if (op_is_flush(bio->bi_opf) && !bio_sectors(bio))
- return;
+ return false;
pr_warn("Trying to write to read-only block-device %pg\n",
bio->bi_bdev);
/* Older lvm-tools actually trigger this */
+ return true;
}
+ return false;
}
I made some tests with archlinux-2023.03.01-x86_64.iso to answer my
question about the need to continue to make a correction : the answer is
yes it is necessary to correct because LVM alters the device set in
read-only mode.
/tmp : file lvm.disk
lvm.disk: QEMU QCOW Image (v3), 268435456 bytes, AES-encrypted (v3),
268435456 bytes
/tmp : sha256sum lvm.disk
55a9af5144edf235cf0ac16fc60a8dab3c88a0d3451eb6e4d61373e0ad80cb82 lvm.disk
/tmp : qemu -cdrom /mnt/archlinux-2023.03.01-x86_64.iso
root@archiso ~ # cat /etc/udev/rules.d/09-scalpel.rules
KERNEL!="ram*", SUBSYSTEM=="block", RUN+="/usr/local/sbin/rodev /dev/%k"
KERNEL=="rtc*", SUBSYSTEM=="rtc", MODE="0400"
root@archiso ~ # cat /usr/local/sbin/rodev
#!/usr/bin/bash
[ ! "${1}" ] && echo "error: device missing" >/dev/stderr && exit 1
[ "${2}" ] && echo "error: too many devices" >/dev/stderr && exit 1
chmod 440 "${1}"
blockdev --setro "${1}"
root@archiso ~ # chmod +x !$
chmod +x /usr/local/sbin/rodev
root@archiso ~ # udevadm control --reload-rules && udevadm trigger
(qemu) drive_add 0 if=none,file=/tmp/lvm.disk,id=usbdrv
(qemu) device_add usb-storage,drive=usbdrv,id=usbkey
Mar 16 10:07:51 archiso kernel: usb 2-3: new SuperSpeed USB device
number 3 using xhci_hcd
Mar 16 10:07:51 archiso kernel: usb 2-3: New USB device found,
idVendor=46f4, idProduct=0001, bcdDevice= 0.00
Mar 16 10:07:51 archiso kernel: usb 2-3: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Mar 16 10:07:51 archiso kernel: usb 2-3: Product: QEMU USB HARDDRIVE
Mar 16 10:07:51 archiso kernel: usb 2-3: Manufacturer: QEMU
Mar 16 10:07:51 archiso kernel: usb 2-3: SerialNumber: 1-0000:00:03.0-3
Mar 16 10:07:51 archiso kernel: usb-storage 2-3:1.0: USB Mass Storage
device detected
Mar 16 10:07:51 archiso kernel: scsi host6: usb-storage 2-3:1.0
Mar 16 10:07:52 archiso kernel: scsi 6:0:0:0: Direct-Access QEMU
QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5
Mar 16 10:07:52 archiso kernel: sd 6:0:0:0: Power-on or device reset
occurred
Mar 16 10:07:52 archiso kernel: sd 6:0:0:0: [sda] 524288 512-byte
logical blocks: (268 MB/256 MiB)
Mar 16 10:07:52 archiso kernel: sd 6:0:0:0: [sda] Write Protect is off
Mar 16 10:07:52 archiso kernel: sd 6:0:0:0: [sda] Mode Sense: 63 00 00
08
Mar 16 10:07:52 archiso kernel: sd 6:0:0:0: [sda] Write cache: enabled,
read cache: enabled, doesn't support DPO or FUA
Mar 16 10:07:52 archiso kernel: sda: sda1 sda2 sda3
Mar 16 10:07:52 archiso kernel: sd 6:0:0:0: [sda] Attached SCSI disk
Mar 16 10:07:52 archiso lvm[1047]: PV /dev/sda3 online, VG test.lvm
incomplete (need 2).
Mar 16 10:07:52 archiso lvm[1049]: PV /dev/sda1 online, VG test.lvm
incomplete (need 1).
Mar 16 10:07:52 archiso lvm[1048]: PV /dev/sda2 online, VG test.lvm is
complete.
Mar 16 10:07:52 archiso kernel: raid6: skipped pq benchmark and
selected sse2x4
Mar 16 10:07:52 archiso kernel: raid6: using intx1 recovery algorithm
Mar 16 10:07:52 archiso kernel: xor: measuring software checksum speed
Mar 16 10:07:52 archiso kernel: prefetch64-sse : 34921 MB/sec
Mar 16 10:07:52 archiso kernel: generic_sse : 31738 MB/sec
Mar 16 10:07:52 archiso kernel: xor: using function: prefetch64-sse
(34921 MB/sec)
Mar 16 10:07:52 archiso kernel: async_tx: api initialized (async)
Mar 16 10:07:52 archiso kernel: device-mapper: raid: Loading target
version 1.15.1
Mar 16 10:07:52 archiso kernel: md/raid1:mdX: active with 3 out of 3
mirrors
Mar 16 10:07:52 archiso kernel: Trying to write to read-only
block-device dm-0
Mar 16 10:07:52 archiso kernel: Trying to write to read-only
block-device dm-2
Mar 16 10:07:52 archiso kernel: Trying to write to read-only
block-device dm-4
Mar 16 10:07:52 archiso kernel: Trying to write to read-only
block-device dm-0
Mar 16 10:07:52 archiso kernel: Trying to write to read-only
block-device sda1
Mar 16 10:07:52 archiso kernel: Trying to write to read-only
block-device dm-2
Mar 16 10:07:52 archiso kernel: Trying to write to read-only
block-device sda2
Mar 16 10:07:52 archiso kernel: Trying to write to read-only
block-device dm-4
Mar 16 10:07:52 archiso kernel: Trying to write to read-only
block-device sda3
Mar 16 10:07:52 archiso systemd[1]: Started Device-mapper event daemon.
Mar 16 10:07:53 archiso dmeventd[1114]: dmeventd ready for processing.
Mar 16 10:07:53 archiso dmeventd[1114]: Monitoring RAID device
test.lvm-lvm.test for events.
Mar 16 10:07:53 archiso lvm[1060]: 1 logical volume(s) in volume
group "test.lvm" now active
Mar 16 10:07:53 archiso systemd[1]: lvm-activate-test.lvm.service:
Deactivated successfully.
Mar 16 10:08:08 archiso kernel: Trying to write to read-only
block-device dm-0
Mar 16 10:08:08 archiso kernel: Trying to write to read-only
block-device dm-2
Mar 16 10:08:08 archiso kernel: Trying to write to read-only
block-device dm-4
Mar 16 10:08:08 archiso kernel: Trying to write to read-only
block-device dm-0
Mar 16 10:08:08 archiso kernel: Trying to write to read-only
block-device sda1
Mar 16 10:08:08 archiso kernel: Trying to write to read-only
block-device dm-2
Mar 16 10:08:08 archiso kernel: Trying to write to read-only
block-device sda2
Mar 16 10:08:08 archiso kernel: Trying to write to read-only
block-device dm-4
Mar 16 10:08:08 archiso kernel: Trying to write to read-only
block-device sda3
root@archiso ~ # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 688.5M 1 loop
/run/archiso/airootfs
sda 8:0 0 256M 1 disk
├─sda1 8:1 0 83M 1 part
│ ├─test.lvm-lvm.test_rmeta_0 254:0 0 4M 1 lvm
│ │ └─test.lvm-lvm.test 254:6 0 64M 1 lvm
│ └─test.lvm-lvm.test_rimage_0 254:1 0 64M 1 lvm
│ └─test.lvm-lvm.test 254:6 0 64M 1 lvm
├─sda2 8:2 0 83M 1 part
│ ├─test.lvm-lvm.test_rmeta_1 254:2 0 4M 1 lvm
│ │ └─test.lvm-lvm.test 254:6 0 64M 1 lvm
│ └─test.lvm-lvm.test_rimage_1 254:3 0 64M 1 lvm
│ └─test.lvm-lvm.test 254:6 0 64M 1 lvm
└─sda3 8:3 0 83M 1 part
├─test.lvm-lvm.test_rmeta_2 254:4 0 4M 1 lvm
│ └─test.lvm-lvm.test 254:6 0 64M 1 lvm
└─test.lvm-lvm.test_rimage_2 254:5 0 64M 1 lvm
└─test.lvm-lvm.test 254:6 0 64M 1 lvm
sr0 11:0 1 810.3M 1 rom
/run/archiso/bootmnt
root@archiso ~ # dd if=/dev/zero of=/dev/sda bs=1M count=16
dd: error writing '/dev/sda': Operation not permitted
1+0 records in
0+0 records out
0 bytes copied, 0.00814249 s, 0.0 kB/s
/tmp : sha256sum lvm.disk
1a11bb40ee4887d0dabd9fca2224cf7219bb37d7efe2a8fbd73a4b656213c228 lvm.disk
root@archiso ~ # pvdisplay
--- Physical volume ---
PV Name /dev/sda1
VG Name test.lvm
PV Size <83.01 MiB / not usable <3.01 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 20
Free PE 3
Allocated PE 17
PV UUID mQR1eS-K5Zf-5lfl-Dupc-lRhN-Yfpf-7Vl36V
--- Physical volume ---
PV Name /dev/sda2
VG Name test.lvm
PV Size <83.01 MiB / not usable <3.01 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 20
Free PE 3
Allocated PE 17
PV UUID As2RrD-Cev0-hhB7-yohn-r5ym-P34m-MFV0M9
--- Physical volume ---
PV Name /dev/sda3
VG Name test.lvm
PV Size <83.01 MiB / not usable <3.01 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 20
Free PE 3
Allocated PE 17
PV UUID khaOAc-YEX4-bi0u-fdtq-doG9-Wuok-B2kCS8
root@archiso ~ # vgdisplay
--- Volume group ---
VG Name test.lvm
System ID
Format lvm2
Metadata Areas 3
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 3
Act PV 3
VG Size 240.00 MiB
PE Size 4.00 MiB
Total PE 60
Alloc PE / Size 51 / 204.00 MiB
Free PE / Size 9 / 36.00 MiB
VG UUID sttYAJ-VmEf-biZh-C8Uh-jUCK-orFO-WVNX6t
root@archiso ~ # vgchange -ay test.lvm
1 logical volume(s) in volume group "test.lvm" now active
/tmp : sha256sum lvm.disk
c39d62a5e9f87dc33339098c64903b56b2d3ac5248d2f34c10e63241a10a35b3 lvm.disk
root@archiso ~ # lvdisplay
--- Logical volume ---
LV Path /dev/test.lvm/lvm.test
LV Name lvm.test
VG Name test.lvm
LV UUID G1y4A0-LbbZ-na9w-AJrQ-jVtc-pKDo-RKgc0S
LV Write Access read/write (activated read only)
LV Creation host, time scalpel, 2019-03-12 14:59:02 +0000
LV Status available
# open 0
LV Size 64.00 MiB
Current LE 16
Mirrored volumes 3
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:6
root@archiso ~ # mount /dev/test.lvm/lvm.test /mnt
mount: /mnt: WARNING: source write-protected, mounted read-only.
root@archiso ~ # ll /mnt
total 16
drwx------ 2 root root 12288 Mar 12 2019 lost+found
-rwxr-xr-x 1 root root 3155 Mar 12 2019 lvm.md
root@archiso ~ # umount /mnt
(qemu) device_del usbkey
Mar 16 10:21:07 archiso kernel: usb 2-3: USB disconnect, device number 3
Mar 16 10:21:07 archiso kernel: sd 6:0:0:0: [sda] Synchronizing SCSI
cache
Mar 16 10:21:07 archiso kernel: sd 6:0:0:0: [sda] Synchronize Cache(10)
failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Mar 16 10:21:07 archiso (udev-worker)[1276]: sda2: Process
'/usr/local/sbin/rodev /dev/sda2' failed with exit code 1.
Mar 16 10:21:07 archiso systemd-homed[268]: block device
/sys/devices/pci0000:00/0000:00:03.0/usb2/2-3/2-3:1.0/host6/target6:0:0/6:0:0:0/block/sda/sda2
has been removed.
Mar 16 10:21:07 archiso (udev-worker)[1275]: sda1: Process
'/usr/local/sbin/rodev /dev/sda1' failed with exit code 1.
Mar 16 10:21:07 archiso systemd-homed[268]: block device
/sys/devices/pci0000:00/0000:00:03.0/usb2/2-3/2-3:1.0/host6/target6:0:0/6:0:0:0/block/sda/sda1
has been removed.
Mar 16 10:21:07 archiso (udev-worker)[1277]: sda3: Process
'/usr/local/sbin/rodev /dev/sda3' failed with exit code 1.
Mar 16 10:21:07 archiso systemd-homed[268]: block device
/sys/devices/pci0000:00/0000:00:03.0/usb2/2-3/2-3:1.0/host6/target6:0:0/6:0:0:0/block/sda/sda3
has been removed.
Mar 16 10:21:07 archiso (udev-worker)[1276]: sda: Process
'/usr/local/sbin/rodev /dev/sda' failed with exit code 1.
Mar 16 10:21:07 archiso systemd-homed[268]: block device
/sys/devices/pci0000:00/0000:00:03.0/usb2/2-3/2-3:1.0/host6/target6:0:0/6:0:0:0/block/sda
has been removed.
/tmp : sha256sum lvm.disk
c39d62a5e9f87dc33339098c64903b56b2d3ac5248d2f34c10e63241a10a35b3 lvm.disk
LVM, even in recent version, does not take into account the read-only
mode...
regards, lacsaP.
Le mer. 15 mars 2023 à 16:36, Emil Velikov <emil.l.veli...@gmail.com> a
écrit :
> Greetings Pascal,
>
> After following the links I see what's happening. Essentially:
> - Kernel gained RO/RW correctness check - circa Jan 2018, kernel
> commit 721c7fc701c71f693307d274d2b346a1ecd4a534
> - LVM was initially buggy but later fixed, circa Mar 2018,
> - Kernel check got partially reverted because broken LVM is still
> used - circa Aug 2018, kernel commit
> a32e236eb93e62a0f692e79b7c3c9636689559b9
> - People used an out of tree patch, reinstating the correctness check
> - The function return type was dropped since it is unused - Sep 2022,
> kernel commit bdb7d420c6f6d2618d4c907cd7742c3195c425e2
> - kernel patch no longer applies, correct behaviour cannot be enforced
>
> To unblock yourself, it will be a matter of reverting
> bdb7d420c6f6d2618d4c907cd7742c3195c425e2 and then
> a32e236eb93e62a0f692e79b7c3c9636689559b9.
>
> For the mid/long run, one should consider a proper upstream solution:
>
> Assuming I'm in your position, I would dig through the data in the
> linked commits and estimate which/how many distributions ship with
> buggy LVM. Then formulate a comprehensive cover letter, proposing a)
> reverts (if LVM is no longer used in the wild) or b) reverts && a
> (KCONFIG, sysctl, other) toggle to control the behaviour.
>
> Hope that helps,
> Emil
>
> On Wed, 15 Mar 2023 at 13:38, Pascal <patate...@gmail.com> wrote:
> >
> > hi Emil,
> >
> > in view of your answer and after rereading my email, I realize that I
> was confused in my request.
> > here it is, I hope, more clearly reformulated :-)
> >
> > first of all, I use ArchLinux to, from time to time, compile the
> slightly modified LTS kernel, and this from PKGBUILD provided by ArchLinux
> at some point.
> >
> > some technologies such as LVM do not take into account the read-only
> applied on a block device.
> > see the two links provided in the previous exchanges for more details...
> >
> >
> > until now, I recompiled the kernel by applying a slight modification to
> the bio_check_ro function present in the blk-core.c source file.
> > the last time I made this modification was on the Linux-LTS-5.10.19
> kernel :
> > (
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v5.10.19
> )
> >
> > $ diff -u 5.10.19.original/blk-core.c 5.10.19.me/blk-core.c
> > --- 5.10.19.original/blk-core.c 2023-03-15 13:44:20.176929833 +0100
> > +++ 5.10.19.me/blk-core.c 2023-03-15 13:44:02.353596114 +0100
> > @@ -706,7 +706,7 @@
> > "Trying to write to read-only block-device %s (partno %d)\n",
> > bio_devname(bio, b), part->partno);
> > /* Older lvm-tools actually trigger this */
> > - return false;
> > + return true;
> > }
> >
> > return false;
> >
> > the compilation of the modified LTS 5.10.19 kernel went well and the
> correction seems to do the job...
> >
> >
> > since this last time (2022/01), the source file blk-core.c has been
> modified a lot and the bio_check_ro function is part of these modifications
> :
> > (
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v6.1.15
> )
> >
> > $ diff -u 5.10.19.original/blk-core.c 6.1.15.original/blk-core.c
> > --- 5.10.19.original/blk-core.c 2023-03-15 13:44:20.176929833 +0100
> > +++ 6.1.15.original/blk-core.c 2023-03-15 13:50:36.560271323 +0100
> > @@ -14,11 +14,10 @@
> > */
> > #include <linux/kernel.h>
> > #include <linux/module.h>
> > -#include <linux/backing-dev.h>
> > #include <linux/bio.h>
> > #include <linux/blkdev.h>
> > -#include <linux/blk-mq.h>
> > ...
> > @@ -681,40 +483,22 @@
> > }
> >
> > late_initcall(fail_make_request_debugfs);
> > -
> > -#else /* CONFIG_FAIL_MAKE_REQUEST */
> > -
> > -static inline bool should_fail_request(struct hd_struct *part,
> > - unsigned int bytes)
> > -{
> > - return false;
> > -}
> > -
> > #endif /* CONFIG_FAIL_MAKE_REQUEST */
> >
> > -static inline bool bio_check_ro(struct bio *bio, struct hd_struct *part)
> > +static inline void bio_check_ro(struct bio *bio)
> > {
> > - const int op = bio_op(bio);
> > -
> > - if (part->policy && op_is_write(op)) {
> > - char b[BDEVNAME_SIZE];
> > -
> > + if (op_is_write(bio_op(bio)) && bdev_read_only(bio->bi_bdev)) {
> > if (op_is_flush(bio->bi_opf) && !bio_sectors(bio))
> > - return false;
> > -
> > - WARN_ONCE(1,
> > - "Trying to write to read-only block-device %s (partno
> %d)\n",
> > - bio_devname(bio, b), part->partno);
> > + return;
> > + pr_warn("Trying to write to read-only block-device %pg\n",
> > + bio->bi_bdev);
> > /* Older lvm-tools actually trigger this */
> > - return false;
> > }
> > -
> > - return false;
> > }
> > ...
> >
> >
> > when I introduce my little modification (see diff below) in the code,
> makepkg fails to compile with the error "return with a value in function
> returning void" (see makepkg below) :
> >
> > $ diff -u 6.1.15.original/blk-core.c 6.1.15.me/blk-core.c
> > --- 6.1.15.original/blk-core.c 2023-03-15 13:50:36.560271323 +0100
> > +++ 6.1.15.me/blk-core.c 2023-03-15 13:56:15.246945330 +0100
> > @@ -493,6 +493,7 @@
> > pr_warn("Trying to write to read-only block-device %pg\n",
> > bio->bi_bdev);
> > /* Older lvm-tools actually trigger this */
> > + return true;
> > }
> > }
> >
> > $ makepkg
> > ...
> > CC block/blk-core.o
> > block/blk-core.c: In function 'bio_check_ro':
> > block/blk-core.c:496:24: error: 'return' with a value, in function
> returning void [-Werror=return-type]
> > 496 | return true;
> > | ^~~~
> > block/blk-core.c:488:20: note: declared here
> > 488 | static inline void bio_check_ro(struct bio *bio)
> > | ^~~~~~~~~~~~
> > cc1: some warnings being treated as errors
> > make[2]: *** [scripts/Makefile.build:250: block/blk-core.o] Error 1
> > make[1]: *** [scripts/Makefile.build:500: block] Error 2
> > make: *** [Makefile:2005: .] Error 2
> >
> >
> > so, how to modify the current code of the bio_check_ro function to get
> the desired result (eg. writes KO on RO blockdevice) ?
> > with the changes in the blk-core.c source code since version 5.10.19, is
> it still necessary to tweak the bio_check_ro function to disallow
> technologies that ignore the read-only block?
> >
> > regards, lacsaP.
> >
> > Le mer. 15 mars 2023 à 12:37, Emil Velikov <emil.l.veli...@gmail.com> a
> écrit :
> >>
> >> Greetings Pascal,
> >>
> >> Couple of suggestions from the peanut gallery, Take them with a heavy
> >> pinch of salt:
> >> - Is the issue happening with upstream code from kernel.org?
> >> - Consider mentioning the commit sha (and URL, if it is missing from
> >> kernel.org) in the email
> >> - Is "intervened" the right word here - the Cambridge dictionary
> >> defines it as "to intentionally become involved in a difficult
> >> situation in order to improve it or prevent it from getting worse"
> >> - Are you contacting a developer only? Have you considered adding the
> >> subsystem maintainer and mailing list in the CC list -
> >> scripts/get_maintainer.pl will give you those
> >> - Have you considered opening a bug report, or better yet sending a
> >> patch? Patch does not have to be perfect and if you have doubts you
> >> can mention those in the email/cover-letter.
> >>
> >> Hope that helps
> >> Emil
> >>
> >> [1] https://dictionary.cambridge.org/dictionary/english/intervene
> >>
> >> On Wed, 15 Mar 2023 at 08:42, Pascal <patate...@gmail.com> wrote:
> >> >
> >> > hi,
> >> >
> >> > I come to you for lack of feedback (I think the Linux kernel
> developers have other cats to whip :-))
> >> > would one of you have the answer or a track to follow concerning the
> question below ?
> >> > the encountered compilation error is behind the forwarded email.
> >> >
> >> > regards, lacsaP.
> >> >
> >> > ---------- Forwarded message ---------
> >> > De : Pascal <patate...@gmail.com>
> >> > Date: mer. 8 mars 2023 à 14:09
> >> > Subject: bio_check_ro @ blk-core.c
> >> >
> >> > hi,
> >> >
> >> > I'm addressing you because you intervened (commit) in the function
> bio_check_ro @ blk-core.c @ Linux-LTS-6.1.15.
> >> > the last time I intervened on this file (@ Linux-LTS-5.10.19 for
> personal use), it was to replace "return false;" by "return true;", which
> theoretically should prevent the possible writing on a device locked in
> read-only mode (see here or here).
> >> > with @ Linux-LTS-6.1.15, if I insert "return true;", I now have a
> compilation error.
> >> > in your opinion, is there still a need to "fix" blk-core.c to prevent
> writing to a read-only locked device and if so, can you help me implement
> this fix?
> >> >
> >> > regards, lacsaP.
> >> > ---------- End forwarded message ---------
> >> >
> >> > SYNC include/config/auto.conf
> >> > CC arch/x86/kernel/asm-offsets.s
> >> > CALL scripts/checksyscalls.sh
> >> > DESCEND objtool
> >> > DESCEND bpf/resolve_btfids
> >> > CC block/bdev.o
> >> > CC block/fops.o
> >> > CC block/bio.o
> >> > CC block/elevator.o
> >> > CC block/blk-core.o
> >> > block/blk-core.c: In function 'bio_check_ro':
> >> > block/blk-core.c:496:24: error: 'return' with a value, in function
> returning void [-Werror=return-type]
> >> > 496 | return true;
> >> > | ^~~~
> >> > block/blk-core.c:488:20: note: declared here
> >> > 488 | static inline void bio_check_ro(struct bio *bio)
> >> > | ^~~~~~~~~~~~
> >> > cc1: some warnings being treated as errors
> >> > make[2]: *** [scripts/Makefile.build:250: block/blk-core.o] Error 1
> >> > make[1]: *** [scripts/Makefile.build:500: block] Error 2
> >> > make: *** [Makefile:2005: .] Error 2
>
