Date: Tue, 27 Mar 2012 21:40:10 GMT From: Ryan Stone <rysto32@gmail.com> To: freebsd-net@FreeBSD.org Subject: Re: kern/165863 Message-ID: <201203272140.q2RLeAeg076788@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/165863; it has been noted by GNATS. From: Ryan Stone <rysto32@gmail.com> To: Eric van Gyzen <eric@vangyzen.net> Cc: Gleb Smirnoff <glebius@freebsd.org>, Eric van Gyzen <eric_van_gyzen@dell.com>, emaste@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/165863 Date: Tue, 27 Mar 2012 17:24:37 -0400 2012/3/9 Eric van Gyzen <eric@vangyzen.net>: > On 03/09/12 03:20, Gleb Smirnoff wrote: >> >> =A0 Hello, Eric and Ed. >> >> =A0 Can you look at this patch? I decided to utilize newer callout API, >> that allows to delegate lock retrieval to the callout subsystem, and >> this makes things simplier. Hope that should work. >> >> =A0 Patch is against head. > > > Doesn't arptimer() still need to acquire the if_afdata_lock in order to f= ree > the entry in the normal case (when the llentry is still in the hash bucke= t > list)? Oops, on reviewing the code I believe that this is correct. My test case wouldn't have had arp entries timing out so I wouldn't have hit this case. I'll try to come up with a test case for this. Unfortunately it's not as quite as simple just acquiring if_afdata_lock because of lock ordering problems. I think that we'll have to revert the usage of callout_init_rw so that arptimer can acquire the if_afdata_lock before acquiring the lock LLE_LOCK.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203272140.q2RLeAeg076788>