From owner-freebsd-bugs Wed May 10 8:16:50 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from portnoy.lbl.gov (portnoy.lbl.gov [131.243.2.11]) by hub.freebsd.org (Postfix) with ESMTP id 3E46537B5A1 for ; Wed, 10 May 2000 08:16:47 -0700 (PDT) (envelope-from jin@portnoy.lbl.gov) Received: (from jin@localhost) by george.lbl.gov () id IAA13138; Wed, 10 May 2000 08:16:43 -0700 (PDT) Date: Wed, 10 May 2000 08:16:43 -0700 (PDT) From: Jin Guojun (FTG staff) Message-Id: <200005101516.IAA13138@george.lbl.gov> To: dwmalone@maths.tcd.ie, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/18471: Checking freeing of mbufs. Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Malone wrote: > > > It would be better if the kernel paniced at the time of the second > > > free, as opposed to some time later when the entry which has been > > > freed twice gets reused while still in use! > > > I disagree to panic at this point. The better fixing is just printing > > out some error message and do nothing for refreeing code. Whoever writes > > such driver code will know what happens. > > That wouldn't really be consistant with the other reference counters > in the kernel (vnode reference counters would be the main example > in my mind). At the stage when this happens the kernel has definitely > done something wrong - possibly having corrupted in data. So a > panic seems apropriate. (1) Free is different from Alloc that is not determineable and can consume the system resource. i.e., if a user keeps doing alloc() for the same pointer, the system has no way to know what is the code doing. Free is different, the memory sub-system knows what piece of memory has been allocated, and it can be freeed. If this piece of memory has been freeed already, the memory sub-system can simply ignore the second free command, and returns a warning code. It should not hurt anything. (2) The panic only helps device driver but not users, so you do not want to put a specific case as generic usage. For example, most ATM vendors can have multiple free()s in a calling chain to avoid lossing memory, you have no source, and you cannot fix the problem soon and by yourself. The vendor may take forever to modify such non-problem and hardly tracking issue, or they may not want to fix such issue at all. Then, panic makes the system useless. Right? > It isn't clear to me what useful message you could print to help > diganose the problem. Neither the address, nor the contents of the > mbuf would be that useful. A stack trace would probably be useful > - but a kernel dump would definitely be. Maybe I've missed something, > but... Since memory leaking and misuse are very common and hard tracking problem, the better thing is not to use alloc/free directly. Use MACROs instead. A senior programmer can easily figure this out : #ifdef DEBUG #define drv_buf_Free(p) \ if (system free(p) has warning) printf(WARN_MSG, __FILE__, __LINE__) #else #define drv_buf_Free(p) free(p) #endif If the new driver writters have no such discipline, they can modify the free/MFREE macro for their own system to panic the system at testing phase. But this should not be a strategy for generic and public usage because the second (2) reason explained above. Is this worth two cents :-) -Jin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message