diff for duplicates of <1516639793.2545.14.camel@sandisk.com> diff --git a/a/1.txt b/N1/1.txt index b805837..4c8ce78 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,60 +1,49 @@ -On Mon, 2018-01-22 at 11:35 +0800, Ming Lei wrote: -> @@ -1280,10 +1282,18 @@ bool blk_mq_dispatch_rq_list(struct request_queue *q, struct list_head *list, -> * - Some but not all block drivers stop a queue before -> * returning BLK_STS_RESOURCE. Two exceptions are scsi-mq -> * and dm-rq. -> + * -> + * If drivers return BLK_STS_RESOURCE and S_SCHED_RESTART -> + * bit is set, run queue after 10ms for avoiding IO hang -> + * because the queue may be idle and the RESTART mechanism -> + * can't work any more. -> */ -> - if (!blk_mq_sched_needs_restart(hctx) || -> + needs_restart = blk_mq_sched_needs_restart(hctx); -> + if (!needs_restart || -> (no_tag && list_empty_careful(&hctx->dispatch_wait.entry))) -> blk_mq_run_hw_queue(hctx, true); -> + else if (needs_restart && (ret == BLK_STS_RESOURCE)) -> + blk_mq_delay_run_hw_queue(hctx, 10); -> } - -In my opinion there are two problems with the above changes: -* Only the block driver author can know what a good choice is for the time - after which to rerun the queue. So I think moving the rerun delay (10 ms) - constant from block drivers into the core is a step backwards instead of a - step forwards. -* The purpose of the BLK_MQ_S_SCHED_RESTART flag is to detect whether or not - any of the queue runs triggered by freeing a tag happened concurrently. I - don't think that there is any relationship between queue runs happening all - or not concurrently and the chance that driver resources become available. - So deciding whether or not a queue should be rerun based on the value of - the BLK_MQ_S_SCHED_RESTART flag seems wrong to me. - -> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c -> index d9ca1dfab154..55be2550c555 100644 -> --- a/drivers/scsi/scsi_lib.c -> +++ b/drivers/scsi/scsi_lib.c -> @@ -2030,9 +2030,9 @@ static blk_status_t scsi_queue_rq(struct blk_mq_hw_ctx *hctx, -> case BLK_STS_OK: -> break; -> case BLK_STS_RESOURCE: -> - if (atomic_read(&sdev->device_busy) == 0 && -> - !scsi_device_blocked(sdev)) -> - blk_mq_delay_run_hw_queue(hctx, SCSI_QUEUE_DELAY); -> + if (atomic_read(&sdev->device_busy) || -> + scsi_device_blocked(sdev)) -> + ret = BLK_STS_DEV_RESOURCE; -> break; -> default: -> /* - -The above introduces two changes that have not been mentioned in the -description of this patch: -- The queue rerunning delay is changed from 3 ms into 10 ms. Where is the - explanation of this change? Does this change have a positive or negative - performance impact? -- The above modifies a guaranteed queue rerun into a queue rerun that - may or may not happen, depending on whether or not multiple tags get freed - concurrently (return BLK_STS_DEV_RESOURCE). Sorry but I think that's wrong. - -Bart. +T24gTW9uLCAyMDE4LTAxLTIyIGF0IDExOjM1ICswODAwLCBNaW5nIExlaSB3cm90ZToNCj4gQEAg +LTEyODAsMTAgKzEyODIsMTggQEAgYm9vbCBibGtfbXFfZGlzcGF0Y2hfcnFfbGlzdChzdHJ1Y3Qg +cmVxdWVzdF9xdWV1ZSAqcSwgc3RydWN0IGxpc3RfaGVhZCAqbGlzdCwNCj4gIAkJICogLSBTb21l +IGJ1dCBub3QgYWxsIGJsb2NrIGRyaXZlcnMgc3RvcCBhIHF1ZXVlIGJlZm9yZQ0KPiAgCQkgKiAg +IHJldHVybmluZyBCTEtfU1RTX1JFU09VUkNFLiBUd28gZXhjZXB0aW9ucyBhcmUgc2NzaS1tcQ0K +PiAgCQkgKiAgIGFuZCBkbS1ycS4NCj4gKwkJICoNCj4gKwkJICogSWYgZHJpdmVycyByZXR1cm4g +QkxLX1NUU19SRVNPVVJDRSBhbmQgU19TQ0hFRF9SRVNUQVJUDQo+ICsJCSAqIGJpdCBpcyBzZXQs +IHJ1biBxdWV1ZSBhZnRlciAxMG1zIGZvciBhdm9pZGluZyBJTyBoYW5nDQo+ICsJCSAqIGJlY2F1 +c2UgdGhlIHF1ZXVlIG1heSBiZSBpZGxlIGFuZCB0aGUgUkVTVEFSVCBtZWNoYW5pc20NCj4gKwkJ +ICogY2FuJ3Qgd29yayBhbnkgbW9yZS4NCj4gIAkJICovDQo+IC0JCWlmICghYmxrX21xX3NjaGVk +X25lZWRzX3Jlc3RhcnQoaGN0eCkgfHwNCj4gKwkJbmVlZHNfcmVzdGFydCA9IGJsa19tcV9zY2hl +ZF9uZWVkc19yZXN0YXJ0KGhjdHgpOw0KPiArCQlpZiAoIW5lZWRzX3Jlc3RhcnQgfHwNCj4gIAkJ +ICAgIChub190YWcgJiYgbGlzdF9lbXB0eV9jYXJlZnVsKCZoY3R4LT5kaXNwYXRjaF93YWl0LmVu +dHJ5KSkpDQo+ICAJCQlibGtfbXFfcnVuX2h3X3F1ZXVlKGhjdHgsIHRydWUpOw0KPiArCQllbHNl +IGlmIChuZWVkc19yZXN0YXJ0ICYmIChyZXQgPT0gQkxLX1NUU19SRVNPVVJDRSkpDQo+ICsJCQli +bGtfbXFfZGVsYXlfcnVuX2h3X3F1ZXVlKGhjdHgsIDEwKTsNCj4gIAl9DQoNCkluIG15IG9waW5p +b24gdGhlcmUgYXJlIHR3byBwcm9ibGVtcyB3aXRoIHRoZSBhYm92ZSBjaGFuZ2VzOg0KKiBPbmx5 +IHRoZSBibG9jayBkcml2ZXIgYXV0aG9yIGNhbiBrbm93IHdoYXQgYSBnb29kIGNob2ljZSBpcyBm +b3IgdGhlIHRpbWUNCiAgYWZ0ZXIgd2hpY2ggdG8gcmVydW4gdGhlIHF1ZXVlLiBTbyBJIHRoaW5r +IG1vdmluZyB0aGUgcmVydW4gZGVsYXkgKDEwIG1zKQ0KICBjb25zdGFudCBmcm9tIGJsb2NrIGRy +aXZlcnMgaW50byB0aGUgY29yZSBpcyBhIHN0ZXAgYmFja3dhcmRzIGluc3RlYWQgb2YgYQ0KICBz +dGVwIGZvcndhcmRzLg0KKiBUaGUgcHVycG9zZSBvZiB0aGUgQkxLX01RX1NfU0NIRURfUkVTVEFS +VCBmbGFnIGlzIHRvIGRldGVjdCB3aGV0aGVyIG9yIG5vdA0KICBhbnkgb2YgdGhlIHF1ZXVlIHJ1 +bnMgdHJpZ2dlcmVkIGJ5IGZyZWVpbmcgYSB0YWcgaGFwcGVuZWQgY29uY3VycmVudGx5LiBJDQog +IGRvbid0IHRoaW5rIHRoYXQgdGhlcmUgaXMgYW55IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHF1ZXVl +IHJ1bnMgaGFwcGVuaW5nIGFsbA0KICBvciBub3QgY29uY3VycmVudGx5IGFuZCB0aGUgY2hhbmNl +IHRoYXQgZHJpdmVyIHJlc291cmNlcyBiZWNvbWUgYXZhaWxhYmxlLg0KICBTbyBkZWNpZGluZyB3 +aGV0aGVyIG9yIG5vdCBhIHF1ZXVlIHNob3VsZCBiZSByZXJ1biBiYXNlZCBvbiB0aGUgdmFsdWUg +b2YNCiAgdGhlIEJMS19NUV9TX1NDSEVEX1JFU1RBUlQgZmxhZyBzZWVtcyB3cm9uZyB0byBtZS4N +Cg0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9zY3NpL3Njc2lfbGliLmMgYi9kcml2ZXJzL3Njc2kv +c2NzaV9saWIuYw0KPiBpbmRleCBkOWNhMWRmYWIxNTQuLjU1YmUyNTUwYzU1NSAxMDA2NDQNCj4g +LS0tIGEvZHJpdmVycy9zY3NpL3Njc2lfbGliLmMNCj4gKysrIGIvZHJpdmVycy9zY3NpL3Njc2lf +bGliLmMNCj4gQEAgLTIwMzAsOSArMjAzMCw5IEBAIHN0YXRpYyBibGtfc3RhdHVzX3Qgc2NzaV9x +dWV1ZV9ycShzdHJ1Y3QgYmxrX21xX2h3X2N0eCAqaGN0eCwNCj4gIAljYXNlIEJMS19TVFNfT0s6 +DQo+ICAJCWJyZWFrOw0KPiAgCWNhc2UgQkxLX1NUU19SRVNPVVJDRToNCj4gLQkJaWYgKGF0b21p +Y19yZWFkKCZzZGV2LT5kZXZpY2VfYnVzeSkgPT0gMCAmJg0KPiAtCQkgICAgIXNjc2lfZGV2aWNl +X2Jsb2NrZWQoc2RldikpDQo+IC0JCQlibGtfbXFfZGVsYXlfcnVuX2h3X3F1ZXVlKGhjdHgsIFND +U0lfUVVFVUVfREVMQVkpOw0KPiArCQlpZiAoYXRvbWljX3JlYWQoJnNkZXYtPmRldmljZV9idXN5 +KSB8fA0KPiArCQkgICAgc2NzaV9kZXZpY2VfYmxvY2tlZChzZGV2KSkNCj4gKwkJCXJldCA9IEJM +S19TVFNfREVWX1JFU09VUkNFOw0KPiAgCQlicmVhazsNCj4gIAlkZWZhdWx0Og0KPiAgCQkvKg0K +DQpUaGUgYWJvdmUgaW50cm9kdWNlcyB0d28gY2hhbmdlcyB0aGF0IGhhdmUgbm90IGJlZW4gbWVu +dGlvbmVkIGluIHRoZQ0KZGVzY3JpcHRpb24gb2YgdGhpcyBwYXRjaDoNCi0gVGhlIHF1ZXVlIHJl +cnVubmluZyBkZWxheSBpcyBjaGFuZ2VkIGZyb20gMyBtcyBpbnRvIDEwIG1zLiBXaGVyZSBpcyB0 +aGUNCiAgZXhwbGFuYXRpb24gb2YgdGhpcyBjaGFuZ2U/IERvZXMgdGhpcyBjaGFuZ2UgaGF2ZSBh +IHBvc2l0aXZlIG9yIG5lZ2F0aXZlDQogIHBlcmZvcm1hbmNlIGltcGFjdD8NCi0gVGhlIGFib3Zl +IG1vZGlmaWVzIGEgZ3VhcmFudGVlZCBxdWV1ZSByZXJ1biBpbnRvIGEgcXVldWUgcmVydW4gdGhh +dA0KICBtYXkgb3IgbWF5IG5vdCBoYXBwZW4sIGRlcGVuZGluZyBvbiB3aGV0aGVyIG9yIG5vdCBt +dWx0aXBsZSB0YWdzIGdldCBmcmVlZA0KICBjb25jdXJyZW50bHkgKHJldHVybiBCTEtfU1RTX0RF +Vl9SRVNPVVJDRSkuIFNvcnJ5IGJ1dCBJIHRoaW5rIHRoYXQncyB3cm9uZy4NCg0KQmFydC4= diff --git a/a/content_digest b/N1/content_digest index c0141e1..8a7dc00 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -15,65 +15,54 @@ " loberman@redhat.com <loberman@redhat.com>\0" "\00:1\0" "b\0" - "On Mon, 2018-01-22 at 11:35 +0800, Ming Lei wrote:\n" - "> @@ -1280,10 +1282,18 @@ bool blk_mq_dispatch_rq_list(struct request_queue *q, struct list_head *list,\n" - "> \t\t * - Some but not all block drivers stop a queue before\n" - "> \t\t * returning BLK_STS_RESOURCE. Two exceptions are scsi-mq\n" - "> \t\t * and dm-rq.\n" - "> +\t\t *\n" - "> +\t\t * If drivers return BLK_STS_RESOURCE and S_SCHED_RESTART\n" - "> +\t\t * bit is set, run queue after 10ms for avoiding IO hang\n" - "> +\t\t * because the queue may be idle and the RESTART mechanism\n" - "> +\t\t * can't work any more.\n" - "> \t\t */\n" - "> -\t\tif (!blk_mq_sched_needs_restart(hctx) ||\n" - "> +\t\tneeds_restart = blk_mq_sched_needs_restart(hctx);\n" - "> +\t\tif (!needs_restart ||\n" - "> \t\t (no_tag && list_empty_careful(&hctx->dispatch_wait.entry)))\n" - "> \t\t\tblk_mq_run_hw_queue(hctx, true);\n" - "> +\t\telse if (needs_restart && (ret == BLK_STS_RESOURCE))\n" - "> +\t\t\tblk_mq_delay_run_hw_queue(hctx, 10);\n" - "> \t}\n" - "\n" - "In my opinion there are two problems with the above changes:\n" - "* Only the block driver author can know what a good choice is for the time\n" - " after which to rerun the queue. So I think moving the rerun delay (10 ms)\n" - " constant from block drivers into the core is a step backwards instead of a\n" - " step forwards.\n" - "* The purpose of the BLK_MQ_S_SCHED_RESTART flag is to detect whether or not\n" - " any of the queue runs triggered by freeing a tag happened concurrently. I\n" - " don't think that there is any relationship between queue runs happening all\n" - " or not concurrently and the chance that driver resources become available.\n" - " So deciding whether or not a queue should be rerun based on the value of\n" - " the BLK_MQ_S_SCHED_RESTART flag seems wrong to me.\n" - "\n" - "> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c\n" - "> index d9ca1dfab154..55be2550c555 100644\n" - "> --- a/drivers/scsi/scsi_lib.c\n" - "> +++ b/drivers/scsi/scsi_lib.c\n" - "> @@ -2030,9 +2030,9 @@ static blk_status_t scsi_queue_rq(struct blk_mq_hw_ctx *hctx,\n" - "> \tcase BLK_STS_OK:\n" - "> \t\tbreak;\n" - "> \tcase BLK_STS_RESOURCE:\n" - "> -\t\tif (atomic_read(&sdev->device_busy) == 0 &&\n" - "> -\t\t !scsi_device_blocked(sdev))\n" - "> -\t\t\tblk_mq_delay_run_hw_queue(hctx, SCSI_QUEUE_DELAY);\n" - "> +\t\tif (atomic_read(&sdev->device_busy) ||\n" - "> +\t\t scsi_device_blocked(sdev))\n" - "> +\t\t\tret = BLK_STS_DEV_RESOURCE;\n" - "> \t\tbreak;\n" - "> \tdefault:\n" - "> \t\t/*\n" - "\n" - "The above introduces two changes that have not been mentioned in the\n" - "description of this patch:\n" - "- The queue rerunning delay is changed from 3 ms into 10 ms. Where is the\n" - " explanation of this change? Does this change have a positive or negative\n" - " performance impact?\n" - "- The above modifies a guaranteed queue rerun into a queue rerun that\n" - " may or may not happen, depending on whether or not multiple tags get freed\n" - " concurrently (return BLK_STS_DEV_RESOURCE). Sorry but I think that's wrong.\n" - "\n" - Bart. + "T24gTW9uLCAyMDE4LTAxLTIyIGF0IDExOjM1ICswODAwLCBNaW5nIExlaSB3cm90ZToNCj4gQEAg\n" + "LTEyODAsMTAgKzEyODIsMTggQEAgYm9vbCBibGtfbXFfZGlzcGF0Y2hfcnFfbGlzdChzdHJ1Y3Qg\n" + "cmVxdWVzdF9xdWV1ZSAqcSwgc3RydWN0IGxpc3RfaGVhZCAqbGlzdCwNCj4gIAkJICogLSBTb21l\n" + "IGJ1dCBub3QgYWxsIGJsb2NrIGRyaXZlcnMgc3RvcCBhIHF1ZXVlIGJlZm9yZQ0KPiAgCQkgKiAg\n" + "IHJldHVybmluZyBCTEtfU1RTX1JFU09VUkNFLiBUd28gZXhjZXB0aW9ucyBhcmUgc2NzaS1tcQ0K\n" + "PiAgCQkgKiAgIGFuZCBkbS1ycS4NCj4gKwkJICoNCj4gKwkJICogSWYgZHJpdmVycyByZXR1cm4g\n" + "QkxLX1NUU19SRVNPVVJDRSBhbmQgU19TQ0hFRF9SRVNUQVJUDQo+ICsJCSAqIGJpdCBpcyBzZXQs\n" + "IHJ1biBxdWV1ZSBhZnRlciAxMG1zIGZvciBhdm9pZGluZyBJTyBoYW5nDQo+ICsJCSAqIGJlY2F1\n" + "c2UgdGhlIHF1ZXVlIG1heSBiZSBpZGxlIGFuZCB0aGUgUkVTVEFSVCBtZWNoYW5pc20NCj4gKwkJ\n" + "ICogY2FuJ3Qgd29yayBhbnkgbW9yZS4NCj4gIAkJICovDQo+IC0JCWlmICghYmxrX21xX3NjaGVk\n" + "X25lZWRzX3Jlc3RhcnQoaGN0eCkgfHwNCj4gKwkJbmVlZHNfcmVzdGFydCA9IGJsa19tcV9zY2hl\n" + "ZF9uZWVkc19yZXN0YXJ0KGhjdHgpOw0KPiArCQlpZiAoIW5lZWRzX3Jlc3RhcnQgfHwNCj4gIAkJ\n" + "ICAgIChub190YWcgJiYgbGlzdF9lbXB0eV9jYXJlZnVsKCZoY3R4LT5kaXNwYXRjaF93YWl0LmVu\n" + "dHJ5KSkpDQo+ICAJCQlibGtfbXFfcnVuX2h3X3F1ZXVlKGhjdHgsIHRydWUpOw0KPiArCQllbHNl\n" + "IGlmIChuZWVkc19yZXN0YXJ0ICYmIChyZXQgPT0gQkxLX1NUU19SRVNPVVJDRSkpDQo+ICsJCQli\n" + "bGtfbXFfZGVsYXlfcnVuX2h3X3F1ZXVlKGhjdHgsIDEwKTsNCj4gIAl9DQoNCkluIG15IG9waW5p\n" + "b24gdGhlcmUgYXJlIHR3byBwcm9ibGVtcyB3aXRoIHRoZSBhYm92ZSBjaGFuZ2VzOg0KKiBPbmx5\n" + "IHRoZSBibG9jayBkcml2ZXIgYXV0aG9yIGNhbiBrbm93IHdoYXQgYSBnb29kIGNob2ljZSBpcyBm\n" + "b3IgdGhlIHRpbWUNCiAgYWZ0ZXIgd2hpY2ggdG8gcmVydW4gdGhlIHF1ZXVlLiBTbyBJIHRoaW5r\n" + "IG1vdmluZyB0aGUgcmVydW4gZGVsYXkgKDEwIG1zKQ0KICBjb25zdGFudCBmcm9tIGJsb2NrIGRy\n" + "aXZlcnMgaW50byB0aGUgY29yZSBpcyBhIHN0ZXAgYmFja3dhcmRzIGluc3RlYWQgb2YgYQ0KICBz\n" + "dGVwIGZvcndhcmRzLg0KKiBUaGUgcHVycG9zZSBvZiB0aGUgQkxLX01RX1NfU0NIRURfUkVTVEFS\n" + "VCBmbGFnIGlzIHRvIGRldGVjdCB3aGV0aGVyIG9yIG5vdA0KICBhbnkgb2YgdGhlIHF1ZXVlIHJ1\n" + "bnMgdHJpZ2dlcmVkIGJ5IGZyZWVpbmcgYSB0YWcgaGFwcGVuZWQgY29uY3VycmVudGx5LiBJDQog\n" + "IGRvbid0IHRoaW5rIHRoYXQgdGhlcmUgaXMgYW55IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHF1ZXVl\n" + "IHJ1bnMgaGFwcGVuaW5nIGFsbA0KICBvciBub3QgY29uY3VycmVudGx5IGFuZCB0aGUgY2hhbmNl\n" + "IHRoYXQgZHJpdmVyIHJlc291cmNlcyBiZWNvbWUgYXZhaWxhYmxlLg0KICBTbyBkZWNpZGluZyB3\n" + "aGV0aGVyIG9yIG5vdCBhIHF1ZXVlIHNob3VsZCBiZSByZXJ1biBiYXNlZCBvbiB0aGUgdmFsdWUg\n" + "b2YNCiAgdGhlIEJMS19NUV9TX1NDSEVEX1JFU1RBUlQgZmxhZyBzZWVtcyB3cm9uZyB0byBtZS4N\n" + "Cg0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9zY3NpL3Njc2lfbGliLmMgYi9kcml2ZXJzL3Njc2kv\n" + "c2NzaV9saWIuYw0KPiBpbmRleCBkOWNhMWRmYWIxNTQuLjU1YmUyNTUwYzU1NSAxMDA2NDQNCj4g\n" + "LS0tIGEvZHJpdmVycy9zY3NpL3Njc2lfbGliLmMNCj4gKysrIGIvZHJpdmVycy9zY3NpL3Njc2lf\n" + "bGliLmMNCj4gQEAgLTIwMzAsOSArMjAzMCw5IEBAIHN0YXRpYyBibGtfc3RhdHVzX3Qgc2NzaV9x\n" + "dWV1ZV9ycShzdHJ1Y3QgYmxrX21xX2h3X2N0eCAqaGN0eCwNCj4gIAljYXNlIEJMS19TVFNfT0s6\n" + "DQo+ICAJCWJyZWFrOw0KPiAgCWNhc2UgQkxLX1NUU19SRVNPVVJDRToNCj4gLQkJaWYgKGF0b21p\n" + "Y19yZWFkKCZzZGV2LT5kZXZpY2VfYnVzeSkgPT0gMCAmJg0KPiAtCQkgICAgIXNjc2lfZGV2aWNl\n" + "X2Jsb2NrZWQoc2RldikpDQo+IC0JCQlibGtfbXFfZGVsYXlfcnVuX2h3X3F1ZXVlKGhjdHgsIFND\n" + "U0lfUVVFVUVfREVMQVkpOw0KPiArCQlpZiAoYXRvbWljX3JlYWQoJnNkZXYtPmRldmljZV9idXN5\n" + "KSB8fA0KPiArCQkgICAgc2NzaV9kZXZpY2VfYmxvY2tlZChzZGV2KSkNCj4gKwkJCXJldCA9IEJM\n" + "S19TVFNfREVWX1JFU09VUkNFOw0KPiAgCQlicmVhazsNCj4gIAlkZWZhdWx0Og0KPiAgCQkvKg0K\n" + "DQpUaGUgYWJvdmUgaW50cm9kdWNlcyB0d28gY2hhbmdlcyB0aGF0IGhhdmUgbm90IGJlZW4gbWVu\n" + "dGlvbmVkIGluIHRoZQ0KZGVzY3JpcHRpb24gb2YgdGhpcyBwYXRjaDoNCi0gVGhlIHF1ZXVlIHJl\n" + "cnVubmluZyBkZWxheSBpcyBjaGFuZ2VkIGZyb20gMyBtcyBpbnRvIDEwIG1zLiBXaGVyZSBpcyB0\n" + "aGUNCiAgZXhwbGFuYXRpb24gb2YgdGhpcyBjaGFuZ2U/IERvZXMgdGhpcyBjaGFuZ2UgaGF2ZSBh\n" + "IHBvc2l0aXZlIG9yIG5lZ2F0aXZlDQogIHBlcmZvcm1hbmNlIGltcGFjdD8NCi0gVGhlIGFib3Zl\n" + "IG1vZGlmaWVzIGEgZ3VhcmFudGVlZCBxdWV1ZSByZXJ1biBpbnRvIGEgcXVldWUgcmVydW4gdGhh\n" + "dA0KICBtYXkgb3IgbWF5IG5vdCBoYXBwZW4sIGRlcGVuZGluZyBvbiB3aGV0aGVyIG9yIG5vdCBt\n" + "dWx0aXBsZSB0YWdzIGdldCBmcmVlZA0KICBjb25jdXJyZW50bHkgKHJldHVybiBCTEtfU1RTX0RF\n" + Vl9SRVNPVVJDRSkuIFNvcnJ5IGJ1dCBJIHRoaW5rIHRoYXQncyB3cm9uZy4NCg0KQmFydC4= -839bc9b7251a43b4ec6a75500c370aec23b464bed07543e5160003fb29720c0a +9d96ebc73e0ae3fb1aded1c98d43d07a35a0fbac4fd53f0462704a543bfc9356
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.