diff for duplicates of <1521558822.15893.12.camel@primarydata.com> diff --git a/a/1.txt b/N1/1.txt index 2f74ac1..f5be7d0 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,58 +1,93 @@ -T24gVHVlLCAyMDE4LTAzLTIwIGF0IDEwOjQ5IC0wNDAwLCBKLiBCcnVjZSBGaWVsZHMgd3JvdGU6 -DQo+IE9uIFR1ZSwgTWFyIDIwLCAyMDE4IGF0IDAxOjQ2OjIwUE0gKzAwMDAsIFRyb25kIE15a2xl -YnVzdCB3cm90ZToNCj4gPiBPbiBUdWUsIDIwMTgtMDMtMjAgYXQgMTM6MzUgKzAwMDAsIERhdmlk -IEhvd2VsbHMgd3JvdGU6DQo+ID4gPiBKLiBCcnVjZSBGaWVsZHMgPGJmaWVsZHNAcmVkaGF0LmNv -bT4gd3JvdGU6DQo+ID4gPiANCj4gPiA+ID4gQEAgLTEzOSw2ICsxMzksOSBAQCBzdHJ1Y3QgY3Jl -ZCB7DQo+ID4gPiA+ICAJc3RydWN0IGtleQkqdGhyZWFkX2tleXJpbmc7IC8qIGtleXJpbmcgcHJp -dmF0ZQ0KPiA+ID4gPiB0bw0KPiA+ID4gPiB0aGlzIHRocmVhZCAqLw0KPiA+ID4gPiAgCXN0cnVj -dCBrZXkJKnJlcXVlc3Rfa2V5X2F1dGg7IC8qIGFzc3VtZWQNCj4gPiA+ID4gcmVxdWVzdF9rZXkg -YXV0aG9yaXR5ICovDQo+ID4gPiA+ICAjZW5kaWYNCj4gPiA+ID4gKyNpZmRlZiBDT05GSUdfRklM -RV9MT0NLSU5HDQo+ID4gPiA+ICsJdm9pZAkJKmxlYXNlX2JyZWFrZXI7IC8qIGlkZW50aWZ5IE5G -Uw0KPiA+ID4gPiBjbGllbnQNCj4gPiA+ID4gYnJlYWtpbmcgYSBkZWxlZ2F0aW9uICovDQo+ID4g -PiA+ICsjZW5kaWYNCj4gPiA+ID4gICNpZmRlZiBDT05GSUdfU0VDVVJJVFkNCj4gPiA+ID4gIAl2 -b2lkCQkqc2VjdXJpdHk7CS8qIHN1YmplY3RpdmUNCj4gPiA+ID4gTFNNDQo+ID4gPiA+IHNlY3Vy -aXR5ICovDQo+ID4gPiA+ICAjZW5kaWYNCj4gPiA+IA0KPiA+ID4gU29ycnksIGJ1dCBld3d3Lg0K -PiA+ID4gDQo+ID4gPiBUd28gcmVhc29ucyBmb3IgdGhhdCBjb21tZW50Og0KPiA+ID4gDQo+ID4g -PiAgKDEpIFRoZSBjcmVkIHN0cnVjdCBtYXkgZ2V0IHJldGFpbmVkIGxvbmcgcGFzdCB3aGVyZSB5 -b3UgZXhwZWN0DQo+ID4gPiBpZg0KPiA+ID4gaXQgZ2V0cw0KPiA+ID4gICAgICBhdHRhY2hlZCB0 -byBhbm90aGVyIHByb2Nlc3Mgb3IgYSBmaWxlIGRlc2NyaXB0b3IuDQo+ID4gPiANCj4gPiA+ICAo -MikgVGhlIC0+bGVhc2VfYnJlYWtlciBwb2ludGVyIG5lZWRzIGxpZmV0aW1lIG1hbmFnZW1lbnQg -aW4NCj4gPiA+IGNyZWQuYy4gIEl0IHdpbGwNCj4gPiA+ICAgICAgcG90ZW50aWFsbHkgZ2V0IGNv -cGllZCBhcm91bmQgYW5kIG1heSBuZWVkIGNsZWFuaW5nIHVwLg0KPiA+ID4gDQo+ID4gPiBDYW4g -eW91IHN0aWNrIHlvdXIgYnJlYWtlciBpZGVudGl0eSBpbiBhIGtleSBzdHJ1Y3QgYXMgSmVmZg0K -PiA+ID4gc3VnZ2VzdGVkPw0KPiA+ID4gDQo+ID4gDQo+ID4gQnJ1Y2UsDQo+ID4gDQo+ID4gRG8g -eW91IHJlYWxseSBuZWVkIHRvIGRvIG1vcmUgdGhhbiBqdXN0IGlkZW50aWZ5IHRoYXQgdGhpcyBp -cyBhDQo+ID4ga25mc2QNCj4gPiB0aHJlYWQgdnMgbm90IGEga25mc2QgdGhyZWFkPyBJJ20gYXNz -dW1pbmcgdGhhdCBhIGtuZnNkIHRocmVhZCB3aWxsDQo+ID4gdXN1YWxseSBiZSBpbiBhIHBvc2l0 -aW9uIHRvIHJlY2FsbCBkZWxlZ2F0aW9ucyBiZWZvcmUgaXQgZXZlbg0KPiA+IGluaXRpYXRlcw0K -PiA+IGFuIG9wZXJhdGlvbiBvbiB0aGUgaW5vZGUgaW4gcXVlc3Rpb24sIHdvbid0IGl0Pw0KPiAN -Cj4gSSB0aGluayBpdCBjb3VsZC4gIEknbSByZWx1Y3RhbnQ6DQo+IA0KPiAJLSBPbmNlIHdlIHN1 -cHBvcnQgd3JpdGUgZGVsZWdhdGlvbnMsIEkgdGhpbmsgd2UgZW5kIHVwIGhhdmluZw0KPiB0bw0K -PiAJICBkbyB0aGF0IGJlZm9yZSBiYXNpY2FsbHkgZXZlcnkgb3BlcmF0aW9uIG9uIGEgaW5vZGUu -DQo+IAktIEknZCBsaWtlIHRoaXMgdG8gbWFrZSBpdCBlYXN5IGZvciBzb21lb25lIHRvIGV4dGVu -ZA0KPiBkZWxlZ2F0aW9uDQo+IAkgIHN1cHBvcnQgdG8gdXNlcnNwYWNlIGV2ZW50dWFsbHkgdG9v -LiAgSSdtIG5vdCBzdXJlIGV4YWN0bHkNCj4gaG93DQo+IAkgIHdlJ2QgaWRlbnRpZnkgc2VsZi1j -b25mbGljdHMgaW4gdGhhdCBjYXNlIChzdHJ1Y3QgZmlsZXM/KSwNCj4gYnV0DQo+IAkgIGFueXdh -eSBJJ2QgcmF0aGVyIHRoaXMgd2Fzbid0IHRvbyBuZnNkLXNwZWNpZmljLg0KDQpUaGF0J3MgbXkg -cG9pbnQuIEEgdXNlcnNwYWNlIGFwcGxpY2F0aW9uIGlzIGdvaW5nIHRvIGhhdmUgdG8gZG8NCnNv -bWV0aGluZyBsaWtlIHRoaXMgYW55d2F5LiBJdCBjYW5ub3QgaW5zdGFsbCBob29rcyBpbiB0aGUg -a2VybmVsIHRvDQpwZXJmb3JtIGVsYWJvcmF0ZSB0ZXN0cywgc28gaXQgaXMgZ29pbmcgdG8gaGF2 -ZSB0byByZWx5IG9uIHNvbWV0aGluZw0KbGlrZSB0aGUgc3RydWN0IGZpbGVfbG9jayAnZmxfbnNw -aWQnIGZpZWxkIGluIG9yZGVyIHRvIGRldGVybWluZQ0Kd2hldGhlciBvciBub3QgdG8gYXBwbHkg -YSBsZWFzZSBicmVhay4NCg0KaS5lLjogdGhlIHVzZXJzcGFjZSBydWxlIHNob3VsZCBiZSB0byBi -cmVhayB0aGUgbGVhc2UgaWYgYW5kIG9ubHkgaWYgaXQNCmlzIG5vdCBvd25lZCBieSBteSBwcm9j -ZXNzLg0KDQo+IFRoYXQgc2FpZCwgSSdtIHN0aWxsIGN1cmlvdXM6DQo+IA0KPiA+IElPVzogd2hh -dCBpZiB5b3Ugd2VyZSB0byBtb2RpZnkgdGhlIGxlYXNlIGNvZGUgdG8gYWxsb3cga25mc2QNCj4g -PiB0aHJlYWRzDQo+ID4gdG8gcmV0dXJuIGEgInBsZWFzZSBpZ25vcmUgbWUsIGFuZCBwcm9jZWVk -IHdpdGggdGhlIG9wZXJhdGlvbiB0aGF0DQo+ID4gdHJpZ2dlcmVkIHRoZSBsZWFzZSBicmVhayIg -cmVwbHksIGFuZCB0aGVuIGhhbmRsZSBjb25mbGljdHMgYmV0d2Vlbg0KPiA+IE5GUw0KPiA+IGNs -aWVudHMgb3V0c2lkZSB0aGUgbGVhc2UgY2FsbGJhY2sgY29kZSBhbHRvZ2V0aGVyPw0KPiANCj4g -U28gaWYgeW91J3JlIGEgcmFuZG9tIGJpdCBvZiBjb2RlLCBob3cgd291bGQgeW91IHJlY29tbWVu -ZCB0ZXN0aW5nDQo+IHdoZXRoZXIgeW91J3JlIHJ1bm5pbmcgaW4gYSBrbmZzZCB0aHJlYWQ/DQoN -ClJpZ2h0IG5vdywgdGhlIGtuZnNkIHRocmVhZHMgYXJlIHJlZ3VsYXIga2VybmVsIHRocmVhZHMs -IHdpdGggZWFjaA0KdGhyZWFkIGFwcGVhcmluZyB0byB1c2Vyc3BhY2UgdG8gYmUgYSBwcm9jZXNz -IGluIGl0cyBvd24gcmlnaHQuDQpJcyB0aGVyZSBhbnkgcmVhc29uIHdoeSB3ZSBjb3VsZCBub3Qg -YXNzaWduIHRoZW0gYSBncm91cCBwaWQgdGhhdCB3b3VsZA0KYWxsb3cgdGhlIGZsX25zcGlkIG1l -Y2hhbmlzbSB0byB3b3JrIChpLmUuIHNldCB0YXNrLT5ncm91cF9sZWFkZXIpPw0KDQoNCi0tIA0K -VHJvbmQgTXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1haW50YWluZXIsIFByaW1hcnlEYXRh -DQp0cm9uZC5teWtsZWJ1c3RAcHJpbWFyeWRhdGEuY29tDQo= +On Tue, 2018-03-20 at 10:49 -0400, J. Bruce Fields wrote: +> On Tue, Mar 20, 2018 at 01:46:20PM +0000, Trond Myklebust wrote: +> > On Tue, 2018-03-20 at 13:35 +0000, David Howells wrote: +> > > J. Bruce Fields <bfields@redhat.com> wrote: +> > > +> > > > @@ -139,6 +139,9 @@ struct cred { +> > > > struct key *thread_keyring; /* keyring private +> > > > to +> > > > this thread */ +> > > > struct key *request_key_auth; /* assumed +> > > > request_key authority */ +> > > > #endif +> > > > +#ifdef CONFIG_FILE_LOCKING +> > > > + void *lease_breaker; /* identify NFS +> > > > client +> > > > breaking a delegation */ +> > > > +#endif +> > > > #ifdef CONFIG_SECURITY +> > > > void *security; /* subjective +> > > > LSM +> > > > security */ +> > > > #endif +> > > +> > > Sorry, but ewww. +> > > +> > > Two reasons for that comment: +> > > +> > > (1) The cred struct may get retained long past where you expect +> > > if +> > > it gets +> > > attached to another process or a file descriptor. +> > > +> > > (2) The ->lease_breaker pointer needs lifetime management in +> > > cred.c. It will +> > > potentially get copied around and may need cleaning up. +> > > +> > > Can you stick your breaker identity in a key struct as Jeff +> > > suggested? +> > > +> > +> > Bruce, +> > +> > Do you really need to do more than just identify that this is a +> > knfsd +> > thread vs not a knfsd thread? I'm assuming that a knfsd thread will +> > usually be in a position to recall delegations before it even +> > initiates +> > an operation on the inode in question, won't it? +> +> I think it could. I'm reluctant: +> +> - Once we support write delegations, I think we end up having +> to +> do that before basically every operation on a inode. +> - I'd like this to make it easy for someone to extend +> delegation +> support to userspace eventually too. I'm not sure exactly +> how +> we'd identify self-conflicts in that case (struct files?), +> but +> anyway I'd rather this wasn't too nfsd-specific. + +That's my point. A userspace application is going to have to do +something like this anyway. It cannot install hooks in the kernel to +perform elaborate tests, so it is going to have to rely on something +like the struct file_lock 'fl_nspid' field in order to determine +whether or not to apply a lease break. + +i.e.: the userspace rule should be to break the lease if and only if it +is not owned by my process. + +> That said, I'm still curious: +> +> > IOW: what if you were to modify the lease code to allow knfsd +> > threads +> > to return a "please ignore me, and proceed with the operation that +> > triggered the lease break" reply, and then handle conflicts between +> > NFS +> > clients outside the lease callback code altogether? +> +> So if you're a random bit of code, how would you recommend testing +> whether you're running in a knfsd thread? + +Right now, the knfsd threads are regular kernel threads, with each +thread appearing to userspace to be a process in its own right. +Is there any reason why we could not assign them a group pid that would +allow the fl_nspid mechanism to work (i.e. set task->group_leader)? + + +-- +Trond Myklebust +Linux NFS client maintainer, PrimaryData +trond.myklebust@primarydata.com diff --git a/a/content_digest b/N1/content_digest index 1043b7f..8c4e7d4 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -13,63 +13,98 @@ " linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>\0" "\00:1\0" "b\0" - "T24gVHVlLCAyMDE4LTAzLTIwIGF0IDEwOjQ5IC0wNDAwLCBKLiBCcnVjZSBGaWVsZHMgd3JvdGU6\n" - "DQo+IE9uIFR1ZSwgTWFyIDIwLCAyMDE4IGF0IDAxOjQ2OjIwUE0gKzAwMDAsIFRyb25kIE15a2xl\n" - "YnVzdCB3cm90ZToNCj4gPiBPbiBUdWUsIDIwMTgtMDMtMjAgYXQgMTM6MzUgKzAwMDAsIERhdmlk\n" - "IEhvd2VsbHMgd3JvdGU6DQo+ID4gPiBKLiBCcnVjZSBGaWVsZHMgPGJmaWVsZHNAcmVkaGF0LmNv\n" - "bT4gd3JvdGU6DQo+ID4gPiANCj4gPiA+ID4gQEAgLTEzOSw2ICsxMzksOSBAQCBzdHJ1Y3QgY3Jl\n" - "ZCB7DQo+ID4gPiA+ICAJc3RydWN0IGtleQkqdGhyZWFkX2tleXJpbmc7IC8qIGtleXJpbmcgcHJp\n" - "dmF0ZQ0KPiA+ID4gPiB0bw0KPiA+ID4gPiB0aGlzIHRocmVhZCAqLw0KPiA+ID4gPiAgCXN0cnVj\n" - "dCBrZXkJKnJlcXVlc3Rfa2V5X2F1dGg7IC8qIGFzc3VtZWQNCj4gPiA+ID4gcmVxdWVzdF9rZXkg\n" - "YXV0aG9yaXR5ICovDQo+ID4gPiA+ICAjZW5kaWYNCj4gPiA+ID4gKyNpZmRlZiBDT05GSUdfRklM\n" - "RV9MT0NLSU5HDQo+ID4gPiA+ICsJdm9pZAkJKmxlYXNlX2JyZWFrZXI7IC8qIGlkZW50aWZ5IE5G\n" - "Uw0KPiA+ID4gPiBjbGllbnQNCj4gPiA+ID4gYnJlYWtpbmcgYSBkZWxlZ2F0aW9uICovDQo+ID4g\n" - "PiA+ICsjZW5kaWYNCj4gPiA+ID4gICNpZmRlZiBDT05GSUdfU0VDVVJJVFkNCj4gPiA+ID4gIAl2\n" - "b2lkCQkqc2VjdXJpdHk7CS8qIHN1YmplY3RpdmUNCj4gPiA+ID4gTFNNDQo+ID4gPiA+IHNlY3Vy\n" - "aXR5ICovDQo+ID4gPiA+ICAjZW5kaWYNCj4gPiA+IA0KPiA+ID4gU29ycnksIGJ1dCBld3d3Lg0K\n" - "PiA+ID4gDQo+ID4gPiBUd28gcmVhc29ucyBmb3IgdGhhdCBjb21tZW50Og0KPiA+ID4gDQo+ID4g\n" - "PiAgKDEpIFRoZSBjcmVkIHN0cnVjdCBtYXkgZ2V0IHJldGFpbmVkIGxvbmcgcGFzdCB3aGVyZSB5\n" - "b3UgZXhwZWN0DQo+ID4gPiBpZg0KPiA+ID4gaXQgZ2V0cw0KPiA+ID4gICAgICBhdHRhY2hlZCB0\n" - "byBhbm90aGVyIHByb2Nlc3Mgb3IgYSBmaWxlIGRlc2NyaXB0b3IuDQo+ID4gPiANCj4gPiA+ICAo\n" - "MikgVGhlIC0+bGVhc2VfYnJlYWtlciBwb2ludGVyIG5lZWRzIGxpZmV0aW1lIG1hbmFnZW1lbnQg\n" - "aW4NCj4gPiA+IGNyZWQuYy4gIEl0IHdpbGwNCj4gPiA+ICAgICAgcG90ZW50aWFsbHkgZ2V0IGNv\n" - "cGllZCBhcm91bmQgYW5kIG1heSBuZWVkIGNsZWFuaW5nIHVwLg0KPiA+ID4gDQo+ID4gPiBDYW4g\n" - "eW91IHN0aWNrIHlvdXIgYnJlYWtlciBpZGVudGl0eSBpbiBhIGtleSBzdHJ1Y3QgYXMgSmVmZg0K\n" - "PiA+ID4gc3VnZ2VzdGVkPw0KPiA+ID4gDQo+ID4gDQo+ID4gQnJ1Y2UsDQo+ID4gDQo+ID4gRG8g\n" - "eW91IHJlYWxseSBuZWVkIHRvIGRvIG1vcmUgdGhhbiBqdXN0IGlkZW50aWZ5IHRoYXQgdGhpcyBp\n" - "cyBhDQo+ID4ga25mc2QNCj4gPiB0aHJlYWQgdnMgbm90IGEga25mc2QgdGhyZWFkPyBJJ20gYXNz\n" - "dW1pbmcgdGhhdCBhIGtuZnNkIHRocmVhZCB3aWxsDQo+ID4gdXN1YWxseSBiZSBpbiBhIHBvc2l0\n" - "aW9uIHRvIHJlY2FsbCBkZWxlZ2F0aW9ucyBiZWZvcmUgaXQgZXZlbg0KPiA+IGluaXRpYXRlcw0K\n" - "PiA+IGFuIG9wZXJhdGlvbiBvbiB0aGUgaW5vZGUgaW4gcXVlc3Rpb24sIHdvbid0IGl0Pw0KPiAN\n" - "Cj4gSSB0aGluayBpdCBjb3VsZC4gIEknbSByZWx1Y3RhbnQ6DQo+IA0KPiAJLSBPbmNlIHdlIHN1\n" - "cHBvcnQgd3JpdGUgZGVsZWdhdGlvbnMsIEkgdGhpbmsgd2UgZW5kIHVwIGhhdmluZw0KPiB0bw0K\n" - "PiAJICBkbyB0aGF0IGJlZm9yZSBiYXNpY2FsbHkgZXZlcnkgb3BlcmF0aW9uIG9uIGEgaW5vZGUu\n" - "DQo+IAktIEknZCBsaWtlIHRoaXMgdG8gbWFrZSBpdCBlYXN5IGZvciBzb21lb25lIHRvIGV4dGVu\n" - "ZA0KPiBkZWxlZ2F0aW9uDQo+IAkgIHN1cHBvcnQgdG8gdXNlcnNwYWNlIGV2ZW50dWFsbHkgdG9v\n" - "LiAgSSdtIG5vdCBzdXJlIGV4YWN0bHkNCj4gaG93DQo+IAkgIHdlJ2QgaWRlbnRpZnkgc2VsZi1j\n" - "b25mbGljdHMgaW4gdGhhdCBjYXNlIChzdHJ1Y3QgZmlsZXM/KSwNCj4gYnV0DQo+IAkgIGFueXdh\n" - "eSBJJ2QgcmF0aGVyIHRoaXMgd2Fzbid0IHRvbyBuZnNkLXNwZWNpZmljLg0KDQpUaGF0J3MgbXkg\n" - "cG9pbnQuIEEgdXNlcnNwYWNlIGFwcGxpY2F0aW9uIGlzIGdvaW5nIHRvIGhhdmUgdG8gZG8NCnNv\n" - "bWV0aGluZyBsaWtlIHRoaXMgYW55d2F5LiBJdCBjYW5ub3QgaW5zdGFsbCBob29rcyBpbiB0aGUg\n" - "a2VybmVsIHRvDQpwZXJmb3JtIGVsYWJvcmF0ZSB0ZXN0cywgc28gaXQgaXMgZ29pbmcgdG8gaGF2\n" - "ZSB0byByZWx5IG9uIHNvbWV0aGluZw0KbGlrZSB0aGUgc3RydWN0IGZpbGVfbG9jayAnZmxfbnNw\n" - "aWQnIGZpZWxkIGluIG9yZGVyIHRvIGRldGVybWluZQ0Kd2hldGhlciBvciBub3QgdG8gYXBwbHkg\n" - "YSBsZWFzZSBicmVhay4NCg0KaS5lLjogdGhlIHVzZXJzcGFjZSBydWxlIHNob3VsZCBiZSB0byBi\n" - "cmVhayB0aGUgbGVhc2UgaWYgYW5kIG9ubHkgaWYgaXQNCmlzIG5vdCBvd25lZCBieSBteSBwcm9j\n" - "ZXNzLg0KDQo+IFRoYXQgc2FpZCwgSSdtIHN0aWxsIGN1cmlvdXM6DQo+IA0KPiA+IElPVzogd2hh\n" - "dCBpZiB5b3Ugd2VyZSB0byBtb2RpZnkgdGhlIGxlYXNlIGNvZGUgdG8gYWxsb3cga25mc2QNCj4g\n" - "PiB0aHJlYWRzDQo+ID4gdG8gcmV0dXJuIGEgInBsZWFzZSBpZ25vcmUgbWUsIGFuZCBwcm9jZWVk\n" - "IHdpdGggdGhlIG9wZXJhdGlvbiB0aGF0DQo+ID4gdHJpZ2dlcmVkIHRoZSBsZWFzZSBicmVhayIg\n" - "cmVwbHksIGFuZCB0aGVuIGhhbmRsZSBjb25mbGljdHMgYmV0d2Vlbg0KPiA+IE5GUw0KPiA+IGNs\n" - "aWVudHMgb3V0c2lkZSB0aGUgbGVhc2UgY2FsbGJhY2sgY29kZSBhbHRvZ2V0aGVyPw0KPiANCj4g\n" - "U28gaWYgeW91J3JlIGEgcmFuZG9tIGJpdCBvZiBjb2RlLCBob3cgd291bGQgeW91IHJlY29tbWVu\n" - "ZCB0ZXN0aW5nDQo+IHdoZXRoZXIgeW91J3JlIHJ1bm5pbmcgaW4gYSBrbmZzZCB0aHJlYWQ/DQoN\n" - "ClJpZ2h0IG5vdywgdGhlIGtuZnNkIHRocmVhZHMgYXJlIHJlZ3VsYXIga2VybmVsIHRocmVhZHMs\n" - "IHdpdGggZWFjaA0KdGhyZWFkIGFwcGVhcmluZyB0byB1c2Vyc3BhY2UgdG8gYmUgYSBwcm9jZXNz\n" - "IGluIGl0cyBvd24gcmlnaHQuDQpJcyB0aGVyZSBhbnkgcmVhc29uIHdoeSB3ZSBjb3VsZCBub3Qg\n" - "YXNzaWduIHRoZW0gYSBncm91cCBwaWQgdGhhdCB3b3VsZA0KYWxsb3cgdGhlIGZsX25zcGlkIG1l\n" - "Y2hhbmlzbSB0byB3b3JrIChpLmUuIHNldCB0YXNrLT5ncm91cF9sZWFkZXIpPw0KDQoNCi0tIA0K\n" - "VHJvbmQgTXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1haW50YWluZXIsIFByaW1hcnlEYXRh\n" - DQp0cm9uZC5teWtsZWJ1c3RAcHJpbWFyeWRhdGEuY29tDQo= + "On Tue, 2018-03-20 at 10:49 -0400, J. Bruce Fields wrote:\n" + "> On Tue, Mar 20, 2018 at 01:46:20PM +0000, Trond Myklebust wrote:\n" + "> > On Tue, 2018-03-20 at 13:35 +0000, David Howells wrote:\n" + "> > > J. Bruce Fields <bfields@redhat.com> wrote:\n" + "> > > \n" + "> > > > @@ -139,6 +139,9 @@ struct cred {\n" + "> > > > \tstruct key\t*thread_keyring; /* keyring private\n" + "> > > > to\n" + "> > > > this thread */\n" + "> > > > \tstruct key\t*request_key_auth; /* assumed\n" + "> > > > request_key authority */\n" + "> > > > #endif\n" + "> > > > +#ifdef CONFIG_FILE_LOCKING\n" + "> > > > +\tvoid\t\t*lease_breaker; /* identify NFS\n" + "> > > > client\n" + "> > > > breaking a delegation */\n" + "> > > > +#endif\n" + "> > > > #ifdef CONFIG_SECURITY\n" + "> > > > \tvoid\t\t*security;\t/* subjective\n" + "> > > > LSM\n" + "> > > > security */\n" + "> > > > #endif\n" + "> > > \n" + "> > > Sorry, but ewww.\n" + "> > > \n" + "> > > Two reasons for that comment:\n" + "> > > \n" + "> > > (1) The cred struct may get retained long past where you expect\n" + "> > > if\n" + "> > > it gets\n" + "> > > attached to another process or a file descriptor.\n" + "> > > \n" + "> > > (2) The ->lease_breaker pointer needs lifetime management in\n" + "> > > cred.c. It will\n" + "> > > potentially get copied around and may need cleaning up.\n" + "> > > \n" + "> > > Can you stick your breaker identity in a key struct as Jeff\n" + "> > > suggested?\n" + "> > > \n" + "> > \n" + "> > Bruce,\n" + "> > \n" + "> > Do you really need to do more than just identify that this is a\n" + "> > knfsd\n" + "> > thread vs not a knfsd thread? I'm assuming that a knfsd thread will\n" + "> > usually be in a position to recall delegations before it even\n" + "> > initiates\n" + "> > an operation on the inode in question, won't it?\n" + "> \n" + "> I think it could. I'm reluctant:\n" + "> \n" + "> \t- Once we support write delegations, I think we end up having\n" + "> to\n" + "> \t do that before basically every operation on a inode.\n" + "> \t- I'd like this to make it easy for someone to extend\n" + "> delegation\n" + "> \t support to userspace eventually too. I'm not sure exactly\n" + "> how\n" + "> \t we'd identify self-conflicts in that case (struct files?),\n" + "> but\n" + "> \t anyway I'd rather this wasn't too nfsd-specific.\n" + "\n" + "That's my point. A userspace application is going to have to do\n" + "something like this anyway. It cannot install hooks in the kernel to\n" + "perform elaborate tests, so it is going to have to rely on something\n" + "like the struct file_lock 'fl_nspid' field in order to determine\n" + "whether or not to apply a lease break.\n" + "\n" + "i.e.: the userspace rule should be to break the lease if and only if it\n" + "is not owned by my process.\n" + "\n" + "> That said, I'm still curious:\n" + "> \n" + "> > IOW: what if you were to modify the lease code to allow knfsd\n" + "> > threads\n" + "> > to return a \"please ignore me, and proceed with the operation that\n" + "> > triggered the lease break\" reply, and then handle conflicts between\n" + "> > NFS\n" + "> > clients outside the lease callback code altogether?\n" + "> \n" + "> So if you're a random bit of code, how would you recommend testing\n" + "> whether you're running in a knfsd thread?\n" + "\n" + "Right now, the knfsd threads are regular kernel threads, with each\n" + "thread appearing to userspace to be a process in its own right.\n" + "Is there any reason why we could not assign them a group pid that would\n" + "allow the fl_nspid mechanism to work (i.e. set task->group_leader)?\n" + "\n" + "\n" + "-- \n" + "Trond Myklebust\n" + "Linux NFS client maintainer, PrimaryData\n" + trond.myklebust@primarydata.com -bbe8e9934da818bf648a12e55c000c8f218a6a1b4d656bb902546c31ebbdbfc9 +3969344bb81f99ac0b8f9f6a59071873223638b0ec54bd1f5ddc5d97290999c0
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.