| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <cb0cf353ec927f21a8f12830605834709b1ee338.camel@oracle.com>
Date: Wed, 5 Mar 2025 00:43:34 +0000
From: Allison Henderson <allison.henderson@...cle.com>
To: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"lkp@...el.com"
<lkp@...el.com>
CC: "llvm@...ts.linux.dev" <llvm@...ts.linux.dev>,
"oe-kbuild-all@...ts.linux.dev" <oe-kbuild-all@...ts.linux.dev>
Subject: Re: [PATCH 5/6] net/rds: rds_tcp_accept_one ought to not discard
messages
On Sun, 2025-03-02 at 07:22 +0800, kernel test robot wrote:
> Hi,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on net/main]
> [also build test WARNING on net-next/main linus/master v6.14-rc4 next-20250228]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://urldefense.com/v3/__https://git-scm.com/docs/git-format-patch*_base_tree_information__;Iw!!ACWV5N9M2RV99hQ!N3fhQzk3WA-OAbKUbFqZo2JRgVJCSPX22UjSEDrigRVQ8QvFOo479ljGaZ4Xkdig5e4AXzn-C8voWMQ$ ]
>
> url: https://urldefense.com/v3/__https://github.com/intel-lab-lkp/linux/commits/allison-henderson-oracle-com/net-rds-Avoid-queuing-superfluous-send-and-recv-work/20250227-123038__;!!ACWV5N9M2RV99hQ!N3fhQzk3WA-OAbKUbFqZo2JRgVJCSPX22UjSEDrigRVQ8QvFOo479ljGaZ4Xkdig5e4AXzn-YEva8Ys$
> base: net/main
> patch link: https://urldefense.com/v3/__https://lore.kernel.org/r/20250227042638.82553-6-allison.henderson*40oracle.com__;JQ!!ACWV5N9M2RV99hQ!N3fhQzk3WA-OAbKUbFqZo2JRgVJCSPX22UjSEDrigRVQ8QvFOo479ljGaZ4Xkdig5e4AXzn-O0k5mu0$
> patch subject: [PATCH 5/6] net/rds: rds_tcp_accept_one ought to not discard messages
> config: riscv-randconfig-002-20250302 (https://urldefense.com/v3/__https://download.01.org/0day-ci/archive/20250302/202503020739.xWWyG7zO-lkp@intel.com/config__;!!ACWV5N9M2RV99hQ!N3fhQzk3WA-OAbKUbFqZo2JRgVJCSPX22UjSEDrigRVQ8QvFOo479ljGaZ4Xkdig5e4AXzn-4P6Kfjw$ )
> compiler: clang version 16.0.6 (https://urldefense.com/v3/__https://github.com/llvm/llvm-project__;!!ACWV5N9M2RV99hQ!N3fhQzk3WA-OAbKUbFqZo2JRgVJCSPX22UjSEDrigRVQ8QvFOo479ljGaZ4Xkdig5e4AXzn-p4RKZfU$ 7cbf1a2591520c2491aa35339f227775f4d3adf6)
> reproduce (this is a W=1 build): (https://urldefense.com/v3/__https://download.01.org/0day-ci/archive/20250302/202503020739.xWWyG7zO-lkp@intel.com/reproduce__;!!ACWV5N9M2RV99hQ!N3fhQzk3WA-OAbKUbFqZo2JRgVJCSPX22UjSEDrigRVQ8QvFOo479ljGaZ4Xkdig5e4AXzn-3tTQLjw$ )
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> > Reported-by: kernel test robot <lkp@...el.com>
> > Closes: https://urldefense.com/v3/__https://lore.kernel.org/oe-kbuild-all/202503020739.xWWyG7zO-lkp@intel.com/__;!!ACWV5N9M2RV99hQ!N3fhQzk3WA-OAbKUbFqZo2JRgVJCSPX22UjSEDrigRVQ8QvFOo479ljGaZ4Xkdig5e4AXzn-gr3kV7I$
>
> All warnings (new ones prefixed by >>):
>
> > > net/rds/tcp_listen.c:137:6: warning: variable 'inet' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
> if (!new_sock) {
> ^~~~~~~~~
> net/rds/tcp_listen.c:179:19: note: uninitialized use occurs here
> my_addr, ntohs(inet->inet_sport),
> ^~~~
> include/linux/byteorder/generic.h:142:27: note: expanded from macro 'ntohs'
> #define ntohs(x) ___ntohs(x)
> ^
> include/linux/byteorder/generic.h:137:35: note: expanded from macro '___ntohs'
> #define ___ntohs(x) __be16_to_cpu(x)
> ^
> include/uapi/linux/byteorder/little_endian.h:43:59: note: expanded from macro '__be16_to_cpu'
> #define __be16_to_cpu(x) __swab16((__force __u16)(__be16)(x))
> ^
> include/uapi/linux/swab.h:105:31: note: expanded from macro '__swab16'
> (__u16)(__builtin_constant_p(x) ? \
> ^
> net/rds/tcp_listen.c:137:2: note: remove the 'if' if its condition is always true
> if (!new_sock) {
> ^~~~~~~~~~~~~~~
> net/rds/tcp_listen.c:115:24: note: initialize the variable 'inet' to silence this warning
> struct inet_sock *inet;
> ^
> = NULL
> 1 warning generated.
>
>
> vim +137 net/rds/tcp_listen.c
>
> 108
> 109 int rds_tcp_accept_one(struct rds_tcp_net *rtn)
> 110 {
> 111 struct socket *listen_sock = rtn->rds_tcp_listen_sock;
> 112 struct socket *new_sock = NULL;
> 113 struct rds_connection *conn;
> 114 int ret;
> 115 struct inet_sock *inet;
> 116 struct rds_tcp_connection *rs_tcp = NULL;
> 117 int conn_state;
> 118 struct rds_conn_path *cp;
> 119 struct in6_addr *my_addr, *peer_addr;
> 120 struct proto_accept_arg arg = {
> 121 .flags = O_NONBLOCK,
> 122 .kern = true,
> 123 };
> 124 #if !IS_ENABLED(CONFIG_IPV6)
> 125 struct in6_addr saddr, daddr;
> 126 #endif
> 127 int dev_if = 0;
> 128
> 129 mutex_lock(&rtn->rds_tcp_accept_lock);
> 130
> 131 if (!listen_sock)
> 132 return -ENETUNREACH;
> 133
> 134 new_sock = rtn->rds_tcp_accepted_sock;
> 135 rtn->rds_tcp_accepted_sock = NULL;
> 136
> > 137 if (!new_sock) {
> 138 ret = sock_create_lite(listen_sock->sk->sk_family,
> 139 listen_sock->sk->sk_type,
> 140 listen_sock->sk->sk_protocol,
> 141 &new_sock);
> 142 if (ret)
> 143 goto out;
> 144
> 145 ret = listen_sock->ops->accept(listen_sock, new_sock, &arg);
> 146 if (ret < 0)
> 147 goto out;
> 148
> 149 /* sock_create_lite() does not get a hold on the owner module so we
> 150 * need to do it here. Note that sock_release() uses sock->ops to
> 151 * determine if it needs to decrement the reference count. So set
> 152 * sock->ops after calling accept() in case that fails. And there's
> 153 * no need to do try_module_get() as the listener should have a hold
> 154 * already.
> 155 */
> 156 new_sock->ops = listen_sock->ops;
> 157 __module_get(new_sock->ops->owner);
> 158
> 159 rds_tcp_keepalive(new_sock);
> 160 if (!rds_tcp_tune(new_sock)) {
> 161 ret = -EINVAL;
> 162 goto out;
> 163 }
> 164
> 165 inet = inet_sk(new_sock->sk);
> 166 }
I think just moving the inet assignment below the last bracket here should correct this warning. Will fix :-)
Thanks!
Allison
> 167
>
Powered by blists - more mailing lists