From: Arnd Bergmann <arnd@arndb.de>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "David S. Miller" <davem@davemloft.net>,
"Jonas Jensen" <jonas.jensen@gmail.com>,
"Luis de Bethencourt" <luis@debethencourt.com>,
"françois romieu" <romieu@fr.zoreil.com>,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch] net: moxa: fix an error code
Date: Wed, 02 Mar 2016 11:36:05 +0000 [thread overview]
Message-ID: <2743496.LmeGdM2Ipd@wuerfel> (raw)
In-Reply-To: <20160302112129.GQ5273@mwanda>
On Wednesday 02 March 2016 14:21:29 Dan Carpenter wrote:
> On Wed, Mar 02, 2016 at 11:52:29AM +0100, Arnd Bergmann wrote:
> > Did you find more of these?
> >
> > it doesn't matter much either way, but if you do multiple such patches,
>
> One or two. I already sent the fixes. I think it was applied.
>
> > I'd suggest using a single PTR_ERR_OR_ZERO() instead of IS_ERR()+PTR_ERR().
> >
> > I have found a couple of drivers in which that leads to better object
> > code, and avoids a warning about a possibly uninitialized variable
> > when the function gets inlined into another one (which won't happen
> > for this driver).
>
> Huh? I sent one where I could have done that but I deliberately didn't
> because I wanted the uninitialized warning if I made a mistake. It
> sounds like you're working around a GCC bug...
The uninitialized warning here is about a type mismatch preventing
gcc from noticing that two conditions are the same, I'm not sure
if this is a bug in gcc, or required by the C standard.
I don't think there is a way in which you would hide a correct
warning about an uninitialized warning.
Have a look at
https://git.kernel.org/cgit/linux/kernel/git/gfs2/linux-gfs2.git/commit/fs/gfs2?h=for-next&id\acfdc3071432a07713e4d007c2811e0224490b0
in which get_leaf_nr() uses the IS_ERR()/PTR_ERR() combo to return
an error from a pointer, or return success when the pointer was set,
followed by a warning about the use of the pointer in another
function. My original patch avoided the warning by using IS_ERR_VALUE()
in the caller, but in retrospect, IS_ERR_OR_ZERO() would have been
a nicer solution:
@@ -783,12 +783,15 @@ static int get_leaf_nr(struct gfs2_inode *dip, u32 index,
u64 *leaf_out)
{
__be64 *hash;
+ int error;
hash = gfs2_dir_get_hash_table(dip);
- if (IS_ERR(hash))
- return PTR_ERR(hash);
- *leaf_out = be64_to_cpu(*(hash + index));
- return 0;
+ error = PTR_ERR_OR_ZERO(hash);
+
+ if (!error)
+ *leaf_out = be64_to_cpu(*(hash + index));
+
+ return error;
}
and I've used that elsewhere now when I ran into this kind of
false positive warning.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "David S. Miller" <davem@davemloft.net>,
"Jonas Jensen" <jonas.jensen@gmail.com>,
"Luis de Bethencourt" <luis@debethencourt.com>,
"françois romieu" <romieu@fr.zoreil.com>,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch] net: moxa: fix an error code
Date: Wed, 02 Mar 2016 12:36:05 +0100 [thread overview]
Message-ID: <2743496.LmeGdM2Ipd@wuerfel> (raw)
In-Reply-To: <20160302112129.GQ5273@mwanda>
On Wednesday 02 March 2016 14:21:29 Dan Carpenter wrote:
> On Wed, Mar 02, 2016 at 11:52:29AM +0100, Arnd Bergmann wrote:
> > Did you find more of these?
> >
> > it doesn't matter much either way, but if you do multiple such patches,
>
> One or two. I already sent the fixes. I think it was applied.
>
> > I'd suggest using a single PTR_ERR_OR_ZERO() instead of IS_ERR()+PTR_ERR().
> >
> > I have found a couple of drivers in which that leads to better object
> > code, and avoids a warning about a possibly uninitialized variable
> > when the function gets inlined into another one (which won't happen
> > for this driver).
>
> Huh? I sent one where I could have done that but I deliberately didn't
> because I wanted the uninitialized warning if I made a mistake. It
> sounds like you're working around a GCC bug...
The uninitialized warning here is about a type mismatch preventing
gcc from noticing that two conditions are the same, I'm not sure
if this is a bug in gcc, or required by the C standard.
I don't think there is a way in which you would hide a correct
warning about an uninitialized warning.
Have a look at
https://git.kernel.org/cgit/linux/kernel/git/gfs2/linux-gfs2.git/commit/fs/gfs2?h=for-next&id=07cfdc3071432a07713e4d007c2811e0224490b0
in which get_leaf_nr() uses the IS_ERR()/PTR_ERR() combo to return
an error from a pointer, or return success when the pointer was set,
followed by a warning about the use of the pointer in another
function. My original patch avoided the warning by using IS_ERR_VALUE()
in the caller, but in retrospect, IS_ERR_OR_ZERO() would have been
a nicer solution:
@@ -783,12 +783,15 @@ static int get_leaf_nr(struct gfs2_inode *dip, u32 index,
u64 *leaf_out)
{
__be64 *hash;
+ int error;
hash = gfs2_dir_get_hash_table(dip);
- if (IS_ERR(hash))
- return PTR_ERR(hash);
- *leaf_out = be64_to_cpu(*(hash + index));
- return 0;
+ error = PTR_ERR_OR_ZERO(hash);
+
+ if (!error)
+ *leaf_out = be64_to_cpu(*(hash + index));
+
+ return error;
}
and I've used that elsewhere now when I ran into this kind of
false positive warning.
Arnd
next prev parent reply other threads:[~2016-03-02 11:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 10:11 [patch] net: moxa: fix an error code Dan Carpenter
2016-03-02 10:11 ` Dan Carpenter
2016-03-02 10:52 ` Arnd Bergmann
2016-03-02 10:52 ` Arnd Bergmann
2016-03-02 11:21 ` Dan Carpenter
2016-03-02 11:21 ` Dan Carpenter
2016-03-02 11:36 ` Arnd Bergmann [this message]
2016-03-02 11:36 ` Arnd Bergmann
2016-03-02 12:15 ` Dan Carpenter
2016-03-02 12:15 ` Dan Carpenter
2016-03-02 12:42 ` Arnd Bergmann
2016-03-02 12:42 ` Arnd Bergmann
2016-03-03 22:17 ` David Miller
2016-03-03 22:17 ` David Miller
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=2743496.LmeGdM2Ipd@wuerfel \
--to=arnd@arndb.de \
--cc=dan.carpenter@oracle.com \
--cc=davem@davemloft.net \
--cc=jonas.jensen@gmail.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=luis@debethencourt.com \
--cc=netdev@vger.kernel.org \
--cc=romieu@fr.zoreil.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.