On Thu, Nov 24, 2022 at 01:48:08PM -0500, John Aron wrote:
> Hello -
>
>
>
> I have an idea of where to begin: our kernel code compiles and works on Red
> Hat, CentOS, and Fedora. In Ubuntu 20.04, I have an error.
>
>
>
> root@form:/home/john/thor-linux/Kernel/ubuntu20.04# make
>
> rmmod: ERROR: Module thor is not currently loaded
>
> make: [Makefile:7: all] Error 1 (ignored)
>
> make[1]: Entering directory '/usr/src/linux-headers-5.4.0-131-generic'
>
> CC [M] /home/john/thor-linux/Kernel/ubuntu22.04/thor.o
>
> /home/john/thor-linux/Kernel/ubuntu22.04/thor.o: warning: objtool:
> _Controller_process_response_map()+0x1b3: unreachable instruction
>
> Building modules, stage 2.
>
> MODPOST 1 modules
>
> CC [M] /home/john/thor-linux/Kernel/ubuntu22.04/thor.mod.o
>
> LD [M] /home/john/thor-linux/Kernel/ubuntu22.04/thor.ko
>
> make[1]: Leaving directory '/usr/src/linux-headers-5.4.0-131-generic'
>
> make[1]: Entering directory '/usr/src/linux-headers-5.4.0-131-generic'
>
> CLEAN /home/john/thor-linux/Kernel/ubuntu22.04/Module.symvers
>
> make[1]: Leaving directory '/usr/src/linux-headers-5.4.0-131-generic'
>
> #@sudo dmesg -C
>
> #@sudo insmod /usr/local/etc/thor.ko
>
> filename: /usr/local/etc/thor.ko
>
> version: 0.1
>
> description: THOR KMOD
>
> author: Aronetics
>
> license: GPL
>
> srcversion: BC856FA85DB2FEFD38A1B2A
>
> depends:
>
> retpoline: Y
>
> name: thor
>
> vermagic: 5.4.0-131-generic SMP mod_unload modversions
>
> #@sudo dmesg
>
> root@form:/home/john/thor-linux/Kernel/ubuntu20.04#
> <mailto:root@form:/home/john/thor-linux/Kernel/ubuntu20.04#>
>
>
>
> Every 2.0s: tail -n30 /var/lib/dkms/thor/1.0.1/build/make.log
>
>
>
> DKMS make.log for thor-1.0.1 for kernel 5.4.0-131-generic (x86_64)
>
> Thu 24 Nov 2022 01:10:33 PM EST
>
> make: Entering directory '/usr/src/linux-headers-5.4.0-131-generic'
>
> CC [M] /var/lib/dkms/thor/1.0.1/build/thor.o
>
> /var/lib/dkms/thor/1.0.1/build/thor.o: warning: objtool:
> _Controller_process_response_map()+0x1b3: unreachable instruction
>
> Building modules, stage 2.
>
> MODPOST 1 modules
>
> CC [M] /var/lib/dkms/thor/1.0.1/build/thor.mod.o
>
> LD [M] /var/lib/dkms/thor/1.0.1/build/thor.ko
>
> make: Leaving directory '/usr/src/linux-headers-5.4.0-131-generic'
>
>
>
> Is this an error in objtool on Ubuntu within
> /usr/src/linux-headers-5.4.0-${26-130}/tools/objtool ?
Do you have a pointer to your code anywhere? Do you have .S files in
it, or is it all C files?
And did you ask the Canonical developers about this? You should have a
support contract you are paying for with them, so why not use that?
thanks,
greg k-h
This bug is marked as fixed by commit:
ext4: block range must be validated before use in ext4_mb_clear_bb()
But I can't find it in any tested tree for more than 90 days.
Is it a correct commit? Please update it by replying:
#syz fix: exact-commit-title
Until then the bug is still considered open and
new crashes with the same signature are ignored.
The condition detecting whether somebody else has the device exclusively
open in disk_scan_partitions() has a brownpaper bag bug. It triggers also
when nobody has the device exclusively open and we are coming from
BLKRRPART path. Interestingly this didn't have any adverse effects
during testing because tools update kernel's notion of the partition
table using ioctls and don't rely on BLKRRPART. Fix the bug before
somebody trips over it.
Fixes: 8d67fc20caf8 ("block: Do not reread partition table on exclusively open device")
CC: stable(a)vger.kernel.org
Signed-off-by: Jan Kara <jack(a)suse.cz>
---
block/genhd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/genhd.c b/block/genhd.c
index 012529d36f5b..29fb2c98b401 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -367,7 +367,7 @@ int disk_scan_partitions(struct gendisk *disk, fmode_t mode, void *owner)
if (disk->open_partitions)
return -EBUSY;
/* Someone else has bdev exclusively open? */
- if (disk->part0->bd_holder != owner)
+ if (disk->part0->bd_holder && disk->part0->bd_holder != owner)
return -EBUSY;
set_bit(GD_NEED_PART_SCAN, &disk->state);
--
2.35.3