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) :
--- 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.