Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 5 Mar 2005 00:25:06 -0800 (PST)
From:      Doug White <dwhite@gumbysoft.com>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/kern uipc_mbuf.c
Message-ID:  <20050305002418.A4084@carver.gumbysoft.com>
In-Reply-To: <34c3d5c3060ce1ea1be35d9be1198902@FreeBSD.org>
References:  <200503030241.j232fbCn032297@repoman.freebsd.org> <34c3d5c3060ce1ea1be35d9be1198902@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Mar 2005, John Baldwin wrote:

>
> On Mar 3, 2005, at 1:24 AM, Alan Cox wrote:
>
> > On Thu, Mar 03, 2005 at 02:41:37AM +0000, Doug White wrote:
> >> dwhite      2005-03-03 02:41:37 UTC
> >>
> >>   FreeBSD src repository
> >>
> >>   Modified files:
> >>     sys/kern             uipc_mbuf.c
> >>   Log:
> >>   Insert volatile cast to discourage gcc from optimizing the read
> >> outside
> >>   of the while loop.
> >>
> >>   Suggested by:   alc
> >>   MFC after:      1 day
> >>
> >>   Revision  Changes    Path
> >>   1.144     +4 -1      src/sys/kern/uipc_mbuf.c
> >
> > I tend to believe that the sparc64's casa() implementation is the real
> > culprit here.  Specifically, I don't believe the right asm operand
> > constraints are being used.  If I'm correct, the addition of volatile
> > here is unnecessary.  Can we hold the MFC until this hypothesis is
> > proven or disproven?
>
> Yes, it looks like it isn't clobbering "memory" which atomic operations
> on other architectures do.

I'll accept a patch to fix this and even try testing it. Fiddling with
low level sparc64 stuff is beyond my skill level, though.

-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite@gumbysoft.com          |  www.FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050305002418.A4084>