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 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.