diff for duplicates of <1507744197.50316.3.camel@primarydata.com> diff --git a/a/1.txt b/N1/1.txt index c3bb3c2..27eae5f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,16 +1,26 @@ -T24gVHVlLCAyMDE3LTEwLTEwIGF0IDEwOjE5IC0wNzAwLCB0akBrZXJuZWwub3JnIHdyb3RlOg0K -PiBIZWxsbywNCj4gDQo+IE9uIFR1ZSwgT2N0IDEwLCAyMDE3IGF0IDA0OjQ4OjU3UE0gKzAwMDAs -IFRyb25kIE15a2xlYnVzdCB3cm90ZToNCj4gPiBUaGFua3MgZm9yIHRoZSBleHBsYW5hdGlvbi4g -V2hhdCBJJ20gbm90IHJlYWxseSB1bmRlcnN0YW5kaW5nIGhlcmUNCj4gPiB0aG91Z2gsIGlzIGhv -dyB0aGUgd29yayBpdGVtIGNvdWxkIGJlIHF1ZXVlZCBhdCBhbGwuIFdlIGhhdmUgYQ0KPiA+IHdh -aXRfb25fYml0X2xvY2soKSBpbiB4cHJ0X2Rlc3Ryb3koKSB0aGF0IHNob3VsZCBtZWFuIHRoZSB4 -cHJ0LQ0KPiA+ID4gdGFza19jbGVhbnVwIHdvcmsgaXRlbSBoYXMgY29tcGxldGVkIHJ1bm5pbmcs -IGFuZCB0aGF0IGl0IGNhbm5vdA0KPiA+ID4gYmUNCj4gPiANCj4gPiByZXF1ZXVlZC4NCj4gPiAN -Cj4gPiBJcyB0aGVyZSBhIHBvc3NpYmlsaXR5IHRoYXQgdGhlIGZsdXNoX3F1ZXVlKCkgbWlnaHQg -YmUgdHJpZ2dlcmVkDQo+ID4gZGVzcGl0ZSB0aGUgd29yayBpdGVtIG5vdCBiZWluZyBxdWV1ZWQ/ -DQo+IA0KPiBZZWFoLCBmb3Igc3VyZS4gIFRoZSBsb2NrZGVwIGFubm90YXRpb25zIGRvbid0IGRp -c3Rpbmd1aXNoIHRob3NlDQo+IGNhc2VzIGFuZCBhc3N1bWUgdGhlIHdvcnN0IGNhc2UuDQo+IA0K -DQpPSy4gTGV0J3MganVzdCByZW1vdmUgdGhhdCBjYWxsIHRvIGNhbmNlbF93b3JrX3N5bmMoKSB0 -aGVuLiBBcyBJIHNhaWQsDQppdCBzaG91bGQgYmUgcmVkdW5kYW50IGR1ZSB0byB0aGUgd2FpdF9v -bl9iaXRfbG9jaygpLg0KDQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBt -YWludGFpbmVyLCBQcmltYXJ5RGF0YQ0KdHJvbmQubXlrbGVidXN0QHByaW1hcnlkYXRhLmNvbQ0K +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 diff --git a/a/content_digest b/N1/content_digest index 8e380ce..0e48eef 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -16,21 +16,31 @@ " anna.schumaker@netapp.com <anna.schumaker@netapp.com>\0" "\00:1\0" "b\0" - "T24gVHVlLCAyMDE3LTEwLTEwIGF0IDEwOjE5IC0wNzAwLCB0akBrZXJuZWwub3JnIHdyb3RlOg0K\n" - "PiBIZWxsbywNCj4gDQo+IE9uIFR1ZSwgT2N0IDEwLCAyMDE3IGF0IDA0OjQ4OjU3UE0gKzAwMDAs\n" - "IFRyb25kIE15a2xlYnVzdCB3cm90ZToNCj4gPiBUaGFua3MgZm9yIHRoZSBleHBsYW5hdGlvbi4g\n" - "V2hhdCBJJ20gbm90IHJlYWxseSB1bmRlcnN0YW5kaW5nIGhlcmUNCj4gPiB0aG91Z2gsIGlzIGhv\n" - "dyB0aGUgd29yayBpdGVtIGNvdWxkIGJlIHF1ZXVlZCBhdCBhbGwuIFdlIGhhdmUgYQ0KPiA+IHdh\n" - "aXRfb25fYml0X2xvY2soKSBpbiB4cHJ0X2Rlc3Ryb3koKSB0aGF0IHNob3VsZCBtZWFuIHRoZSB4\n" - "cHJ0LQ0KPiA+ID4gdGFza19jbGVhbnVwIHdvcmsgaXRlbSBoYXMgY29tcGxldGVkIHJ1bm5pbmcs\n" - "IGFuZCB0aGF0IGl0IGNhbm5vdA0KPiA+ID4gYmUNCj4gPiANCj4gPiByZXF1ZXVlZC4NCj4gPiAN\n" - "Cj4gPiBJcyB0aGVyZSBhIHBvc3NpYmlsaXR5IHRoYXQgdGhlIGZsdXNoX3F1ZXVlKCkgbWlnaHQg\n" - "YmUgdHJpZ2dlcmVkDQo+ID4gZGVzcGl0ZSB0aGUgd29yayBpdGVtIG5vdCBiZWluZyBxdWV1ZWQ/\n" - "DQo+IA0KPiBZZWFoLCBmb3Igc3VyZS4gIFRoZSBsb2NrZGVwIGFubm90YXRpb25zIGRvbid0IGRp\n" - "c3Rpbmd1aXNoIHRob3NlDQo+IGNhc2VzIGFuZCBhc3N1bWUgdGhlIHdvcnN0IGNhc2UuDQo+IA0K\n" - "DQpPSy4gTGV0J3MganVzdCByZW1vdmUgdGhhdCBjYWxsIHRvIGNhbmNlbF93b3JrX3N5bmMoKSB0\n" - "aGVuLiBBcyBJIHNhaWQsDQppdCBzaG91bGQgYmUgcmVkdW5kYW50IGR1ZSB0byB0aGUgd2FpdF9v\n" - "bl9iaXRfbG9jaygpLg0KDQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBt\n" - YWludGFpbmVyLCBQcmltYXJ5RGF0YQ0KdHJvbmQubXlrbGVidXN0QHByaW1hcnlkYXRhLmNvbQ0K + "On Tue, 2017-10-10 at 10:19 -0700, tj@kernel.org wrote:\n" + "> Hello,\n" + "> \n" + "> On Tue, Oct 10, 2017 at 04:48:57PM +0000, Trond Myklebust wrote:\n" + "> > Thanks for the explanation. What I'm not really understanding here\n" + "> > though, is how the work item could be queued at all. We have a\n" + "> > wait_on_bit_lock() in xprt_destroy() that should mean the xprt-\n" + "> > > task_cleanup work item has completed running, and that it cannot\n" + "> > > be\n" + "> > \n" + "> > requeued.\n" + "> > \n" + "> > Is there a possibility that the flush_queue() might be triggered\n" + "> > despite the work item not being queued?\n" + "> \n" + "> Yeah, for sure. The lockdep annotations don't distinguish those\n" + "> cases and assume the worst case.\n" + "> \n" + "\n" + "OK. Let's just remove that call to cancel_work_sync() then. As I said,\n" + "it should be redundant due to the wait_on_bit_lock().\n" + "\n" + "-- \n" + "Trond Myklebust\n" + "Linux NFS client maintainer, PrimaryData\n" + trond.myklebust@primarydata.com -2f35c53d35edfac41dc30fb3ab7cfea56cd4316151fcdcd041904de5da2df4dc +40a57173c0a3386736721e8a6da733f96aa1b0b2ef02495d39a54c910c6ac885
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.