Re: svn commit: r278729 - head/sys/sys
On Fri, Feb 17, 2017 at 11:06:21AM -0800, hiren panchasara wrote:
h> On 03/19/15 at 11:08P, hiren panchasara wrote:
h> > On 03/16/15 at 06:06P, hiren panchasara wrote:
h> > > On 03/16/15 at 03:39P, Gleb Smirnoff wrote:
h> > > > On Wed, Mar 11, 2015 at 02:36:07PM -0700, hiren panchasara wrote:
h> > > > h> On 02/13/15 at 11:19P, Simon J. Gerraty wrote:
h> > > > h> > Author: sjg
h> > > > h> > Date: Fri Feb 13 23:19:35 2015
h> > > > h> > New Revision: 278729
h> > > > h> > URL: https://svnweb.freebsd.org/changeset/base/278729
h> > > > h> >
h> > > > h> > Log:
h> > > > h> > sbspace: size of bleft, mleft must match sockbuf fields to avoid
h> > > > h> > overflow on amd64
h> > > > h> >
h> > > > h> > Submitted by: anshu...@juniper.net
h> > > > h> > Obtained from: Juniper Networks
h> > > > h>
h> > > > h> Talking to sjg on -arch to MFC this. If he cannot get around doing
that,
h> > > > h> I'll do it tomorrow.
h> > > > h>
h> > > > h> Letting people know here to see if there are any objections.
h> > > >
h> > > > Would that fix the bug we've been discussing?
h> > >
h> > > Unsure as I am not sure what caused the issue I saw.
h> > >
h> > > For those who do not know the details, we recently saw a userland
h> > > process stuck spinning at 100% around sbcut_internal(). Inside
h> > > sbflush_internal(), the sb_cc was grown to be about 4G. And before
h> > > passing it to sbcut_internal(), we cast it from uint to int which
h> > > would make that valud -ve.
h> > >
h> > > Gleb pointed out to me that sbspace() is supposed to check/stop sb_cc
h> > > from growing that large.
h> > >
h> > > Now, I am not sure if we'd ever run into this situation again but
h> > > current fix is a great catch anyways.
h> > >
h> > > I still have 2 questions around what we saw. It'd be great if someone can
h> > > clarify them for my understanding:
h> > >
h> > > 1) Even if we get into such a scenario that we were in, following would
h> > > help by not looping endlessly.
h> > >
h> > > --- uipc_sockbuf.c.02015-03-11 15:49:52.0 -0700
h> > > +++ uipc_sockbuf.c 2015-03-11 15:51:48.0 -0700
h> > > @@ -877,6 +877,9 @@
h> > > {
h> > > struct mbuf *m, *n, *next, *mfree;
h> > >
h> > > + if (len < 0)
h> > > + panic("%s: len is %d and it is supposed to be +ve",
h> > > +__func__, len);
h> > > +
h> > > next = (m = sb->sb_mb) ? m->m_nextpkt : 0;
h> > > mfree = NULL
h> > >
h> > > 2) We need 1) because we are casting a uint to int which _may_ rander a
h> > > value -ve. Is there a way we can avoid the casting?
h> >
h> > It'd be useful if someone with knowledge in this area can weigh in.
h>
h> Ran into this again today. While the real question of how sb_ccc grew
h> this large is still unsolved, any objection to adding this patch to
h> avoid a hang and panic instead?
I am all for adding KASSERT now and then fixing the bug.
--
Totus tuus, Glebius.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278729 - head/sys/sys
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> >
> > > h> > Log:
> > > h> > sbspace: size of bleft, mleft must match sockbuf fields to avoid
> > > h> > overflow on amd64
> > > h> >
> > > h> > Submitted by: anshu...@juniper.net
> > > h> > Obtained from: Juniper Networks
> > > h>
> > > h> Talking to sjg on -arch to MFC this. If he cannot get around doing
> > > that,
> > > h> I'll do it tomorrow.
> > > h>
> > > h> Letting people know here to see if there are any objections.
> > >
> > > 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
> > from 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.02015-03-11 15:49:52.0 -0700
> > +++ uipc_sockbuf.c 2015-03-11 15:51:48.0 -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 = (m = sb->sb_mb) ? m->m_nextpkt : 0;
> > mfree = 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?
>
> 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
pgpxuhhAOgLkb.pgp
Description: PGP signature
Re: svn commit: r278729 - head/sys/sys
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
h Log:
hsbspace: size of bleft, mleft must match sockbuf fields to avoid
hoverflow on amd64
h
hSubmitted by:anshu...@juniper.net
hObtained from: Juniper Networks
h
h Talking to sjg on -arch to MFC this. If he cannot get around doing that,
h I'll do it tomorrow.
h
h Letting people know here to see if there are any objections.
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
from 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.02015-03-11 15:49:52.0 -0700
+++ uipc_sockbuf.c 2015-03-11 15:51:48.0 -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 = (m = sb-sb_mb) ? m-m_nextpkt : 0;
mfree = 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?
It'd be useful if someone with knowledge in this area can weigh in.
cheers,
Hiren
pgpa14oStcqUd.pgp
Description: PGP signature
Re: svn commit: r278729 - head/sys/sys
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
h Log:
hsbspace: size of bleft, mleft must match sockbuf fields to avoid
hoverflow on amd64
h
hSubmitted by: anshu...@juniper.net
hObtained from: Juniper Networks
h
h Talking to sjg on -arch to MFC this. If he cannot get around doing that,
h I'll do it tomorrow.
h
h Letting people know here to see if there are any objections.
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
from 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.02015-03-11 15:49:52.0 -0700
+++ uipc_sockbuf.c 2015-03-11 15:51:48.0 -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 = (m = sb-sb_mb) ? m-m_nextpkt : 0;
mfree = 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
pgpQ0hJEmtm_E.pgp
Description: PGP signature
Re: svn commit: r278729 - head/sys/sys
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 h Log: hsbspace: size of bleft, mleft must match sockbuf fields to avoid hoverflow on amd64 h hSubmitted by:anshu...@juniper.net hObtained from: Juniper Networks h h Talking to sjg on -arch to MFC this. If he cannot get around doing that, h I'll do it tomorrow. h h Letting people know here to see if there are any objections. Would that fix the bug we've been discussing? -- Totus tuus, Glebius. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r278729 - head/sys/sys
On 02/13/15 at 11:19P, Simon J. Gerraty wrote: Author: sjg Date: Fri Feb 13 23:19:35 2015 New Revision: 278729 URL: https://svnweb.freebsd.org/changeset/base/278729 Log: sbspace: size of bleft, mleft must match sockbuf fields to avoid overflow on amd64 Submitted by: anshu...@juniper.net Obtained from: Juniper Networks Talking to sjg on -arch to MFC this. If he cannot get around doing that, I'll do it tomorrow. Letting people know here to see if there are any objections. Cheers, Hiren pgpc2PWr049zm.pgp Description: PGP signature
Re: svn commit: r278729 - head/sys/sys
hiren panchasara hi...@strugglingcoder.info wrote: Talking to sjg on -arch to MFC this. If he cannot get around doing that, I'll do it tomorrow. I can do it - assuming no one objects. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
