diff for duplicates of <1501610315.73115.1.camel@primarydata.com> diff --git a/a/1.txt b/N1/1.txt index 378ab39..a451938 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,25 +1,37 @@ -T24gVHVlLCAyMDE3LTA4LTAxIGF0IDEzOjUwIC0wNDAwLCBkYXZlakBjb2RlbW9ua2V5Lm9yZy51 -ayB3cm90ZToNCj4gT24gVHVlLCBBdWcgMDEsIDIwMTcgYXQgMTA6MjA6MzFBTSAtMDcwMCwgTGlu -dXMgVG9ydmFsZHMgd3JvdGU6DQo+IA0KPiAgPiBTbyBJIHRoaW5rIHRoZSAncGF0aG5hbWUnIHBh -cnQgbWF5IGFjdHVhbGx5IGJlIGVudGlyZWx5IGEgcmVkDQo+IGhlcnJpbmcsDQo+ICA+IGFuZCBp -dCdzIHRoZSB1bmRlcmx5aW5nIGFjY2VzcyBpdHNlbGYgdGhhdCBqdXN0IHBpY2tzIHVwIGEgcmFu -ZG9tDQo+ICA+IHBvaW50ZXIgZnJvbSBhIHN0YWNrIHRoYXQgbm93IGNvbnRhaW5zIHNvbWV0aGlu -ZyBkaWZmZXJlbnQuIEFuZA0KPiBLQVNBTg0KPiAgPiBkaWRuJ3Qgbm90aWNlIHRoZSBzdGFsZSBz -dGFjayBhY2Nlc3MgaXRzZWxmLCBiZWNhdXNlIHRoZSBzdGFjaw0KPiBzbG90IGlzDQo+ICA+IHN0 -aWxsIHZhbGlkIC0gaXQncyBqdXN0IG5vIGxvbmdlciB0aGUgb3JpZ2luYWwgJ3ZlcmlmaWVyJw0K -PiBhbGxvY2F0aW9uLg0KPiAgPiANCj4gID4gT3IgKnNvbWV0aGluZyogbGlrZSB0aGF0Lg0KPiAg -PiANCj4gID4gTm9uZSBvZiB0aGlzIGxvb2tzIGV2ZW4gcmVtb3RlbHkgbmV3LCB0aG91Z2ggLSB0 -aGUgY29kZSBzZWVtcyB0bw0KPiBnbw0KPiAgPiBiYWNrIHRvIDIwMDkuIEhhdmUgeW91IGp1c3Qg -Y2hhbmdlZCB3aGF0IHlvdSdyZSB0ZXN0aW5nIHRvIHRyaWdnZXINCj4gID4gdGhlc2UgdGhpbmdz -Pw0KPiANCj4gTm8gaWRlYSB3aHkgaXQgb25seSBqdXN0IHNob3dlZCB1cCwgYnV0IGl0IGlzbid0 -IDEwMCUgcmVwcm9kdWNhYmxlDQo+IGVpdGhlci4gIEEgbW9udGggb3Igc28gYWdvIEkgZGlkIGRp -c2FibGUgdGhlIFY0IGNvZGUgb24gdGhlIHNlcnZlcg0KPiBjb21wbGV0ZWx5IChhcyBJIHdhcyB1 -c2luZyB2MyBldmVyeXdoZXJlIGVsc2UpLCBzbyBtYXliZSBJIHN0YXJ0ZWQNCj4gaGl0dGluZw0K -PiBhIGZhbGxiYWNrIHBhdGggc29tZXdoZXJlLiAgKnNocnVnKg0KPiANCg0KSSB3b3VsZCBvbmx5 -IGV4cGVjdCB5b3UgdG9vIHNlZSBpdCBpZiB5b3UgaW50ZXJydXB0IHRoZSB3YWl0IG9uIHRoZQ0K -YXN5bmNocm9ub3VzIEVYQ0hBTkdFX0lEIGNhbGwgKHdoaWNoIHdvdWxkIGFsbG93IHRoZSBSUEMg -Y2FsbCB0bw0KY29udGludWUgd2hpbGUgdGhlIGNhbGxlciBzdGFjayBpcyB0cmFzaGVkKS4gUHJp -b3IgdG8gY29tbWl0DQo4ZDg5YmQ3MGJjOTM5LCB0aGF0IGNvZGUgcGF0aCB3YXMgZnVsbHkgc3lu -Y2hyb25vdXMsIHNvIHRoZXJlIHdhcyBubw0KaXNzdWUgd2l0aCBpbnRlcnJ1cHRpbmcgdGhlIGNh -bGwuDQoNCi0tIA0KVHJvbmQgTXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1haW50YWluZXIs -IFByaW1hcnlEYXRhDQp0cm9uZC5teWtsZWJ1c3RAcHJpbWFyeWRhdGEuY29tDQo= +On Tue, 2017-08-01 at 13:50 -0400, davej@codemonkey.org.uk wrote: +> On Tue, Aug 01, 2017 at 10:20:31AM -0700, Linus Torvalds wrote: +> +> > So I think the 'pathname' part may actually be entirely a red +> herring, +> > and it's the underlying access itself that just picks up a random +> > pointer from a stack that now contains something different. And +> KASAN +> > didn't notice the stale stack access itself, because the stack +> slot is +> > still valid - it's just no longer the original 'verifier' +> allocation. +> > +> > Or *something* like that. +> > +> > None of this looks even remotely new, though - the code seems to +> go +> > back to 2009. Have you just changed what you're testing to trigger +> > these things? +> +> No idea why it only just showed up, but it isn't 100% reproducable +> either. A month or so ago I did disable the V4 code on the server +> completely (as I was using v3 everywhere else), so maybe I started +> hitting +> a fallback path somewhere. *shrug* +> + +I would only expect you too see it if you interrupt the wait on the +asynchronous EXCHANGE_ID call (which would allow the RPC call to +continue while the caller stack is trashed). Prior to commit +8d89bd70bc939, that code path was fully synchronous, so there was no +issue with interrupting the call. + +-- +Trond Myklebust +Linux NFS client maintainer, PrimaryData +trond.myklebust@primarydata.com diff --git a/a/content_digest b/N1/content_digest index fc527aa..a7df9ed 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -21,30 +21,42 @@ " linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>\0" "\00:1\0" "b\0" - "T24gVHVlLCAyMDE3LTA4LTAxIGF0IDEzOjUwIC0wNDAwLCBkYXZlakBjb2RlbW9ua2V5Lm9yZy51\n" - "ayB3cm90ZToNCj4gT24gVHVlLCBBdWcgMDEsIDIwMTcgYXQgMTA6MjA6MzFBTSAtMDcwMCwgTGlu\n" - "dXMgVG9ydmFsZHMgd3JvdGU6DQo+IA0KPiAgPiBTbyBJIHRoaW5rIHRoZSAncGF0aG5hbWUnIHBh\n" - "cnQgbWF5IGFjdHVhbGx5IGJlIGVudGlyZWx5IGEgcmVkDQo+IGhlcnJpbmcsDQo+ICA+IGFuZCBp\n" - "dCdzIHRoZSB1bmRlcmx5aW5nIGFjY2VzcyBpdHNlbGYgdGhhdCBqdXN0IHBpY2tzIHVwIGEgcmFu\n" - "ZG9tDQo+ICA+IHBvaW50ZXIgZnJvbSBhIHN0YWNrIHRoYXQgbm93IGNvbnRhaW5zIHNvbWV0aGlu\n" - "ZyBkaWZmZXJlbnQuIEFuZA0KPiBLQVNBTg0KPiAgPiBkaWRuJ3Qgbm90aWNlIHRoZSBzdGFsZSBz\n" - "dGFjayBhY2Nlc3MgaXRzZWxmLCBiZWNhdXNlIHRoZSBzdGFjaw0KPiBzbG90IGlzDQo+ICA+IHN0\n" - "aWxsIHZhbGlkIC0gaXQncyBqdXN0IG5vIGxvbmdlciB0aGUgb3JpZ2luYWwgJ3ZlcmlmaWVyJw0K\n" - "PiBhbGxvY2F0aW9uLg0KPiAgPiANCj4gID4gT3IgKnNvbWV0aGluZyogbGlrZSB0aGF0Lg0KPiAg\n" - "PiANCj4gID4gTm9uZSBvZiB0aGlzIGxvb2tzIGV2ZW4gcmVtb3RlbHkgbmV3LCB0aG91Z2ggLSB0\n" - "aGUgY29kZSBzZWVtcyB0bw0KPiBnbw0KPiAgPiBiYWNrIHRvIDIwMDkuIEhhdmUgeW91IGp1c3Qg\n" - "Y2hhbmdlZCB3aGF0IHlvdSdyZSB0ZXN0aW5nIHRvIHRyaWdnZXINCj4gID4gdGhlc2UgdGhpbmdz\n" - "Pw0KPiANCj4gTm8gaWRlYSB3aHkgaXQgb25seSBqdXN0IHNob3dlZCB1cCwgYnV0IGl0IGlzbid0\n" - "IDEwMCUgcmVwcm9kdWNhYmxlDQo+IGVpdGhlci4gIEEgbW9udGggb3Igc28gYWdvIEkgZGlkIGRp\n" - "c2FibGUgdGhlIFY0IGNvZGUgb24gdGhlIHNlcnZlcg0KPiBjb21wbGV0ZWx5IChhcyBJIHdhcyB1\n" - "c2luZyB2MyBldmVyeXdoZXJlIGVsc2UpLCBzbyBtYXliZSBJIHN0YXJ0ZWQNCj4gaGl0dGluZw0K\n" - "PiBhIGZhbGxiYWNrIHBhdGggc29tZXdoZXJlLiAgKnNocnVnKg0KPiANCg0KSSB3b3VsZCBvbmx5\n" - "IGV4cGVjdCB5b3UgdG9vIHNlZSBpdCBpZiB5b3UgaW50ZXJydXB0IHRoZSB3YWl0IG9uIHRoZQ0K\n" - "YXN5bmNocm9ub3VzIEVYQ0hBTkdFX0lEIGNhbGwgKHdoaWNoIHdvdWxkIGFsbG93IHRoZSBSUEMg\n" - "Y2FsbCB0bw0KY29udGludWUgd2hpbGUgdGhlIGNhbGxlciBzdGFjayBpcyB0cmFzaGVkKS4gUHJp\n" - "b3IgdG8gY29tbWl0DQo4ZDg5YmQ3MGJjOTM5LCB0aGF0IGNvZGUgcGF0aCB3YXMgZnVsbHkgc3lu\n" - "Y2hyb25vdXMsIHNvIHRoZXJlIHdhcyBubw0KaXNzdWUgd2l0aCBpbnRlcnJ1cHRpbmcgdGhlIGNh\n" - "bGwuDQoNCi0tIA0KVHJvbmQgTXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1haW50YWluZXIs\n" - IFByaW1hcnlEYXRhDQp0cm9uZC5teWtsZWJ1c3RAcHJpbWFyeWRhdGEuY29tDQo= + "On Tue, 2017-08-01 at 13:50 -0400, davej@codemonkey.org.uk wrote:\n" + "> On Tue, Aug 01, 2017 at 10:20:31AM -0700, Linus Torvalds wrote:\n" + "> \n" + "> > So I think the 'pathname' part may actually be entirely a red\n" + "> herring,\n" + "> > and it's the underlying access itself that just picks up a random\n" + "> > pointer from a stack that now contains something different. And\n" + "> KASAN\n" + "> > didn't notice the stale stack access itself, because the stack\n" + "> slot is\n" + "> > still valid - it's just no longer the original 'verifier'\n" + "> allocation.\n" + "> > \n" + "> > Or *something* like that.\n" + "> > \n" + "> > None of this looks even remotely new, though - the code seems to\n" + "> go\n" + "> > back to 2009. Have you just changed what you're testing to trigger\n" + "> > these things?\n" + "> \n" + "> No idea why it only just showed up, but it isn't 100% reproducable\n" + "> either. A month or so ago I did disable the V4 code on the server\n" + "> completely (as I was using v3 everywhere else), so maybe I started\n" + "> hitting\n" + "> a fallback path somewhere. *shrug*\n" + "> \n" + "\n" + "I would only expect you too see it if you interrupt the wait on the\n" + "asynchronous EXCHANGE_ID call (which would allow the RPC call to\n" + "continue while the caller stack is trashed). Prior to commit\n" + "8d89bd70bc939, that code path was fully synchronous, so there was no\n" + "issue with interrupting the call.\n" + "\n" + "-- \n" + "Trond Myklebust\n" + "Linux NFS client maintainer, PrimaryData\n" + trond.myklebust@primarydata.com -4660fc49cda102d34d3aafb538d5a45bbb6f6969491af07abf366f0094215c40 +33df762e8ffe0db6b720f35a9303989b37bd0337bcee51d540af50b37226328f
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.