From: Trond Myklebust <trondmy@primarydata.com> To: "bfields@fieldses.org" <bfields@fieldses.org> Cc: "bfields@redhat.com" <bfields@redhat.com>, "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>, "dhowells@redhat.com" <dhowells@redhat.com>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org> Subject: Re: [PATCH 10/10] nfsd: clients don't need to break their own delegations Date: Tue, 20 Mar 2018 15:13:47 +0000 [thread overview] Message-ID: <1521558822.15893.12.camel@primarydata.com> (raw) In-Reply-To: <20180320144928.GA4288@fieldses.org> 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
WARNING: multiple messages have this Message-ID (diff)
From: Trond Myklebust <trondmy@primarydata.com> To: "bfields@fieldses.org" <bfields@fieldses.org> Cc: "bfields@redhat.com" <bfields@redhat.com>, "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>, "dhowells@redhat.com" <dhowells@redhat.com>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org> Subject: Re: [PATCH 10/10] nfsd: clients don't need to break their own delegations Date: Tue, 20 Mar 2018 15:13:47 +0000 [thread overview] Message-ID: <1521558822.15893.12.camel@primarydata.com> (raw) In-Reply-To: <20180320144928.GA4288@fieldses.org> 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=
next prev parent reply other threads:[~2018-03-20 15:13 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-19 14:36 [PATCH 00/10] Eliminate delegation self-conflicts v2 J. Bruce Fields 2018-03-19 14:36 ` [PATCH 01/10] vfs: remove unnecessary fl_owner_t typedef J. Bruce Fields 2018-03-19 14:36 ` J. Bruce Fields 2018-03-19 14:36 ` [PATCH 02/10] nfsd: simplify put of fi_deleg_file J. Bruce Fields 2018-03-19 14:36 ` [PATCH 03/10] nfsd: simplify nfs4_put_deleg_lease calls J. Bruce Fields 2018-03-19 14:36 ` [PATCH 04/10] nfsd4: set fl_owner to delegation, not file pointer J. Bruce Fields 2018-03-19 14:36 ` [PATCH 05/10] nfsd4: dp->dl_stid.sc_file doesn't need locking J. Bruce Fields 2018-03-19 14:36 ` [PATCH 06/10] nfsd: make nfs4_get_existing_delegation less confusing J. Bruce Fields 2018-03-19 14:36 ` [PATCH 07/10] nfsd: factor out common delegation-destruction code J. Bruce Fields 2018-03-19 14:36 ` [PATCH 08/10] nfsd: move sc_file assignment into alloc_init_deleg J. Bruce Fields 2018-03-19 14:36 ` [PATCH 09/10] nfsd: create a separate lease for each delegation J. Bruce Fields 2018-03-19 14:36 ` [PATCH 10/10] nfsd: clients don't need to break their own delegations J. Bruce Fields 2018-03-20 13:10 ` [PATCH 00/10] Eliminate delegation self-conflicts v2 Jeff Layton 2018-03-20 13:35 ` [PATCH 10/10] nfsd: clients don't need to break their own delegations David Howells 2018-03-20 13:46 ` Trond Myklebust 2018-03-20 13:46 ` Trond Myklebust 2018-03-20 14:49 ` J. Bruce Fields 2018-03-20 15:13 ` Trond Myklebust [this message] 2018-03-20 15:13 ` Trond Myklebust 2018-03-20 16:02 ` bfields 2018-09-06 19:40 ` bfields 2018-03-20 14:52 ` J. Bruce Fields
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1521558822.15893.12.camel@primarydata.com \ --to=trondmy@primarydata.com \ --cc=bfields@fieldses.org \ --cc=bfields@redhat.com \ --cc=dhowells@redhat.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-nfs@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.