diff for duplicates of <1503073304.2622.5.camel@wdc.com> diff --git a/a/1.txt b/N1/1.txt index 8538fb8..bc06f13 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,35 +1,35 @@ -T24gRnJpLCAyMDE3LTA4LTE4IGF0IDA5OjU1IC0wNDAwLCBXYWltYW4gTG9uZyB3cm90ZToNCj4g -T24gMDgvMTcvMjAxNyAwNTozMCBQTSwgU3RldmVuIFJvc3RlZHQgd3JvdGU6DQo+ID4gT24gVGh1 -LCAxNyBBdWcgMjAxNyAxNzoxMDowNyAtMDQwMA0KPiA+IFN0ZXZlbiBSb3N0ZWR0IDxyb3N0ZWR0 -QGdvb2RtaXMub3JnPiB3cm90ZToNCj4gPiA+IEluc3RlYWQgb2YgcGxheWluZyBnYW1lcyB3aXRo -IHRha2luZyB0aGUgbG9jaywgdGhlIG9ubHkgd2F5IHRoaXMgcmFjZQ0KPiA+ID4gaXMgaGl0LCBp -cyBpZiB0aGUgcGFydGl0aW9uIGlzIGJlaW5nIGRlbGV0ZWQgYW5kIHRoZSBzeXNmcyBhdHRyaWJ1 -dGUgaXMNCj4gPiA+IGJlaW5nIHJlYWQgYXQgdGhlIHNhbWUgdGltZSwgY29ycmVjdD8gSW4gdGhh -dCBjYXNlLCBqdXN0IHJldHVybg0KPiA+ID4gLUVOT0RFViwgYW5kIGJlIGRvbmUgd2l0aCBpdC4N -Cj4gPiANCj4gPiBOZXZlcm1pbmQgdGhhdCB3b250IHdvcmsuIFRvbyBiYWQgdGhlcmUncyBub3Qg -YSBtdXRleF9sb2NrX3RpbWVvdXQoKQ0KPiA+IHRoYXQgd2UgY291bGQgdXNlIGluIGEgbG9vcC4g -SXQgd291bGQgc29sdmUgdGhlIGlzc3VlIG9mIGZvcndhcmQNCj4gPiBwcm9ncmVzcyB3aXRoIFJU -IHRhc2tzLCBhbmQgd2lsbCBicmVhayBhZnRlciBhIHRpbWVvdXQgaW4gY2FzZSBvZg0KPiA+IGRl -YWRsb2NrLg0KPiANCj4gSSB0aGluayBpdCB3aWxsIGJlIHVzZWZ1bCB0byBoYXZlIG11dGV4X3Rp -bWVkX2xvY2soKS4gUlQtbXV0ZXggZG9lcyBoYXZlDQo+IGEgdGltZWQgdmVyc2lvbiwgc28gSSBn -dWVzcyBpdCBzaG91bGRuJ3QgYmUgaGFyZCB0byBpbXBsZW1lbnQgb25lIGZvcg0KPiBtdXRleC4g -SSBjYW4gdGFrZSBhIHNob3QgYXQgdHJ5aW5nIHRvIGRvIHRoYXQuDQoNCihqdXN0IGNhdWdodCB1 -cCB3aXRoIHRoZSBlbnRpcmUgZS1tYWlsIHRocmVhZCkNCg0KU29ycnkgV2FpbWFuIGJ1dCBwZXJz -b25hbGx5IEkgdGhvcm91Z2hseSBkZXRlc3QgbG9vcHMgYXJvdW5kIG11dGV4X3RyeWxvY2soKSBv -cg0KbXV0ZXhfdGltZWRfbG9jaygpIGJlY2F1c2Ugc3VjaCBsb29wcyBhcmUgdXN1YWxseSB1c2Vk -IHRvIHBhcGVyIG92ZXIgYSBwcm9ibGVtDQppbnN0ZWFkIG9mIGZpeGluZyB0aGUgcm9vdCBjYXVz -ZS4gV2hhdCBJIHVuZGVyc3Rvb2QgZnJvbSB0aGUgY29tbWVudCBpbiB2MSBvZiB5b3VyDQpwYXRj -aCBpcyB0aGF0IGJkX211dGV4IGlzIG5vdCBvbmx5IGhlbGQgZHVyaW5nIGJsb2NrIGRldmljZSBj -cmVhdGlvbiBhbmQgcmVtb3ZhbA0KYnV0IGFkZGl0aW9uYWxseSB0aGF0IGJkX211dGV4IGlzIG9i -dGFpbmVkIGluc2lkZSBzeXNmcyBhdHRyaWJ1dGUgY2FsbGJhY2sgbWV0aG9kcz8NClRoYXQgcGF0 -dGVybiBpcyBndWFyYW50ZWVkIHRvIGxlYWQgdG8gZGVhZGxvY2tzLiBTaW5jZSB0aGUgYmxvY2sg -ZGV2aWNlIHJlbW92YWwNCmNvZGUgd2FpdHMgdW50aWwgYWxsIHN5c2ZzIGNhbGxiYWNrIG1ldGhv -ZHMgaGF2ZSBmaW5pc2hlZCB0aGVyZSBpcyBubyBuZWVkIHRvDQpwcm90ZWN0IGFnYWluc3QgYmxv -Y2sgZGV2aWNlIHJlbW92YWwgaW5zaWRlIHRoZSBzeXNmcyBjYWxsYmFjayBtZXRob2RzLiBNeSBw -cm9wb3NhbA0KaXMgdG8gc3BsaXQgYmRfbXV0ZXg6IG9uZSBnbG9iYWwgbXV0ZXggdGhhdCBzZXJp -YWxpemVzIGJsb2NrIGRldmljZSBjcmVhdGlvbiBhbmQNCnJlbW92YWwgYW5kIG9uZSBtdXRleCBw -ZXIgYmxvY2sgZGV2aWNlIHRoYXQgc2VyaWFsaXplcyBjaGFuZ2VzIHRvIGEgc2luZ2xlIGJsb2Nr -DQpkZXZpY2UuIE9idGFpbmluZyB0aGUgZ2xvYmFsIG11dGV4IGZyb20gaW5zaWRlIGEgYmxvY2sg -ZGV2aWNlIHN5c2ZzIGNhbGxiYWNrDQpmdW5jdGlvbiBpcyBub3Qgc2FmZSBidXQgb2J0YWluaW5n -IHRoZSBwZXItYmxvY2stZGV2aWNlIG11dGV4IGZyb20gaW5zaWRlIGEgc3lzZnMNCmNhbGxiYWNr -IGZ1bmN0aW9uIGlzIHNhZmUuDQoNCkJhcnQu +On Fri, 2017-08-18 at 09:55 -0400, Waiman Long wrote: +> On 08/17/2017 05:30 PM, Steven Rostedt wrote: +> > On Thu, 17 Aug 2017 17:10:07 -0400 +> > Steven Rostedt <rostedt@goodmis.org> wrote: +> > > Instead of playing games with taking the lock, the only way this race +> > > is hit, is if the partition is being deleted and the sysfs attribute is +> > > being read at the same time, correct? In that case, just return +> > > -ENODEV, and be done with it. +> > +> > Nevermind that wont work. Too bad there's not a mutex_lock_timeout() +> > that we could use in a loop. It would solve the issue of forward +> > progress with RT tasks, and will break after a timeout in case of +> > deadlock. +> +> I think it will be useful to have mutex_timed_lock(). RT-mutex does have +> a timed version, so I guess it shouldn't be hard to implement one for +> mutex. I can take a shot at trying to do that. + +(just caught up with the entire e-mail thread) + +Sorry Waiman but personally I thoroughly detest loops around mutex_trylock() or +mutex_timed_lock() because such loops are usually used to paper over a problem +instead of fixing the root cause. What I understood from the comment in v1 of your +patch is that bd_mutex is not only held during block device creation and removal +but additionally that bd_mutex is obtained inside sysfs attribute callback methods? +That pattern is guaranteed to lead to deadlocks. Since the block device removal +code waits until all sysfs callback methods have finished there is no need to +protect against block device removal inside the sysfs callback methods. My proposal +is to split bd_mutex: one global mutex that serializes block device creation and +removal and one mutex per block device that serializes changes to a single block +device. Obtaining the global mutex from inside a block device sysfs callback +function is not safe but obtaining the per-block-device mutex from inside a sysfs +callback function is safe. + +Bart. diff --git a/a/content_digest b/N1/content_digest index 4d96f50..6ee7124 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -18,40 +18,40 @@ " linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>\0" "\00:1\0" "b\0" - "T24gRnJpLCAyMDE3LTA4LTE4IGF0IDA5OjU1IC0wNDAwLCBXYWltYW4gTG9uZyB3cm90ZToNCj4g\n" - "T24gMDgvMTcvMjAxNyAwNTozMCBQTSwgU3RldmVuIFJvc3RlZHQgd3JvdGU6DQo+ID4gT24gVGh1\n" - "LCAxNyBBdWcgMjAxNyAxNzoxMDowNyAtMDQwMA0KPiA+IFN0ZXZlbiBSb3N0ZWR0IDxyb3N0ZWR0\n" - "QGdvb2RtaXMub3JnPiB3cm90ZToNCj4gPiA+IEluc3RlYWQgb2YgcGxheWluZyBnYW1lcyB3aXRo\n" - "IHRha2luZyB0aGUgbG9jaywgdGhlIG9ubHkgd2F5IHRoaXMgcmFjZQ0KPiA+ID4gaXMgaGl0LCBp\n" - "cyBpZiB0aGUgcGFydGl0aW9uIGlzIGJlaW5nIGRlbGV0ZWQgYW5kIHRoZSBzeXNmcyBhdHRyaWJ1\n" - "dGUgaXMNCj4gPiA+IGJlaW5nIHJlYWQgYXQgdGhlIHNhbWUgdGltZSwgY29ycmVjdD8gSW4gdGhh\n" - "dCBjYXNlLCBqdXN0IHJldHVybg0KPiA+ID4gLUVOT0RFViwgYW5kIGJlIGRvbmUgd2l0aCBpdC4N\n" - "Cj4gPiANCj4gPiBOZXZlcm1pbmQgdGhhdCB3b250IHdvcmsuIFRvbyBiYWQgdGhlcmUncyBub3Qg\n" - "YSBtdXRleF9sb2NrX3RpbWVvdXQoKQ0KPiA+IHRoYXQgd2UgY291bGQgdXNlIGluIGEgbG9vcC4g\n" - "SXQgd291bGQgc29sdmUgdGhlIGlzc3VlIG9mIGZvcndhcmQNCj4gPiBwcm9ncmVzcyB3aXRoIFJU\n" - "IHRhc2tzLCBhbmQgd2lsbCBicmVhayBhZnRlciBhIHRpbWVvdXQgaW4gY2FzZSBvZg0KPiA+IGRl\n" - "YWRsb2NrLg0KPiANCj4gSSB0aGluayBpdCB3aWxsIGJlIHVzZWZ1bCB0byBoYXZlIG11dGV4X3Rp\n" - "bWVkX2xvY2soKS4gUlQtbXV0ZXggZG9lcyBoYXZlDQo+IGEgdGltZWQgdmVyc2lvbiwgc28gSSBn\n" - "dWVzcyBpdCBzaG91bGRuJ3QgYmUgaGFyZCB0byBpbXBsZW1lbnQgb25lIGZvcg0KPiBtdXRleC4g\n" - "SSBjYW4gdGFrZSBhIHNob3QgYXQgdHJ5aW5nIHRvIGRvIHRoYXQuDQoNCihqdXN0IGNhdWdodCB1\n" - "cCB3aXRoIHRoZSBlbnRpcmUgZS1tYWlsIHRocmVhZCkNCg0KU29ycnkgV2FpbWFuIGJ1dCBwZXJz\n" - "b25hbGx5IEkgdGhvcm91Z2hseSBkZXRlc3QgbG9vcHMgYXJvdW5kIG11dGV4X3RyeWxvY2soKSBv\n" - "cg0KbXV0ZXhfdGltZWRfbG9jaygpIGJlY2F1c2Ugc3VjaCBsb29wcyBhcmUgdXN1YWxseSB1c2Vk\n" - "IHRvIHBhcGVyIG92ZXIgYSBwcm9ibGVtDQppbnN0ZWFkIG9mIGZpeGluZyB0aGUgcm9vdCBjYXVz\n" - "ZS4gV2hhdCBJIHVuZGVyc3Rvb2QgZnJvbSB0aGUgY29tbWVudCBpbiB2MSBvZiB5b3VyDQpwYXRj\n" - "aCBpcyB0aGF0IGJkX211dGV4IGlzIG5vdCBvbmx5IGhlbGQgZHVyaW5nIGJsb2NrIGRldmljZSBj\n" - "cmVhdGlvbiBhbmQgcmVtb3ZhbA0KYnV0IGFkZGl0aW9uYWxseSB0aGF0IGJkX211dGV4IGlzIG9i\n" - "dGFpbmVkIGluc2lkZSBzeXNmcyBhdHRyaWJ1dGUgY2FsbGJhY2sgbWV0aG9kcz8NClRoYXQgcGF0\n" - "dGVybiBpcyBndWFyYW50ZWVkIHRvIGxlYWQgdG8gZGVhZGxvY2tzLiBTaW5jZSB0aGUgYmxvY2sg\n" - "ZGV2aWNlIHJlbW92YWwNCmNvZGUgd2FpdHMgdW50aWwgYWxsIHN5c2ZzIGNhbGxiYWNrIG1ldGhv\n" - "ZHMgaGF2ZSBmaW5pc2hlZCB0aGVyZSBpcyBubyBuZWVkIHRvDQpwcm90ZWN0IGFnYWluc3QgYmxv\n" - "Y2sgZGV2aWNlIHJlbW92YWwgaW5zaWRlIHRoZSBzeXNmcyBjYWxsYmFjayBtZXRob2RzLiBNeSBw\n" - "cm9wb3NhbA0KaXMgdG8gc3BsaXQgYmRfbXV0ZXg6IG9uZSBnbG9iYWwgbXV0ZXggdGhhdCBzZXJp\n" - "YWxpemVzIGJsb2NrIGRldmljZSBjcmVhdGlvbiBhbmQNCnJlbW92YWwgYW5kIG9uZSBtdXRleCBw\n" - "ZXIgYmxvY2sgZGV2aWNlIHRoYXQgc2VyaWFsaXplcyBjaGFuZ2VzIHRvIGEgc2luZ2xlIGJsb2Nr\n" - "DQpkZXZpY2UuIE9idGFpbmluZyB0aGUgZ2xvYmFsIG11dGV4IGZyb20gaW5zaWRlIGEgYmxvY2sg\n" - "ZGV2aWNlIHN5c2ZzIGNhbGxiYWNrDQpmdW5jdGlvbiBpcyBub3Qgc2FmZSBidXQgb2J0YWluaW5n\n" - "IHRoZSBwZXItYmxvY2stZGV2aWNlIG11dGV4IGZyb20gaW5zaWRlIGEgc3lzZnMNCmNhbGxiYWNr\n" - IGZ1bmN0aW9uIGlzIHNhZmUuDQoNCkJhcnQu + "On Fri, 2017-08-18 at 09:55 -0400, Waiman Long wrote:\n" + "> On 08/17/2017 05:30 PM, Steven Rostedt wrote:\n" + "> > On Thu, 17 Aug 2017 17:10:07 -0400\n" + "> > Steven Rostedt <rostedt@goodmis.org> wrote:\n" + "> > > Instead of playing games with taking the lock, the only way this race\n" + "> > > is hit, is if the partition is being deleted and the sysfs attribute is\n" + "> > > being read at the same time, correct? In that case, just return\n" + "> > > -ENODEV, and be done with it.\n" + "> > \n" + "> > Nevermind that wont work. Too bad there's not a mutex_lock_timeout()\n" + "> > that we could use in a loop. It would solve the issue of forward\n" + "> > progress with RT tasks, and will break after a timeout in case of\n" + "> > deadlock.\n" + "> \n" + "> I think it will be useful to have mutex_timed_lock(). RT-mutex does have\n" + "> a timed version, so I guess it shouldn't be hard to implement one for\n" + "> mutex. I can take a shot at trying to do that.\n" + "\n" + "(just caught up with the entire e-mail thread)\n" + "\n" + "Sorry Waiman but personally I thoroughly detest loops around mutex_trylock() or\n" + "mutex_timed_lock() because such loops are usually used to paper over a problem\n" + "instead of fixing the root cause. What I understood from the comment in v1 of your\n" + "patch is that bd_mutex is not only held during block device creation and removal\n" + "but additionally that bd_mutex is obtained inside sysfs attribute callback methods?\n" + "That pattern is guaranteed to lead to deadlocks. Since the block device removal\n" + "code waits until all sysfs callback methods have finished there is no need to\n" + "protect against block device removal inside the sysfs callback methods. My proposal\n" + "is to split bd_mutex: one global mutex that serializes block device creation and\n" + "removal and one mutex per block device that serializes changes to a single block\n" + "device. Obtaining the global mutex from inside a block device sysfs callback\n" + "function is not safe but obtaining the per-block-device mutex from inside a sysfs\n" + "callback function is safe.\n" + "\n" + Bart. -4c66019f2c6e9db6c5c0c4dca2963a2697b7e55cc4c1e444346860aafcbdc0cd +4bb737834ecd5d58158cf39182bd82dba5b9ff6835606f40f3db7259bc44cead
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.