Messages in this thread | | | From | Jon Maloy <> | Subject | RE: -Wsometimes-uninitialized Clang warning in net/tipc/node.c | Date | Thu, 21 Mar 2019 19:49:55 +0000 |
| |
> -----Original Message----- > From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> > On Behalf Of Arnd Bergmann > Sent: 21-Mar-19 19:23 > To: Jon Maloy <jon.maloy@ericsson.com> > Cc: Nick Desaulniers <ndesaulniers@google.com>; Nathan Chancellor > <natechancellor@gmail.com>; Ying Xue <ying.xue@windriver.com>; David S. > Miller <davem@davemloft.net>; tipc-discussion@lists.sourceforge.net; > Networking <netdev@vger.kernel.org>; LKML <linux- > kernel@vger.kernel.org>; clang-built-linux@googlegroups.com > Subject: Re: -Wsometimes-uninitialized Clang warning in net/tipc/node.c > > On Thu, Mar 21, 2019 at 4:25 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > > On Thu, Mar 21, 2019 at 3:57 PM Jon Maloy <jon.maloy@ericsson.com> > wrote: > > > > > > > > > diff --git a/net/tipc/node.c b/net/tipc/node.c index > > > > 2dc4919ab23c..147786795e48 100644 > > > > --- a/net/tipc/node.c > > > > +++ b/net/tipc/node.c > > > > @@ -844,7 +844,8 @@ static void tipc_node_link_down(struct > > > > tipc_node *n, int bearer_id, bool delete) > > > > tipc_node_write_unlock(n); > > > > if (delete) > > > > tipc_mon_remove_peer(n->net, n->addr, old_bearer_id); > > > > - tipc_bearer_xmit(n->net, bearer_id, &xmitq, maddr); > > > > + if (skb_queue_empty(xmitq)) > > > > + tipc_bearer_xmit(n->net, bearer_id, &xmitq, > > > > + maddr); > > > > tipc_sk_rcv(n->net, &le->inputq); } > > > > > > > > This duplicates the check inside of skb_queue_empty(), but I don't > > > > know if the compiler can see through the logic behind the inlined > function calls. > > > > > > Probably not, but this is not in any way time critical. > > > > I meant it's unclear whether compilers should be expected to see that > > skb_queue_empty() is true after the call to __skb_queue_head_init() > > initializes it. > > I reproduced the warning now, and verified that my change eliminates the > warning. I still think that is the more logical solution here.
Ok. No problems with that.
///jon
> > Arnd
| |