Date: Sat, 29 Jan 2000 18:55:55 -0600 (CST) From: Mike Spengler <mks@networkcs.com> To: kimch@etri.re.kr (Changhoon Kim) Cc: harp-bugs@magic.net, FreeBSD-ATM@FreeBSD.ORG (FreeBSD ATM), hschoi@etri.re.kr Subject: Re: Shielding Mechanisms in ATMARP module of HARP Message-ID: <200001300055.SAA35392@us.networkcs.com> In-Reply-To: <38929E61.E524CD88@etri.re.kr> from "Changhoon Kim" at Jan 29, 2000 05:01:37 PM
next in thread | previous in thread | raw e-mail | index | archive | help
Changhoon Kim claims: > > The new FreeBSD router couldn't last barely twenty minutes before > collapsing by a kernel panic. > And the message printed on a console at the kernel panic was > "m_copydata". > > OK... time to plunge into kernel codes. > [nice analysis of the problem deleted...] Thanks for digging into the problem - your analysis is right on! > > Anyway, let's concentrate on just HARP. > I believe that, although this problem was resulted from an errorneous > behavior of the third party manufacturer's equipments (Yes, I know I can > not assert yet.), FreeBSD kernel have to be safe enough not to be > collapsed by this kind of subtle bug. > Yes, the kernel code must protect itself from badly/illegally formed packets. > This time, I just solved this problem by modifying uniarp_input.c as > shown in the appendix of this mail. But, I think we need more secure > shielding mechanisms in ATMARP module of HARP in order to protect a > kernel adequately. > The basic problem here is that the semantics of m_copydata() don't exactly match those expected by the KB_COPYDATA() macro. The macro is designed to notify the caller if all the data requested to be copied was not all present in the mbuf chain - m_copydata() assumes the caller already knows the data is present. I will have to rewrite the KB_COPYDATA() macro to DTRT. > In my humble opinion, if an OS could be called a decent one, the crash > of the kernel have to be occurred just by hardware errors. And, most of > all, I want to believe that FreeBSD is one of the most stable and > reliable OS running on a PC. > No argument here!! Thanks again for the problem report. -- Mike Spengler Network Computing Services, Inc. Email: mks@networkcs.com 1200 Washington Ave. So. Phone: +1 612 337 3557 Minneapolis MN 55415 FAX: +1 612 337 3400 (aka Minnesota Supercomputer Center) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-atm" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001300055.SAA35392>