netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Poirier <bpoirier@suse.de>
To: Ido Shamay <idos@dev.mellanox.co.il>
Cc: Amir Vadai <amirv@mellanox.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mlx4: Fix tx ring affinity_mask creation
Date: Mon, 13 Apr 2015 17:22:56 -0700	[thread overview]
Message-ID: <20150414002256.GA22775@f1.synalogic.ca> (raw)
In-Reply-To: <552A18A8.1040109@dev.mellanox.co.il>

On 2015/04/12 10:03, Ido Shamay wrote:
> Hi Benjamin,
> 
> On 4/10/2015 7:27 PM, Benjamin Poirier wrote:
> >By default, the number of tx queues is limited by the number of online cpus in
> >mlx4_en_get_profile(). However, this limit no longer holds after the ethtool
> >.set_channels method has been called. In that situation, the driver may access
> >invalid bits of certain cpumask variables when queue_index > nr_cpu_ids.
> 
> I must say I don't see the above issue with the current code.
> Whatever is the modified value of priv->num_tx_rings_p_up, it will set XPS
> only on queues which have
> been set with CPU affinity mask (no access to invalid bits).

The problem is not with the call to netif_set_xps_queue() it is with the
calls to cpu_online() and cpumask_set_cpu().

For example, if the user calls `ethtool -L ethX tx 32`, queue_index in
mlx4_en_create_tx_ring() can be up to 255. Depending on CONFIG_NR_CPUS
and CONFIG_CPUMASK_OFFSTACK this may result in calls to cpu_online() and
cpumask_set_cpu() with cpu >= nr_cpumask_bits which is an invalid usage
of the cpumask api. The driver will potentially read or write beyond the
end of the bitmap. With CONFIG_CPUMASK_OFFSTACK=y and
CONFIG_DEBUG_PER_CPU_MAPS=y, the aforementioned ethtool call on a system
with <32 cpus triggers the warning in cpumask_check(). 

> 
> It's true that when priv->num_tx_rings_p_up > nr_cpus. not all queues will
> be set with XPS.
> This is because the code tries to preserve 1:1 mapping of queues to cores,
> to avoid a double mapping
> of queues to cores.
> I guess it's ok to break the 1:1 mapping in this condition, but the commit
> message should say that instead
> of invalid bits. Please fix me if I'm wrong.
> 
> >Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
> >---
> >  drivers/net/ethernet/mellanox/mlx4/en_tx.c | 8 +++++---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> >index 55f9f5c..8c234ec 100644
> >--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> >+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> >@@ -143,8 +143,10 @@ int mlx4_en_create_tx_ring(struct mlx4_en_priv *priv,
> >  	ring->hwtstamp_tx_type = priv->hwtstamp_config.tx_type;
> >  	ring->queue_index = queue_index;
> >-	if (queue_index < priv->num_tx_rings_p_up && cpu_online(queue_index))
> >-		cpumask_set_cpu(queue_index, &ring->affinity_mask);
> >+	if (queue_index < priv->num_tx_rings_p_up)
> >+			cpumask_set_cpu_local_first(queue_index,
> >+					    priv->mdev->dev->numa_node,
> >+					    &ring->affinity_mask);
> Moving from cpumask_set_cpu to cpumask_set_cpu_local_first is great, but
> should come in a different commit, since
> the behavior of the XPS is changed here (xps_cpus[tx_ring[queue_index]] !=
> queue_index from now).
> Commit should state of this behavior change.
> Thanks a lot Benjamin.
> >  	*pring = ring;
> >  	return 0;
> >@@ -213,7 +215,7 @@ int mlx4_en_activate_tx_ring(struct mlx4_en_priv *priv,
> >  	err = mlx4_qp_to_ready(mdev->dev, &ring->wqres.mtt, &ring->context,
> >  			       &ring->qp, &ring->qp_state);
> >-	if (!user_prio && cpu_online(ring->queue_index))
> >+	if (!cpumask_empty(&ring->affinity_mask))
> >  		netif_set_xps_queue(priv->dev, &ring->affinity_mask,
> >  				    ring->queue_index);
> 

  reply	other threads:[~2015-04-14  0:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-10 16:27 [PATCH] mlx4: Fix tx ring affinity_mask creation Benjamin Poirier
2015-04-12  7:03 ` Ido Shamay
2015-04-14  0:22   ` Benjamin Poirier [this message]
2015-04-28  3:26     ` Benjamin Poirier
2015-04-28 13:37       ` Ido Shamay
2015-04-28 18:24 ` Or Gerlitz

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=20150414002256.GA22775@f1.synalogic.ca \
    --to=bpoirier@suse.de \
    --cc=amirv@mellanox.com \
    --cc=idos@dev.mellanox.co.il \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).