November 2021 - kernelnewbies@kernelnewbies.org

When reviewers stop responding
by Ian Pilcher June 22, 2022

June 22, 2022

I am looking for advice on how to proceed when kernel patch reviewers stop responding to patches. I've been working on a patch series for several months - sending 3 "RFC" and 8 non-RFC versions, receiving feedback, and implementing all of the changes that have been requested. I sent the last patch series (version 8) on October 9, and resent it on October 22. I also sent an off-list email to the subsystem maintainer and the (previously) most active reviewer on November 8. I haven't received any responses since October 8. How should I proceed? Thanks! -- ======================================================================== In Soviet Russia, Google searches you! ========================================================================

3 5

error: impossible constraint in 'asm' when compiling kernel code with -O0 option
by ckim＠etri.re.kr Jan. 19, 2022

Jan. 19, 2022

In linux-5.4.21 code, To prevent some variables from being 'optimized out' during kernel code analysis using gdb, I added in drivers/iommu/Makefile, (replacing -O2 flags to -O0 flags for some files, I found http://www.joelfernandes.org/linux/2018/06/10/kernel-gdb.html ) CFLAGS_REMOVE_arm-smmu.o := -O2 CFLAGS_REMOVE_arm-smmu-impl.o := -O2 CFLAGS_REMOVE_io-pgtable-arm-v7s.o := -O2 CFLAGS_REMOVE_io-pgtable-arm.o := -O2 CFLAGS_REMOVE_of_iommu.o := -O2 CFLAGS_REMOVE_arm-smmu-v3.o := -O2 CFLAGS_arm-smmu.o := -O0 CFLAGS_arm-smmu-impl.o := -O0 CFLAGS_io-pgtable-arm-v7s.o := -O0 CFLAGS_io-pgtable-arm.o := -O0 CFLAGS_of_iommu.o := -O0 CFLAGS_arm-smmu-v3.o := -O0 But when I do make ARCH=arm64 CROSS_COMPILE=aarch64-none-elf- Image, I get CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh CHK include/generated/compile.h CC drivers/iommu/io-pgtable-arm.o In file included from ././include/linux/compiler_types.h:68, from <command-line>: ./arch/arm64/include/asm/jump_label.h: In function 'system_uses_lse_atomics': ./include/linux/compiler-gcc.h:120:38: warning: asm operand 0 probably doesn't match constraints 120 | #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0) | ^~~ ./arch/arm64/include/asm/jump_label.h:38:2: note: in expansion of macro 'asm_volatile_goto' 38 | asm_volatile_goto( | ^~~~~~~~~~~~~~~~~ ./include/linux/compiler-gcc.h:120:38: warning: asm operand 0 probably doesn't match constraints 120 | #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0) | ^~~ ./arch/arm64/include/asm/jump_label.h:38:2: note: in expansion of macro 'asm_volatile_goto' 38 | asm_volatile_goto( | ^~~~~~~~~~~~~~~~~ ./include/linux/compiler-gcc.h:120:38: error: impossible constraint in 'asm' 120 | #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0) | ^~~ ./arch/arm64/include/asm/jump_label.h:38:2: note: in expansion of macro 'asm_volatile_goto' 38 | asm_volatile_goto( | ^~~~~~~~~~~~~~~~~ ./include/linux/compiler-gcc.h:120:38: error: impossible constraint in 'asm' 120 | #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0) | ^~~ ./arch/arm64/include/asm/jump_label.h:38:2: note: in expansion of macro 'asm_volatile_goto' 38 | asm_volatile_goto( | ^~~~~~~~~~~~~~~~~ make[2]: *** [scripts/Makefile.build:266: drivers/iommu/io-pgtable-arm.o] Error 1 make[1]: *** [scripts/Makefile.build:509: drivers/iommu] Error 2 make: *** [Makefile:1652: drivers] Error 2 Does anybody know how can I use -O0 flag? (I tried -Og flag but some variables are still optimized out). Thank you! Chan Kim

4 3

x86, nmi: IOCK error
by Muni Sekhar Jan. 8, 2022

Jan. 8, 2022

Hi all, The following message is seen on the console "NMI: IOCK error (debug interrupt?) for reason 60 on CPU 0.", what does it mean? Does this likely confirm the CPU is faulty? If so, how to resolve this? -- Thanks, Sekhar

3 3

Re: dm-verity: How to exactly use the dm-mod.create with verity-metadata append
by Pintu Agarwal Nov. 25, 2021

Nov. 25, 2021

On Tue, 23 Nov 2021 at 22:13, Will Drewry <wad(a)chromium.org> wrote: > > On Tue, Nov 23, 2021 at 4:36 AM Pintu Agarwal <pintu.ping(a)gmail.com> wrote: > > > > Hi, > > > > For rootfs dm-verity I am trying to pass dm-mod.create from our > > bootloader but it seems not working for me. > > So, I need some guidance on the parameters that we pass here. > > The documentation also does not seem to help much. > > > > Kernel: 4.14 (with dm-init patch backported) > > Target: Arm-32 / NAND / Simple Busybox / Bootloader (edk2) > > Build: Ubuntu-18.04 / Yocto 2.6 > > > > Steps I followed: > > 1) First I am trying to generate the root hash for our rootfs using > > the veritysetup command: > > $ ls -l system.img > > 64172032 ==> IMAGE_SIZE > > $ veritysetup format system.img dm-init-verity.img > > UUID: eca62b73-b66a-4249-834b-471e83fc382c > > Hash type: 1 > > Data blocks: 15667 > > Data block size: 4096 > > Hash block size: 4096 > > Hash algorithm: sha256 > > Salt: > > 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b > > Root hash: > > 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af > > > > 2) Then I am trying to append the verity with the system image itself: > > $ cat dm-init-verity.img >> system.img > > > > 3) After that I am trying to pass dm-mod.create parameter like this: > > dm-mod.create=\"system,,,ro, 0 IMAGE_SIZE/512 verity 1 > > /dev/ubiblock0_0 /dev/ubiblock0_0 4096 4096 DATA_BLOCKS 1 sha256 > > 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af > > 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b\" > > > > 4) The Kernel command line seems to be updated properly: > > [ 0.000000] Kernel command line:.. rootfstype=squashfs > > ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/ubiblock0_0 > > dm-mod.create="system,,,ro, 0 125336 verity 1 /dev/ubiblock0_0 > > /dev/ubiblock0_0 4096 4096 15667 1 sha256 > > 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af > > 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b" .... > > > > But it does not seem to work as expected. > > It gives below errors: > > .... > > [ 4.747708] block ubiblock0_0: created from ubi0:0(system) > > [ 4.752313] device-mapper: init: waiting for all devices to be > > available before creating mapped devices > > [ 4.752313] > > [ 4.766061] device-mapper: verity: sha256 using implementation > > "sha256-generic" > > [ 4.776178] device-mapper: ioctl: dm-0 (system) is ready > > [ 4.848886] md: Skipping autodetection of RAID arrays. > > (raid=autodetect will force) > > [ 4.849288] VFS: Cannot open root device "ubiblock0_0" or > > unknown-block(252,0): error -16 > > I'd start with changing your root device to point to the device mapper > one you've just created. E.g., root=/dev/dm-0 Then see how it goes > from there. Yes I tried this already but it seems the problem was something else. > > > > I followed almost the same example from dm-init document: > > "verity": > > dm-verity,,4,ro, > > 0 1638400 verity 1 8:1 8:2 4096 4096 204800 1 sha256 > > fb1a5a0f00deb908d8b53cb270858975e76cf64105d412ce764225d53b8f3cfd > > 51934789604d1b92399c52e7cb149d1b3a1b74bbbcb103b2a0aaacbed5c08584 > > > > But this seems only refer to system and verity on a different blocks. > > I am not sure what parameter should be changed if my verity metadata > > is part of system image itself. > > Also, I don't know how 1638400;204800;1 is calculated here based on image size ? > > It's the range of sectors covered by the device 0 to size_in_sectors: > (data_blocks * block_size)/sector_size > (15667 * 4096)/512 > 125336 > which you have in your entry already. > Now I made it working using both dmsetup first and then using dm-mod.create with the same parameters. There is slightly a different step when appending metadata to the system image itself. First, we need to adjust the hash offset for metadata location. Then we need to specify the offset in terms of number of blocks. This is still fine. But the problem is to specify the hash_start which is (number of blocks + 1). So, I used like this: veritysetup format --hash-offset=<image size> system.img system.img (The metadata will be appended automatically at the end of system.img) This will give the data blocks as well. dm-mod.create=\"system,,,ro, 0 125336 verity 1 /dev/ubiblock0_0 /dev/ubiblock0_0 4096 4096 15667 15668 sha256 39438d7915f2af8532752d78ce0cc08dc9d23b9e7176518310bc65de5c226c7d 56413cf91ccc9e32ec5b2d36b54e61114ab92a345d8547a194fc86ff4437896c\" So, this worked for me. Thank you so much! Regards, Pintu

1 0

dm-verity: How to exactly use the dm-mod.create with verity-metadata append
by Pintu Agarwal Nov. 23, 2021

Nov. 23, 2021

Hi, For rootfs dm-verity I am trying to pass dm-mod.create from our bootloader but it seems not working for me. So, I need some guidance on the parameters that we pass here. The documentation also does not seem to help much. Kernel: 4.14 (with dm-init patch backported) Target: Arm-32 / NAND / Simple Busybox / Bootloader (edk2) Build: Ubuntu-18.04 / Yocto 2.6 Steps I followed: 1) First I am trying to generate the root hash for our rootfs using the veritysetup command: $ ls -l system.img 64172032 ==> IMAGE_SIZE $ veritysetup format system.img dm-init-verity.img UUID: eca62b73-b66a-4249-834b-471e83fc382c Hash type: 1 Data blocks: 15667 Data block size: 4096 Hash block size: 4096 Hash algorithm: sha256 Salt: 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b Root hash: 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af 2) Then I am trying to append the verity with the system image itself: $ cat dm-init-verity.img >> system.img 3) After that I am trying to pass dm-mod.create parameter like this: dm-mod.create=\"system,,,ro, 0 IMAGE_SIZE/512 verity 1 /dev/ubiblock0_0 /dev/ubiblock0_0 4096 4096 DATA_BLOCKS 1 sha256 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b\" 4) The Kernel command line seems to be updated properly: [ 0.000000] Kernel command line:.. rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/ubiblock0_0 dm-mod.create="system,,,ro, 0 125336 verity 1 /dev/ubiblock0_0 /dev/ubiblock0_0 4096 4096 15667 1 sha256 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b" .... But it does not seem to work as expected. It gives below errors: .... [ 4.747708] block ubiblock0_0: created from ubi0:0(system) [ 4.752313] device-mapper: init: waiting for all devices to be available before creating mapped devices [ 4.752313] [ 4.766061] device-mapper: verity: sha256 using implementation "sha256-generic" [ 4.776178] device-mapper: ioctl: dm-0 (system) is ready [ 4.848886] md: Skipping autodetection of RAID arrays. (raid=autodetect will force) [ 4.849288] VFS: Cannot open root device "ubiblock0_0" or unknown-block(252,0): error -16 .... I followed almost the same example from dm-init document: "verity": dm-verity,,4,ro, 0 1638400 verity 1 8:1 8:2 4096 4096 204800 1 sha256 fb1a5a0f00deb908d8b53cb270858975e76cf64105d412ce764225d53b8f3cfd 51934789604d1b92399c52e7cb149d1b3a1b74bbbcb103b2a0aaacbed5c08584 But this seems only refer to system and verity on a different blocks. I am not sure what parameter should be changed if my verity metadata is part of system image itself. Also, I don't know how 1638400;204800;1 is calculated here based on image size ? So, people who have made this working successfully, please share the correct parameter to be used for the same block device. Thanks, Pintu

2 1

Does sysrq work over USB?
by Marc SCHAEFER Nov. 21, 2021

Nov. 21, 2021

Hello, I made the following setup work, that is I can send break and '?' (to get the magic sysrq help) or 's' to do an Emergency sync, and the kernel logs it: laptop apu2 USB serial port ------- null modem ------- ttyS0 internal 16550A (an apu2 is an embedded amd64 computer [4]) As it works, of course MAGIC_SYSRQ is enabled, including for serial ports, and the correct value is in the /proc pseudo-file. It works with the getty enabled or disabled. However, the following does not work to support magic sysrq, although bidirectionnal communication also works with cu [5], with the correct speed set: laptop apu2 USB serial port ------- null modem ------- USB serial port First, reading documentation, I thought that this would not be possible with USB and only with the internal serial port [1], but then, reading kernel source, it looks it should work with my adapter: Oct 11 14:30:56 apu2-init7 kernel: [ 9.915105] usb 2-2: pl2303 converter now attached to ttyUSB0 since the driver [2] contains code for magic sysrq, see line 993 for sysrq mode and line 892 for break handling, with implementation in [3] (lines 589-597). I am running Debian buster kernel 4.19.0-18-amd64 on the apu2. Should I abandon all hope to make it work with USB, or should it work? Thank your for any pointers. [1] https://www.kernel.org/doc/Documentation/admin-guide/sysrq.rst "On the serial console (PC style standard serial ports only)" [2] https://github.com/jplozi/linux-4.19/blob/loadbalancing/drivers/usb/serial/… [3] https://github.com/jplozi/linux-4.19/blob/loadbalancing/drivers/usb/serial/… [4] https://pcengines.ch/apu2.htm [5] https://linux.die.net/man/1/cu from the days before 2003 where I was doing UUCP cu -l ttyUSB0 -s 9600

2 5

USB: invalid maxpacket 8
by Muni Sekhar Nov. 18, 2021

Nov. 18, 2021

Hi all, I'm trying to connect to a USB device on Linux PC and getting an error about "invalid maxpacket 8". What does it mean? Does this error causes USB packet transfer failures? Any ideas how to fix this? Thank you for any pointers. dmesg log: --------------- [1920549.030669] usb 2-2: New USB device found, idVendor=05c6, idProduct=9500 [1920549.030682] usb 2-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [1920549.032623] hub 2-2:1.0: USB hub found [1920549.032672] hub 2-2:1.0: 7 ports detected [1920549.302875] usb 2-2.1: new high-speed USB device number 98 using xhci_hcd [1920549.391765] usb 2-2.1: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 8 [1920549.391777] usb 2-2.1: config 1 interface 0 altsetting 0 bulk endpoint 0x2 has invalid maxpacket 8 -- Thanks, Sekhar

2 1

DMB vs DSB in ARM
by Zhang Zeren Nov. 15, 2021

Nov. 15, 2021

Hi all, As far as I understand it , they both provide a full memory barrier, but their usage in the real world is still vague to me. I noticed that a lot of DSBs is used while flushing the TLB, can these DSBs be replaced by DMB? Why? Thanks in advance, Zhang Zeren

1 0

Re: Help needed in getting kernel dump in QEMU VM
by Dongliang Mu Nov. 15, 2021

Nov. 15, 2021

On Mon, Nov 15, 2021 at 3:27 PM Baoquan He <bhe(a)redhat.com> wrote: > > Hi, > > On 11/13/21 at 10:40am, Dongliang Mu wrote: > > Hi all KDUMP maintainers, > > > > I would like to generate a kernel dump within QEMU VM. > > > > 1. I reproduced the kernel crash [1] in QEMU VM. The QEMU startup > > script is as follows: > > > > qemu-system-x86_64 \ > > -kernel $KERNEL/arch/x86/boot/bzImage \ > > -append "console=ttyS0 root=/dev/sda debug earlyprintk=serial slub_debug=QUZ"\ > > -hda $IMAGE/stretch.img \ > > -net user,hostfwd=tcp::10021-:22 -net nic \ > > -enable-kvm \ > > -nographic \ > > -m 2G \ > > -smp 2 \ > > -pidfile vm.pid \ > > 2>&1 | tee vm.log > > > > The stretch.img is generated by Syzkaller script [1]. -kernel option > > is convenient for loading any other kernels. > > > > 2. As the .config already has the essential > > configuration(CONFIG_KEXEC, CONFIG_CRASH_DUMP, CONFIG_DEBUG_INFO), I > > did not change this configuration file. > > > > 3. I installed kdump-tools crash kexec-tools makedumpfile > > linux-image-4.9.0-13-amd64 in the stretch.img. Here I installed > > linux-image-4.9.0-13-amd64 because there is no default kernel in /boot > > directory. And to make kdump-tools working, I modify > > /etc/default/kdump-tools in the following: > > > > KDUMP_INITRD=/boot/initrd.img-4.9.0-13-amd64 > > KDUMP_KERNEL=/boot/vmlinuz-4.9.0-13-amd64 > > What distros are you using? Asking this because I am sure you are not > using Fedora/RHEL OS. The implementation of kdump tools is different in > each distros, even though the mechanims in kdump code is the same. > I am using Debian stretch as the guest OS. So kdump-tools kexec makedumpfile is all from Debian. > When we try to get help from upstream, considering and asking good question > is very important for getting quick response and effective help. > > Thanks > Baoquan > > > > > 4. I append "crashkernel=384M-:128M" to the command line in the > > startup script of QEMU. > > > > 5. After rebooting, kdump service can start successfully, and the > > kdump-config shows: > > > > root@syzkaller:~# kdump-config show > > DUMP_MODE: kdump > > USE_KDUMP: 1 > > KDUMP_SYSCTL: kernel.panic_on_oops=1 > > KDUMP_COREDIR: /var/crash > > crashkernel addr: 0x77000000 > > /boot/vmlinuz-4.9.0-13-amd64 > > kdump initrd: > > /boot/initrd.img-4.9.0-13-amd64 > > current state: ready to kdump > > > > kexec command: > > /sbin/kexec -p --command-line="earlyprintk=serial oops=panic > > panic_on_warn=1 nmi_watchdog=panic panic=86400 net.ifnames=0 > > sysctl.kernel.hung_task_all_cpu_backtrace=1 ima_policy=tcb > > kvm-intel.nested=1 nf-conntrack-ftp.ports=20000 > > nf-conntrack-tftp.ports=20000 nf-conntrack-sip.ports=20000 > > nf-conntrack-irc.ports=20000 nf-conntrack-sane.ports=20000 > > vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 > > netrom.nr_ndevs=16 rose.rose_ndevs=16 spec_store_bypass_disable=prctl > > numa=fake=2 nopcid dummy_hcd.num=8 binder.debug_mask=0 > > rcupdate.rcu_expedited=1 root=/dev/sda console=ttyS0 vsyscall=native > > watchdog_thresh=55 workqueue.watchdog_thresh=140 console=ttyS0 > > root=/dev/sda debug earlyprintk=serial slub_debug=QUZ irqpoll > > nr_cpus=1 nousb systemd.unit=kdump-tools.service > > ata_piix.prefer_ms_hyperv=0" --initrd=/boot/initrd.img-4.9.0-13-amd64 > > /boot/vmlinuz-4.9.0-13-amd64 > > > > 6. When I execute the PoC, the current kernel crashes and then reboots > > into the dump-capture kernel. However, the kernel log shows, it is in > > emergency mode, > > > > You are in emergency mode. After logging in, type "journalctl -xb" to view > > system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to > > try again to boot into default mode. > > > > Finally, I would like to ask several questions: > > 1) is the emergency mode due to the incorrect command line? > > 2) is this the right way to generate kernel dump from QEMU VM? > > 3) Any comments on the above procedures? > > > > Thanks very much in advance. > > > > [1] general protection fault in reiserfs_security_init > > (https://syzkaller.appspot.com/bug?id=8abaedbdeb32c861dc5340544284167dd0e46c…) > > > > [2] https://github.com/google/syzkaller/blob/master/tools/create-image.sh > > > > -- > > My best regards to you. > > > > No System Is Safe! > > Dongliang Mu > >

2 1

Help needed in getting kernel dump in QEMU VM
by Dongliang Mu Nov. 15, 2021

Nov. 15, 2021

Hi all KDUMP maintainers, I would like to generate a kernel dump within QEMU VM. 1. I reproduced the kernel crash [1] in QEMU VM. The QEMU startup script is as follows: qemu-system-x86_64 \ -kernel $KERNEL/arch/x86/boot/bzImage \ -append "console=ttyS0 root=/dev/sda debug earlyprintk=serial slub_debug=QUZ"\ -hda $IMAGE/stretch.img \ -net user,hostfwd=tcp::10021-:22 -net nic \ -enable-kvm \ -nographic \ -m 2G \ -smp 2 \ -pidfile vm.pid \ 2>&1 | tee vm.log The stretch.img is generated by Syzkaller script [1]. -kernel option is convenient for loading any other kernels. 2. As the .config already has the essential configuration(CONFIG_KEXEC, CONFIG_CRASH_DUMP, CONFIG_DEBUG_INFO), I did not change this configuration file. 3. I installed kdump-tools crash kexec-tools makedumpfile linux-image-4.9.0-13-amd64 in the stretch.img. Here I installed linux-image-4.9.0-13-amd64 because there is no default kernel in /boot directory. And to make kdump-tools working, I modify /etc/default/kdump-tools in the following: KDUMP_INITRD=/boot/initrd.img-4.9.0-13-amd64 KDUMP_KERNEL=/boot/vmlinuz-4.9.0-13-amd64 4. I append "crashkernel=384M-:128M" to the command line in the startup script of QEMU. 5. After rebooting, kdump service can start successfully, and the kdump-config shows: root@syzkaller:~# kdump-config show DUMP_MODE: kdump USE_KDUMP: 1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR: /var/crash crashkernel addr: 0x77000000 /boot/vmlinuz-4.9.0-13-amd64 kdump initrd: /boot/initrd.img-4.9.0-13-amd64 current state: ready to kdump kexec command: /sbin/kexec -p --command-line="earlyprintk=serial oops=panic panic_on_warn=1 nmi_watchdog=panic panic=86400 net.ifnames=0 sysctl.kernel.hung_task_all_cpu_backtrace=1 ima_policy=tcb kvm-intel.nested=1 nf-conntrack-ftp.ports=20000 nf-conntrack-tftp.ports=20000 nf-conntrack-sip.ports=20000 nf-conntrack-irc.ports=20000 nf-conntrack-sane.ports=20000 vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 netrom.nr_ndevs=16 rose.rose_ndevs=16 spec_store_bypass_disable=prctl numa=fake=2 nopcid dummy_hcd.num=8 binder.debug_mask=0 rcupdate.rcu_expedited=1 root=/dev/sda console=ttyS0 vsyscall=native watchdog_thresh=55 workqueue.watchdog_thresh=140 console=ttyS0 root=/dev/sda debug earlyprintk=serial slub_debug=QUZ irqpoll nr_cpus=1 nousb systemd.unit=kdump-tools.service ata_piix.prefer_ms_hyperv=0" --initrd=/boot/initrd.img-4.9.0-13-amd64 /boot/vmlinuz-4.9.0-13-amd64 6. When I execute the PoC, the current kernel crashes and then reboots into the dump-capture kernel. However, the kernel log shows, it is in emergency mode, You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to try again to boot into default mode. Finally, I would like to ask several questions: 1) is the emergency mode due to the incorrect command line? 2) is this the right way to generate kernel dump from QEMU VM? 3) Any comments on the above procedures? Thanks very much in advance. [1] general protection fault in reiserfs_security_init (https://syzkaller.appspot.com/bug?id=8abaedbdeb32c861dc5340544284167dd0e46c…) [2] https://github.com/google/syzkaller/blob/master/tools/create-image.sh -- My best regards to you. No System Is Safe! Dongliang Mu

2 1