linux-kernel - Re: regression: fireware causes oops during system

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]

Message-Id: <200709162152.24793.rjw@sisk.pl>
Date:	Sun, 16 Sep 2007 21:52:24 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Pavel Machek <pavel@....cz>
Cc:	Ben Collins <ben.collins@...ntu.com>,
	kernel list <linux-kernel@...r.kernel.org>,
	linux1394-devel@...ts.sourceforge.net, Ingo Molnar <mingo@...e.hu>
Subject: Re: regression: fireware causes oops during system

On Sunday, 16 September 2007 20:41, Stefan Richter wrote:
> (Adding Cc: Rafael, Ingo)
> 
> Pavel Machek wrote:
> >> Dmesg with the oops or/and bisection would be good.
> > 
> > Sorry, had to hand-copy. It is oops at virtual adddress 6b6b6b7b --
> > looks like slab poison to me?
> > 
> > EIP is in task_rq_lock, backtrace is
> > try_to_wake_up
> > highlevel_host_reset
> > ohci_irq_handler
> 
> In reverse order, this trace is most certainly
> 
> 	drivers/ieee1394/ohci1394.c::ohci_irq_handler
> 	drivers/ieee1394/highlevel.c::highlevel_host_reset
> 	drivers/ieee1394/highlevel.c::nodemgr_highlevel.host_reset
> 						== nodemgr_host_reset
> 	kernel/sched.c::wake_up_process(hi->thread);
> 
> with hi->thread being the kthread which executes
> drivers/ieee1394/nodemgr.c::nodemgr_host_thread of the ieee1394 core driver.
> 
> The ieee1394 core has two (or more) threads:  One nodemgr_host_thread
> alias [knodemgrd_*] for each card, and one hpsbpkt_thread alias
> [khpsbpkt] for all cards.  The knodemgrd should be frozen during suspend
> or hibernate, while khpsbpkt should not be frozen in order to let
> transactions to go on in the case of saving the hibernation image to a
> FireWire disk.
> 
> 
> Quoting your other post:
> > On Tue 2007-09-11 21:45:58, Stefan Richter wrote:
> >> Between -rc3 and -rc4:
> >> 
> >> 	ieee1394: sbp2: fix sbp2_remove_device for error cases
> >> 	a2ee3f9bbb0ce57102dad8928d54f59acdc4b8f7
> >> 	should not occur in suspend path
> > 
> > Plus I do not have firewire attached disk here, so sbp2 should not be
> > used, right? 
> 
> Sbp2's host_reset handler would do something if it was loaded even
> without any SBP-2 devices attached,but it wouldn't under any
> circumstances call try_to_wake_up.  Actually with no devices attached it
> would simply "iterate" over an empty list.
> 
> >> Between -rc1 and -rc2:
> >> 
> >> 	ieee1394: sbp2: more correct Kconfig dependencies
> >> 	e4f8cac5e07528f7e0bc21d3682c16c9de993ecb
> >> 	unrelated
> >> 
> >> 	ieee1394: revert "sbp2: enforce 32bit DMA mapping"
> >> 	a9c2f18800753c82c45fc13b27bdc148849bdbb2
> >> 	unrelated
> >> 
> >> 	(not via linux1394-2.6.git)
> >> 	raw1394 __user annotation
> >> 	5b26e64ea39e45802c5736c8261bf8a8704d212f
> >> 	unrelated
> >> 
> >> So it must be something older which was somehow uncovered.
> >> Dmesg with the oops or/and bisection would be good.
> > 
> > The others look even more innocent. I wonder if this may have been
> > responsible?
> > 
> > commit 831441862956fffa17b9801db37e6ea1650b0f69
> > tree b0334921341f8f1734bdd3243de76d676329d21c
> > parent 787d2214c19bcc9b6ac48af0ce098277a801eded
> > author Rafael J. Wysocki <rjw@...k.pl> Tue, 17 Jul 2007 04:03:35 -0700
> > committer Linus Torvalds <torvalds@...dy.linux-foundation.org> Tue, 17
> > Jul 2007 10:23:02 -0700
> > 
> >     Freezer: make kernel threads nonfreezable by default

Well, I don't think so.

nodemgr_host_thread() calls set_freezable() as it should.

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/