| Message ID | 20180418210437.97702-1-aweits@rit.edu (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Apr 18, 2018 at 05:04:37PM -0400, Andrew Elble wrote: > I noticed a memory corruption crash in nfsd in > 4.17-rc1. This patch corrects the issue. > > Fix to return error if the delegation couldn't be hashed or there was > a recall in progress. Use the existing error path instead of > destroy_delegation() for readability. Apologies for the slow response, this looks right, I'm just still trying to figure out whether this is the only problem here--e.g. does it cause problems to have this lease temporarily applied before the delegation is hashed? Also the RHEL7 code appears to have worse problems in the same spot and I'm trying to work out if they'd explaining a long-standing bug report.... --b. > > Signed-off-by: Andrew Elble <aweits@rit.edu> > Fixes: 353601e7d323c ("nfsd: create a separate lease for each delegation") > --- > fs/nfsd/nfs4state.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c > index 71b87738c015..449d42a0f71b 100644 > --- a/fs/nfsd/nfs4state.c > +++ b/fs/nfsd/nfs4state.c > @@ -4376,8 +4376,11 @@ static struct file_lock *nfs4_alloc_init_lease(struct nfs4_delegation *dp, > spin_unlock(&state_lock); > > if (status) > - destroy_unhashed_deleg(dp); > + goto out_unlock; > + > return dp; > +out_unlock: > + vfs_setlease(fp->fi_deleg_file, F_UNLCK, NULL, (void **)&dp); > out_clnt_odstate: > put_clnt_odstate(dp->dl_clnt_odstate); > out_stid: > -- > 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
"J. Bruce Fields" <bfields@fieldses.org> writes: > Apologies for the slow response, this looks right, I'm just still trying > to figure out whether this is the only problem here--e.g. does it cause > problems to have this lease temporarily applied before the delegation is > hashed? So the only thing I can currently theorize is that we might eject some recalls for delegations that will never hit the wire. I think the worst possibility is that nfsd4_cb_recall_done() might wind up declaring the callback path to be down? Still looking... Thanks, Andy
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index 71b87738c015..449d42a0f71b 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -4376,8 +4376,11 @@ static struct file_lock *nfs4_alloc_init_lease(struct nfs4_delegation *dp, spin_unlock(&state_lock); if (status) - destroy_unhashed_deleg(dp); + goto out_unlock; + return dp; +out_unlock: + vfs_setlease(fp->fi_deleg_file, F_UNLCK, NULL, (void **)&dp); out_clnt_odstate: put_clnt_odstate(dp->dl_clnt_odstate); out_stid:
I noticed a memory corruption crash in nfsd in 4.17-rc1. This patch corrects the issue. Fix to return error if the delegation couldn't be hashed or there was a recall in progress. Use the existing error path instead of destroy_delegation() for readability. Signed-off-by: Andrew Elble <aweits@rit.edu> Fixes: 353601e7d323c ("nfsd: create a separate lease for each delegation") --- fs/nfsd/nfs4state.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)