Date: Fri, 17 Feb 2017 11:06:21 -0800 From: hiren panchasara <hiren@strugglingcoder.info> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: "Simon J. Gerraty" <sjg@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r278729 - head/sys/sys Message-ID: <20170217190621.GE66077@strugglingcoder.info> In-Reply-To: <20150319180812.GI53237@strugglingcoder.info> References: <201502132319.t1DNJZuP057045@svn.freebsd.org> <20150311213607.GN88380@strugglingcoder.info> <20150316123940.GA17947@FreeBSD.org> <20150317010654.GB53237@strugglingcoder.info> <20150319180812.GI53237@strugglingcoder.info>
next in thread | previous in thread | raw e-mail | index | archive | help
--PPYy/fEw/8QCHSq3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/19/15 at 11:08P, hiren panchasara wrote: > On 03/16/15 at 06:06P, hiren panchasara wrote: > > 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 avo= id > > > 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= that, > > > 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? > >=20 > > Unsure as I am not sure what caused the issue I saw. > >=20 > > 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. > >=20 > > Gleb pointed out to me that sbspace() is supposed to check/stop sb_cc > > from growing that large. > >=20 > > Now, I am not sure if we'd ever run into this situation again but > > current fix is a great catch anyways. > >=20 > > I still have 2 questions around what we saw. It'd be great if someone c= an > > clarify them for my understanding: > >=20 > > 1) Even if we get into such a scenario that we were in, following would > > help by not looping endlessly. > >=20 > > --- 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; > >=20 > > + 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 > >=20 > > 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? >=20 > It'd be useful if someone with knowledge in this area can weigh in. Ran into this again today. While the real question of how sb_ccc grew this large is still unsolved, any objection to adding this patch to avoid a hang and panic instead? Cheers, Hiren --PPYy/fEw/8QCHSq3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJYp0moXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lLG4IAJ+xldkMPsMXUL5x8iBE1xSR DiK8Ir1CfODMMOA0vRqr1iGmh6aPZomx6tb9Wso8jRV4JvuxzL0k5GqN9JwmzikD T+N8ttD6tTgm9McKIr1EzO+YRLG55KxZiQ+KJYtZq0M5s9O2hGL8tb74dstDpDlw n9f1BTyEJ38GBOgmOqQJepEd5AV/ZcbvVyaXymwI6qQo+EGGIKBU1GdupiWSPSO1 mO3nVOgw+DeqLFAeSVwI2ej/IF47S8DB9l/qt1vkS2jggXZVmGNPMrL7/CE4Nq4A HiYr4QqcYWKqdf3zbSSxlusluQ9l9juGDFPX+02J/cMjuI00+fS1x68jY13D1qI= =a+1M -----END PGP SIGNATURE----- --PPYy/fEw/8QCHSq3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170217190621.GE66077>