Fwd: bio_check_ro @ blk-core.c
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
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
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
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
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/...
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/...)*
$ 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/...
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/...)*
$ 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
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
wrote: hi,
I come to you for lack of feedback (I think the Linux kernel developers
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
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
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
have other cats to whip :-)) 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). 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
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
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/...)
$ 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/...)
$ 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
#include -#include #include #include -#include ... @@ -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
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
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
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
hi Emil,
thank you for this investigation, this history.
for the moment, I simply reversed the function bio_check_ro and the
compilation is running...
if all is ok, I will just 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 *.disk
lvm.disk: QEMU QCOW Image (v3), 268435456 bytes, AES-encrypted (v3),
268435456 bytes
/tmp : sha256sum *.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 *.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 *.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 *.disk
c39d62a5e9f87dc33339098c64903b56b2d3ac5248d2f34c10e63241a10a35b3 lvm.disk
the same test was performed with for example Linux Software RAID (mdadm)
and the device is not modified (as expected from being locked in read-only
mode).
in conclusion, it seems that 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
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
wrote: hi Emil,
in view of your answer and after rereading my email, I realize that I
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 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/... )
$ 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/... )
$ 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
#include -#include #include #include -#include ... @@ -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
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
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
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
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
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
was confused in my request. the bio_check_ro function present in the blk-core.c source file. the desired result (eg. writes KO on RO blockdevice) ? 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). 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
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
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
wrote: hi Emil,
in view of your answer and after rereading my email, I realize that I
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 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/... )
$ 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/... )
$ 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
#include -#include #include #include -#include ... @@ -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
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
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
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
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
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
was confused in my request. the bio_check_ro function present in the blk-core.c source file. the desired result (eg. writes KO on RO blockdevice) ? 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). 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
hi Emil,
forgive me if this is the third time I've replied to this message but I
received a moderation warning the two previous times that my reply was over
40Kb when my preparation file was only 13Kb...
I haven't had any feedback about this moderation since last week, so I
don't know if you received my answer...
this one concluded that the recent version of LVM integrated in the ISO
image of ArchLinux modifies a disk, even if this one and all its partitions
are set as read-only (chmod 444 /dev/sdX* && blockdev --setro /dev/sdX*
with udev rule).
thank you for this investigation, this history.
regards; lacsaP.
Le mer. 15 mars 2023 à 16:36, Emil Velikov
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
wrote: hi Emil,
in view of your answer and after rereading my email, I realize that I
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 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/... )
$ 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/... )
$ 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
#include -#include #include #include -#include ... @@ -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
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
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
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
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
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
was confused in my request. the bio_check_ro function present in the blk-core.c source file. the desired result (eg. writes KO on RO blockdevice) ? 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). 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
hi,
back again ;-)
this github page
https://github.com/patatetom/lvm-on-readonly-block-device/blob/main/README.m...
will perhaps allow you to better understand my problem and to guide me
towards a solution.
my main problem is my inability to patch the kernel as I used to do in
order to prevent LVM to modify a read-only disk.
regards, lacsaP.
Le lun. 20 mars 2023 à 10:11, lacsaP Patatetom
hi Emil,
forgive me if this is the third time I've replied to this message but I received a moderation warning the two previous times that my reply was over 40Kb when my preparation file was only 13Kb...
I haven't had any feedback about this moderation since last week, so I don't know if you received my answer...
this one concluded that the recent version of LVM integrated in the ISO image of ArchLinux modifies a disk, even if this one and all its partitions are set as read-only (chmod 444 /dev/sdX* && blockdev --setro /dev/sdX* with udev rule).
thank you for this investigation, this history.
regards; lacsaP.
Le mer. 15 mars 2023 à 16:36, Emil Velikov
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
wrote: hi Emil,
in view of your answer and after rereading my email, I realize that I
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 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/... )
$ 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/... )
$ 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
#include -#include #include #include -#include ... @@ -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
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
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
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
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
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
was confused in my request. the bio_check_ro function present in the blk-core.c source file. the desired result (eg. writes KO on RO blockdevice) ? 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). 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
On Mon, 20 Mar 2023 at 16:49, lacsaP Patatetom
hi,
back again ;-)
this github page will perhaps allow you to better understand my problem and to guide me towards a solution.
my main problem is my inability to patch the kernel as I used to do in order to prevent LVM to modify a read-only disk.
I don't have experience with the kernel block layer, so you're better off asking on the official mailing list (ML). To make your experience smoother, I would suggest using plain text emails [2] and avoiding top-posting [3]. You also might want to have a quick look at their ML archive [4] for other "dos" and "don'ts". HTH Emil [1] linux-block@vger.kernel.org [2] https://www.lifewire.com/how-to-send-a-message-in-plain-text-from-gmail-1171... [3] https://en.wikipedia.org/wiki/Posting_style#Top-posting [4] https://lore.kernel.org/linux-block/
Le mar. 21 mars 2023 à 11:27, Emil Velikov
On Mon, 20 Mar 2023 at 16:49, lacsaP Patatetom
wrote: hi,
back again ;-)
this github page will perhaps allow you to better understand my problem and to guide me towards a solution.
my main problem is my inability to patch the kernel as I used to do in order to prevent LVM to modify a read-only disk.
I don't have experience with the kernel block layer, so you're better off asking on the official mailing list (ML).
To make your experience smoother, I would suggest using plain text emails [2] and avoiding top-posting [3]. You also might want to have a quick look at their ML archive [4] for other "dos" and "don'ts".
HTH Emil
[1] linux-block@vger.kernel.org [2] https://www.lifewire.com/how-to-send-a-message-in-plain-text-from-gmail-1171... [3] https://en.wikipedia.org/wiki/Posting_style#Top-posting [4] https://lore.kernel.org/linux-block/
thanks a lot for everything Emil ! have a good day, regards, lacsaP.
participants (3)
-
Emil Velikov
-
lacsaP Patatetom
-
Pascal