All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Trond Myklebust <trond.myklebust@primarydata.com>,
	Anna Schumaker <anna.schumaker@netapp.com>
Cc: netdev@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 1/2] NFSv4.1: work around -Wmaybe-uninitialized warning
Date: Wed, 31 Aug 2016 14:39:01 +0200	[thread overview]
Message-ID: <20160831123911.3467676-1-arnd@arndb.de> (raw)

A bugfix introduced a harmless gcc warning in nfs4_slot_seqid_in_use:

fs/nfs/nfs4session.c:203:54: error: 'cur_seq' may be used uninitialized in this function [-Werror=maybe-uninitialized]

gcc is not smart enough to conclude that the IS_ERR/PTR_ERR pair
results in a nonzero return value here. Using PTR_ERR_OR_ZERO()
instead makes this clear to the compiler.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: e09c978aae5b ("NFSv4.1: Fix Oopsable condition in server callback races")
---
 fs/nfs/nfs4session.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

The patch that caused this just came in for v4.8-rc5. As the warning
is now disabled by default and this is harmless, this can probably
get queued for v4.9 instead.

I mentioned earlier that I got the new warning for net-next, but
failed to notice that it had come from mainline instead.

diff --git a/fs/nfs/nfs4session.c b/fs/nfs/nfs4session.c
index b62973045a3e..150c5a1879bf 100644
--- a/fs/nfs/nfs4session.c
+++ b/fs/nfs/nfs4session.c
@@ -178,12 +178,14 @@ static int nfs4_slot_get_seqid(struct nfs4_slot_table  *tbl, u32 slotid,
 	__must_hold(&tbl->slot_tbl_lock)
 {
 	struct nfs4_slot *slot;
+	int ret;
 
 	slot = nfs4_lookup_slot(tbl, slotid);
-	if (IS_ERR(slot))
-		return PTR_ERR(slot);
-	*seq_nr = slot->seq_nr;
-	return 0;
+	ret = PTR_ERR_OR_ZERO(slot);
+	if (!ret)
+		*seq_nr = slot->seq_nr;
+
+	return ret;
 }
 
 /*
-- 
2.9.0

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Trond Myklebust
	<trond.myklebust-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>,
	Anna Schumaker
	<anna.schumaker-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [PATCH 1/2] NFSv4.1: work around -Wmaybe-uninitialized warning
Date: Wed, 31 Aug 2016 14:39:01 +0200	[thread overview]
Message-ID: <20160831123911.3467676-1-arnd@arndb.de> (raw)

A bugfix introduced a harmless gcc warning in nfs4_slot_seqid_in_use:

fs/nfs/nfs4session.c:203:54: error: 'cur_seq' may be used uninitialized in this function [-Werror=maybe-uninitialized]

gcc is not smart enough to conclude that the IS_ERR/PTR_ERR pair
results in a nonzero return value here. Using PTR_ERR_OR_ZERO()
instead makes this clear to the compiler.

Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Fixes: e09c978aae5b ("NFSv4.1: Fix Oopsable condition in server callback races")
---
 fs/nfs/nfs4session.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

The patch that caused this just came in for v4.8-rc5. As the warning
is now disabled by default and this is harmless, this can probably
get queued for v4.9 instead.

I mentioned earlier that I got the new warning for net-next, but
failed to notice that it had come from mainline instead.

diff --git a/fs/nfs/nfs4session.c b/fs/nfs/nfs4session.c
index b62973045a3e..150c5a1879bf 100644
--- a/fs/nfs/nfs4session.c
+++ b/fs/nfs/nfs4session.c
@@ -178,12 +178,14 @@ static int nfs4_slot_get_seqid(struct nfs4_slot_table  *tbl, u32 slotid,
 	__must_hold(&tbl->slot_tbl_lock)
 {
 	struct nfs4_slot *slot;
+	int ret;
 
 	slot = nfs4_lookup_slot(tbl, slotid);
-	if (IS_ERR(slot))
-		return PTR_ERR(slot);
-	*seq_nr = slot->seq_nr;
-	return 0;
+	ret = PTR_ERR_OR_ZERO(slot);
+	if (!ret)
+		*seq_nr = slot->seq_nr;
+
+	return ret;
 }
 
 /*
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2016-08-31 12:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-31 12:39 Arnd Bergmann [this message]
2016-08-31 12:39 ` [PATCH 1/2] NFSv4.1: work around -Wmaybe-uninitialized warning Arnd Bergmann
2016-08-31 12:39 ` [PATCH 2/2] rxrpc: fix undefined behavior in rxrpc_mark_call_released Arnd Bergmann
2016-08-31 13:17 ` [PATCH 1/2] NFSv4.1: work around -Wmaybe-uninitialized warning Trond Myklebust
2016-08-31 13:17   ` Trond Myklebust
2016-08-31 13:37   ` Arnd Bergmann
2016-08-31 13:37     ` Arnd Bergmann
2016-08-31 15:02     ` Trond Myklebust
2016-08-31 15:02       ` Trond Myklebust
2016-08-31 15:02       ` Trond Myklebust
2016-08-31 15:52       ` Arnd Bergmann
2016-08-31 17:39 ` [PATCH 2/2] rxrpc: fix undefined behavior in rxrpc_mark_call_released David Howells
2016-08-31 19:40   ` Arnd Bergmann
2016-08-31 20:25 ` David Howells
2016-08-31 20:31   ` Arnd Bergmann
2016-08-31 20:52   ` David Miller
2016-08-31 20:26 ` David Howells
2016-08-31 20:37   ` Arnd Bergmann
2016-08-31 21:05   ` David Howells

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=20160831123911.3467676-1-arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=anna.schumaker@netapp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=trond.myklebust@primarydata.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.