From: Trond Myklebust <trondmy@primarydata.com>
To: "tj@kernel.org" <tj@kernel.org>
Cc: "bfields@fieldses.org" <bfields@fieldses.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
"jlayton@poochiereds.net" <jlayton@poochiereds.net>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"jiangshanlai@gmail.com" <jiangshanlai@gmail.com>,
"anna.schumaker@netapp.com" <anna.schumaker@netapp.com>
Subject: Re: net/sunrpc: v4.14-rc4 lockdep warning
Date: Wed, 11 Oct 2017 17:49:59 +0000 [thread overview]
Message-ID: <1507744197.50316.3.camel@primarydata.com> (raw)
In-Reply-To: <20171010171919.GO3301751@devbig577.frc2.facebook.com>
T24gVHVlLCAyMDE3LTEwLTEwIGF0IDEwOjE5IC0wNzAwLCB0akBrZXJuZWwub3JnIHdyb3RlOg0K
PiBIZWxsbywNCj4gDQo+IE9uIFR1ZSwgT2N0IDEwLCAyMDE3IGF0IDA0OjQ4OjU3UE0gKzAwMDAs
IFRyb25kIE15a2xlYnVzdCB3cm90ZToNCj4gPiBUaGFua3MgZm9yIHRoZSBleHBsYW5hdGlvbi4g
V2hhdCBJJ20gbm90IHJlYWxseSB1bmRlcnN0YW5kaW5nIGhlcmUNCj4gPiB0aG91Z2gsIGlzIGhv
dyB0aGUgd29yayBpdGVtIGNvdWxkIGJlIHF1ZXVlZCBhdCBhbGwuIFdlIGhhdmUgYQ0KPiA+IHdh
aXRfb25fYml0X2xvY2soKSBpbiB4cHJ0X2Rlc3Ryb3koKSB0aGF0IHNob3VsZCBtZWFuIHRoZSB4
cHJ0LQ0KPiA+ID4gdGFza19jbGVhbnVwIHdvcmsgaXRlbSBoYXMgY29tcGxldGVkIHJ1bm5pbmcs
IGFuZCB0aGF0IGl0IGNhbm5vdA0KPiA+ID4gYmUNCj4gPiANCj4gPiByZXF1ZXVlZC4NCj4gPiAN
Cj4gPiBJcyB0aGVyZSBhIHBvc3NpYmlsaXR5IHRoYXQgdGhlIGZsdXNoX3F1ZXVlKCkgbWlnaHQg
YmUgdHJpZ2dlcmVkDQo+ID4gZGVzcGl0ZSB0aGUgd29yayBpdGVtIG5vdCBiZWluZyBxdWV1ZWQ/
DQo+IA0KPiBZZWFoLCBmb3Igc3VyZS4gIFRoZSBsb2NrZGVwIGFubm90YXRpb25zIGRvbid0IGRp
c3Rpbmd1aXNoIHRob3NlDQo+IGNhc2VzIGFuZCBhc3N1bWUgdGhlIHdvcnN0IGNhc2UuDQo+IA0K
DQpPSy4gTGV0J3MganVzdCByZW1vdmUgdGhhdCBjYWxsIHRvIGNhbmNlbF93b3JrX3N5bmMoKSB0
aGVuLiBBcyBJIHNhaWQsDQppdCBzaG91bGQgYmUgcmVkdW5kYW50IGR1ZSB0byB0aGUgd2FpdF9v
bl9iaXRfbG9jaygpLg0KDQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBt
YWludGFpbmVyLCBQcmltYXJ5RGF0YQ0KdHJvbmQubXlrbGVidXN0QHByaW1hcnlkYXRhLmNvbQ0K
WARNING: multiple messages have this Message-ID (diff)
From: Trond Myklebust <trondmy@primarydata.com>
To: "tj@kernel.org" <tj@kernel.org>
Cc: "bfields@fieldses.org" <bfields@fieldses.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
"jlayton@poochiereds.net" <jlayton@poochiereds.net>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"jiangshanlai@gmail.com" <jiangshanlai@gmail.com>,
"anna.schumaker@netapp.com" <anna.schumaker@netapp.com>
Subject: Re: net/sunrpc: v4.14-rc4 lockdep warning
Date: Wed, 11 Oct 2017 17:49:59 +0000 [thread overview]
Message-ID: <1507744197.50316.3.camel@primarydata.com> (raw)
In-Reply-To: <20171010171919.GO3301751@devbig577.frc2.facebook.com>
On Tue, 2017-10-10 at 10:19 -0700, tj@kernel.org wrote:
> Hello,
>
> On Tue, Oct 10, 2017 at 04:48:57PM +0000, Trond Myklebust wrote:
> > Thanks for the explanation. What I'm not really understanding here
> > though, is how the work item could be queued at all. We have a
> > wait_on_bit_lock() in xprt_destroy() that should mean the xprt-
> > > task_cleanup work item has completed running, and that it cannot
> > > be
> >
> > requeued.
> >
> > Is there a possibility that the flush_queue() might be triggered
> > despite the work item not being queued?
>
> Yeah, for sure. The lockdep annotations don't distinguish those
> cases and assume the worst case.
>
OK. Let's just remove that call to cancel_work_sync() then. As I said,
it should be redundant due to the wait_on_bit_lock().
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@primarydata.com
next prev parent reply other threads:[~2017-10-11 17:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-09 18:17 net/sunrpc: v4.14-rc4 lockdep warning Lorenzo Pieralisi
2017-10-09 18:32 ` Trond Myklebust
2017-10-09 18:32 ` Trond Myklebust
2017-10-10 14:03 ` tj
2017-10-10 16:48 ` Trond Myklebust
2017-10-10 16:48 ` Trond Myklebust
2017-10-10 17:19 ` tj
2017-10-11 17:49 ` Trond Myklebust [this message]
2017-10-11 17:49 ` Trond Myklebust
2017-10-16 13:34 ` Jan Glauber
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=1507744197.50316.3.camel@primarydata.com \
--to=trondmy@primarydata.com \
--cc=anna.schumaker@netapp.com \
--cc=bfields@fieldses.org \
--cc=jiangshanlai@gmail.com \
--cc=jlayton@poochiereds.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=tj@kernel.org \
/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.