Bosko Milekic writes: > > > Secondly, this may not be as much of a problem as you may think. > > > Particularly if you consider the m_split() case, for example. For > > > example, if you're calling m_split() on an mbuf chain that may refer > > > to cluster(s) where none of the clusters has a ref. count greater than > > > 1 -- which is usually the case anyway -- then this is fine; since you > > > have posession of the chain referring to those clusters, and > > > presumably the chain isn't sitting in some queue somewhere (if it is, > > > you'd have to be under the protection of that queue anyway - splimp() > > > or whatever), then you're the only one who has posession of that > > > > The *chain* won't be sitting in a queue, but there may be a different > > mbuf in a queue somehwere that points to the same cluster. > > I did say "if the refcount is exactly 1" !!!! (which is often the > case in there).
Oops, sorry.. right, if the ref count is one there can be no race. > > Since mid-level code only increments the ref count, I think the > > worst that can happen is the ref count is incorrectly too high, > > which could only cause a memory leak rather than a crash. > > No, the worse case is that it is too low. > > increment: > > read > inc > write > > two increments, unprotected: Yes, you are right.. I was thinking that mbuf's were only free'd in interrupt handlers rather than allocated. If they are also allocated then the double-free race happens. We cannot assume that they aren't so this is indeed a more serious, if rare, bug. Re: the -stable patch. I agree we need a more general MFC/cleanup of some of the mbuf improvements from -current into -stable. If I find time perhaps I'll do that as well, but in a separate patch. For the present time, I'll commit this once 4.6-REL is done. Thanks for your comments. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
