All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: netdev@vger.kernel.org, Jay Vosburgh <j.vosburgh@gmail.com>,
	"David S . Miller" <davem@davemloft.net>,
	Jonathan Toppins <jtoppins@redhat.com>,
	Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>, Liang Li <liali@redhat.com>,
	Simon Horman <simon.horman@corigine.com>,
	Miroslav Lichvar <mlichvar@redhat.com>
Subject: Re: [PATCHv4 net-next] bonding: add software tx timestamping support
Date: Fri, 14 Apr 2023 18:02:05 -0700	[thread overview]
Message-ID: <20230414180205.1220135d@kernel.org> (raw)
In-Reply-To: <20230414083526.1984362-1-liuhangbin@gmail.com>

On Fri, 14 Apr 2023 16:35:26 +0800 Hangbin Liu wrote:
> v4: add ASSERT_RTNL to make sure bond_ethtool_get_ts_info() called via
>     RTNL. Only check _TX_SOFTWARE for the slaves.

> +	ASSERT_RTNL();
> +
>  	rcu_read_lock();
>  	real_dev = bond_option_active_slave_get_rcu(bond);
>  	dev_hold(real_dev);
> @@ -5707,10 +5713,36 @@ static int bond_ethtool_get_ts_info(struct net_device *bond_dev,
>  			ret = ops->get_ts_info(real_dev, info);
>  			goto out;
>  		}
> +	} else {
> +		/* Check if all slaves support software tx timestamping */
> +		rcu_read_lock();
> +		bond_for_each_slave_rcu(bond, slave, iter) {

> +			ret = -1;
> +			ops = slave->dev->ethtool_ops;
> +			phydev = slave->dev->phydev;
> +
> +			if (phy_has_tsinfo(phydev))
> +				ret = phy_ts_info(phydev, &ts_info);
> +			else if (ops->get_ts_info)
> +				ret = ops->get_ts_info(slave->dev, &ts_info);

My comment about this path being under rtnl was to point out that we
don't need the RCU protection to iterate over the slaves. This is 
a bit of a guess, I don't know bonding, but can we not use
bond_for_each_slave() ?

As a general rule we should let all driver callbacks sleep. Drivers 
may need to consult the FW or read something over a slow asynchronous
bus which requires process / non-atomic context. RCU lock puts us in 
an atomic context. And ->get_ts_info() is a driver callback.

It's not a deal breaker if we can't avoid RCU, but if we can - we should
let the drivers sleep. Sorry if I wasn't very clear previously.

  parent reply	other threads:[~2023-04-15  1:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-14  8:35 [PATCHv4 net-next] bonding: add software tx timestamping support Hangbin Liu
2023-04-14 20:13 ` Jay Vosburgh
2023-04-15  1:02 ` Jakub Kicinski [this message]
2023-04-15  3:43   ` Jay Vosburgh
2023-04-17  0:17     ` Hangbin Liu
2023-04-17 18:47       ` Jakub Kicinski
2023-04-16 23:08   ` Hangbin Liu

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=20230414180205.1220135d@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=j.vosburgh@gmail.com \
    --cc=jtoppins@redhat.com \
    --cc=liali@redhat.com \
    --cc=liuhangbin@gmail.com \
    --cc=mlichvar@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=simon.horman@corigine.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 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.