Date: Wed, 10 May 2000 08:16:43 -0700 (PDT) From: Jin Guojun (FTG staff) <jin@george.lbl.gov> To: dwmalone@maths.tcd.ie, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/18471: Checking freeing of mbufs. Message-ID: <200005101516.IAA13138@george.lbl.gov>
next in thread | raw e-mail | index | archive | help
David Malone <dwmalone@maths.tcd.ie> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005101516.IAA13138>