Re: [BETA7-panic] sodealloc(): so_count 1

From: Robert Watson (rwatson_at_freebsd.org)
Date: 10/21/04

  • Next message: Michael Nottebrock: "Re: [Fwd: What do people think about not installing a stripped /kernel ?]" 
    Date: Thu, 21 Oct 2004 05:37:54 -0400 (EDT)
To: Vlad <marchenko@gmail.com>

    On Wed, 20 Oct 2004, Vlad wrote:

    > just wanted to drop a quick update - after I've applied your patch, it's
    > been up for a couple of days now ... we don't have that bad traffic now,
    > so it's hard to judge did it really help it or not, but at least it
    > looks like it didn't hurt ;)
    >
    > would you drop me a note after this patch will be submitted to releng
    > 5.3 branch?

    Ok, it's now MFC'd. Please let me know if you see any recurrence of that
    problem (or other stack problems). Thanks!

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

    >
    > thank you.
    >
    >
    > On Mon, 18 Oct 2004 18:24:06 -0400 (EDT), Robert Watson
    > <rwatson@freebsd.org> wrote:
    > >
    > > I've merged a likely fix to the problem to HEAD as of a minute or two ago,
    > > which broadens the scope of the accept mutex to reduce the opportunity for
    > > races (it both expands the coverage to some additional reference
    > > operations, and also avoids dropping a lock to reorder). With this change
    > > in place, I'm no longer able to easily reproduce the problem -- I've had a
    > > couple of SMP boxes running for an hour or two trying without success.
    > > Previously I had reproduction time with just the right traffic down to a
    > > second or two. I'll merge the fix to RELENG_5 shortly for merge to
    > > RELENG_5_3 before 5.3 goes out the door. Obviously, any help in getting
    > > testing exposure for this change, as it comes very late in the release
    > > cycle, would be most welcome. A copy of the patch can be found at:
    > >
    > > http://www.watson.org/~robert/freebsd/netperf/20041018-sofree-race-fix.diff
    > >
    > > A complete description can be found in the commit message. Thanks to
    > > everyone who has helped diagnosis and fix this! Hopefully we've got the
    > > right fix now, although obviously as the next few days of testing play
    > > out, we'll see.
    >
    > --
    > Vlad
    >

    _______________________________________________
    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: Michael Nottebrock: "Re: [Fwd: What do people think about not installing a stripped /kernel ?]"

    Relevant Pages

    • Re: [BETA7-panic] sodealloc(): so_count 1
      ... On Sun, 17 Oct 2004, Vlad wrote: ... I've merged a likely fix to the problem to HEAD as of a minute or two ago, ... testing exposure for this change, as it comes very late in the release ... >> I've managed to reproduce the problem, and am able to get a core. ...
      (freebsd-current)
    • Re: [BETA7-panic] sodealloc(): so_count 1
      ... On Wed, 20 Oct 2004, Vlad wrote: ... >> I've merged a likely fix to the problem to HEAD as of a minute or two ago, ... >> which broadens the scope of the accept mutex to reduce the opportunity for ... >> testing exposure for this change, as it comes very late in the release ...
      (freebsd-current)
    • Re: [patch 3/5] sctp: Make sure N * sizeof(union sctp_addr) does not overflow.
      ... Vlad found another case in SCTP which has ... an overflow bug similar to this one. ... fix for that today and submit. ...
      (Linux-Kernel)
    • Re: [patch 3/5] sctp: Make sure N * sizeof(union sctp_addr) does not overflow.
      ... Vlad found another case in SCTP which has ... an overflow bug similar to this one. ... fix for that today and submit. ...
      (Linux-Kernel)
    • Re: [BETA7-panic] sodealloc(): so_count 1
      ... would you drop me a note after this patch will be submitted to releng ... > which broadens the scope of the accept mutex to reduce the opportunity for ... I'll merge the fix to RELENG_5 shortly for merge to ... > testing exposure for this change, as it comes very late in the release ...
      (freebsd-current)