Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Mar 2015 18:06:54 -0700
From:      hiren panchasara <hiren@strugglingcoder.info>
To:        Gleb Smirnoff <glebius@FreeBSD.org>
Cc:        "Simon J. Gerraty" <sjg@FreeBSD.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r278729 - head/sys/sys
Message-ID:  <20150317010654.GB53237@strugglingcoder.info>
In-Reply-To: <20150316123940.GA17947@FreeBSD.org>
References:  <201502132319.t1DNJZuP057045@svn.freebsd.org> <20150311213607.GN88380@strugglingcoder.info> <20150316123940.GA17947@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--NDin8bjvE/0mNLFQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 03/16/15 at 03:39P, Gleb Smirnoff wrote:
> On Wed, Mar 11, 2015 at 02:36:07PM -0700, hiren panchasara wrote:
> h> On 02/13/15 at 11:19P, Simon J. Gerraty wrote:
> h> > Author: sjg
> h> > Date: Fri Feb 13 23:19:35 2015
> h> > New Revision: 278729
> h> > URL: https://svnweb.freebsd.org/changeset/base/278729
> h> >=20
> h> > Log:
> h> >   sbspace: size of bleft, mleft must match sockbuf fields to avoid
> h> >   overflow on amd64
> h> >  =20
> h> >   Submitted by:	anshukla@juniper.net
> h> >   Obtained from:	Juniper Networks
> h>=20
> h> Talking to sjg on -arch to MFC this. If he cannot get around doing tha=
t,
> h> I'll do it tomorrow.=20
> h>=20
> h> Letting people know here to see if there are any objections.
>=20
> Would that fix the bug we've been discussing?

Unsure as I am not sure what caused the issue I saw.

For those who do not know the details, we recently saw a userland
process stuck spinning at 100% around sbcut_internal(). Inside
sbflush_internal(), the sb_cc was grown to be about 4G. And before
passing it to sbcut_internal(), we cast it from uint to int which
would make that valud -ve.

Gleb pointed out to me that sbspace() is supposed to check/stop sb_cc
=66rom growing that large.

Now, I am not sure if we'd ever run into this situation again but
current fix is a great catch anyways.

I still have 2 questions around what we saw. It'd be great if someone can
clarify them for my understanding:

1) Even if we get into such a scenario that we were in, following would
help by not looping endlessly.

--- uipc_sockbuf.c.0    2015-03-11 15:49:52.000000000 -0700
+++ uipc_sockbuf.c      2015-03-11 15:51:48.000000000 -0700
@@ -877,6 +877,9 @@
{
         struct mbuf *m, *n, *next, *mfree;

+      if (len < 0)
+               panic("%s: len is %d and it is supposed to be +ve",
+		    __func__, len);
+
         next =3D (m =3D sb->sb_mb) ? m->m_nextpkt : 0;
         mfree =3D NULL

2) We need 1) because we are casting a uint to int which _may_ rander a
value -ve. Is there a way we can avoid the casting?

cheers,
Hiren

--NDin8bjvE/0mNLFQ
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)

iQF8BAEBCgBmBQJVB34tXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4
QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/ld9AH/1nGS6BhZb2+k6C/2TKuhIYn
kEYDg42LlT3oJoKPNAqbmO8AS30cLz2hnf8dUNpfwuaaPt3zwuyXz70HhEcV1Snn
b/GQzM/k3j87oZvq1Ao+QdE5+vBnttaDBUjo7xrWXj8/upZJDXLAlHpL1HxgTVDk
mVJTbI2hNo2+rWn7xfIGDKBz+FXPa+BWG4f8ciidpaXNh65qCz+emWOxSF4uh+jb
65kWAAZ88h23y7H+JuG+RapBaB/F0RqNhJIasmirGojHswR/cGGrDJ5wtC9OE77I
A/XN6Oc2AdUsEgLFH6WcmI5gWgx8FmB1/L4J/M2jkPUBJRHzf1R8zUwqoJARd8o=
=NdEP
-----END PGP SIGNATURE-----

--NDin8bjvE/0mNLFQ--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150317010654.GB53237>