From: Stephen Hemminger <stephen@networkplumber.org>
To: Jonathan Toppins <jtoppins@redhat.com>
Cc: netdev@vger.kernel.org, Jay Vosburgh <j.vosburgh@gmail.com>,
Veaceslav Falico <vfalico@gmail.com>,
Andy Gospodarek <andy@greyhouse.net>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC net-next] bonding: netlink error message support for options
Date: Tue, 17 May 2022 15:44:19 -0700 [thread overview]
Message-ID: <20220517154419.44a1cb6a@hermes.local> (raw)
In-Reply-To: <5a6ba6f14b0fad6d4ba077a5230ee71cbf970934.1652819479.git.jtoppins@redhat.com>
On Tue, 17 May 2022 16:31:19 -0400
Jonathan Toppins <jtoppins@redhat.com> wrote:
> This is an RFC because the current NL_SET_ERR_MSG() macros do not support
> printf like semantics so I rolled my own buffer setting in __bond_opt_set().
> The issue is I could not quite figure out the life-cycle of the buffer, if
> rtnl lock is held until after the text buffer is copied into the packet
> then we are ok, otherwise, some other type of buffer management scheme will
> be needed as this could result in corrupted error messages when modifying
> multiple bonds.
Might be better for others in long term if NL_SET_ERR_MSG() had printf like
semantics. Surely this isn't going to be first or last case.
Then internally, it could print right to the netlink message.
next prev parent reply other threads:[~2022-05-17 22:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-17 20:31 [RFC net-next] bonding: netlink error message support for options Jonathan Toppins
2022-05-17 21:11 ` Jay Vosburgh
2022-05-17 22:33 ` Jakub Kicinski
2022-05-17 22:44 ` Stephen Hemminger [this message]
2022-05-17 23:54 ` Jakub Kicinski
2022-05-18 3:37 ` Jonathan Toppins
2022-05-27 19:59 ` [RFC net-next v2] " Jonathan Toppins
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=20220517154419.44a1cb6a@hermes.local \
--to=stephen@networkplumber.org \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=j.vosburgh@gmail.com \
--cc=jtoppins@redhat.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vfalico@gmail.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.