NetBSD Problem Report #46118

From holger@weiss.in-berlin.de  Thu Mar  1 10:34:42 2012
Return-Path: <holger@weiss.in-berlin.de>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 6BED163CAE9
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  1 Mar 2012 10:34:42 +0000 (UTC)
Message-Id: <20120301103442.DFC8F43D82@mail.weiss.in-berlin.de>
Date: Thu,  1 Mar 2012 11:34:42 +0100 (CET)
From: Holger Weiss <holger@weiss.in-berlin.de>
To: gnats-bugs@gnats.NetBSD.org
Subject: pppoe(4) via axe(4) triggers locking-related panic
X-Send-Pr-Version: 3.95

>Number:         46118
>Category:       kern
>Synopsis:       pppoe(4) via axe(4) triggers locking-related panic
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 01 10:35:00 +0000 2012
>Closed-Date:    
>Last-Modified:  Sun Jun 02 00:51:03 +0000 2013
>Originator:     Holger Weiss
>Release:        NetBSD 6.0_BETA (2012-02-29)
>Organization:
Individual Network Berlin e.V.
>Environment:
System: NetBSD petty.weiss.in-berlin.de 6.0_BETA NetBSD 6.0_BETA (GENERIC) #0: Wed Feb 29 17:02:14 CET 2012 holger@smith.weiss.in-berlin.de:/src/build/obj/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
Initiating a pppoe(4) connection using an axe(4) interface quickly
triggers a "KERNEL_LOCKED_P()" assertion failure in sys/dev/usb/usbdi.c:

| panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file "/src/netbsd/base/sys/dev/usb/usbdi.c", line 264
| cpu0: Begin traceback...
| kern_assert() at netbsd:kern_assert+0x48
| usbd_transfer() at netbsd:usbd_transfer+0x202
| axe_start() at netbsd:axe_start+0x131
| ifq_enqueue() at netbsd:ifq_enqueue+0x9b
| ether_output() at netbsd:ether_output+0x5ad
| pppoe_output() at netbsd:pppoe_output+0x83
| pppoe_start() at netbsd:pppoe_start+0xd4
| sppp_output() at netbsd:sppp_output+0x3fc
| fr_fastroute() at netbsd:fr_fastroute+0x202
| fr_send_ip() at netbsd:fr_send_ip+0x16f
| fr_send_reset() at netbsd:fr_send_reset+0x199
| fr_check() at netbsd:fr_check+0xca0
| fr_check_wrapper() at netbsd:fr_check_wrapper+0x8f
| pfil_run_hooks() at netbsd:pfil_run_hooks+0x9f
| ip_input() at netbsd:ip_input+0x1ab
| ipintr() at netbsd:ipintr+0x112
| softint_dispatch() at netbsd:softint_dispatch+0xe0
| DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfffffe810e68ed70
| Xsoftintr() at netbsd:Xsoftintr+0x4f
| --- interrupt ---
| 0:
| cpu0: End traceback...

Using the axe(4) adapter as a normal LAN interface seems to work just
fine on the same system, and so does using pppoe(4) via wm(4).
>How-To-Repeat:
Initiate a pppoe(4) connection with an axe(4) interface, e.g.:

	ifconfig axe0 up
	ifconfig pppoe0 create
	pppoectl -e axe0 pppoe0
	pppoectl -f /etc/pppoe/configuration pppoe0
	ifconfig pppoe0 0.0.0.0 0.0.0.1 up
>Fix:
Unknwon.  Grab the kernel lock at the appropriate place, I guess?

>Release-Note:

>Audit-Trail:
From: Holger =?iso-8859-1?Q?Wei=DF?= <holger@weiss.in-berlin.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46118
Date: Wed, 21 Mar 2012 17:04:39 +0100

 FWIW, the following patch makes the panic go away for me, but I have no
 idea whether it's correct (i.e., I don't know where in the call chain
 the locking should be handled):

 Index: sys/dev/usb/if_axe.c
 ===================================================================
 RCS file: /cvsroot/src/sys/dev/usb/if_axe.c,v
 retrieving revision 1.51
 diff -u -r1.51 if_axe.c
 --- sys/dev/usb/if_axe.c	2 Feb 2012 19:43:07 -0000	1.51
 +++ sys/dev/usb/if_axe.c	21 Mar 2012 07:55:10 -0000
 @@ -1134,7 +1134,9 @@
  	    axe_txeof);

  	/* Transmit */
 +	KERNEL_LOCK(1, curlwp);
  	err = usbd_transfer(c->axe_xfer);
 +	KERNEL_UNLOCK_ONE(curlwp);
  	if (err != USBD_IN_PROGRESS) {
  		axe_stop(ifp, 0);
  		return EIO;

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Fri, 04 Jan 2013 03:43:31 +0000
State-Changed-Why:
Are you able to try -current? The multiprocessorizing of usb should
have fixed this.


From: Holger Weiss <holger@weiss.in-berlin.de>
To: GNATS Bugs <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: kern/46118 (pppoe(4) via axe(4) triggers locking-related panic)
Date: Fri, 4 Jan 2013 10:12:09 +0100

 > Are you able to try -current? The multiprocessorizing of usb should
 > have fixed this.

 Not right now, sorry.  As far as I'm concerned, feel free to close the
 PR and I'll re-open it if I manage to reproduce the panic after
 upgrading the box to the new code (which would surprise me, too).

From: David Holland <dholland-gnats@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/46118: pppoe(4) via axe(4) triggers locking-related panic
Date: Sun, 2 Jun 2013 00:45:02 +0000

 not sent to gnats

    ------

 From: Michael van Elst <mlelstv@serpens.de>
 To: gnats@netbsd.org
 Subject: Re: kern/46118: pppoe(4) via axe(4) triggers locking-related panic
 Date: Tue, 26 Mar 2013 13:56:01 +0100


 Locking is supposed to occur on a higher layer. Most calls into
 an if_start routine come through ifq_enqueue() which protects
 the if_start routine by aquiring the kernel lock.

 Some code however does not use ifq_enqueue() but calls if_start
 directly, and none if it cares about the kernel lock. In particular:

 - ppp / pppoe
 - sl
 - strip
 - ieee1394
 - bridge
 - vlan

 netipsec and net80211 might have similar problem paths.


 Greetings,
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 02 Jun 2013 00:51:03 +0000
State-Changed-Why:
submitter couldn't test my theory/guess


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.