Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Jan 2012 15:47:34 +0000
From:      "Bjoern A. Zeeb" <bz@FreeBSD.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        FreeBSD Net <freebsd-net@freebsd.org>, Robert Watson <rwatson@freebsd.org>
Subject:   Re: Transitioning if_addr_lock to an rwlock
Message-ID:  <4D3CFC08-7DE4-4620-B8FC-162CEEA14F75@FreeBSD.org>
In-Reply-To: <21AEF92A-94B5-4115-91A7-D3BEEFDAB433@FreeBSD.org>
References:  <201112221130.01823.jhb@freebsd.org> <201112291527.26763.jhb@freebsd.org> <76A806B1-6D12-46DD-BC9D-F3CBDC587330@FreeBSD.org> <21AEF92A-94B5-4115-91A7-D3BEEFDAB433@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 4. Jan 2012, at 12:45 , Bjoern A. Zeeb wrote:

>=20
> On 3. Jan 2012, at 22:19 , Bjoern A. Zeeb wrote:
>=20
>> On 29. Dec 2011, at 20:27 , John Baldwin wrote:
>>> I've gone ahead with this approach.  I have three separate patches =
that should
>>> implement Phase 1.  All of them can be found at
>>> http://www.FreeBSD.org/~jhb/patches/
>>>=20
>>> - if_addr_dev.patch      This fixes a few new device drivers that =
were using
>>>                       the locking macros directly rather than the =
wrapper
>>>                       functions Robert added.  I've already sent =
this
>>>                       directly to the relevant driver maintainers =
for their
>>>                       review.
>>> - if_addr_macros.patch   This adds new locking macros to support =
read locks vs
>>>                       write locks.  However, they all still map to =
mutex
>>>                       operations.
>>=20
>> The first two look good.  I wondered why you didn't need the =
r-wraper-functions
>> but obviously they had been named like that already:)
>>=20
>>=20
>> I'll look at the one below in more detail and get back to you.
>>=20
>>> - if_addr_uses.patch     This changes callers of the existing macros =
to use
>>>                       either read or write locks.  This is the patch =
that
>>>                       could use the most review.
>=20
> I went through this one as well.
>=20
> I skipped mld6.c, in6.c, igmp.c and in.c as they need to be =
regenerated.
> in nd6_rtr.c/prelist_update I think we are lacking an ifa_ref() dance
> currently but that's unrelated.  The other conversions to R/W locking
> seemed ok.

The other 4 seem ok in the regen'ed version though I didn't fully check
all RLOCKs into called functions in the two multicast ones.

/bz

--=20
Bjoern A. Zeeb                                 You have to have visions!
   It does not matter how good you are. It matters what good you do!




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D3CFC08-7DE4-4620-B8FC-162CEEA14F75>