On 2 November 2015 at 14:49, Andriy Voskoboinyk <a...@freebsd.org> wrote:
> Tue, 03 Nov 2015 00:38:45 +0200 було написано Adrian Chadd
> <adr...@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 worried that there's a bunch of other places where this happens.
I'm also worried about trying to modify the rest of the mbuf API right
now just to fix things; I'd rather we revert things back to working
state and do this work in a branch.

in ath(4), the main place this gets unhappy is ath_tx_dmasetup() where
it may do a defrag first, and then if the defrag succeeds but the load
fails, then we're stuck with an mbuf that isn't the original one.

I think the safest thing to do here is to revert it so the driver has
to free the mbuf (ie, how it was.) We should sit down and figure out
how to more cleanly solve this before we attempt it again.

Do you have a problem with that? Any other ideas?




-adrian
_______________________________________________
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to