All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: <david.vrabel@citrix.com>, <mrushton@amazon.com>,
	<msw@amazon.com>, <boris.ostrovsky@oracle.com>,
	Jens Axboe <axboe@kernel.dk>, <xen-devel@lists.xensource.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.14 : NFO: trying to register non-static key. the code is fine but needs lockdep annotation.
Date: Tue, 11 Feb 2014 18:40:02 +0100	[thread overview]
Message-ID: <52FA6072.40908@citrix.com> (raw)
In-Reply-To: <1542261541.20140211170750@eikelenboom.it>

On 11/02/14 17:07, Sander Eikelenboom wrote:
> 
> Tuesday, February 11, 2014, 4:56:50 PM, you wrote:
> 
>> On Tue, Feb 11, 2014 at 04:52:15PM +0100, Sander Eikelenboom wrote:
>>> Hi Konrad,
>>>
>>> Today decided to tryout another kernel RC and your pull request to Jens on top of it .. and I encoutered this one:
> 
>> Thank you for testing!
> 
>> Could you provide the .config file please?
> 
> Attached
> 
>> Did you see this _before_ the pull request with Jens? I presume
>> not, but just double checking?
> 
> Nope not too my knowledge (though it's a bit messy with things broken on 3.14 at the moment)
> 
>> And lastly - what were you doing when you triggered this? Just launching
>> a guest?
> 
> Nope it triggers on guest shutdown ..
> 
> 
>> CC-ing Roger and other folks who were on the patches.
> 
>>>
>>>
>>> [  438.029756] INFO: trying to register non-static key.
>>> [  438.029759] the code is fine but needs lockdep annotation.
>>> [  438.029760] turning off the locking correctness validator.
>>> [  438.029770] CPU: 3 PID: 9593 Comm: blkback.2.xvda Tainted: G        W    3.14.0-rc2-20140211-pcireset-net-btrevert-xenblock+ #1
>>> [  438.029773] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS V1.8B1 09/13/2010
>>> [  438.029784]  ffff88005224c4f0 ffff88004e5d9b68 ffffffff81b808c4 ffff88004ba2b510
>>> [  438.029791]  0000000000000002 ffff88004e5d9c38 ffffffff81116eab ffff88004e5d9bf8
>>> [  438.029798]  ffffffff81117b35 0000000000000000 0000000000000000 ffffffff82cee570
>>> [  438.029799] Call Trace:
>>> [  438.029815]  [<ffffffff81b808c4>] dump_stack+0x46/0x58
>>> [  438.029826]  [<ffffffff81116eab>] __lock_acquire+0x1c2b/0x2220
>>> [  438.029833]  [<ffffffff81117b35>] ? lock_acquire+0xe5/0x150
>>> [  438.029841]  [<ffffffff81117b0d>] lock_acquire+0xbd/0x150
>>> [  438.029847]  [<ffffffff810e5965>] ? flush_work+0x5/0x290
>>> [  438.029852]  [<ffffffff810e599d>] flush_work+0x3d/0x290
>>> [  438.029856]  [<ffffffff810e5965>] ? flush_work+0x5/0x290
>>> [  438.029863]  [<ffffffff81117b35>] ? lock_acquire+0xe5/0x150
>>> [  438.029872]  [<ffffffff816fef01>] ? xen_blkif_schedule+0x1a1/0x8d0
>>> [  438.029881]  [<ffffffff81b8ae0d>] ? _raw_spin_unlock_irqrestore+0x6d/0x90
>>> [  438.029888]  [<ffffffff8111392b>] ? trace_hardirqs_on_caller+0xfb/0x240
>>> [  438.029894]  [<ffffffff81113a7d>] ? trace_hardirqs_on+0xd/0x10
>>> [  438.029901]  [<ffffffff816fefe9>] xen_blkif_schedule+0x289/0x8d0
>>> [  438.029907]  [<ffffffff8110d510>] ? __init_waitqueue_head+0x60/0x60
>>> [  438.029913]  [<ffffffff81113a7d>] ? trace_hardirqs_on+0xd/0x10
>>> [  438.029919]  [<ffffffff81b8ae21>] ? _raw_spin_unlock_irqrestore+0x81/0x90
>>> [  438.029925]  [<ffffffff816fed60>] ? xen_blkif_be_int+0x40/0x40
>>> [  438.029932]  [<ffffffff810ee374>] kthread+0xe4/0x100
>>> [  438.029938]  [<ffffffff81b8afe0>] ? _raw_spin_unlock_irq+0x30/0x50
>>> [  438.029946]  [<ffffffff810ee290>] ? __init_kthread_worker+0x70/0x70
>>> [  438.029951]  [<ffffffff81b8c1fc>] ret_from_fork+0x7c/0xb0
>>> [  438.029958]  [<ffffffff810ee290>] ? __init_kthread_worker+0x70/0x70
>>>
>>> Doesn't seem to serious .. but never the less :-)

Thanks for the report!

Does the following patch solve the problem?

---
commit c1460953d081c8a18ac9e84fe90f696cdceae105
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Tue Feb 11 17:21:19 2014 +0100

    xen-blkback: init persistent_purge_work work_struct
    
    Do a dummy initialization of the persistent_purge_work
    work_struct on xen_blkif_alloc, so that when flush_work is called on
    shutdown the struct is initialized even if it hasn't been used.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 84973c6..3df7575 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -129,6 +129,17 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
 	blkif->free_pages_num = 0;
 	atomic_set(&blkif->persistent_gnt_in_use, 0);
 	atomic_set(&blkif->inflight, 0);
+	/*
+	 * Init the work struct with a NULL function, this is done
+	 * so that flush_work doesn't complain when shutting down if
+	 * persistent_purge_work has not been used during the lifetime
+	 * of this blkback instance.
+	 *
+	 * NB: In purge_persistent_gnt we make sure that
+	 * persistent_purge_work is always correctly setup with a valid
+	 * function pointer before being scheduled.
+	 */
+	INIT_WORK(&blkif->persistent_purge_work, NULL);
 
 	INIT_LIST_HEAD(&blkif->pending_free);
 



WARNING: multiple messages have this Message-ID (diff)
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: david.vrabel@citrix.com, mrushton@amazon.com, msw@amazon.com,
	boris.ostrovsky@oracle.com, Jens Axboe <axboe@kernel.dk>,
	xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.14 : NFO: trying to register non-static key. the code is fine but needs lockdep annotation.
Date: Tue, 11 Feb 2014 18:40:02 +0100	[thread overview]
Message-ID: <52FA6072.40908@citrix.com> (raw)
In-Reply-To: <1542261541.20140211170750@eikelenboom.it>

On 11/02/14 17:07, Sander Eikelenboom wrote:
> 
> Tuesday, February 11, 2014, 4:56:50 PM, you wrote:
> 
>> On Tue, Feb 11, 2014 at 04:52:15PM +0100, Sander Eikelenboom wrote:
>>> Hi Konrad,
>>>
>>> Today decided to tryout another kernel RC and your pull request to Jens on top of it .. and I encoutered this one:
> 
>> Thank you for testing!
> 
>> Could you provide the .config file please?
> 
> Attached
> 
>> Did you see this _before_ the pull request with Jens? I presume
>> not, but just double checking?
> 
> Nope not too my knowledge (though it's a bit messy with things broken on 3.14 at the moment)
> 
>> And lastly - what were you doing when you triggered this? Just launching
>> a guest?
> 
> Nope it triggers on guest shutdown ..
> 
> 
>> CC-ing Roger and other folks who were on the patches.
> 
>>>
>>>
>>> [  438.029756] INFO: trying to register non-static key.
>>> [  438.029759] the code is fine but needs lockdep annotation.
>>> [  438.029760] turning off the locking correctness validator.
>>> [  438.029770] CPU: 3 PID: 9593 Comm: blkback.2.xvda Tainted: G        W    3.14.0-rc2-20140211-pcireset-net-btrevert-xenblock+ #1
>>> [  438.029773] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS V1.8B1 09/13/2010
>>> [  438.029784]  ffff88005224c4f0 ffff88004e5d9b68 ffffffff81b808c4 ffff88004ba2b510
>>> [  438.029791]  0000000000000002 ffff88004e5d9c38 ffffffff81116eab ffff88004e5d9bf8
>>> [  438.029798]  ffffffff81117b35 0000000000000000 0000000000000000 ffffffff82cee570
>>> [  438.029799] Call Trace:
>>> [  438.029815]  [<ffffffff81b808c4>] dump_stack+0x46/0x58
>>> [  438.029826]  [<ffffffff81116eab>] __lock_acquire+0x1c2b/0x2220
>>> [  438.029833]  [<ffffffff81117b35>] ? lock_acquire+0xe5/0x150
>>> [  438.029841]  [<ffffffff81117b0d>] lock_acquire+0xbd/0x150
>>> [  438.029847]  [<ffffffff810e5965>] ? flush_work+0x5/0x290
>>> [  438.029852]  [<ffffffff810e599d>] flush_work+0x3d/0x290
>>> [  438.029856]  [<ffffffff810e5965>] ? flush_work+0x5/0x290
>>> [  438.029863]  [<ffffffff81117b35>] ? lock_acquire+0xe5/0x150
>>> [  438.029872]  [<ffffffff816fef01>] ? xen_blkif_schedule+0x1a1/0x8d0
>>> [  438.029881]  [<ffffffff81b8ae0d>] ? _raw_spin_unlock_irqrestore+0x6d/0x90
>>> [  438.029888]  [<ffffffff8111392b>] ? trace_hardirqs_on_caller+0xfb/0x240
>>> [  438.029894]  [<ffffffff81113a7d>] ? trace_hardirqs_on+0xd/0x10
>>> [  438.029901]  [<ffffffff816fefe9>] xen_blkif_schedule+0x289/0x8d0
>>> [  438.029907]  [<ffffffff8110d510>] ? __init_waitqueue_head+0x60/0x60
>>> [  438.029913]  [<ffffffff81113a7d>] ? trace_hardirqs_on+0xd/0x10
>>> [  438.029919]  [<ffffffff81b8ae21>] ? _raw_spin_unlock_irqrestore+0x81/0x90
>>> [  438.029925]  [<ffffffff816fed60>] ? xen_blkif_be_int+0x40/0x40
>>> [  438.029932]  [<ffffffff810ee374>] kthread+0xe4/0x100
>>> [  438.029938]  [<ffffffff81b8afe0>] ? _raw_spin_unlock_irq+0x30/0x50
>>> [  438.029946]  [<ffffffff810ee290>] ? __init_kthread_worker+0x70/0x70
>>> [  438.029951]  [<ffffffff81b8c1fc>] ret_from_fork+0x7c/0xb0
>>> [  438.029958]  [<ffffffff810ee290>] ? __init_kthread_worker+0x70/0x70
>>>
>>> Doesn't seem to serious .. but never the less :-)

Thanks for the report!

Does the following patch solve the problem?

---
commit c1460953d081c8a18ac9e84fe90f696cdceae105
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Tue Feb 11 17:21:19 2014 +0100

    xen-blkback: init persistent_purge_work work_struct
    
    Do a dummy initialization of the persistent_purge_work
    work_struct on xen_blkif_alloc, so that when flush_work is called on
    shutdown the struct is initialized even if it hasn't been used.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 84973c6..3df7575 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -129,6 +129,17 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
 	blkif->free_pages_num = 0;
 	atomic_set(&blkif->persistent_gnt_in_use, 0);
 	atomic_set(&blkif->inflight, 0);
+	/*
+	 * Init the work struct with a NULL function, this is done
+	 * so that flush_work doesn't complain when shutting down if
+	 * persistent_purge_work has not been used during the lifetime
+	 * of this blkback instance.
+	 *
+	 * NB: In purge_persistent_gnt we make sure that
+	 * persistent_purge_work is always correctly setup with a valid
+	 * function pointer before being scheduled.
+	 */
+	INIT_WORK(&blkif->persistent_purge_work, NULL);
 
 	INIT_LIST_HEAD(&blkif->pending_free);
 

  reply	other threads:[~2014-02-11 17:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-10 18:44 [GIT PULL] (xen) stable/for-jens-3.14 Konrad Rzeszutek Wilk
2014-02-10 19:54 ` Jens Axboe
2014-02-11 15:52   ` [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.14 : NFO: trying to register non-static key. the code is fine but needs lockdep annotation Sander Eikelenboom
2014-02-11 15:52     ` Sander Eikelenboom
2014-02-11 15:56     ` Konrad Rzeszutek Wilk
2014-02-11 16:07       ` Sander Eikelenboom
2014-02-11 16:07         ` Sander Eikelenboom
2014-02-11 17:40         ` Roger Pau Monné [this message]
2014-02-11 17:40           ` Roger Pau Monné
2014-02-11 17:52           ` David Vrabel
2014-02-11 17:52             ` David Vrabel
2014-02-11 18:15             ` Roger Pau Monné
2014-02-11 18:15               ` Roger Pau Monné
2014-02-11 18:21               ` David Vrabel
2014-02-11 18:21                 ` David Vrabel
2014-02-11 20:21                 ` Sander Eikelenboom
2014-02-11 20:21                   ` Sander Eikelenboom
2014-02-11 21:44                   ` [Xen-devel] " Jens Axboe
2014-02-12  3:14                     ` Konrad Rzeszutek Wilk
2014-02-12  3:34                       ` Jens Axboe

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=52FA6072.40908@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=axboe@kernel.dk \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@eikelenboom.it \
    --cc=mrushton@amazon.com \
    --cc=msw@amazon.com \
    --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.