From owner-svn-src-all@FreeBSD.ORG Tue Mar 17 01:07:02 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7737CEFA; Tue, 17 Mar 2015 01:07:02 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5DC7F2EE; Tue, 17 Mar 2015 01:07:01 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 4B85D105571; Mon, 16 Mar 2015 18:06:54 -0700 (PDT) Date: Mon, 16 Mar 2015 18:06:54 -0700 From: hiren panchasara To: Gleb Smirnoff Subject: Re: svn commit: r278729 - head/sys/sys Message-ID: <20150317010654.GB53237@strugglingcoder.info> References: <201502132319.t1DNJZuP057045@svn.freebsd.org> <20150311213607.GN88380@strugglingcoder.info> <20150316123940.GA17947@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NDin8bjvE/0mNLFQ" Content-Disposition: inline In-Reply-To: <20150316123940.GA17947@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "Simon J. Gerraty" , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 01:07:02 -0000 --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--