Date: Sun, 20 Jan 2019 14:02:08 +0000 From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: "Andriy Voskoboinyk" <avos@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r343213 - in head/sys: net80211 sys Message-ID: <64B0B511-D3A0-4034-B602-2C3956669D58@FreeBSD.org> In-Reply-To: <201901201339.x0KDdICk003155@repo.freebsd.org> References: <201901201339.x0KDdICk003155@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20 Jan 2019, at 13:39, Andriy Voskoboinyk wrote: > Author: avos > Date: Sun Jan 20 13:39:18 2019 > New Revision: 343213 > URL: https://svnweb.freebsd.org/changeset/base/343213 > > Log: > net80211: resolve ioctl <-> detach race for ieee80211com structure > > Since r287197 ieee80211com is a part of drivers softc; as a result, > after detach all pointers to it (iv_ic, ni_ic) are invalid. Most > possible users (tasks, interrupt handlers) are blocked / removed > when device is stopped; however, ioctl handlers were not tracked > and may crash if ieee80211com structure is accessed. > > Since ieee80211com pointer access from ieee80211vap structure is not > protected by lock (constant after interface creation) and used in > many other places just use reference counting for ioctl handlers; > on detach set 'detached' flag and wait until reference counter goes > to 0. So how do any cloned interfaces do this (wifi or non-wifi)? Is this a more general problem or are some wifi drivers just not exactly careful with the order they take things down? On another note, why would refcount(9) not be sufficient? I didn’t really like the MC() macros and the hand crafted state machine for a refcount when scrolling through. /bz
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64B0B511-D3A0-4034-B602-2C3956669D58>