The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: jan sonnek <ha2nny@gmail.com>,
	linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
	Catalin Marinas <catalin.marinas@arm.com>,
	Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: Regression - locking (all from 2.6.28)
Date: Tue, 03 Mar 2009 19:12:41 +0100	[thread overview]
Message-ID: <1236103961.5330.5108.camel@laptop> (raw)
In-Reply-To: <20090302121127.e46dc4be.akpm@linux-foundation.org>

On Mon, 2009-03-02 at 12:11 -0800, Andrew Morton wrote:

> > Mar  1 00:07:03 localhost kernel: [   86.440261] =========================================================
> > Mar  1 00:07:03 localhost kernel: [   86.440266] [ INFO: possible irq lock inversion dependency detected ]
> > Mar  1 00:07:03 localhost kernel: [   86.440271] 2.6.29-rc6-mm1-hanny #17
> > Mar  1 00:07:03 localhost kernel: [   86.440273] ---------------------------------------------------------
> 
> I stared at this for a while, but my brain broke trying to work out
> what lockdep is trying to tell us.
> 
> > Mar  1 00:07:03 localhost kernel: [   86.440277] Xorg/2733 just changed the state of lock:
> > Mar  1 00:07:03 localhost kernel: [   86.440280]  (fasync_lock){.-....}, at: [<c01952bb>] kill_fasync+0x20/0x3a
> > Mar  1 00:07:03 localhost kernel: [   86.440292] but this lock took another, HARDIRQ-READ-irq-unsafe lock in the past:
> > Mar  1 00:07:03 localhost kernel: [   86.440296]  (&f->f_lock){+.+...}
> 
> This message needs help.  A lock cannot "take" another lock. 

It seemed a simple enough way to tell that the latter lock nests inside
the former lock.

So what its saying is that we have:

  fasync_lock
    f->f_lock

nesting, and fasync_lock got used in hardirq context, but the lock that
was previously found to nest inside, was an IRQ-unsafe lock.

So $CODE code take f->f_lock, then IRQ could happen and fasync_lock,
f->f_lock could happen and we'd be stuck.

Would something like:

"but this lock had a %s-irq-unsafe nestee in the past:" read better?

> And why
> is f_lock described as "HARDIRQ-READ-irq-unsafe"?  It's a spinlock and
> the "READ" part is not relevant.

I think that's a bug due to the recent irq state tracking generalization
patches, will hunt.

> > Mar  1 00:07:03 localhost kernel: [   86.440299] 
> > Mar  1 00:07:03 localhost kernel: [   86.440300] and interrupts could create inverse lock ordering between them.
> > Mar  1 00:07:03 localhost kernel: [   86.440302] 




  parent reply	other threads:[~2009-03-03 18:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <49AC334A.9030800@gmail.com>
2009-03-02 20:11 ` Regression - locking (all from 2.6.28) Andrew Morton
2009-03-03 10:41   ` Catalin Marinas
2009-03-03 15:01     ` Catalin Marinas
2009-03-05  0:54       ` Dave Hansen
2009-03-05 18:04         ` Catalin Marinas
2009-03-05 18:29           ` Peter Zijlstra
2009-03-06 16:40         ` Catalin Marinas
2009-03-06 16:52           ` Dave Hansen
2009-03-06 17:18             ` Catalin Marinas
2009-03-06 17:26               ` Dave Hansen
2009-03-06 18:00                 ` Catalin Marinas
2009-03-06 19:19                   ` Dave Hansen
2009-03-06 19:28                     ` Pavel Machek
2009-03-16 22:04                       ` Rafael J. Wysocki
2009-03-17  0:07                         ` KAMEZAWA Hiroyuki
2009-03-14 16:24                           ` Pavel Machek
2009-03-16 17:12                     ` Catalin Marinas
2009-03-03 18:12   ` Peter Zijlstra [this message]
2009-03-22  4:45 jan sonnek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1236103961.5330.5108.camel@laptop \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=fengguang.wu@intel.com \
    --cc=ha2nny@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox