From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Daniel Stodden <daniel.stodden@citrix.com>
Cc: Xen <xen-devel@lists.xensource.com>, Tom Kopec <tek@acm.org>
Subject: blktap lockdep hiccup
Date: Tue, 07 Sep 2010 11:39:49 +1000 [thread overview]
Message-ID: <4C8597E5.4070802@goop.org> (raw)
In-Reply-To: <1283468932.3092.3924.camel@ramone.somacoma.net>
On 09/03/2010 09:08 AM, Daniel Stodden wrote:
> On Thu, 2010-09-02 at 18:46 -0400, Jeremy Fitzhardinge wrote:
>> On 08/22/2010 11:54 PM, Daniel Stodden wrote:
>>> Response processing doesn't really belong into hard irq context.
>>>
>>> Another potential problem this avoids is that switching interrupt cpu
>>> affinity in Xen domains can presently lead to event loss, if
>>> RING_FINAL_CHECK is run from hard irq context.
>> I just got this warning from a 32-bit pv domain. I think it may relate
>> to this change. The warning is
> We clearly spin_lock_irqsave all through the blkif_do_interrupt frame.
>
> It follows that something underneath quite unconditionally chose to
> reenable them again (?)
>
> Either: Can you add a bunch of similar WARN_ONs along that path?
>
> Or: This lock is quite coarse-grained. The lock only matters for queue
> access, and we know irqs are reenabled, so no need for flags. In fact we
> only need to spin_lock_irq around the __blk_end_ calls and
> kick_pending_.
>
> But I don't immediately see what's to blame, so I'd be curious.
I haven't got around to investigating this in more detail yet, but
there's also this long-standing lockdep hiccup in blktap:
Starting auto Xen domains: lurch alloc irq_desc for 1235 on node 0
alloc kstat_irqs on node 0
block tda: sector-size: 512 capacity: 614400
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
Pid: 4266, comm: tapdisk2 Not tainted 2.6.32.21 #146
Call Trace:
[<ffffffff8107f0a4>] __lock_acquire+0x1df/0x16e5
[<ffffffff8100f955>] ? xen_force_evtchn_callback+0xd/0xf
[<ffffffff81010082>] ? check_events+0x12/0x20
[<ffffffff810f0359>] ? apply_to_page_range+0x295/0x37d
[<ffffffff81080677>] lock_acquire+0xcd/0xf1
[<ffffffff810f0359>] ? apply_to_page_range+0x295/0x37d
[<ffffffff810f0259>] ? apply_to_page_range+0x195/0x37d
[<ffffffff81506f7d>] _spin_lock+0x31/0x40
[<ffffffff810f0359>] ? apply_to_page_range+0x295/0x37d
[<ffffffff810f0359>] apply_to_page_range+0x295/0x37d
[<ffffffff812ab37c>] ? blktap_map_uaddr_fn+0x0/0x55
[<ffffffff8100d0cf>] ? xen_make_pte+0x8a/0x8e
[<ffffffff812ac34e>] blktap_device_process_request+0x43d/0x954
[<ffffffff8100f955>] ? xen_force_evtchn_callback+0xd/0xf
[<ffffffff81010082>] ? check_events+0x12/0x20
[<ffffffff8100f955>] ? xen_force_evtchn_callback+0xd/0xf
[<ffffffff81010082>] ? check_events+0x12/0x20
[<ffffffff8107d687>] ? mark_held_locks+0x52/0x70
[<ffffffff81506ddb>] ? _spin_unlock_irq+0x30/0x3c
[<ffffffff8107d949>] ? trace_hardirqs_on_caller+0x125/0x150
[<ffffffff812acba6>] blktap_device_run_queue+0x1c5/0x28f
[<ffffffff812a0234>] ? unbind_from_irq+0x18/0x198
[<ffffffff81010082>] ? check_events+0x12/0x20
[<ffffffff812ab14d>] blktap_ring_poll+0x7c/0xc7
[<ffffffff81124e9b>] do_select+0x387/0x584
[<ffffffff81124b14>] ? do_select+0x0/0x584
[<ffffffff811255de>] ? __pollwait+0x0/0xcc
[<ffffffff811256aa>] ? pollwake+0x0/0x56
[<ffffffff811256aa>] ? pollwake+0x0/0x56
[<ffffffff811256aa>] ? pollwake+0x0/0x56
[<ffffffff811256aa>] ? pollwake+0x0/0x56
[<ffffffff8108059b>] ? __lock_acquire+0x16d6/0x16e5
[<ffffffff8100f955>] ? xen_force_evtchn_callback+0xd/0xf
[<ffffffff81010082>] ? check_events+0x12/0x20
[<ffffffff8100f955>] ? xen_force_evtchn_callback+0xd/0xf
[<ffffffff81010082>] ? check_events+0x12/0x20
[<ffffffff8100f955>] ? xen_force_evtchn_callback+0xd/0xf
[<ffffffff811252a4>] core_sys_select+0x20c/0x2da
[<ffffffff811250d6>] ? core_sys_select+0x3e/0x2da
[<ffffffff81010082>] ? check_events+0x12/0x20
[<ffffffff8101006f>] ? xen_restore_fl_direct_end+0x0/0x1
[<ffffffff81108661>] ? kmem_cache_free+0x18e/0x1c8
[<ffffffff8141e912>] ? sock_destroy_inode+0x19/0x1b
[<ffffffff811299bd>] ? destroy_inode+0x2f/0x44
[<ffffffff8102ef22>] ? pvclock_clocksource_read+0x4b/0xa2
[<ffffffff8100fe8b>] ? xen_clocksource_read+0x21/0x23
[<ffffffff81010003>] ? xen_clocksource_get_cycles+0x9/0x16
[<ffffffff81075700>] ? ktime_get_ts+0xb2/0xbf
[<ffffffff811255b6>] sys_select+0x96/0xbe
[<ffffffff81013d32>] system_call_fastpath+0x16/0x1b
block tdb: sector-size: 512 capacity: 20971520
block tdc: sector-size: 512 capacity: 146800640
block tdd: sector-size: 512 capacity: 188743680
J
next prev parent reply other threads:[~2010-09-07 1:39 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-23 6:54 Fix the occasional xen-blkfront deadlock, when irqbalancing Daniel Stodden
2010-08-23 6:54 ` [PATCH] blkfront: Move blkif_interrupt into a tasklet Daniel Stodden
2010-08-23 7:01 ` Daniel Stodden
2010-09-02 22:46 ` Jeremy Fitzhardinge
2010-09-02 23:08 ` Daniel Stodden
2010-09-07 1:39 ` Jeremy Fitzhardinge [this message]
2010-09-07 1:46 ` blktap lockdep hiccup Daniel Stodden
2010-09-08 2:03 ` [PATCH] blkfront: Move blkif_interrupt into a tasklet Jeremy Fitzhardinge
2010-09-08 2:21 ` Daniel Stodden
2010-09-08 6:37 ` Jeremy Fitzhardinge
2010-09-23 16:08 ` Andrew Jones
2010-09-23 16:23 ` Jeremy Fitzhardinge
2010-09-23 16:38 ` Paolo Bonzini
2010-09-23 18:36 ` Jeremy Fitzhardinge
2010-09-24 7:14 ` Andrew Jones
2010-09-24 18:50 ` Jeremy Fitzhardinge
2010-09-27 7:41 ` Andrew Jones
2010-09-27 9:46 ` Daniel Stodden
2010-09-27 10:21 ` Andrew Jones
2011-08-16 11:26 ` imammedo
2011-08-16 14:57 ` Konrad Rzeszutek Wilk
2011-08-17 2:38 ` Konrad Rzeszutek Wilk
2011-08-17 7:30 ` Paolo Bonzini
2011-08-17 9:07 ` Igor Mammedov
2011-08-24 15:36 ` Konrad Rzeszutek Wilk
2011-08-24 16:36 ` Igor Mammedov
2011-08-29 19:46 ` Konrad Rzeszutek Wilk
2011-08-31 23:47 ` [PATCH] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context Igor Mammedov
2011-08-31 23:47 ` Igor Mammedov
2011-08-31 22:37 ` Jeremy Fitzhardinge
2011-08-31 22:37 ` Jeremy Fitzhardinge
2011-09-01 8:19 ` Igor Mammedov
2011-09-01 11:46 ` [PATCH v2] " Igor Mammedov
2011-09-01 11:46 ` Igor Mammedov
2011-09-01 15:45 ` Konrad Rzeszutek Wilk
2011-09-01 16:46 ` Jeremy Fitzhardinge
2011-09-02 8:18 ` Igor Mammedov
2011-09-02 13:40 ` [Xen-devel] " Konrad Rzeszutek Wilk
2011-09-02 13:40 ` Konrad Rzeszutek Wilk
2011-09-02 14:01 ` [Xen-devel] " Igor Mammedov
2011-09-02 14:47 ` Konrad Rzeszutek Wilk
2011-09-02 14:47 ` Konrad Rzeszutek Wilk
2011-09-06 9:16 ` [Xen-devel] " Igor Mammedov
2011-09-06 9:16 ` Igor Mammedov
2011-09-02 9:19 ` Igor Mammedov
2011-09-02 10:00 ` Keir Fraser
2010-08-23 21:09 ` Fix the occasional xen-blkfront deadlock, when irqbalancing Jeremy Fitzhardinge
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=4C8597E5.4070802@goop.org \
--to=jeremy@goop.org \
--cc=daniel.stodden@citrix.com \
--cc=tek@acm.org \
--cc=xen-devel@lists.xensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.