linux-ext4 - [Bug 25832] kernel crashes upon resume if usb devices are removed when suspended

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

Message-Id: <201103140410.p2E4A7vu004978@demeter2.kernel.org>
Date:	Mon, 14 Mar 2011 04:10:07 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 25832] kernel crashes upon resume if usb devices are removed
 when suspended

https://bugzilla.kernel.org/show_bug.cgi?id=25832

--- Comment #48 from rocko <rockorequin@...mail.com>  2011-03-14 04:10:06 ---
Unfortunately there are a couple of problems with bisecting this, quite apart
from the time it takes to build and test each kernel...

The first is that it is unsurprisingly easy to crash an rc1 kernel, which makes
it even harder to reliably detect the bug. For instance, I managed to crash the
first bisect of 35-36.rc1 with the suspend/resume test eventually (it seems
much more robust than 2.6.38 with respect to this bug) but it isn't clear that
the problem occurred as a result of the USB removal - the stack trace looks
like it includes memory allocations and socket receives. Why, the first time I
booted the 36rc1 kernel, it hung completely at the login screen with no human
input whatsoever, clearly as a result of a different bug. I'm not even positive
that the log I posted from the 36rc1 kernel crash above is related to this bug,
as it looks different from the 2.6.37/38 logs.

The second problem is that I can't necessarily compile all the bisects! For
instance commit f6cec0ae58c17522a7bc4e2f39dae19f199ab534 (the second bisect I
tried) fails with this error:

drivers/staging/comedi/drivers/das08_cs.c: In function
‘das08_pcmcia_config_loop’:
drivers/staging/comedi/drivers/das08_cs.c:225:8: error: ‘struct pcmcia_device’
has no member named ‘io

Is there a way to make the kernel handle a bug like this more gracefully? It
seems that there are many great debug tools for extracting information about
process states, but they are all useless here because the crash is so
catastrophic.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html