From owner-freebsd-current@FreeBSD.ORG Sat May 23 22:47:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AAEB106564A for ; Sat, 23 May 2009 22:47:01 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1C2F98FC1A for ; Sat, 23 May 2009 22:47:00 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n4NMIoRX084052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 15:18:51 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4A18764A.3000806@errno.com> Date: Sat, 23 May 2009 15:18:50 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Lucius Windschuh References: <4A11A08B.6090309@errno.com> <90a5caac0905231443l6d275f79t8e8024268aca2bbb@mail.gmail.com> In-Reply-To: <90a5caac0905231443l6d275f79t8e8024268aca2bbb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: 802.11 monitor mode changes coming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 22:47:01 -0000 Lucius Windschuh wrote: > 2009/5/18 Sam Leffler : > >> I plan to commit these changes by the end of the week. >> > > Hi Sam. > Since updating from r192372 to r192667, ending "tcpdump -ni uath0" > with ^C results in this witness warning: > > taskqueue_drain with the following non-sleepable locks held: > exclusive sleep mutex bpf global lock (bpf global lock) r = 0 > (0xc0bdafd8) locked @ /usr/src/sys/net/bpf.c:605 > KDB: stack backtrace: > db_trace_self_wrapper(c09bbd1c,eb107a24,c06da925,c09c6d24,25d,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c09c6d24,25d,ffffffff,c0baabcc,eb107a5c,...) at kdb_backtrace+0x29 > _witness_debugger(c09be0ad,eb107a70,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c0967968,137,c712ec1c,...) at witness_warn+0x1fd > taskqueue_drain(c712ec00,c72400b8,c7240000,eb107ad0,c0773f49,...) at > taskqueue_drain+0xa9 > ieee80211_waitfor_parent(c7240000,0,c09cc970,caf,c7240014,...) at > ieee80211_waitfor_parent+0x7b > ieee80211_ioctl(c64ac400,80206910,eb107af0,eb107b20,8903,...) at > ieee80211_ioctl+0x1a9 > if_setflag(c64ac44c,0,c09b71f8,ca,0,...) at if_setflag+0x10a > ifpromisc(c64ac400,0,c09c6d24,236,c615ad4c,...) at ifpromisc+0x33 > bpf_detachd(c0bdafd8,0,c09c6d24,25d,c6863400,...) at bpf_detachd+0x242 > bpf_dtor(c6f4ba00,0,c09ab531,9f,c771a578,...) at bpf_dtor+0xb0 > devfs_destroy_cdevpriv(c6863400,0,c09ab531,a9,eb107be8,...) at > devfs_destroy_cdevpriv+0xac > devfs_fpdrop(c771a578,c77356c0,3,0,c771a578,...) at devfs_fpdrop+0x68 > _fdrop(c771a578,c77356c0,eb107c1c,c06da76c,0,c7735764,c0baabc8,c0a26b14,c09b3b14,c6f0972c,45b,c09b3b14,eb107c44,c06a2c90,c6f0972c,8,c09b3b14,45b) > at _fdrop+0x53 > closef(c771a578,c77356c0,45b,440,c771a578,...) at closef+0x290 > kern_close(c77356c0,3,eb107d2c,c09285d3,c77356c0,...) at kern_close+0x102 > close(c77356c0,eb107cf8,4,c09b53e8,c0a1ec10,...) at close+0x1a > syscall(eb107d38) at syscall+0x283 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (6, FreeBSD ELF32, close), eip = 0x2838f9b3, esp = > 0xbfbfe54c, ebp = 0xbfbfe568 -- > > Well, I have no perfect evidence that your changes caused this > behaviour, but since it happens only on 802.11 interfaces and not in > my previous CURRENT, this looks like fallout from your monitor works. > It's been like that for a while. bpf holds a lock over the ifpromisc call which causes many issues. This is a problem that needs to be fixed in bpf. Sam