Re: panic: sbflush_locked

From: Robert Watson (rwatson_at_freebsd.org)
Date: 12/22/04

  • Next message: Pawel Jakub Dawidek: "Re: geom_gate panic" 
    Date: Wed, 22 Dec 2004 08:55:31 +0000 (GMT)
To: Alan Cox <alc@cs.rice.edu>

    On Mon, 20 Dec 2004, Alan Cox wrote:

    > > I haven't seen this in a very long time, but I've definitely tried to
    > > track it down before with zero luck.
    >
    > With the attached change, I've had no more crashes.
    >
    > I speculate uipc_send() is missing needed synchronization on so_snd.
    > Robert, can you verify the patch?

    Sorry for the delay in responding to your original post; I'm still
    catching up with e-mail from my trip to Bangladesh. I actually had
    similar changes to this in the netperf branch at one point, but think I
    removed them due to concerns about lock order. However, this change is
    careful to acquire the send lock before the receive lock, so I think
    shouldn't present a problem from that perspective. Please go ahead and
    commit, perhaps with a 2 week MFC time?

    Thanks!

    Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
    robert@fledge.watson.org Principal Research Scientist, McAfee Research

    > Index: kern/uipc_usrreq.c
    > ===================================================================
    > RCS file: /home/ncvs/src/sys/kern/uipc_usrreq.c,v
    > retrieving revision 1.143
    > diff -u -r1.143 uipc_usrreq.c
    > --- kern/uipc_usrreq.c 1 Dec 2004 09:22:26 -0000 1.143
    > +++ kern/uipc_usrreq.c 19 Dec 2004 03:22:50 -0000
    > @@ -452,7 +452,9 @@
    > }
    > }
    >
    > + SOCKBUF_LOCK(&so->so_snd);
    > if (so->so_snd.sb_state & SBS_CANTSENDMORE) {
    > + SOCKBUF_UNLOCK(&so->so_snd);
    > error = EPIPE;
    > break;
    > }
    > @@ -478,6 +480,7 @@
    > (so2->so_rcv.sb_cc - unp->unp_conn->unp_cc);
    > (void)chgsbsize(so->so_cred->cr_uidinfo, &so->so_snd.sb_hiwat,
    > newhiwat, RLIM_INFINITY);
    > + SOCKBUF_UNLOCK(&so->so_snd);
    > unp->unp_conn->unp_cc = so2->so_rcv.sb_cc;
    > sorwakeup_locked(so2);
    > m = NULL;

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Pawel Jakub Dawidek: "Re: geom_gate panic"

    Relevant Pages

    • Re: Random System Crashes
      ... Hash: SHA1 ... My system would just completely lock up and not respond to ... When my system crashes EVERYTHING ...
      (Debian-User)
    • Re: [PATCH 1/2] pci: Block config access during BIST
      ... On Sat, 2004-11-20 at 12:42 +0000, Alan Cox wrote: ... >> locking or some something that can be fixed at the driver level. ... > Some of the Intel CPU's are very bad at lock handling so it is an issue. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 4/5] usb_serial: Kill port mutex
      ... On Wed, 7 Oct 2009, Alan Cox wrote: ... Probably it needs a counting lock as the code is currently structured - ... However in the option and sierra drivers there is a perverse path from ...
      (Linux-Kernel)
    • [PATCH] fb: move mutex_init to framebuffer_alloc()
      ... a per-fbinfo mutex was added and framebuffer drivers were ... This new lock is currently initialized in ... register_framebufferis called and hence crashes the system very ...
      (Linux-Kernel)
    • Re: [PATCH 0/1] SIGWINCH problem with terminal apps still alive
      ... Alan Cox wrote: ... race because of rescheduling so lock is not working here. ... Adam, since you are working on this issue, I'd suggest you modify the source ...
      (Linux-Kernel)
    Loading