On Wed, 15 Jul 2020 16:26:25 -0700 John-Mark Gurney <j...@funkthat.com> wrote:
> I happen to be looking at the implementation of IFQ_DRV_PREPEND, and > unlike IFQ_DRV_DEQUEUE, it doesn't obtain the lock when manipulating > the ifq. I took a brief look at a few drivers, and it looks like some > of them expect that _PREPEND lock the Q like _DEQUEUE does. > > This is likely not an issue often, since it's an error path that > likely rarely happens, but we should fix it. > > Should we just add the IFQ_LOCK/_UNLOCK to the macro? > > Comments or thoughts? I also have a hard time understanding the semantics of IFQ_DRV_* macros: per altq(9) they appear to be variants of their IFQ_ counterparts which are intended to be protected by some other mechanism rather than IFQ_LOCK, but in some instances this isn't the case, as they do grab the IFQ_LOCK. Marko _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
