bridge/wifi panic

[Andriy Voskoboinyk]

Tue, 03 Nov 2015 00:38:45 +0200 було написано Adrian Chadd  
<adrian at 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 at 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