From: "J. Bruce Fields" <bfields@fieldses.org>
To: Wang Chen <wangchen@cn.fujitsu.com>
Cc: neilb@suse.de, Trond.Myklebust@netapp.com,
linux-nfs@vger.kernel.org,
FNST-Bian Naimeng <biannm@cn.fujitsu.com>
Subject: Re: [PATCH] nfs lockd: detect grace_list corruption
Date: Fri, 8 May 2009 14:26:48 -0400 [thread overview]
Message-ID: <20090508182648.GD20539@fieldses.org> (raw)
In-Reply-To: <4A0284EB.9050202@cn.fujitsu.com>
On Thu, May 07, 2009 at 02:51:23PM +0800, Wang Chen wrote:
> J. Bruce Fields said the following on 2009-5-7 4:32:
> > On Wed, May 06, 2009 at 05:17:20PM +0800, Wang Chen wrote:
> >> J. Bruce Fields said the following on 2009-4-25 7:12:
> >>> On Fri, Apr 24, 2009 at 11:09:44AM +0800, Wang Chen wrote:
> >>>> Although I can't reproduce it now, it really happened that some lock manager
> >>>> started grace period but didn't end it.
> >>>> This causes an lm entry be left in grace_list, and when service nfs restart,
> >>>> the same lm will be added again into the list.
> >>>> As you know, adding an entry, which is in the list, to a list will leads to
> >>>> list corruption.
> >>> I'd really like to understand why locks_end_grace() isn't being called.
> >>> I'm probably overlooking something obvious, but I just can't see how
> >>> lockd or nfsd can be shut down right now without locks_end_grace() being
> >>> called.
> >>>
> >> Me neither can figure out why locks_end_grace() isn't being called.
> >>
> >> But do locks_start_grace() twice can trigger this warning too.
> >> You can do
> >> 1. service nfs restart
> >> 2. (immediately) kill -s SIGKILL lockd
> >> this can trigger
> >> ---
> >> lockd(void *vrqstp)
> >> ...
> >> if (signalled()) {
> >> flush_signals(current);
> >> if (nlmsvc_ops) {
> >> nlmsvc_invalidate_all();
> >> set_grace_period();
> >> ---
> >> and makes locks_start_grace() be called twice without locks_end_grace().
> >
> > Ah-hah!
> >
> >> So I still suggest to do something to protect the lm list. :)
> >
> > I wouldn't be opposed to a simple WARN_ON(!list_empty()) in
> > locks_start_grace(), but I'm mainly worried about fixing the original
> > bug. How about the following?
> >
>
> Yeah, the following fix is OK to me, although it only fixed
> "start_grace again after start_grace" case.
OK, thanks.
> The bug about "quit lockd without end_grace", which I encountered before
> incidentally, maybe is still there.
You're talking about the report that started this thread?:
http://marc.info/?l=linux-nfs&m=124054262421444&w=2
It looks to me like that could be explained by two start_grace's in a
row.
--b.
>
> > --b.
> >
> > diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
> > index abf8388..1a54ae1 100644
> > --- a/fs/lockd/svc.c
> > +++ b/fs/lockd/svc.c
> > @@ -104,6 +104,16 @@ static void set_grace_period(void)
> > schedule_delayed_work(&grace_period_end, grace_period);
> > }
> >
> > +static void restart_grace(void)
> > +{
> > + if (nlmsvc_ops) {
> > + cancel_delayed_work_sync(&grace_period_end);
> > + locks_end_grace(&lockd_manager);
> > + nlmsvc_invalidate_all();
> > + set_grace_period();
> > + }
> > +}
> > +
> > /*
> > * This is the lockd kernel thread
> > */
> > @@ -149,10 +159,7 @@ lockd(void *vrqstp)
> >
> > if (signalled()) {
> > flush_signals(current);
> > - if (nlmsvc_ops) {
> > - nlmsvc_invalidate_all();
> > - set_grace_period();
> > - }
> > + restart_grace();
> > continue;
> > }
> >
> >
>
next prev parent reply other threads:[~2009-05-08 18:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-24 3:09 [PATCH] nfs lockd: detect grace_list corruption Wang Chen
2009-04-24 5:15 ` Bian Naimeng
2009-04-24 7:35 ` [PATCH V2] " Wang Chen
2009-04-24 23:12 ` [PATCH] " J. Bruce Fields
2009-05-06 9:17 ` Wang Chen
2009-05-06 20:32 ` J. Bruce Fields
2009-05-07 6:51 ` Wang Chen
2009-05-08 18:26 ` J. Bruce Fields [this message]
2009-05-11 6:13 ` Wang Chen
2009-05-11 20:57 ` J. Bruce Fields
2009-05-12 0:43 ` Wang Chen
2009-05-12 19:13 ` J. Bruce Fields
2009-05-13 2:24 ` Wang Chen
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=20090508182648.GD20539@fieldses.org \
--to=bfields@fieldses.org \
--cc=Trond.Myklebust@netapp.com \
--cc=biannm@cn.fujitsu.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=wangchen@cn.fujitsu.com \
/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 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.