From: Wendy Cheng <wcheng@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Re: [PATCH 1/2] NLM failover unlock commands
Date: Tue, 15 Jan 2008 15:17:09 -0500 [thread overview]
Message-ID: <478D14C5.1000804@redhat.com> (raw)
In-Reply-To: <18315.62909.330258.83038@notabene.brown>
Neil Brown wrote:
> On Saturday January 12, wcheng at redhat.com wrote:
>
>> This is a combined patch that has:
>>
>> * changes made by Christoph Hellwig
>> * code segment that handles f_locks so we would not walk inode->i_flock
>> list twice.
>>
>>
.....
>
> if (unlikely(failover) &&
> !failover(data, file))
> file->f_locks = nlm_file_inuse(file);
> else if (nlm_inspect_file(data, file, match))
> ret = 1;
>
> Though the logic still isn't very clear... maybe:
>
> if (likely(failover == NULL) ||
> failover(data, file))
> ret |= nlm_inspect_file(data, file, match);
> else
> file->f_locks = nlm_file_inuse(file);
>
> Actually I would like to make nlm_inspect_file return 'void'.
> The returned value of '1' is ultimately either ignored or it triggers
> a BUG(). And the case where it triggers a BUG is the "host != NULL"
> case. (I think - if someone could check, that would be good).
> So putting BUG_ON(host) in nlm_traverse_locks (along with a nice big
> comment) would mean we can discard the return value from
> nlm_traverse_locks and nlm_inspect_file and nlm_traverse_files.
>
Current logic BUG() when:
1. host is not NULL; and
2. nlm_traverse_locks() somehow can't unlock the file.
I don't feel comfortable to change the existing code structure,
especially a BUG() statement. It would be better to separate lock
failover function away from lockd code clean-up. This is to make it
easier for problem isolations (just in case).
On the other hand, if we view "ret" as a file count that tells us how
many files fail to get unlocked, it would be great for debugging
purpose. So the changes I made (currently in the middle of cluster
testing) end up like this:
if (likely(is_failover_file == NULL) ||
is_failover_file(data, file)) {
/*
* Note that nlm_inspect_file updates f_locks
* and ret is the number of files that can't
* be unlocked.
*/
ret += nlm_inspect_file(data, file, match);
} else
file->f_locks = nlm_file_inuse(file);
>
>
>
>
>>
>> mutex_lock(&nlm_file_mutex);
>> file->f_count--;
>> /* No more references to this file. Let go of it. */
>> - if (list_empty(&file->f_blocks) && !file->f_locks
>> + if (!file->f_locks && list_empty(&file->f_blocks)
>>
>
> Is this change actually achieving something? or is it just noise?
>
Not really - but I thought checking for f_locks would be faster (tiny
bit of optimization :))
-- Wendy
>
> NeilBrown
>
>
next prev parent reply other threads:[~2008-01-15 20:17 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-07 5:39 [Cluster-devel] [PATCH 1/2] NLM failover unlock commands Wendy Cheng
[not found] ` <message from Wendy Cheng on Monday January 7>
2008-01-08 5:18 ` [Cluster-devel] " Neil Brown
2008-01-09 2:51 ` Wendy Cheng
2008-01-08 5:31 ` [Cluster-devel] Re: [PATCH 2/2] Fix lockd panic Neil Brown
2008-01-09 3:02 ` Wendy Cheng
2008-01-09 4:43 ` Wendy Cheng
2008-01-09 23:33 ` Wendy Cheng
2008-01-12 6:51 ` Wendy Cheng
2008-01-08 17:02 ` [Cluster-devel] Re: [PATCH 1/2] NLM failover unlock commands Christoph Hellwig
2008-01-08 17:49 ` Christoph Hellwig
2008-01-08 20:57 ` Wendy Cheng
2008-01-09 18:02 ` Christoph Hellwig
2008-01-10 7:59 ` Christoph Hellwig
2008-01-12 7:03 ` Wendy Cheng
2008-01-12 9:38 ` Christoph Hellwig
2008-01-14 23:07 ` J. Bruce Fields
[not found] ` <message from J. Bruce Fields on Monday January 14>
2008-01-14 23:31 ` Neil Brown
2008-01-22 22:53 ` J. Bruce Fields
[not found] ` <message from J. Bruce Fields on Tuesday January 22>
2008-01-24 4:02 ` Neil Brown
2008-01-15 16:14 ` Wendy Cheng
2008-01-15 16:30 ` J. Bruce Fields
[not found] ` <message from Wendy Cheng on Saturday January 12>
2008-01-14 23:52 ` Neil Brown
2008-01-15 20:17 ` Wendy Cheng [this message]
[not found] ` <message from Wendy Cheng on Tuesday January 15>
2008-01-15 20:50 ` Neil Brown
2008-01-15 20:56 ` Wendy Cheng
2008-01-15 22:48 ` Wendy Cheng
2008-01-17 15:10 ` J. Bruce Fields
2008-01-17 15:48 ` Wendy Cheng
2008-01-17 16:08 ` Wendy Cheng
2008-01-17 16:10 ` Wendy Cheng
2008-01-18 10:21 ` Frank van Maarseveen
2008-01-18 15:00 ` Wendy Cheng
2008-01-17 16:14 ` J. Bruce Fields
2008-01-17 16:17 ` Wendy Cheng
2008-01-17 16:21 ` J. Bruce Fields
2008-01-17 16:31 ` J. Bruce Fields
2008-01-17 16:31 ` Wendy Cheng
2008-01-17 16:40 ` J. Bruce Fields
[not found] ` <1200591323.13670.34.camel@dyn9047022153>
2008-01-17 17:59 ` Wendy Cheng
2008-01-17 18:07 ` Wendy Cheng
2008-01-17 20:23 ` J. Bruce Fields
2008-01-18 10:03 ` Frank van Maarseveen
2008-01-18 14:56 ` Wendy Cheng
2008-01-24 16:00 ` J. Bruce Fields
[not found] ` <4798BAAE.6090107@redhat.com>
2008-01-24 16:39 ` J. Bruce Fields
2008-01-24 19:45 ` Wendy Cheng
2008-01-24 20:19 ` J. Bruce Fields
2008-01-24 21:06 ` Wendy Cheng
2008-01-24 21:40 ` J. Bruce Fields
2008-01-24 21:49 ` Wendy Cheng
2008-01-28 3:46 ` Felix Blyakher
2008-01-28 15:56 ` Wendy Cheng
2008-01-28 17:06 ` Felix Blyakher
2008-01-16 4:19 ` Neil Brown
2008-01-09 3:49 ` Wendy Cheng
2008-01-09 16:13 ` J. Bruce Fields
-- strict thread matches above, loose matches on Subject: below --
2008-01-07 5:53 [Cluster-devel] [PATCH 2/2] Fix lockd panic Wendy Cheng
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=478D14C5.1000804@redhat.com \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).