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
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Wendy Cheng <wcheng@redhat.com>
To: Neil Brown <neilb@suse.de>
Cc: Christoph Hellwig <hch@infradead.org>,
"J. Bruce Fields" <bfields@fieldses.org>,
NFS list <linux-nfs@vger.kernel.org>,
cluster-devel@redhat.com
Subject: 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@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: 117+ 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
2008-01-07 5:39 ` Wendy Cheng
[not found] ` <message from Wendy Cheng on Monday January 7>
2008-01-08 5:18 ` [Cluster-devel] " Neil Brown
2008-01-08 5:18 ` Neil Brown
2008-01-09 2:51 ` [Cluster-devel] " Wendy Cheng
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-08 5:31 ` Neil Brown
2008-01-09 3:02 ` [Cluster-devel] " Wendy Cheng
2008-01-09 3:02 ` Wendy Cheng
2008-01-09 4:43 ` [Cluster-devel] " Wendy Cheng
2008-01-09 4:43 ` Wendy Cheng
2008-01-09 23:33 ` [Cluster-devel] " Wendy Cheng
2008-01-09 23:33 ` Wendy Cheng
2008-01-12 6:51 ` [Cluster-devel] " 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:02 ` Christoph Hellwig
2008-01-08 17:49 ` [Cluster-devel] " Christoph Hellwig
2008-01-08 17:49 ` Christoph Hellwig
2008-01-08 20:57 ` [Cluster-devel] " Wendy Cheng
2008-01-08 20:57 ` Wendy Cheng
2008-01-09 18:02 ` [Cluster-devel] " Christoph Hellwig
2008-01-09 18:02 ` Christoph Hellwig
2008-01-10 7:59 ` [Cluster-devel] " Christoph Hellwig
2008-01-10 7:59 ` Christoph Hellwig
2008-01-12 7:03 ` [Cluster-devel] " Wendy Cheng
2008-01-12 7:03 ` Wendy Cheng
2008-01-12 9:38 ` [Cluster-devel] " Christoph Hellwig
2008-01-12 9:38 ` Christoph Hellwig
2008-01-14 23:07 ` [Cluster-devel] " J. Bruce Fields
2008-01-14 23:07 ` J. Bruce Fields
[not found] ` <message from J. Bruce Fields on Monday January 14>
2008-01-14 23:31 ` [Cluster-devel] " Neil Brown
2008-01-14 23:31 ` Neil Brown
[not found] ` <18315.61638.14133.308991-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-01-15 16:38 ` Chuck Lever
2008-01-22 22:53 ` [Cluster-devel] " J. Bruce Fields
2008-01-22 22:53 ` J. Bruce Fields
[not found] ` <message from J. Bruce Fields on Tuesday January 22>
2008-01-24 4:02 ` [Cluster-devel] " Neil Brown
2008-01-24 4:02 ` Neil Brown
2008-01-15 16:14 ` [Cluster-devel] " Wendy Cheng
2008-01-15 16:14 ` Wendy Cheng
2008-01-15 16:30 ` [Cluster-devel] " J. Bruce Fields
2008-01-15 16:30 ` J. Bruce Fields
[not found] ` <message from Wendy Cheng on Saturday January 12>
2008-01-14 23:52 ` [Cluster-devel] " Neil Brown
2008-01-14 23:52 ` Neil Brown
2008-01-15 20:17 ` Wendy Cheng [this message]
2008-01-15 20:17 ` Wendy Cheng
[not found] ` <message from Wendy Cheng on Tuesday January 15>
2008-01-15 20:50 ` [Cluster-devel] " Neil Brown
2008-01-15 20:50 ` Neil Brown
2008-01-15 20:56 ` [Cluster-devel] " Wendy Cheng
2008-01-15 20:56 ` Wendy Cheng
2008-01-15 22:48 ` [Cluster-devel] " Wendy Cheng
2008-01-15 22:48 ` Wendy Cheng
2008-01-17 15:10 ` [Cluster-devel] " J. Bruce Fields
2008-01-17 15:10 ` J. Bruce Fields
2008-01-17 15:48 ` [Cluster-devel] " Wendy Cheng
2008-01-17 15:48 ` Wendy Cheng
2008-01-17 16:08 ` [Cluster-devel] " Wendy Cheng
2008-01-17 16:08 ` Wendy Cheng
2008-01-17 16:10 ` [Cluster-devel] " Wendy Cheng
2008-01-17 16:10 ` Wendy Cheng
2008-01-18 10:21 ` [Cluster-devel] " Frank van Maarseveen
2008-01-18 10:21 ` Frank van Maarseveen
2008-01-18 15:00 ` [Cluster-devel] " Wendy Cheng
2008-01-18 15:00 ` Wendy Cheng
2008-01-17 16:14 ` [Cluster-devel] " J. Bruce Fields
2008-01-17 16:14 ` J. Bruce Fields
2008-01-17 16:17 ` [Cluster-devel] " Wendy Cheng
2008-01-17 16:17 ` Wendy Cheng
2008-01-17 16:21 ` [Cluster-devel] " J. Bruce Fields
2008-01-17 16:21 ` J. Bruce Fields
2008-01-17 16:31 ` [Cluster-devel] " J. Bruce Fields
2008-01-17 16:31 ` J. Bruce Fields
2008-01-17 16:31 ` [Cluster-devel] " Wendy Cheng
2008-01-17 16:31 ` Wendy Cheng
2008-01-17 16:40 ` [Cluster-devel] " J. Bruce Fields
2008-01-17 16:40 ` J. Bruce Fields
2008-01-17 17:35 ` Frank Filz
2008-01-17 17:59 ` [Cluster-devel] " Wendy Cheng
2008-01-17 17:59 ` Wendy Cheng
2008-01-17 18:07 ` [Cluster-devel] " Wendy Cheng
2008-01-17 18:07 ` Wendy Cheng
2008-01-17 20:23 ` [Cluster-devel] " J. Bruce Fields
2008-01-17 20:23 ` J. Bruce Fields
2008-01-18 10:03 ` [Cluster-devel] " Frank van Maarseveen
2008-01-18 10:03 ` Frank van Maarseveen
2008-01-18 14:56 ` [Cluster-devel] " Wendy Cheng
2008-01-18 14:56 ` Wendy Cheng
2008-01-24 16:00 ` [Cluster-devel] " J. Bruce Fields
2008-01-24 16:00 ` J. Bruce Fields
2008-01-24 16:19 ` Peter Staubach
2008-01-24 16:39 ` [Cluster-devel] " J. Bruce Fields
2008-01-24 16:39 ` J. Bruce Fields
2008-01-24 19:45 ` [Cluster-devel] " Wendy Cheng
2008-01-24 19:45 ` Wendy Cheng
2008-01-24 20:19 ` [Cluster-devel] " J. Bruce Fields
2008-01-24 20:19 ` J. Bruce Fields
2008-01-24 21:06 ` [Cluster-devel] " Wendy Cheng
2008-01-24 21:06 ` Wendy Cheng
2008-01-24 21:40 ` [Cluster-devel] " J. Bruce Fields
2008-01-24 21:40 ` J. Bruce Fields
2008-01-24 21:49 ` [Cluster-devel] " Wendy Cheng
2008-01-24 21:49 ` Wendy Cheng
2008-01-28 3:46 ` [Cluster-devel] " Felix Blyakher
2008-01-28 3:46 ` Felix Blyakher
2008-01-28 15:56 ` [Cluster-devel] " Wendy Cheng
2008-01-28 15:56 ` Wendy Cheng
2008-01-28 17:06 ` [Cluster-devel] " Felix Blyakher
2008-01-28 17:06 ` Felix Blyakher
2008-01-16 4:19 ` Neil Brown
2008-01-16 4:19 ` Neil Brown
2008-01-09 3:49 ` [Cluster-devel] " Wendy Cheng
2008-01-09 3:49 ` Wendy Cheng
2008-01-09 16:13 ` [Cluster-devel] " J. Bruce Fields
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
2008-01-07 5:53 ` 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 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.