On Aug 9, 2009, at 21:53, Rick Macklem wrote: > On Sun, 9 Aug 2009, Thomas Backman wrote: > > [stuff snipped] >>> --- xdr/xdr_mbuf.c.sav 2009-08-07 15:02:35.000000000 -0400 >>> +++ xdr/xdr_mbuf.c 2009-08-07 15:03:04.000000000 -0400 >>> _at__at_ -282,6 +282,8 _at__at_ >>> size_t available; >>> char *p; >>> + if (!m) >>> + return (0); >>> if (xdrs->x_op == XDR_ENCODE) { >>> available = M_TRAILINGSPACE(m) + (m->m_len - xdrs->x_handy); >>> } else { >> >> Initial results are certainly good! :-) >> Pre-patch, it panicked three times in a row, as I said within a few >> seconds. Post-patch I've looped the simpler scan for a while (10 >> minutes, or about 8-9 runs) with no crash, and I also ran the more >> extensive one (which I doubt makes any difference...) once. >> Just for fun, I tried actually using nfsd while looping the scan, >> too. No problems. >> > Ok, sounds good. It's already in the re_at_ queue, so it should make it > into > 8.0. If it does crap out again, please let the list (and me) know. > > Thanks for testing the patch, rick > ps: Thanks mostly goes to pho_at_ for his "wicked" test scripts that > found > the crash that the above patch fixes + a bunch of others. I just looked at the xdrs variable in kgdb, and "m" would indeed be 0 in the crash: (kgdb) p *xdrs $2 = {x_op = XDR_DECODE, x_ops = 0xffffffff806a16c0, x_public = 0xffffff007ffdc3a8 "�Z\t<", x_private = 0x0, x_base = 0xffffff000a066e00 "", x_handy = 0} And since m is "xdrs->x_private", accessing m wouln't be a good idea. As a newbie, I still think it's safe to say that at least this particular issue is fixed (for me, anyhow). :) Regards, ThomasReceived on Sun Aug 09 2009 - 17:55:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:53 UTC