From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 18:45:19 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3880416A41C; Fri, 1 Jul 2005 18:45:19 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE0B743D49; Fri, 1 Jul 2005 18:45:18 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.94] ([66.127.85.94]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j61IjHms012630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jul 2005 11:45:18 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42C58F55.3040108@errno.com> Date: Fri, 01 Jul 2005 11:45:41 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tai-hwa Liang References: <200506241600.42470.jhb@FreeBSD.org> <0506251043379.48374@www.mmlab.cse.yzu.edu.tw> In-Reply-To: <0506251043379.48374@www.mmlab.cse.yzu.edu.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Rainer Hungershausen , John Baldwin , Pascal Hofstee Subject: Re: if_ral + wpa_supplicant stack backtrace 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: Fri, 01 Jul 2005 18:45:19 -0000 Tai-hwa Liang wrote: > On Fri, 24 Jun 2005, John Baldwin wrote: > >> On Saturday 18 June 2005 11:56 am, Pascal Hofstee wrote: >> >>> Hi, >>> >>> I am seeing period occurances of the same system call with the same >>> WITNESS warning and similar backtrace on yesterday's AMD64 CURRENT. >>> >>> ---------------------- >>> ral0: link state changed to DOWN >>> malloc(M_WAITOK) of "32", forcing M_NOWAIT with the following >>> non-sleepable locks held: >>> exclusive sleep mutex ral0 (network driver) r = 0 (0xffffffff80c64de8) >>> locked @ /usr/src/sys/dev/ral/if_ral.c:2167 >>> KDB: stack backtrace: >>> kdb_backtrace() at kdb_backtrace+0x37 >>> witness_warn() at witness_warn+0x2c1 >>> uma_zalloc_arg() at uma_zalloc_arg+0x69 >>> malloc() at malloc+0xf5 >>> ieee80211_ioctl_setoptie() at ieee80211_ioctl_setoptie+0x4b >>> ieee80211_ioctl_set80211() at ieee80211_ioctl_set80211+0x64e >>> ieee80211_ioctl() at ieee80211_ioctl+0x125 >>> ral_ioctl() at ral_ioctl+0xa4 >>> in_control() at in_control+0xc2f >>> ifioctl() at ifioctl+0x1f6 >>> soo_ioctl() at soo_ioctl+0x38c >>> ioctl() at ioctl+0x476 >>> syscall() at syscall+0x332 >>> Xfast_syscall() at Xfast_syscall+0xa8 >>> --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x8007c2d4c, rsp = >>> 0x7fffffffdfd8, rbp = 0x18 --- >>> ral0: link state changed to UP >>> ---------------------- >>> >>> I am indeed curious to understand what exactly is causing these WITNESS >>> warnings >> >> >> This is a bug in ral(4) as it indiscriminately just holds its mutex >> across >> ieee80211_ioctl() which isn't safe. The ral(4) maintainer needs to >> fix it. > > > The same WITNESS warning also occurs in ath(4) whilst using > wpa_supplicant. > It looks to me that it's probably not individual driver's fault, but a > known > behaviour in net80211. > > Attached patch should suppress this warning; however, I'm not quite sure > about whether it's safe to do so or not.... > > > ------------------------------------------------------------------------ > > --- ieee80211_ioctl.c.orig Sat Jun 18 14:07:01 2005 > +++ ieee80211_ioctl.c Sat Jun 25 10:04:48 2005 > @@ -1475,7 +1475,7 @@ > if (ireq->i_len > IEEE80211_MAX_OPT_IE) > return EINVAL; > /* NB: data.length is validated by the wireless extensions code */ > - MALLOC(ie, void *, ireq->i_len, M_DEVBUF, M_WAITOK); > + MALLOC(ie, void *, ireq->i_len, M_DEVBUF, M_NOWAIT); > if (ie == NULL) > return ENOMEM; > error = copyin(ireq->i_data, ie, ireq->i_len); This is one instance of a general problem that's existed for over a year. Calling ieee80211_ioctl (typically) requires the driver hold it's lock but certain operations in the 802.11 layer may need to block but have no way to release the driver lock or otherwise synchronize the operations. I've brought this up several times and suggested that the cleanest solution looks to be exposing the driver lock to the 802.11 layer; possibly by making the driver softc lock part of the ifnet structure. But this approach never went very far so the problems have remained. The key concern with doing the ifnet/softc lock thing is that it might force us into a locking model that's too restrictive. Sam