| Message ID | 166689675530.90991.2630847343462195612.stgit@klimt.1015granger.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Series short description | expand |
On Fri, 28 Oct 2022, Chuck Lever wrote: > Name nfs4_file-related helpers consistently. There are already > nfs4_file_yada functions, so let's go with the same convention used > by put_nfs4_file(): init_nfs4_file(). I don't understand. You say "consistently", then you say that as we have lots of "nfs4_file_yada" functions, this new one will NOT follow that pattern. Surely "consistency" means renaming put_nfs4_file() to nfs4_file_put(), and introducing nfs4_file_init(). Not that I really care that much about the naming, but would like to be able to follow your logic. Thanks, NeilBrown
> On Oct 27, 2022, at 7:22 PM, NeilBrown <neilb@suse.de> wrote: > > On Fri, 28 Oct 2022, Chuck Lever wrote: >> Name nfs4_file-related helpers consistently. There are already >> nfs4_file_yada functions, so let's go with the same convention used >> by put_nfs4_file(): init_nfs4_file(). > > I don't understand. You say "consistently", then you say that as we > have lots of "nfs4_file_yada" functions, this new one will NOT follow > that pattern. Patch description is admittedly terse. I want a naming convention that sets apart the helpers that deal with the nfs4_file hash table. Maybe nfs4_file_hash_yada would be a better choice? But we already have put_nfs4_file()... > Surely "consistency" means renaming put_nfs4_file() to nfs4_file_put(), > and introducing nfs4_file_init(). > > Not that I really care that much about the naming, but would like to be > able to follow your logic. > > Thanks, > NeilBrown -- Chuck Lever
On Fri, 28 Oct 2022, Chuck Lever III wrote: > > > On Oct 27, 2022, at 7:22 PM, NeilBrown <neilb@suse.de> wrote: > > > > On Fri, 28 Oct 2022, Chuck Lever wrote: > >> Name nfs4_file-related helpers consistently. There are already > >> nfs4_file_yada functions, so let's go with the same convention used > >> by put_nfs4_file(): init_nfs4_file(). > > > > I don't understand. You say "consistently", then you say that as we > > have lots of "nfs4_file_yada" functions, this new one will NOT follow > > that pattern. > > Patch description is admittedly terse. > > I want a naming convention that sets apart the helpers that > deal with the nfs4_file hash table. Maybe nfs4_file_hash_yada > would be a better choice? > > But we already have put_nfs4_file()... OK, that makes more sense. Thanks, NeilBrown > > > > Surely "consistency" means renaming put_nfs4_file() to nfs4_file_put(), > > and introducing nfs4_file_init(). > > > > Not that I really care that much about the naming, but would like to be > > able to follow your logic. > > > > Thanks, > > NeilBrown > > -- > Chuck Lever > > > >
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index 60f1aa2c5442..c793b62e2ec0 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -4262,11 +4262,8 @@ static struct nfs4_file *nfsd4_alloc_file(void) } /* OPEN Share state helper functions */ -static void nfsd4_init_file(struct svc_fh *fh, unsigned int hashval, - struct nfs4_file *fp) +static void init_nfs4_file(const struct svc_fh *fh, struct nfs4_file *fp) { - lockdep_assert_held(&state_lock); - refcount_set(&fp->fi_ref, 1); spin_lock_init(&fp->fi_lock); INIT_LIST_HEAD(&fp->fi_stateids); @@ -4284,7 +4281,6 @@ static void nfsd4_init_file(struct svc_fh *fh, unsigned int hashval, INIT_LIST_HEAD(&fp->fi_lo_states); atomic_set(&fp->fi_lo_recalls, 0); #endif - hlist_add_head_rcu(&fp->fi_hash, &file_hashtbl[hashval]); } void @@ -4702,7 +4698,8 @@ static struct nfs4_file *insert_file(struct nfs4_file *new, struct svc_fh *fh, fp->fi_aliased = alias_found = true; } if (likely(ret == NULL)) { - nfsd4_init_file(fh, hashval, new); + init_nfs4_file(fh, new); + hlist_add_head_rcu(&new->fi_hash, &file_hashtbl[hashval]); new->fi_aliased = alias_found; ret = new; }
Name nfs4_file-related helpers consistently. There are already nfs4_file_yada functions, so let's go with the same convention used by put_nfs4_file(): init_nfs4_file(). Change the @fh parameter to be const pointer for better type safety. Finally, move the hash insertion operation to the caller. This is typical for most other "init_object" type helpers, and it is where most of the other nfs4_file hash table operations are located. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> --- fs/nfsd/nfs4state.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)