linux-kernel - [REGRESSION] failed to boot: commit 1aec4211204d parport: daisy: use new parport device model

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190325113650.56f596f9@gandalf.local.home>
Date:   Mon, 25 Mar 2019 11:36:50 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     LKML <linux-kernel@...r.kernel.org>
Cc:     Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: [REGRESSION] failed to boot: commit 1aec4211204d parport: daisy:
 use new parport device model


Running my tests on the latest (5.1-rc2) kernel, one test wont boot. It
ends here:

============================================================
               Welcome to Fedora 
                Press 'I' to enter interactive startup.
Starting udev: udev: starting version 153
udevd (2103): /proc/2103/oom_adj is deprecated, please use /proc/2103/oom_score_adj instead.
udevd-work[2142]: error opening ATTR{/sys/devices/system/cpu/cpu0/online} for writing: Permission denied

libphy: r8169: probed
r8169 0000:02:00.0 eth0: RTL8168g/8111g, 44:8a:5b:97:e2:1a, XID 4c0, IRQ 28
r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
r8169 0000:02:00.0 eth6: renamed from eth0
============================================================

That's where it hangs and does not go further.

I bisected it down to this commit:

  aec4211204d ("parport: daisy: use new parport device model")

If I checkout that commit and then run:

 git show | patch -p1 -R 

It boots. If I put back the commit, it does not. This is 100%
reproducible thus, the problem stated with that commit.

[ Update ]

Now, while writing this email, I found that the machine does actually
finish booting (after a very long time, because udev timed out):

udevd[188]: worker [362] unexpectedly returned with status 0x0100

udevd[188]: worker [362] failed while handling '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0400:00'

But I still ended up with:

 # echo w > /proc/sysrq-trigger
 # dmseg
[..]
sysrq: Show Blocked State
  task                PC stack   pid father
modprobe        D    0   383      1 0x80000080
Call Trace:
 __schedule+0x621/0x663
 schedule+0x49/0x57
 schedule_timeout+0x26/0xbe
 ? _raw_spin_unlock_irq+0x27/0x2b
 ? lockdep_hardirqs_on+0x14c/0x168
 ? trace_hardirqs_on+0x48/0x4a
 __wait_for_common+0xc9/0x143
 ? usleep_range+0x80/0x80
 ? wake_up_q+0x3f/0x3f
 wait_for_completion_killable+0x1c/0x28
 call_usermodehelper_exec+0xa7/0x108
 ? __wait_for_common+0x2b/0x143
 __request_module+0x351/0x3d8
 ? get_lowlevel_driver+0x28/0x41 [parport]
 ? vprintk_emit+0x285/0x290
 ? vprintk_default+0x17/0x19
 get_lowlevel_driver+0x28/0x41 [parport]
 __parport_register_driver+0x39/0x1f4 [parport]
 ? 0xf7e41000
 daisy_drv_init+0x31/0x4f [parport]
 parport_bus_init+0x5d/0x7b [parport]
 parport_default_proc_register+0x26/0x1000 [parport]
 do_one_initcall+0xc2/0x1e0
 ? trace_kmalloc+0x80/0xa7
 ? do_init_module+0x21/0x1d4
 ? kmem_cache_alloc_trace+0xd1/0xec
 ? do_init_module+0x21/0x1d4
 do_init_module+0x50/0x1d4
 load_module+0x1c2e/0x21b3
 ? map_vm_area+0x30/0x42
 sys_init_module+0xef/0x117
 ? translate_table+0x272/0x5e2 [ip6_tables]
 ? do_ip6t_get_ctl+0x212/0x393 [ip6_tables]
 ? 0xf7e4f000
 do_fast_syscall_32+0xa5/0xe4
 entry_SYSENTER_32+0x70/0xc8
EIP: 0xb7f8c6fd
Code: Bad RIP value.
EAX: ffffffda EBX: 0932c790 ECX: 0000b254 EDX: 09325e88
ESI: 003f5ff4 EDI: 003f73a0 EBP: bfe55e48 ESP: bfe55db0
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246

 # ps aux

has:

root       383  0.0  0.0   2108  1428 ?        D<   10:59   0:00 /sbin/modprobe -b acpi:PNP0400:
root       460  0.0  0.0   2104  1424 ?        S    10:59   0:00 /sbin/modprobe -q -- parport_lowlevel


I have this in the config:

 CONFIG_PARPORT_1284=y

If I change that to:

 # CONFIG_PARPORT_1284 is not set

It boots without issue.

So somethings going on with this change. Attached is the config I used.
Let me know if there's any thing else you need.

BTW, this also locks up when booting 64 bit mode, but as my tests start
by testing 32 bit, that's the one that I first found and started to
debug with.

-- Steve

Download attachment "config-bad" of type "application/octet-stream" (136581 bytes)