Re: drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c:173 mlx5_fc_stats_query_all_counters() error: uninitialized symbol 'bulk_query_time'.
From: Cosmin Ratiu
Date: Mon Dec 09 2024 - 05:10:21 EST
On Mon, 2024-12-09 at 09:20 +0300, Dan Carpenter wrote:
> tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ma
> ster
> head: b5f217084ab3ddd4bdd03cd437f8e3b7e2d1f5b6
> commit: 918af0219a4d6a89cf02839005ede24e91f13bf6 net/mlx5: hw
> counters: Replace IDR+lists with xarray
> config: openrisc-randconfig-r072-20241206
> (https://download.01.org/0day-ci/archive/20241207/202412071312.oNFnyT
> 9f-lkp@xxxxxxxxx/config)
> compiler: or1k-linux-gcc (GCC) 14.2.0
>
> 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@xxxxxxxxx>
> > Reported-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
> > Closes:
> > https://lore.kernel.org/r/202412071312.oNFnyT9f-lkp@xxxxxxxxx/
>
> smatch warnings:
> drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c:173
> mlx5_fc_stats_query_all_counters() error: uninitialized symbol
> 'bulk_query_time'.
> drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c:174
> mlx5_fc_stats_query_all_counters() error: uninitialized symbol
> 'bulk_base_id'.
>
> vim +/bulk_query_time +173
> drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
>
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 138 static void
> mlx5_fc_stats_query_all_counters(struct mlx5_core_dev *dev)
> a351a1b03bf169f Amir Vadai 2016-07-14 139 {
> 5acd957a986c167 Cosmin Ratiu 2024-10-01 140 struct mlx5_fc_stats
> *fc_stats = dev->priv.fc_stats;
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 141 u32 bulk_len =
> fc_stats->bulk_query_len;
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 142 XA_STATE(xas,
> &fc_stats->counters, 0);
> 6f06e04b67baa1c Gavi Teitz 2019-07-29 143 u32 *data =
> fc_stats->bulk_query_out;
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 144 struct mlx5_fc
> *counter;
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 145 u32 last_bulk_id =
> 0;
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 146 u64 bulk_query_time;
> 6f06e04b67baa1c Gavi Teitz 2019-07-29 147 u32 bulk_base_id;
> a351a1b03bf169f Amir Vadai 2016-07-14 148 int err;
> a8ffcc741acb3c7 Rabie Loulou 2017-07-09 149
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 150 xas_lock(&xas);
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 151 xas_for_each(&xas,
> counter, U32_MAX) {
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 152 if
> (xas_retry(&xas, counter))
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01
> 153 continue;
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 154 if
> (unlikely(counter->id >= last_bulk_id)) {
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 155 /*
> Start new bulk query. */
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 156 /*
> First id must be aligned to 4 when using bulk query. */
> 6f06e04b67baa1c Gavi Teitz 2019-07-29
> 157 bulk_base_id = counter->id & ~0x3;
>
> ^^^^^^^^^^^^
>
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01
> 158 last_bulk_id = bulk_base_id + bulk_len;
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 159 /*
> The lock is released while querying the hw and reacquired after. */
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01
> 160 xas_unlock(&xas);
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 161 /*
> The same id needs to be processed again in the next loop iteration.
> */
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01
> 162 xas_reset(&xas);
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01
> 163 bulk_query_time = jiffies;
>
> bulk_query_time is only initialized on this path which is marked as
> unlikely()
> and not initialized on the else statement.
>
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 164 err
> = mlx5_cmd_fc_bulk_query(dev, bulk_base_id, bulk_len, data);
> a351a1b03bf169f Amir Vadai 2016-07-14 165 if
> (err) {
> a351a1b03bf169f Amir Vadai 2016-07-14
> 166 mlx5_core_err(dev, "Error doing bulk query: %d\n", err);
> 6f06e04b67baa1c Gavi Teitz 2019-07-29
> 167 return;
> a351a1b03bf169f Amir Vadai 2016-07-14 168 }
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01
> 169 xas_lock(&xas);
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01
> 170 continue;
> 6f06e04b67baa1c Gavi Teitz 2019-07-29 171 }
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 172 /* Do not
> update counters added after bulk query was started. */
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 @173 if
> (time_after64(bulk_query_time, counter->cache.lastuse))
>
> ^^^^^^^^^^^^^^^
>
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01
> @174 update_counter_cache(counter->id - bulk_base_id, data,
>
> ^^^^^^^^^^^^
>
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01
> 175 &counter->cache);
> a351a1b03bf169f Amir Vadai 2016-07-14 176 }
> 918af0219a4d6a8 Cosmin Ratiu 2024-10-01 177 xas_unlock(&xas);
> a351a1b03bf169f Amir Vadai 2016-07-14 178 }
>
Hi Dan,
Thanks for the report. But this came up during the submission and the
conclusion was that this is a false positive from Smatch.
See the discussions:
https://lore.kernel.org/netdev/0dce2c1d2f8adccbfbff39118af9796d84404a67.camel@xxxxxxxxxx/
https://lore.kernel.org/netdev/66ccbb841794c98b91d9e8aba48b90c63caa45e7.camel@xxxxxxxxxx/
You were also part of that thread and you reported no issue on your
side back then:
https://lore.kernel.org/netdev/fcecb18a-1a30-400d-b8ec-1806d856d145@stanley.mountain/
I am not sure what the conclusion was on the Smatch side, whether there
were planned fixes or the whole thing was just forgotten.
Cosmin.