> I'm pretty sure holding a lock across putnext can be considered a bug > in a DLPI driver so, if other drivers do have this flaw, the are > generally asking for trouble.
They are generally asking for trouble, but I recall drivers that do this under the assumption that it won't be an issue as long as they ensure that the lock in question will never be acquired by the same thread on reentry. For instance, they might hold foo_lock across putnext() on the read side, but then ensure that foo_lock is only held in srv(9E) context on the write side. The current GLDv3 locking design makes that assumption insufficient. -- meem
