From: Nikolay Aleksandrov <nikolay@redhat.com>
To: Ding Tianhong <dingtianhong@huawei.com>,
Jay Vosburgh <fubar@us.ibm.com>,
Andy Gospodarek <andy@greyhouse.net>,
Veaceslav Falico <vfalico@redhat.com>,
Cong Wang <cwang@twopensource.com>,
Thomas Glanzmann <thomas@glanzmann.de>,
Jiri Pirko <jiri@resnulli.us>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Scott Feldman <sfeldma@cumulusnetworks.com>,
Netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next] bonding: Fix RTNL: assertion failed at net/core/rtnetlink.c for 802.3ad mode
Date: Tue, 18 Feb 2014 12:49:24 +0100 [thread overview]
Message-ID: <530348C4.4050408@redhat.com> (raw)
In-Reply-To: <53034312.1060203@huawei.com>
On 02/18/2014 12:25 PM, Ding Tianhong wrote:
> The problem was introduced by the commit 1d3ee88ae0d
> (bonding: add netlink attributes to slave link dev).
> The bond_set_active_slave() and bond_set_backup_slave()
> will use rtmsg_ifinfo to send slave's states, so these
> two functions should be called in RTNL.
>
> In 802.3ad mode, acquiring RTNL for the __enable_port and
> __disable_port cases is difficult, as those calls generally
> already hold the state machine lock, and cannot 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.
>
> According to the Jay's opinion, I don't think it is a problem that
> the slave don't send notify message synchronously when the status
> changed, normally the state machine is running every 100 ms, send
> the notify message at the end of the state machine if the slave's
> state changed should be better.
>
> I fix the problem through these steps:
>
> 1). add a new function bond_set_slave_state() which could change
> the slave's state and call rtmsg_ifinfo() according to the input
> parameters called notify.
>
> 2). Add a new slave parameter which called should_notify, if the slave's state
> changed and don't notify yet, the parameter will be set to 1, and then if
> the slave's state changed again, the param will be set to 0, it indicate that
> the slave's state has been restored, no need to notify any one.
>
> 3). 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.
>
> 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>
> ---
Hi Ding,
I think there's a possible race condition which could lead to inconsistent
state because you set slave->should_notify to 0 under RTNL but
__disable_port can update it without RTNL e.g. can be called via
bond_3ad_state_machine_handler -> ad_agg_selection_logic so in theory (I
haven't tested it) they can execute concurrently. This is not a big deal
though, but it would make this kind of message unreliable.
Nik
next prev parent reply other threads:[~2014-02-18 11:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 11:25 [PATCH net-next] bonding: Fix RTNL: assertion failed at net/core/rtnetlink.c for 802.3ad mode Ding Tianhong
2014-02-18 11:49 ` Nikolay Aleksandrov [this message]
2014-02-18 11:53 ` Nikolay Aleksandrov
2014-02-18 12:14 ` Thomas Glanzmann
2014-02-18 12:16 ` Ding Tianhong
2014-02-18 22:38 ` David Miller
2014-02-19 2:13 ` Ding Tianhong
2014-02-18 23:18 ` Jay Vosburgh
2014-02-19 2:26 ` Ding Tianhong
2014-02-21 3:38 ` Scott Feldman
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=530348C4.4050408@redhat.com \
--to=nikolay@redhat.com \
--cc=andy@greyhouse.net \
--cc=cwang@twopensource.com \
--cc=davem@davemloft.net \
--cc=dingtianhong@huawei.com \
--cc=edumazet@google.com \
--cc=fubar@us.ibm.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 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.