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'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 <adr...@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 _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"