Re: drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c:173 mlx5_fc_stats_query_all_counters() error: uninitialized symbol 'bulk_query_time'.

[Cosmin Ratiu <cratiu@nvidia.com>]

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@intel.com/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@intel.com>
> > Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> > Closes:
> > https://lore.kernel.org/r/202412071312.oNFnyT9f-lkp@intel.com/
> 
> 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@nvidia.com/
https://lore.kernel.org/netdev/66ccbb841794c98b91d9e8aba48b90c63caa45e7.camel@nvidia.com/
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.