From: Benny Halevy <bhalevy@panasas.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org, pnfs@linux-nfs.org,
Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Subject: Re: [PATCH] nfsd41: renew_client must be called under the state lock
Date: Tue, 25 Aug 2009 20:02:41 +0300 [thread overview]
Message-ID: <4A941931.8070609@panasas.com> (raw)
In-Reply-To: <20090825131829.GA24049@fieldses.org>
On Aug. 25, 2009, 16:18 +0300, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Tue, Aug 25, 2009 at 10:06:34AM +0300, Benny Halevy wrote:
>> On Aug. 24, 2009, 19:29 +0300, "J. Bruce Fields" <bfields@fieldses.org> wrote:
>>> On Thu, Aug 20, 2009 at 03:21:56AM +0300, Benny Halevy wrote:
>>>> nfsd4_sequence() should not renew the client state if the session was not
>>>> found or if there was a bad slot. This will also avoid dereferencing a
>>>> null session pointer.
>>>>
>>>> FIXME: until we work out the state locking so we can use a
>>>> spin lock to protect the cl_lru we need to take the state_lock
>>>> to renew the client.
>>> Is that first paragraph left over from some previous iteration of this
>>> patch?
>> Not really.
>> It sort of sets up the stage for the state lock elimination project.
>> That said, feel free to remove these lines as they are not particularly
>> important for understanding what this patch does or how to do it better.
>
> Note I was referring to "should not renew..." That seems to describe a
> problem that has already been fixed.
Hmm, apparently this came from "Do not renew state on error"
which was squashed together with this patch.
The text is still valid though somewhat unrelated to this patch's
title. Maybe a better title would be the original one:
""Do not renew state on error"
Benny
>
> --b.
>
>>>> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
>>>> [nfsd41: Do not renew state on error]
>>>> Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
>>>> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
>>>> ---
>>>>
>>>> Bruce, I'm not whether it is too late but this patch fixes
>>>> a bug in 2.6.31-rc that we've hit in the last Bakeathon.
>>> I think we should wait for 2.6.32. (And was the bug you hit due to the
>>> lack of state locking or to the NULL dereference?)
>>>
>>> I don't have any fix for the locking problem queued up for 2.6.32.
>>>
>>> --b.
>>>
>>>> Benny
>>>>
>>>> fs/nfsd/nfs4state.c | 30 +++++++++++++++++++-----------
>>>> 1 files changed, 19 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
>>>> index 1dedde9..3e7b20a 100644
>>>> --- a/fs/nfsd/nfs4state.c
>>>> +++ b/fs/nfsd/nfs4state.c
>>>> @@ -1436,12 +1436,16 @@ nfsd4_sequence(struct svc_rqst *rqstp,
>>>> spin_lock(&sessionid_lock);
>>>> status = nfserr_badsession;
>>>> session = find_in_sessionid_hashtbl(&seq->sessionid);
>>>> - if (!session)
>>>> - goto out;
>>>> + if (!session) {
>>>> + spin_unlock(&sessionid_lock);
>>>> + goto err;
>>>> + }
>>>>
>>>> status = nfserr_badslot;
>>>> - if (seq->slotid >= session->se_fchannel.maxreqs)
>>>> - goto out;
>>>> + if (seq->slotid >= session->se_fchannel.maxreqs) {
>>>> + spin_unlock(&sessionid_lock);
>>>> + goto err;
>>>> + }
>>>>
>>>> slot = &session->se_slots[seq->slotid];
>>>> dprintk("%s: slotid %d\n", __func__, seq->slotid);
>>>> @@ -1454,10 +1458,12 @@ nfsd4_sequence(struct svc_rqst *rqstp,
>>>> * for nfsd4_proc_compound processing */
>>>> status = nfsd4_replay_cache_entry(resp, seq);
>>>> cstate->status = nfserr_replay_cache;
>>>> - goto replay_cache;
>>>> - }
>>>> - if (status)
>>>> goto out;
>>>> + }
>>>> + if (status) {
>>>> + spin_unlock(&sessionid_lock);
>>>> + goto err;
>>>> + }
>>>>
>>>> /* Success! bump slot seqid */
>>>> slot->sl_inuse = true;
>>>> @@ -1470,15 +1476,17 @@ nfsd4_sequence(struct svc_rqst *rqstp,
>>>> cstate->slot = slot;
>>>> cstate->session = session;
>>>>
>>>> -replay_cache:
>>>> - /* Renew the clientid on success and on replay.
>>>> - * Hold a session reference until done processing the compound:
>>>> + /* Hold a session reference until done processing the compound:
>>>> * nfsd4_put_session called only if the cstate slot is set.
>>>> */
>>>> - renew_client(session->se_client);
>>>> nfsd4_get_session(session);
>>>> out:
>>>> spin_unlock(&sessionid_lock);
>>>> + /* Renew the clientid on success and on replay */
>>>> + nfs4_lock_state();
>>>> + renew_client(session->se_client);
>>>> + nfs4_unlock_state();
>>>> +err:
>>>> dprintk("%s: return %d\n", __func__, ntohl(status));
>>>> return status;
>>>> }
>>>> --
>>>> 1.6.4
>>>>
next prev parent reply other threads:[~2009-08-25 17:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-20 0:21 [PATCH] nfsd41: renew_client must be called under the state lock Benny Halevy
2009-08-24 16:29 ` J. Bruce Fields
2009-08-25 7:06 ` Benny Halevy
2009-08-25 13:18 ` J. Bruce Fields
2009-08-25 17:02 ` Benny Halevy [this message]
2009-08-25 21:59 ` J. Bruce Fields
2009-08-26 8:20 ` [pnfs] " Boaz Harrosh
2009-08-26 21:02 ` J. Bruce Fields
2009-08-27 16:37 ` Benny Halevy
2009-08-27 21:16 ` J. Bruce Fields
2009-08-27 21:38 ` J. Bruce Fields
-- strict thread matches above, loose matches on Subject: below --
2009-06-19 2:01 Benny Halevy
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=4A941931.8070609@panasas.com \
--to=bhalevy@panasas.com \
--cc=Ricardo.Labiaga@netapp.com \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=pnfs@linux-nfs.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox