Re: 802.11 monitor mode changes coming

Lucius Windschuh wrote:
> 2009/5/18 Sam Leffler <sam_at_errno.com>:
>   
>> 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 _at_ /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