All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Wendy Cheng <wcheng@redhat.com>
Cc: NFS list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] Fix NLM reference count panic
Date: Sat, 5 Jan 2008 01:05:09 -0500	[thread overview]
Message-ID: <20080105060509.GA29020@fieldses.org> (raw)
In-Reply-To: <477F0F8B.9020706@redhat.com>

On Sat, Jan 05, 2008 at 12:03:07AM -0500, Wendy Cheng wrote:
> J. Bruce Fields wrote:
>
>> On Fri, Jan 04, 2008 at 05:48:49PM -0500, Wendy Cheng wrote:
>> This just replaces the file->f_locks check by a search of the inode's
>> lock list.
>>
>> What confuses me here is that the nlm_inspect_file() call just above
>> already did that search, and set file->f_locks accordingly.  The only
>> difference is that now we've acquired the nlm_file_mutex.  I don't
>> understand yet how that makes a difference.
>>
>>  
> You're right. I got the patch sequence wrong. It will cause panic only when 
> we selectively unlock nlm locks under my "unlock" patch as the following. 
> See how it returns without doing nlm_traverse_locks() below ... Let's 
> combine this patch into the big unlock patch so we won't have any 
> confusion. The unlock patch will submitted on Monday after this weekend's 
> sanity check test run. In short, I withdraw this patch... Wendy

OK.  I'll admit to still being a little confused--but with luck it'll
all make sense when I see the whole thing.  Have a good weekend!

--b.

> nlm_inspect_file(struct nlm_host *host, struct nlm_file *file, 
> nlm_host_match_fn_t match)
> {
> + /* Cluster failover has timing constraints. There is a slight
> + * performance hit if nlm_fo_unlock_match() is implemented as
> + * a match fn (since it will be invoked for each block, share,
> + * and lock later when the lists are traversed). Instead, we
> + * add path-matching logic into the following unlikely clause.
> + * If matches, the dummy nlmsvc_fo_match will always return
> + * true.
> + */
> + dprintk("nlm_inspect_files: file=%p\n", file);
> + if (unlikely(match == nlmsvc_fo_match)) {
> + if (!nlmsvc_fo_unlock_match((void *)host, file))
> + return 0;
> + fo_printk("nlm_fo find lock file entry (0x%p)\n", file);
> + }
> +
> nlmsvc_traverse_blocks(host, file, match);
> nlmsvc_traverse_shares(host, file, match);
> return nlm_traverse_locks(host, file, match);
> @@ -369,3 +451,35 @@ nlmsvc_invalidate_all(void)
> */
> nlm_traverse_files(NULL, nlmsvc_is_client);
> }
>

  reply	other threads:[~2008-01-05  6:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-04 22:48 [PATCH] Fix NLM reference count panic Wendy Cheng
2008-01-04 22:58 ` Wendy Cheng
2008-01-04 23:24 ` J. Bruce Fields
2008-01-05  5:03   ` Wendy Cheng
2008-01-05  6:05     ` J. Bruce Fields [this message]
2008-01-05 17:46       ` Wendy Cheng
2008-01-05 17:36         ` 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=20080105060509.GA29020@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=wcheng@redhat.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.