No. dev_kfree_skb() handles unlocking from the driver side. kfree_skb
does not free buffers a driver has marked as locked. What you are seeing
implies your driver was handed a buffer that somehow became unlocked or
you referenced it after dev_kfree_skb() or unlocking it.
> My feeling is that if the buffer is locked at the time that
> tcp_ack wants to dequeue it, then it should not dequeue it, and
> it should not free it. Does this seem right?
Thats what kfree_skb() does. A locked buffer changes to skb->free==3
which causes the unlock to free the buffer up.
Can you see what kind of packets are doing this (tcp data, tcp ack etc)
and if they are first for arp resolve etc ?