Re: ng_ksocket on CURRENT

  Julian, Robert,

it's good that you have already payed attention to my mail.

On my way home I have tested the following patch:

--- ng_ksocket.c        25 Jun 2004 19:22:03 -0000      1.46
+++ ng_ksocket.c        5 Jul 2004 17:46:24 -0000
_at__at_ -914,7 +914,9 _at__at_
 
        /* Send packet */
        priv->flags |= KSF_SENDING;
+       NET_LOCK_GIANT();
        error = (*so->so_proto->pr_usrreqs->pru_sosend)(so, sa, 0, m, 0, 0, td);
+       NET_UNLOCK_GIANT();
        priv->flags &= ~KSF_SENDING;
 
        return (error);

Seems like it just works.

On Mon, Jul 05, 2004 at 12:23:36PM -0400, Robert Watson wrote:
R> > It looks like ksocket needs to ensure that it has giant before calling
R> > the network stack. 
R> 
R> In the debug.mpsafenet=0 scenario, Giant should be held for all of this. 
R> The bit of missing information below appears to be how we got onto a call
R> stack without Giant held -- and it looks like that information isn't in
R> the stack trace (?).  Normally this would suggest a callout -- I've found
R> a couple that may not be holding Giant properly, but neither looks like
R> it's a match for this trace.  Do you know of a way the stack trace below
R> can occur?  It looks like the Netgraph netisr holds Giant, and with
R> debug.mpsafenet=0, the inbound network path and system calls should as
R> well.

Robert,
yes, this thread is originating from a callout. Actually, it
is impossible to reproduce this as I described in previous letter. Sorry.

So you suggest to lock Giant in a callout handle? Or should we somewhat tweak
ng_ksocket?

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE