From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964797AbWGEKaW (ORCPT ); Wed, 5 Jul 2006 06:30:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964809AbWGEKaW (ORCPT ); Wed, 5 Jul 2006 06:30:22 -0400 Received: from hp3.statik.TU-Cottbus.De ([141.43.120.68]:15030 "EHLO hp3.statik.tu-cottbus.de") by vger.kernel.org with ESMTP id S964797AbWGEKaU (ORCPT ); Wed, 5 Jul 2006 06:30:20 -0400 Message-ID: <44AB940F.7000801@s5r6.in-berlin.de> Date: Wed, 05 Jul 2006 12:27:27 +0200 From: Stefan Richter User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: de, en MIME-Version: 1.0 To: Arjan van de Ven CC: netdev@vger.kernel.org, "Rafael J. Wysocki" , Andrew Morton , linux-kernel@vger.kernel.org, Ingo Molnar Subject: Re: 2.6.17-mm6 References: <20060703030355.420c7155.akpm@osdl.org> <200607042153.31848.rjw@sisk.pl> <1152043271.3109.95.camel@laptopd505.fenrus.org> In-Reply-To: <1152043271.3109.95.camel@laptopd505.fenrus.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 7/4/2006 10:01 PM, Arjan van de Ven wrote: > this is one for the networking people, and thus netdev It's actually ieee1394 using net infrastructure for purposes which ar unrelated to networking. Furthermore... > On Tue, 2006-07-04 at 21:53 +0200, Rafael J. Wysocki wrote: >> On Monday 03 July 2006 12:03, Andrew Morton wrote: >> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ >> > >> > - A major update to the e1000 driver. >> > - 1394 updates ...I believe it is unrelated to the 1394 updates new to -mm6. >> Just found this in dmesg: >> >> ================================= >> [ INFO: inconsistent lock state ] >> --------------------------------- >> inconsistent {in-hardirq-W} -> {hardirq-on-W} usage. >> nscd/4929 [HC0[0]:SC0[1]:HE1:SE0] takes: >> (&skb_queue_lock_key){++..}, at: [] udp_ioctl+0x50/0xa0 >> {in-hardirq-W} state was registered at: >> [] lock_acquire+0x8a/0xc0 >> [] _spin_lock_irqsave+0x3f/0x60 >> [] skb_queue_tail+0x25/0x60 > > ok so skb_queue_lock is used in a hardirq context > >> [] queue_packet_complete+0x27/0x40 [ieee1394] >> [] hpsb_packet_sent+0xab/0x100 [ieee1394] >> [] dma_trm_reset+0x115/0x140 [ohci1394] >> [] ohci_devctl+0x1c2/0x540 [ohci1394] >> [] hpsb_bus_reset+0x43/0xb0 [ieee1394] >> [] ohci_irq_handler+0x416/0x830 [ohci1394] >> [] handle_IRQ_event+0x2b/0x70 >> [] handle_level_irq+0xc4/0x130 >> [] do_IRQ+0x112/0x130 >> [] common_interrupt+0x64/0x65 >> irq event stamp: 4280 >> hardirqs last enabled at (4279): [] trace_hardirqs_on_thunk+0x35/0x37 >> hardirqs last disabled at (4278): [] trace_hardirqs_off_thunk+0x35/0x67 >> softirqs last enabled at (4258): [] release_sock+0xd5/0xe0 >> softirqs last disabled at (4280): [] _spin_lock_bh+0x11/0x50 >> >> other info that might help us debug this: >> no locks held by nscd/4929. >> >> stack backtrace: >> >> Call Trace: >> [] show_trace+0x9f/0x240 >> [] dump_stack+0x15/0x20 >> [] print_usage_bug+0x272/0x290 >> [] mark_lock+0x267/0x5f0 >> [] __lock_acquire+0x546/0xd10 >> [] lock_acquire+0x8b/0xc0 >> [] _spin_lock_bh+0x34/0x50 >> [] udp_ioctl+0x50/0xa0 > > yet udp_ioctl takes it only for _bh > >> [] inet_ioctl+0x69/0x70 >> [] sock_ioctl+0x22c/0x270 >> [] do_ioctl+0x31/0xa0 >> [] vfs_ioctl+0x2bb/0x2e0 >> [] sys_ioctl+0x6a/0xa0 >> [] system_call+0x7e/0x83 >> [<00002b2d76ab98a9>] > > is this a real scenario, or is this a case of "firewire is special and > needs it's own rules"? Well, firewire is special, but that should already be addressed by this patch: "lockdep: annotate ieee1394 skb-queue-head locking" http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=d378834840907326ac9d448056d957d13cc3718f Why is there still a lockdep warning? (Ieee1394 core's usage of the skb_* API is entirely unrelated to networking; even if eth1394 was used.) -- Stefan Richter -=====-=-==- -=== --=-= http://arcgraph.de/sr/