Date: Tue, 03 Nov 2015 00:49:07 +0200 From: "Andriy Voskoboinyk" <avos@freebsd.org> To: "Adrian Chadd" <adrian@freebsd.org>, "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org> Subject: Re: bridge/wifi panic Message-ID: <op.x7hwb5kl4dikkl@localhost> In-Reply-To: <CAJ-Vmo=LgSeD%2BViEYdp4D2kBqQ=1KNOSnTTke9SqzkgJLtEHaw@mail.gmail.com> References: <1446174922.809135.424262409.16BCE412@webmail.messagingengine.com> <CAJ-Vmon-kwdeG2nVRGMoKBE654o0Yx8G8UB9=E6%2Ba=XyvDNrmg@mail.gmail.com> <BEB3A1D6-B877-4C65-B66E-9EFA39E2912C@FreeBSD.org> <CAJ-Vmo=exW_kmX0tnjQ81o8HxgJvG=5KtWf%2B3cQeAFteLPgtHw@mail.gmail.com> <A6634DC8-90CB-40C1-8B93-747E6AAC4A3D@FreeBSD.org> <CAJ-VmonrCfB_6jvFLMrJ6fD4ma=f8mHNmhQhum86wOPmzTNdoA@mail.gmail.com> <1446474203.3014685.426732569.13D78488@webmail.messagingengine.com> <CAJ-VmokBbh6Uh6FOaKhKPH_FxbNcHu7EdxP1SSh1ZzeQKqda_Q@mail.gmail.com> <op.x7hcb1o54dikkl@localhost> <CAJ-Vmo=uZbErxRudyoq6B7AG=SRb_PmoTQ4cD8-uhVPFHzbOEQ@mail.gmail.com> <CAJ-Vmo=tc%2BHvcLAVe_APVFkLUs76SmhpYJiPZT7BAyL5Jin-EQ@mail.gmail.com> <CAJ-Vmo=LgSeD%2BViEYdp4D2kBqQ=1KNOSnTTke9SqzkgJLtEHaw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tue, 03 Nov 2015 00:38:45 +0200 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Adrian Chadd = <adrian@freebsd.org>: > Actually, this is more annoying than I'd thought. There's a whole > bunch of places where mbufs can change during processing in ath(4) and= > yeah, we can't guarantee the original mbuf is available. > > I wonder how many other drivers are doing this - stuff like > m_collapse(), m_defrag(), etc. If this is called then the original > mbuf can't be returned upon error. I have thinked about that few hours ago - there are many ways to fix it:= 1) add a guarantee for current m_collapse() / m_defrag() that current mbuf pointer will not change (like it works in OpenBSD); 2) implement third function with this guarantee (for backward = compatibility); 3) pass pointer to mbuf pointer via ic_raw_xmit() / ic_transmit() - then the caller can change it (that's the way I've seen in other m_collapse() consumers); 4) move m_defrag() / m_collapse() to the net80211 (to the = ieee80211_encap() ?). This will require an additional parameter, which will limit max number of segments for device. ... (something else?) *) leave it 'as is'. > > I'm torn as to whether to back out the mbuf API change and have the > driver consume it, or whether we want to go through the pain of fixing= > things. > > Let's figure this out ASAP. > > Thanks, > > > -adrian > > > On 2 November 2015 at 14:35, Adrian Chadd <adrian@freebsd.org> wrote: >> Ok, yeah, I think your initial churn of ath(4) for error handling is >> way incomplete, and we're going to have to fix this stuff before it >> causes lots more issues in -HEAD. >> >> >> >> -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.x7hwb5kl4dikkl>