Date: Thu, 11 May 2000 00:22:40 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Jin Guojun (FTG staff) <jin@george.lbl.gov> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/18471: Checking freeing of mbufs. Message-ID: <200005110022.aa91705@salmon.maths.tcd.ie> In-Reply-To: Your message of "Wed, 10 May 2000 08:16:43 PDT." <200005101516.IAA13138@george.lbl.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Yep - the problem is not that is is being freed twice, but some piece of code is continuing to use the mbuf after it has been freed. It's seriously dangerous to continue using a resource that the system thinks is free to be given to another consumer of that resource. This is even more true in the kernel, where you have interupts and stuff possibly grabbing new mbufs and clusters. > (2) > The panic only helps device driver but not users, so you do not want to > put a specific case as generic usage. I can't think of any cases of panic that isn't like this. There are panics for "vrele: negative reference count" and "freeing free block" which are in very similar situations. > For example, most ATM vendors can have multiple free()s in a calling chain Are you talking Async Transfer Mode or Automatic Teller Machine here? I guess what you're saying applies to either ;-) > 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? If you're freeing mbufs too many times then you will be seeing data corruption and probably panics anyway. You just see them closer to the problem this way. > Since memory leaking and misuse are very common and hard tracking > problem, the better thing is not to use alloc/free directly. I don't think you're understanding the use of mfree and friends. Any piece of code using a mbuf must have incremented the reference count on that mbuf - if it doesn't then the mbuf may be ripped out from under it at any time. It is more than just a memory accounting issue. People writing code which uses mbufs have to be very careful about passing ownership of mbufs around. Each function call has a protocol regarding who owns the mbuf after the success or failure. You have to be careful not to accidently create extra references, otherwise you'll corrupt the free lists and end up in trouble later. > Is this worth two cents :-) Easily! It's about $100 worth of programming advice - but I'm not sure it applies in this case ;-) David. 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?200005110022.aa91705>