Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Tue, 17 May 2022 15:44:19 -0700
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
Message-ID: <20220517154419.44a1cb6a@hermes.local>
In-Reply-To: <5a6ba6f14b0fad6d4ba077a5230ee71cbf970934.1652819479.git.jtoppins@redhat.com>
References: <5a6ba6f14b0fad6d4ba077a5230ee71cbf970934.1652819479.git.jtoppins@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.