[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220517153326.1fbbe2cc@kernel.org>
Date: Tue, 17 May 2022 15:33:26 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jay Vosburgh <jay.vosburgh@...onical.com>
Cc: Jonathan Toppins <jtoppins@...hat.com>, netdev@...r.kernel.org,
Veaceslav Falico <vfalico@...il.com>,
Andy Gospodarek <andy@...yhouse.net>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC net-next] bonding: netlink error message support for
options
On Tue, 17 May 2022 14:11:14 -0700 Jay Vosburgh wrote:
> If I'm reading the code correctly, rtnl isn't held that long.
> Once the ->doit() returns, rtnl is dropped, but the copy happens later:
>
> rtnetlink_rcv()
> netlink_rcv_skb(skb, &rtnetlink_rcv_msg)
> rtnetlink_rcv_msg() [ as cb(skb, nlh, &extack) ]
> rtnl_lock()
> link->doit() [ rtnl_setlink, rtnl_newlink, et al ]
> rtnl_unlock()
> netlink_ack()
>
> inside netlink_ack():
>
> if (nlk_has_extack && extack) {
> if (extack->_msg) {
> WARN_ON(nla_put_string(skb, NLMSGERR_ATTR_MSG,
> extack->_msg));
> }
Indeed.
> Even if the strings have to be constant (via NL_SET_ERR_MSG),
> adding extack messages is likely still an improvement.
At a quick glance it seems like the major use of the printf here is to
point at a particular option. If options are carried in individual
attributes pointing at the right attribute with NL_SET_ERR_MSG_ATTR()
should also be helpful. Maybe that's stating the obvious.
Powered by blists - more mailing lists