Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Mar 2006 15:01:05 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        "Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=" <des@des.no>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/i386/include atomic.h
Message-ID:  <200603281501.08699.jhb@freebsd.org>
In-Reply-To: <86acbawerh.fsf@xps.des.no>
References:  <200603281434.k2SEYmaR031447@repoman.freebsd.org> <200603281358.26703.jhb@freebsd.org> <86acbawerh.fsf@xps.des.no>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 28 March 2006 14:28, Dag-Erling Sm=F8rgrav wrote:
> John Baldwin <jhb@freebsd.org> writes:
> > On Tuesday 28 March 2006 13:05, Dag-Erling Sm=F8rgrav wrote:
> > > John Baldwin <jhb@freebsd.org> writes:
> > > > One reason for not having the casts, btw, is that you lose type
> > > > checking.
> > > Huh?  Before my patch, any use of atomic_*_ptr with warnings turned
> > > off would result in a slew of warnings because you'd be passing
> > > pointers to a function which is declared to take u_int.  The only way
> > > to make this type safe is to use inline functions instead of the
> > > macros I wrote.
> >
> > s/off/on/ I trust
> >
> > Not true.  The tinderbox would attest to that.  Please see code such as
> > this:  [...]
>=20
> which uses uintptr_t, not actual pointers, to avoid warnings.  In
> effect, that code is broken.

No, it's on _purpose_, because we do arithmetic on the value (setting
flags, etc.)  We happen to use curthread as our cookie value, but
the cookie is an integer, not a pointer.

> Apply the attached patch, see how far a buildkernel gets...

Your patch could break the kernel, as it doesn't say that the value
being modified is volatile (volatile void ** !=3D volatile uintptr_t *).
I can't even get cdecl to tell me how to declare a pointer to a volatile
void pointer.

> I think the proper thing to do, to cover all your bases, would be to
> define a MD atomic_*_intptr family which operated on uintptr_t, and
> define an MI atomic_*_ptr family which operates on void * based on
> that.

*sigh*  Where were you 6 months ago when I changed atomic_foo_ptr() to
use uintptr_t rather than void *?  (For very valid reasons you haven't
bothered to research?)

> > Even userland uses casts when it uses void * rather than uintptr_t for
> > the underlying type.  See src/lib/libpthread/sys/lock.c or
> > src/lib/libthr/thr_umtx.h.
>=20
> The latter only works because libthr is built with warnings disabled.
> I just finished working on making it build at WARNS level 2; higher
> levels will require a major overhaul, because the kernel interface it
> uses is fundamentally broken.

No, it needs to use the correct casts.  We've been through this, the
atomic(9) manpage covers it, etc.

=2D-=20
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =3D  http://www.FreeBSD.org



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