From: Dan Carpenter <dan.carpenter@linaro.org>
To: Simon Horman <horms@kernel.org>
Cc: Tariq Toukan <tariqt@nvidia.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org, Saeed Mahameed <saeedm@nvidia.com>,
Gal Pressman <gal@nvidia.com>,
Leon Romanovsky <leonro@nvidia.com>,
Cosmin Ratiu <cratiu@nvidia.com>
Subject: Re: [PATCH net-next 03/10] net/mlx5: hw counters: Replace IDR+lists with xarray
Date: Tue, 27 Aug 2024 18:27:51 +0300 [thread overview]
Message-ID: <fcecb18a-1a30-400d-b8ec-1806d856d145@stanley.mountain> (raw)
In-Reply-To: <20240815134425.GD632411@kernel.org>
On Thu, Aug 15, 2024 at 02:44:25PM +0100, Simon Horman wrote:
> On Thu, Aug 15, 2024 at 08:46:49AM +0300, Tariq Toukan wrote:
>
> ...
>
> > +/* Synchronization notes
> > + *
> > + * Access to counter array:
> > + * - create - mlx5_fc_create() (user context)
> > + * - inserts the counter into the xarray.
> > + *
> > + * - destroy - mlx5_fc_destroy() (user context)
> > + * - erases the counter from the xarray and releases it.
> > + *
> > + * - query mlx5_fc_query(), mlx5_fc_query_cached{,_raw}() (user context)
> > + * - user should not access a counter after destroy.
> > + *
> > + * - bulk query (single thread workqueue context)
> > + * - create: query relies on 'lastuse' to avoid updating counters added
> > + * around the same time as the current bulk cmd.
> > + * - destroy: destroyed counters will not be accessed, even if they are
> > + * destroyed during a bulk query command.
> > + */
> > +static void mlx5_fc_stats_query_all_counters(struct mlx5_core_dev *dev)
> > {
> > struct mlx5_fc_stats *fc_stats = dev->priv.fc_stats;
> > - bool query_more_counters = (first->id <= last_id);
> > - int cur_bulk_len = fc_stats->bulk_query_len;
> > + u32 bulk_len = fc_stats->bulk_query_len;
> > + XA_STATE(xas, &fc_stats->counters, 0);
> > u32 *data = fc_stats->bulk_query_out;
> > - struct mlx5_fc *counter = first;
> > + struct mlx5_fc *counter;
> > + u32 last_bulk_id = 0;
> > + u64 bulk_query_time;
> > u32 bulk_base_id;
> > - int bulk_len;
> > int err;
> >
> > - while (query_more_counters) {
> > - /* first id must be aligned to 4 when using bulk query */
> > - bulk_base_id = counter->id & ~0x3;
> > -
> > - /* number of counters to query inc. the last counter */
> > - bulk_len = min_t(int, cur_bulk_len,
> > - ALIGN(last_id - bulk_base_id + 1, 4));
> > -
> > - err = mlx5_cmd_fc_bulk_query(dev, bulk_base_id, bulk_len,
> > - data);
> > - if (err) {
> > - mlx5_core_err(dev, "Error doing bulk query: %d\n", err);
> > - return;
> > - }
> > - query_more_counters = false;
> > -
> > - list_for_each_entry_from(counter, &fc_stats->counters, list) {
> > - int counter_index = counter->id - bulk_base_id;
> > - struct mlx5_fc_cache *cache = &counter->cache;
> > -
> > - if (counter->id >= bulk_base_id + bulk_len) {
> > - query_more_counters = true;
> > - break;
> > + xas_lock(&xas);
> > + xas_for_each(&xas, counter, U32_MAX) {
> > + if (xas_retry(&xas, counter))
> > + continue;
> > + if (unlikely(counter->id >= last_bulk_id)) {
> > + /* Start new bulk query. */
> > + /* First id must be aligned to 4 when using bulk query. */
> > + bulk_base_id = counter->id & ~0x3;
> > + last_bulk_id = bulk_base_id + bulk_len;
> > + /* The lock is released while querying the hw and reacquired after. */
> > + xas_unlock(&xas);
> > + /* The same id needs to be processed again in the next loop iteration. */
> > + xas_reset(&xas);
> > + bulk_query_time = jiffies;
> > + err = mlx5_cmd_fc_bulk_query(dev, bulk_base_id, bulk_len, data);
> > + if (err) {
> > + mlx5_core_err(dev, "Error doing bulk query: %d\n", err);
> > + return;
> > }
> > -
> > - update_counter_cache(counter_index, data, cache);
> > + xas_lock(&xas);
> > + continue;
> > }
> > + /* Do not update counters added after bulk query was started. */
>
> Hi Cosmin and Tariq,
>
> It looks like bulk_query_time and bulk_base_id may be uninitialised or
> stale - from a previous loop iteration - if the condition above is not met.
>
> Flagged by Smatch.
I don't see this warning on my end. For me what Smatch says is that
last_bulk_id is 0U so the "counter->id >= last_bulk_id" condition is true.
Smatch doesn't warn about the uninitialized varabiable because it appears to
smatch to be in dead code. In other words smatch is doing the correct thing but
for the wrong reasons. :/
I've tested on the released code and I'm not seing this warning.
regards,
dan carpenter
next prev parent reply other threads:[~2024-08-27 15:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-15 5:46 [PATCH net-next 00/10] net/mlx5: hw counters refactor and misc Tariq Toukan
2024-08-15 5:46 ` [PATCH net-next 01/10] net/mlx5: hw counters: Make fc_stats & fc_pool private Tariq Toukan
2024-08-15 5:46 ` [PATCH net-next 02/10] net/mlx5: hw counters: Use kvmalloc for bulk query buffer Tariq Toukan
2024-08-15 5:46 ` [PATCH net-next 03/10] net/mlx5: hw counters: Replace IDR+lists with xarray Tariq Toukan
2024-08-15 13:44 ` Simon Horman
2024-08-27 11:14 ` Cosmin Ratiu
2024-08-27 15:01 ` Simon Horman
2024-08-27 15:20 ` Simon Horman
2024-08-29 23:20 ` Saeed Mahameed
2024-08-30 2:20 ` Jakub Kicinski
2024-08-27 15:27 ` Dan Carpenter [this message]
2024-08-15 5:46 ` [PATCH net-next 04/10] net/mlx5: hw counters: Drop unneeded cacheline alignment Tariq Toukan
2024-08-15 5:46 ` [PATCH net-next 05/10] net/mlx5: hw counters: Don't maintain a counter count Tariq Toukan
2024-08-15 5:46 ` [PATCH net-next 06/10] net/mlx5: hw counters: Remove mlx5_fc_create_ex Tariq Toukan
2024-08-15 5:46 ` [PATCH net-next 07/10] net/mlx5: Allow users to configure affinity for SFs Tariq Toukan
2024-08-15 5:46 ` [PATCH net-next 08/10] net/mlx5: Add NOT_READY command return status Tariq Toukan
2024-08-15 5:46 ` [PATCH net-next 09/10] net/mlx5e: SHAMPO, Add no-split ethtool counters for header/data split Tariq Toukan
2024-08-15 5:46 ` [PATCH net-next 10/10] net/mlx5e: Match cleanup order in mlx5e_free_rq in reverse of mlx5e_alloc_rq Tariq Toukan
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=fcecb18a-1a30-400d-b8ec-1806d856d145@stanley.mountain \
--to=dan.carpenter@linaro.org \
--cc=cratiu@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=leonro@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox