IF_DRV_PREPEND unlocked?

[Marko Zec]

On Wed, 15 Jul 2020 16:26:25 -0700
John-Mark Gurney <jmg at 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