Re: Bug in FAST_IPSEC

[christos%astron.com@localhost (Christos Zoulas)]

In article <D0E89213-567B-402E-A0EE-9A0DFFE6D07A%bbn.com@localhost>,
Beverly Schwartz  <bschwart%bbn.com@localhost> wrote:
>
>Two questions:
>1. Do I need to do the unlock after (*ifp->if_start)(ifp)? Some drivers are
>MP_SAFE, others are not.  We are using bnx, and all of the bnx code assumes
>that KERNEL_LOCK is held when it is called.  (So far, I have not run into
>trouble with the change as illustrated above, but I'm also not doing any
>transport mode, which is when I would guess this code would be tickled.)
>2. If ifp is not NULL, do I need to take KERNEL_LOCK at all?  (If I don't,
>then question 1 goes away.)  If ifp is not NULL, then this packet is
>going to an output queue rather than an input queue.  Some drivers are
>MP_SAFE, some are not...
>

Hi Beverly,

I think you can answer both questions with experimentation. For 1,
you can try to move the lock and see if that has ill effects (with
LOCKDEBUG). For 2 you can replicate your test and not lock if ifp is
NULL. I am inclined to commit what you have now, because it fixes the
problem, and it does not matter too much for the future because all
the locking will need to be redone in the networking stack.

christos