All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.duyck@gmail.com>
To: Antoine Tenart <atenart@kernel.org>
Cc: David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next v2 09/12] net-sysfs: remove the rtnl lock when accessing the xps maps
Date: Mon, 8 Feb 2021 14:20:58 -0800	[thread overview]
Message-ID: <CAKgT0Uc3TePxDd12MQiWtkUmtjnd4CAsrN2U49R1p7wXsvxgRA@mail.gmail.com> (raw)
In-Reply-To: <20210208171917.1088230-10-atenart@kernel.org>

On Mon, Feb 8, 2021 at 9:19 AM Antoine Tenart <atenart@kernel.org> wrote:
>
> Now that nr_ids and num_tc are stored in the xps dev_maps, which are RCU
> protected, we do not have the need to protect the xps_cpus_show and
> xps_rxqs_show functions with the rtnl lock.
>
> Signed-off-by: Antoine Tenart <atenart@kernel.org>
> ---
>  net/core/net-sysfs.c | 26 ++++----------------------
>  1 file changed, 4 insertions(+), 22 deletions(-)
>
> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
> index c2276b589cfb..6ce5772e799e 100644
> --- a/net/core/net-sysfs.c
> +++ b/net/core/net-sysfs.c
> @@ -1328,17 +1328,12 @@ static ssize_t xps_cpus_show(struct netdev_queue *queue,
>
>         index = get_netdev_queue_index(queue);
>
> -       if (!rtnl_trylock())
> -               return restart_syscall();
> -
>         /* If queue belongs to subordinate dev use its map */
>         dev = netdev_get_tx_queue(dev, index)->sb_dev ? : dev;
>
>         tc = netdev_txq_to_tc(dev, index);
> -       if (tc < 0) {
> -               ret = -EINVAL;
> -               goto err_rtnl_unlock;
> -       }
> +       if (tc < 0)
> +               return -EINVAL;
>
>         rcu_read_lock();
>         dev_maps = rcu_dereference(dev->xps_maps[XPS_CPUS]);

So I think we hit a snag here. The sb_dev pointer is protected by the
rtnl_lock. So I don't think we can release the rtnl_lock until after
we are done with the dev pointer.

Also I am not sure it is safe to use netdev_txq_to_tc without holding
the lock. I don't know if we ever went through and guaranteed that it
will always work if the lock isn't held since in theory the device
could reprogram all the map values out from under us.

Odds are we should probably fix traffic_class_show as I suspect it
probably also needs to be holding the rtnl_lock to prevent any
possible races. I'll submit a patch for that.

> @@ -1371,16 +1366,12 @@ static ssize_t xps_cpus_show(struct netdev_queue *queue,
>  out_no_maps:
>         rcu_read_unlock();
>
> -       rtnl_unlock();
> -
>         len = bitmap_print_to_pagebuf(false, buf, mask, nr_ids);
>         bitmap_free(mask);
>         return len < PAGE_SIZE ? len : -EINVAL;
>
>  err_rcu_unlock:
>         rcu_read_unlock();
> -err_rtnl_unlock:
> -       rtnl_unlock();
>         return ret;
>  }
>
> @@ -1435,14 +1426,9 @@ static ssize_t xps_rxqs_show(struct netdev_queue *queue, char *buf)
>
>         index = get_netdev_queue_index(queue);
>
> -       if (!rtnl_trylock())
> -               return restart_syscall();
> -
>         tc = netdev_txq_to_tc(dev, index);
> -       if (tc < 0) {
> -               ret = -EINVAL;
> -               goto err_rtnl_unlock;
> -       }
> +       if (tc < 0)
> +               return -EINVAL;
>
>         rcu_read_lock();
>         dev_maps = rcu_dereference(dev->xps_maps[XPS_RXQS]);
> @@ -1475,8 +1461,6 @@ static ssize_t xps_rxqs_show(struct netdev_queue *queue, char *buf)
>  out_no_maps:
>         rcu_read_unlock();
>
> -       rtnl_unlock();
> -
>         len = bitmap_print_to_pagebuf(false, buf, mask, nr_ids);
>         bitmap_free(mask);
>
> @@ -1484,8 +1468,6 @@ static ssize_t xps_rxqs_show(struct netdev_queue *queue, char *buf)
>
>  err_rcu_unlock:
>         rcu_read_unlock();
> -err_rtnl_unlock:
> -       rtnl_unlock();
>         return ret;
>  }
>
> --
> 2.29.2
>

  reply	other threads:[~2021-02-08 22:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08 17:19 [PATCH net-next v2 00/12] net: xps: improve the xps maps handling Antoine Tenart
2021-02-08 17:19 ` [PATCH net-next v2 01/12] net-sysfs: convert xps_cpus_show to bitmap_zalloc Antoine Tenart
2021-02-08 17:19 ` [PATCH net-next v2 02/12] net-sysfs: store the return of get_netdev_queue_index in an unsigned int Antoine Tenart
2021-02-08 17:19 ` [PATCH net-next v2 03/12] net-sysfs: make xps_cpus_show and xps_rxqs_show consistent Antoine Tenart
2021-02-08 17:19 ` [PATCH net-next v2 04/12] net: embed num_tc in the xps maps Antoine Tenart
2021-02-08 17:19 ` [PATCH net-next v2 05/12] net: embed nr_ids " Antoine Tenart
2021-02-08 17:19 ` [PATCH net-next v2 06/12] net: assert the rtnl lock is held when calling __netif_set_xps_queue Antoine Tenart
2021-02-23  6:27   ` [net] 81bb8ff453: assertion_failed kernel test robot
2021-02-23  6:27     ` kernel test robot
2021-02-08 17:19 ` [PATCH net-next v2 07/12] net: remove the xps possible_mask Antoine Tenart
2021-02-08 21:43   ` Alexander Duyck
2021-02-09  8:47     ` Antoine Tenart
2021-02-08 17:19 ` [PATCH net-next v2 08/12] net: move the xps maps to an array Antoine Tenart
2021-02-08 17:19 ` [PATCH net-next v2 09/12] net-sysfs: remove the rtnl lock when accessing the xps maps Antoine Tenart
2021-02-08 22:20   ` Alexander Duyck [this message]
2021-02-09  9:12     ` Antoine Tenart
2021-02-09  9:20       ` Antoine Tenart
2021-02-08 17:19 ` [PATCH net-next v2 10/12] net: add an helper to copy xps maps to the new dev_maps Antoine Tenart
2021-02-08 17:19 ` [PATCH net-next v2 11/12] net: improve queue removal readability in __netif_set_xps_queue Antoine Tenart
2021-02-08 17:19 ` [PATCH net-next v2 12/12] net-sysfs: move the xps cpus/rxqs retrieval in a common function Antoine Tenart
2021-02-08 22:45   ` Alexander Duyck

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=CAKgT0Uc3TePxDd12MQiWtkUmtjnd4CAsrN2U49R1p7wXsvxgRA@mail.gmail.com \
    --to=alexander.duyck@gmail.com \
    --cc=atenart@kernel.org \
    --cc=davem@davemloft.net \
    --cc=kuba@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.