From: Bob Peterson <rpeterso@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 PATCH] GFS2: Fix up some sparse warnings
Date: Tue, 22 Aug 2017 15:54:14 -0400 (EDT) [thread overview]
Message-ID: <58198541.947848.1503431654929.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20170818155159.GC12296@cicero>
Hi Andy,
Comments inline.
----- Original Message -----
| On Fri, Aug 18, 2017 at 10:20:56AM -0400, Bob Peterson wrote:
| > Hi,
| >
| > This patch cleans up various pieces of GFS2 to avoid sparse errors.
| > This doesn't fix them all, but it fixes several. The first error,
| > in function glock_hash_walk was a genuine bug where the rhashtable
| > could be started and not stopped.
| >
| > Signed-off-by: Bob Peterson <rpeterso@redhat.com>
| > ---
| > diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
| > index ffca19598525..db78720f3c89 100644
| > --- a/fs/gfs2/glock.c
| > +++ b/fs/gfs2/glock.c
| > @@ -1550,14 +1550,13 @@ static void glock_hash_walk(glock_examiner
| > examiner, const struct gfs2_sbd *sdp)
| >
| > do {
| > gl = ERR_PTR(rhashtable_walk_start(&iter));
|
| Couldn't the rhashtable_walk_start() call be moved before the outer loop?
|
| "* Returns -EAGAIN if resize event occured. Note that the iterator
| * will rewind back to the beginning and you may use it immediately
| * by calling rhashtable_walk_next."
|
| so it looks like -EAGAIN doesn't require a stop and restart of the walk.
Yes, I'm pretty sure you're right. I could (and should) re-factor this
and straighten it out. However, my goal with this set of patches was
to not change the logic at all, and in today's code, it's inside the loop.
| > - if (gl)
| > - continue;
| > -
| > - while ((gl = rhashtable_walk_next(&iter)) && !IS_ERR(gl))
| > - if ((gl->gl_name.ln_sbd == sdp) &&
| > - lockref_get_not_dead(&gl->gl_lockref))
| > - examiner(gl);
| > -
| > + if (!gl) {
|
| This looks like it should be if (!IS_ERR(gl)) { ...
Here again, the original was "if (gl)" and I didn't want to change it,
so it becomes "if (gl) {". Again, I think I need to change it, but
perhaps in another patch that targets this function, especially since
it can't return anything other than 0 or -EAGAIN.
| > + while ((gl = rhashtable_walk_next(&iter)) &&
| > + !IS_ERR(gl))
| > + if ((gl->gl_name.ln_sbd == sdp) &&
| > + lockref_get_not_dead(&gl->gl_lockref))
| > + examiner(gl);
| > + }
| > rhashtable_walk_stop(&iter);
So I propose I push this patch "as is" and write another patch to re-work
function glock_hash_walk so it cleans up the issues you pointed out and
makes more logical sense.
Regards,
Bob Peterson
Red Hat File Systems
next prev parent reply other threads:[~2017-08-22 19:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1809292291.1872363.1503065998850.JavaMail.zimbra@redhat.com>
2017-08-18 14:20 ` [Cluster-devel] [GFS2 PATCH] GFS2: Fix up some sparse warnings Bob Peterson
2017-08-18 15:52 ` Andrew Price
2017-08-22 19:54 ` Bob Peterson [this message]
2017-08-23 15:27 ` [Cluster-devel] [GFS2 PATCH] [v2] " Bob Peterson
2017-08-23 16:19 ` Andrew Price
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=58198541.947848.1503431654929.JavaMail.zimbra@redhat.com \
--to=rpeterso@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).