From: Jay Vosburgh <fubar@us.ibm.com>
To: Ding Tianhong <dingtianhong@huawei.com>
Cc: vfalico@redhat.com, andy@greyhouse.net, cwang@twopensource.com,
jiri@resnulli.us, thomas@glanzmann.de, eric.dumazet@gmail.com,
sfeldma@cumulusnetworks.com, davem@davemloft.net,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next 3/3] bonding: Fix the RTNL assertion failed for 802.3ad state machine
Date: Mon, 17 Feb 2014 18:06:12 -0800 [thread overview]
Message-ID: <5300.1392689172@death.nxdomain> (raw)
In-Reply-To: <1392626151-23916-4-git-send-email-dingtianhong@huawei.com>
Ding Tianhong <dingtianhong@huawei.com> wrote:
>The 802.3ad state machine don't run in RTNL, but when the slave's
>state changed, the rtmsg_ifinfo will be called, it will cause
>warning message because the RTML is not locked, acquiring RTNL
>for the __enable_port and __disable_port cases is difficult, as
>those calls generally already hold the state machine lock, and
>can't unconditionally call rtnl_lock because either they already
>hold RTNL (for calls via bond_3ad_unbind_slave) or due to the
>potential for deadlock with bond_3ad_adapter_speed_changed,
>bond_3ad_adapter_duplex_changed, bond_3ad_link_change, or
>bond_3ad_update_lacp_rate. All four of those are called with RTNL
>held, and acquire the state machine lock second, The calling contexts for
>__enable_port and __disable_port already hold the state machine lock,
>and may or may not need RTNL.
>
>So according to the Jay's opinion, the __enable_port and __disable_port
>should not call rtmsg_ifinfo in the state machine lock, any change in
>the state of slave could set a flag in the slave, it will indicated that
>an rtmsg_ifinfo should be called at the end of the state machine.
To clarify, my opinion being referenced here was really asking
Scott Feldman <sfeldma@cumulusnetworks.com> if: (a) the calls had to be
synchronous, and, (b) if the intermediate calls to adjust flags within
the ARP monitor "cycle through slaves looking for a functional slave"
all required notifications. My suspicion is that the answer to both of
those is "no," but I haven't heard from Scott.
>Cc: Jay Vosburgh <fubar@us.ibm.com>
>Cc: Veaceslav Falico <vfalico@redhat.com>
>Cc: Andy Gospodarek <andy@greyhouse.net>
>Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>---
> drivers/net/bonding/bond_3ad.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
>index cce1f1b..e80b78f 100644
>--- a/drivers/net/bonding/bond_3ad.c
>+++ b/drivers/net/bonding/bond_3ad.c
>@@ -181,7 +181,7 @@ static inline int __agg_has_partner(struct aggregator *agg)
> */
> static inline void __disable_port(struct port *port)
> {
>- bond_set_slave_inactive_flags(port->slave);
>+ bond_set_slave_flags(port->slave, BOND_STATE_BACKUP, false);
> }
>
> /**
>@@ -193,7 +193,7 @@ static inline void __enable_port(struct port *port)
> struct slave *slave = port->slave;
>
> if ((slave->link == BOND_LINK_UP) && IS_UP(slave->dev))
>- bond_set_slave_active_flags(slave);
>+ bond_set_slave_flags(slave, BOND_STATE_ACTIVE, false);
I don't agree that we need to have two separate systems (your
new bond_set_slave_flags plus bond_set_slave_{active,inactive}_flags)
that both tweak the "active" or "inactive" flags for a slave. It would
be much cleaner and consistent with the current code to add a "notify"
boolean to the existing functions.
-J
> }
>
> /**
>@@ -2123,6 +2123,7 @@ void bond_3ad_state_machine_handler(struct work_struct *work)
> re_arm:
> rcu_read_unlock();
> read_unlock(&bond->lock);
>+ bond_slave_state_notify(bond, false);
> queue_delayed_work(bond->wq, &bond->ad_work, ad_delta_in_ticks);
> }
>
>--
>1.8.0
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
next prev parent reply other threads:[~2014-02-18 2:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-17 8:35 [PATCH net-next 0/3] bonding: Fix RTNL: assertion failed at net/core/rtnetlink.c Ding Tianhong
2014-02-17 8:35 ` [PATCH net-next 1/3] bonding: add bond_set_slave_state/flags() Ding Tianhong
2014-02-18 2:08 ` Jay Vosburgh
2014-02-18 3:50 ` Ding Tianhong
2014-02-17 8:35 ` [PATCH net-next 2/3] bonding: add new slave param and bond_slave_state_notify() Ding Tianhong
2014-02-18 2:07 ` Jay Vosburgh
2014-02-18 3:49 ` Ding Tianhong
2014-02-17 8:35 ` [PATCH net-next 3/3] bonding: Fix the RTNL assertion failed for 802.3ad state machine Ding Tianhong
2014-02-18 2:06 ` Jay Vosburgh [this message]
2014-02-18 3:47 ` Ding Tianhong
2014-02-17 14:06 ` [PATCH net-next 0/3] bonding: Fix RTNL: assertion failed at net/core/rtnetlink.c Thomas Glanzmann
2014-02-17 21:36 ` David Miller
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=5300.1392689172@death.nxdomain \
--to=fubar@us.ibm.com \
--cc=andy@greyhouse.net \
--cc=cwang@twopensource.com \
--cc=davem@davemloft.net \
--cc=dingtianhong@huawei.com \
--cc=eric.dumazet@gmail.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=sfeldma@cumulusnetworks.com \
--cc=thomas@glanzmann.de \
--cc=vfalico@redhat.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;
as well as URLs for NNTP newsgroup(s).