Date: Mon, 3 Jun 2002 19:36:51 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Archie Cobbs <archie@dellroad.org> Cc: Julian Elischer <julian@elischer.org>, Alfred Perlstein <bright@mu.org>, freebsd-net@FreeBSD.ORG Subject: Re: Race condition with M_EXT ref count? Message-ID: <20020603193651.A29296@unixdaemons.com> In-Reply-To: <200206032301.g53N1To48300@arch20m.dellroad.org>; from archie@dellroad.org on Mon, Jun 03, 2002 at 04:01:29PM -0700 References: <20020603184740.A19963@unixdaemons.com> <200206032301.g53N1To48300@arch20m.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 03, 2002 at 04:01:29PM -0700, Archie Cobbs wrote:
> 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).
> 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:
count initially: 1
read 1
inc 1->2 read 1
write 2 inc 1->2
write 2
count finally: 2 (it should be 3 now)
Two frees will now result in the cluster being freed instead of 3.
The final free will be bogus.
> There's not way for the ref count to be too low, or for the cluster
> to be free'd twice, because all decrements are protected by splimp().
>
> However, once you start adding in custom code then we may not be
> so lucky..
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * Packet Design * http://www.packetdesign.com
--
Bosko Milekic
bmilekic@unixdaemons.com
bmilekic@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020603193651.A29296>