linux-kernel - Re: regression (bisected): "modprobe parport

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 17 Mar 2019 19:05:46 +0100
From:   Michal Kubecek <mkubecek@...e.cz>
To:     Sudip Mukherjee <sudipm.mukherjee@...il.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: regression (bisected): "modprobe parport_pc" hangs in current
 mainline

On Sun, Mar 17, 2019 at 05:01:37PM +0000, Sudip Mukherjee wrote:
> On Wed, Mar 13, 2019 at 6:45 AM Michal Kubecek <mkubecek@...e.cz> wrote:
> > I encountered a regression in current (post-5.0) mainline kernel which I
> > bisected to commit 1aec4211204d ("parport: daisy: use new parport device
> > model"). Running "modprobe parport_pc" hangs up:
> 
> Can you please send me your .config so that I can test it from my side.

Attaching two versions: config-full.gz is the real life config from the
machine where I found the issue and config-mini.gz is a minimized config
I was using while bisecting the issue. (I made a mistake and thought
that I have seen the issue with snapshot before both parport commits so
that I ran a full bisect instead of simply checking the two parport
commits which came in the merge window.)

> > tweed:~ # ps ax | grep modprobe
> >  1206 pts/0    D+     0:00 modprobe parport_pc
> >  1209 ?        S      0:00 /sbin/modprobe -q -- parport_lowlevel
> >  1211 pts/1    S+     0:00 grep modprobe
> > tweed:~ # cat /proc/1206/stack
> > [<0>] call_usermodehelper_exec+0xc7/0x140
> > [<0>] __request_module+0x1a1/0x430
> > [<0>] __parport_register_driver+0x142/0x150 [parport]
> 
> And also, modprobe is trying to load a dependent module, so it will be
> great if you can also do a "lsmod" before doing the modprobe and I can
> check what is going wrong.

Attached are three lists:

  - lsmod-before ... before running "modprobe parport_pc"
  - lsmod-test   ... while "modprobe parport_pc" is stuck
  - lsmod-after  ... after killing second modprobe (1209 above)

Killing the second modprobe (PID 1209 above) lets the first finish and
as a result, parport, parport_pc and ppdev are loaded (it's the only
difference against lsmod-before). When modprobe is stuck, lsmod shows
parport with refcount of 1 (the only difference against lsmod-before).

Michal

Download attachment "config-full.gz" of type "application/x-gzip" (52138 bytes)

Download attachment "config-mini.gz" of type "application/x-gzip" (34903 bytes)

View attachment "lsmod-before" of type "text/plain" (6664 bytes)

View attachment "lsmod-test" of type "text/plain" (6696 bytes)

View attachment "lsmod-after" of type "text/plain" (6778 bytes)