ng_ksocket on CURRENT
Gleb Smirnoff
glebius at cell.sick.ru
Mon Jul 5 11:11:19 PDT 2004
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
@@ -914,7 +914,9 @@
/* 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
More information about the freebsd-current
mailing list