On 6. Jan 2012, at 20:39 , John Baldwin wrote:
>
> Now that all of this is in the tree, here is the small patch to cut the locks
> over to rwlocks rather than mutexes:
I have not checked if that's all (esp. for witness) but the macro conversion
look right.
> Index: kern/subr_witness.c
> ==
On Thursday, December 29, 2011 3:27:26 pm John Baldwin wrote:
> On Thursday, December 22, 2011 11:30:01 am John Baldwin wrote:
> > Another bit of lock contention I ran into between a device driver doing
> > slow
> > MAC filter updates and the receive path is IF_ADDR_LOCK(). NIC device
> > drive
On Wednesday, January 04, 2012 7:45:26 am Bjoern A. Zeeb wrote:
>
> On 3. Jan 2012, at 22:19 , Bjoern A. Zeeb wrote:
>
> > 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
On 4. Jan 2012, at 12:45 , Bjoern A. Zeeb wrote:
>
> On 3. Jan 2012, at 22:19 , Bjoern A. Zeeb wrote:
>
>> 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
>
On 3. Jan 2012, at 22:19 , Bjoern A. Zeeb wrote:
> 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/
>>
>> - if_addr_dev.
On 3. Jan 2012, at 21:45 , John Baldwin wrote:
> On Thursday, December 29, 2011 5:55:39 pm Gleb Smirnoff wrote:
>> Reviewing your patch I've found several problems not introduced by it,
>> but already existing, and somewhat related to your patch:
>>
>> 2) Potential race when dropping a lock insi
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/
>
> - if_addr_dev.patch This fixes a few new device drivers that were using
On Thursday, December 29, 2011 5:55:39 pm Gleb Smirnoff wrote:
> Reviewing your patch I've found several problems not introduced by it,
> but already existing, and somewhat related to your patch:
>
> 2) Potential race when dropping a lock inside FOREACH loop:
>
> igmp.c:2058
> mld6.c:1419
> mld6.
On 29. Dec 2011, at 22:55 , Gleb Smirnoff wrote:
> 3) I've found that in6_ifawithifp() doesn't do what it is supposed
> to, as well as uses incorrect locking during this. As last resort
> it should run through global list of addresses, not run throgh the
> ifp one again. Patch attached.
the first
On 3. Jan 2012, at 16:23 , John Baldwin wrote:
> On Thursday, December 29, 2011 5:55:39 pm Gleb Smirnoff wrote:
>> On Thu, Dec 29, 2011 at 03:27:26PM -0500, John Baldwin wrote:
>> J> - if_addr_uses.patch This changes callers of the existing macros to
>> use
>> J> eit
On Thursday, December 29, 2011 5:55:39 pm Gleb Smirnoff wrote:
> On Thu, Dec 29, 2011 at 03:27:26PM -0500, John Baldwin wrote:
> J> - if_addr_uses.patch This changes callers of the existing macros to use
> J> either read or write locks. This is the patch
> that
> J>
On Thu, Dec 29, 2011 at 03:27:26PM -0500, John Baldwin wrote:
J> - if_addr_uses.patch This changes callers of the existing macros to use
J> either read or write locks. This is the patch that
J> could use the most review.
Reviewing your patch I
On Thursday, December 22, 2011 11:30:01 am John Baldwin wrote:
> Another bit of lock contention I ran into between a device driver doing slow
> MAC filter updates and the receive path is IF_ADDR_LOCK(). NIC device
> drivers
> typically hold this lock while iterating the list of multicast addres
On Thu, Dec 29, 2011 at 11:36:01AM -0500, John Baldwin wrote:
J> On Monday, December 26, 2011 11:17:28 pm Gleb Smirnoff wrote:
J> > On Thu, Dec 22, 2011 at 11:30:01AM -0500, John Baldwin wrote:
J> > J> You can find the patch for 8.x at
J> > J> http://www.freebsd.org/~jhb/patches/if_addr_rwlock.pat
On Monday, December 26, 2011 11:17:28 pm Gleb Smirnoff wrote:
> On Thu, Dec 22, 2011 at 11:30:01AM -0500, John Baldwin wrote:
> J> You can find the patch for 8.x at
> J> http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patch
>
> Just my two pennies: for head/ patching if ip_carp.c should
> be s
2011/12/27 Gleb Smirnoff :
> On Tue, Dec 27, 2011 at 11:29:02AM +0100, Ermal Lu?i wrote:
> E> 2011/12/27 Gleb Smirnoff :
> E> > On Thu, Dec 22, 2011 at 11:30:01AM -0500, John Baldwin wrote:
> E> > J> You can find the patch for 8.x at
> E> > J> http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patc
On Tue, Dec 27, 2011 at 11:29:02AM +0100, Ermal Lu?i wrote:
E> 2011/12/27 Gleb Smirnoff :
E> > On Thu, Dec 22, 2011 at 11:30:01AM -0500, John Baldwin wrote:
E> > J> You can find the patch for 8.x at
E> > J> http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patch
E> >
E> > Just my two pennies: for
2011/12/27 Gleb Smirnoff :
> On Thu, Dec 22, 2011 at 11:30:01AM -0500, John Baldwin wrote:
> J> You can find the patch for 8.x at
> J> http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patch
>
> Just my two pennies: for head/ patching if ip_carp.c should
> be straightforward:
>
> 1) Using W in car
On Thu, Dec 22, 2011 at 11:30:01AM -0500, John Baldwin wrote:
J> You can find the patch for 8.x at
J> http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patch
Just my two pennies: for head/ patching if ip_carp.c should
be straightforward:
1) Using W in carp_alloc_if() and carp_free_if().
2) Usin
On Friday, December 23, 2011 12:13:44 pm Arnaud Lacombe wrote:
> Hi,
>
> On Thu, Dec 22, 2011 at 11:30 AM, John Baldwin wrote:
> > Another bit of lock contention I ran into between a device driver doing slow
> > MAC filter updates and the receive path is IF_ADDR_LOCK(). NIC device
> > drivers
>
On 22 Dec 2011, at 16:30, John Baldwin wrote:
> Phase 1 should definitely be MFC'able. Phase 2 may or may not be. Robert
> had
> the foresight to change drivers to use explicit function wrappers around
> IF_ADDR_LOCK, and sizeof(struct mtx) == sizeof(struct rwlock), so if we
> changed the l
Hi,
On Thu, Dec 22, 2011 at 11:30 AM, John Baldwin wrote:
> Another bit of lock contention I ran into between a device driver doing slow
> MAC filter updates and the receive path is IF_ADDR_LOCK(). NIC device drivers
> typically hold this lock while iterating the list of multicast addresses to
>
22 matches
Mail list logo