Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Aug 2005 13:56:57 -0400
From:      John Baldwin <jhb@FreeBSD.org>
To:        Hajimu UMEMOTO <ume@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/netinet6 in6_src.c
Message-ID:  <200508171356.59672.jhb@FreeBSD.org>
In-Reply-To: <yger7csmp6n.wl%ume@mahoroba.org>
References:  <200508161949.j7GJnAaG015685@repoman.freebsd.org> <200508171318.27652.jhb@FreeBSD.org> <yger7csmp6n.wl%ume@mahoroba.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 17 August 2005 01:46 pm, Hajimu UMEMOTO wrote:
> Hi,
>
> >>>>> On Wed, 17 Aug 2005 13:18:25 -0400
> >>>>> John Baldwin <jhb@FreeBSD.org> said:
>
> jhb> Thanks.  I see that you still kept the mutex and and properly lock
> both the sx jhb> and mutex when making updates, so it seems it is on
> purpose.  The one place jhb> that doesn't use the sx lock is
> lookup_addrsel_policy() which is called from jhb> in6_selectsrc().  I guess
> it is not ok to sleep in that function and that is jhb> why you don't use
> the sx lock in that one place?
>
> Because, lookup_addrsel_policy() is protected by mutex lock.
> add_addrsel_policyent() and delete_addrsel_policyent() do update the
> tailq.  Both of the two functions are also protected by mutex.  So, I
> tought that lookup_addrsel_policy() doesn't need sx lock.
> I tried to stop using of mutex locks and used only sx locks, as learn
> by mistake.  It ended up with exclusive lock error between INP_LOCK.
> So, I avoided to use sx lock in lookup_addrsel_policy().
> Am I something wrong?

Ah, if you had a witness warning from INP_LOCK because INP_LOCK is held when 
in6_selectsrc() is called then you did the right thing and that answers my 
question.  Thanks.

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



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