Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Apr 2010 09:26:06 -0700
From:      Jack Vogel <jfvogel@gmail.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        pyunyh@gmail.com, freebsd-current@freebsd.org, Mike Tancsa <mike@sentex.net>
Subject:   Re: LOR on em in HEAD ( was Re: em driver regression
Message-ID:  <z2l2a41acea1004120926k728fe54cz4e29503ed9ab42c2@mail.gmail.com>
In-Reply-To: <201004121052.42350.jhb@freebsd.org>
References:  <201004081313.o38DD4JM041821@lava.sentex.ca> <201004091900.o39J0b0k051687@lava.sentex.ca> <z2r2a41acea1004091209maca81e47td7f03d7c343b3ec9@mail.gmail.com> <201004121052.42350.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 12, 2010 at 7:52 AM, John Baldwin <jhb@freebsd.org> wrote:

> On Friday 09 April 2010 3:09:24 pm Jack Vogel wrote:
> > Someone else also pointed this out. I'm dubious about its claim.
> > This happens because there is an RX lock taken in rxeof, its held
> > thru the call into the stack, it then encounters another lock there
> > and hence this complaint. I've had the RX hold as it is for a long
> > while and would rather not have to give it up, can someone look
> > at it and advise?
>
> I've seen it happen with igb.  I suspect it is a transitive lock order.
>  That
> is, you probably never have the UDP lock acquired before an em/igb RX lock.
> However, if you have an em/igb adapter TX lock held when you acquire an
> em/igb
> RX lock in one place, and in if_start() you acquire the TX lock while the
> UDP
> lock is held, that can trigger the LOR.  Specifically, those two paths
> would
> give you these two orders:
>
> TX -> RX
> UDP -> TX
>
> which implies the order
>
> UDP -> RX
>
> (lock order relationsips are transitive, just like a > b and b > c implies
> a > c).
>
> However, I haven't been able to track down what the raw orders are that
> might
> lead to this transitive order.  Attilio added some sysctls to dump all the
> raw
> lock orders in one of the debug.witness sysctls.  You can also try
> hardcoding
> the 'RX -> UDP' order using WITNESS_DEFINEORDER() before any of the em/igb
> RX/TX locks are acquired to see what different LOR is triggered.  If that
> LOR
> looks valid then you can keep hardcoding valid orders until you find the
> invalid one.
>
> Do you think releasing the RX lock before the stack entry would get rid of
the problem?

Other ideas?

Jack



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