[uml-devel] fuzz testing a 32 bit UML guest - ssh login won't work since a hour

[Toralf F. <tor...@gm...>]

Fuzz testing a 32 bit x86 Gentoo UML guest (especially NFSv4 files, nfs sserver and client runs within the UML guest) with current git kernel brought the guest into a state, where no ssh login is any longer possible.

At the host side I can see that the linux processes are still running.

I attached the gdb to the linux processes at the host (even 32 bit x86 Gentoo). I do get nearly all the time:


Thread 1 (process 4252):
#0  0xb7736aec in __kernel_vsyscall ()
#1  0x08496faf in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
#2  0x08073124 in idle_sleep (nsecs=606859328243668608) at arch/um/os-Linux/time.c:183
#3  0x08060b3f in arch_cpu_idle () at arch/um/kernel/process.c:208
#4  0x080a5405 in cpuidle_idle_call () at kernel/sched/idle.c:120
#5  cpu_idle_loop () at kernel/sched/idle.c:224
#6  cpu_startup_entry (state=CPUHP_ONLINE) at kernel/sched/idle.c:272
#7  0x084e16d2 in rest_init () at init/main.c:419
#8  0x0804892e in start_kernel () at init/main.c:679
#9  0x08049fc9 in start_kernel_proc (unused=0x0) at arch/um/kernel/skas/process.c:46
#10 0x0806064b in new_thread_handler () at arch/um/kernel/process.c:129
#11 0x00000000 in ?? ()

...



but at least one time I got:


0x08108de3 in __put_super (sb=0x86a60000) at fs/super.c:246
246             if (!--sb->s_count) {

Thread 1 (process 4252):
#0  0x08108de3 in __put_super (sb=0x86a60000) at fs/super.c:246
#1  0x081096ac in put_super (sb=<optimized out>) at fs/super.c:262
#2  drop_super (sb=0x86a60000) at fs/super.c:487
#3  0x0812a337 in __writeback_inodes_wb (wb=0x8421c09c, work=0x1) at fs/fs-writeback.c:733
#4  0x0812a479 in wb_writeback (wb=0x8421c09c, work=0x869d7efc) at fs/fs-writeback.c:863
#5  0x0812a74e in wb_check_background_flush (wb=<optimized out>) at fs/fs-writeback.c:944
#6  wb_do_writeback (wb=<optimized out>) at fs/fs-writeback.c:1014
#7  bdi_writeback_workfn (work=0x8421c0a8) at fs/fs-writeback.c:1043
#8  0x08090d11 in process_one_work (worker=0x84325000, work=0x8421c0a8) at kernel/workqueue.c:2081
#9  0x0809116a in worker_thread (__worker=0x84325000) at kernel/workqueue.c:2212
#10 0x08096806 in kthread (_create=0x84207410) at kernel/kthread.c:207
#11 0x0806064b in new_thread_handler () at arch/um/kernel/process.c:129
#12 0x00000000 in ?? ()

...


Now I'm wondering if this is an issue which is worth to be debugged or whether I just should ignore it.

BTW the nsecs of 2 gdb calls in a row are identical since few minutes : 606859328243668608
before the value was : 606859328233668608



-- 
Toralf