Date: Wed, 09 Nov 2005 22:32:56 +0600 From: Victor Snezhko <snezhko@indorsoft.ru> To: freebsd-current@freebsd.org Cc: Mark Tinguely <tinguely@casselton.net> Subject: Re: CURRENT + amd64 + user-ppp = panic Message-ID: <uy83x3hon.fsf@indorsoft.ru> In-Reply-To: <200511091358.jA9DwiC0045661@casselton.net> (Mark Tinguely's message of "Wed, 9 Nov 2005 07:58:44 -0600 (CST)") References: <200511091358.jA9DwiC0045661@casselton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Tinguely <tinguely@casselton.net> writes: > I also was not thinking MBUF when I suggested trace locations. m_sanity() > in kern/uipc_mbuf.c will also set "0xdeadc0de" if the "sanitize" > option is requested. Now I have a current of 2005.10.21.16.25.00, and there is no deadcode there. Only a comment stating that deadc0de'ing would be not bad. > But common sense says that your trash_dtor() > code should catch this before it gets set, but if you wish to test > there also it would put my mind at ease. Sure. I have already submitted a PR(kern/88725) with all the results I have so far, and when I find all the other places I'll make a followup to it. > In the mean time, I will look for callouts that are not stopped before > they are freed. So far, I found the &sp->ifstart_callout in the file > net/if_spppsubr.c started but not stopped before freed, but you are > not using that routine. I will concentrate on the files that you listed > were changed. Yes, it's right. This commit needs a serious checking even if we'll fix my issue with ppp. -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?uy83x3hon.fsf>