linux-kernel - Re: [RFC net-next] bonding: netlink error message support for options

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 17 May 2022 16:54:19 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     Jonathan Toppins <jtoppins@...hat.com>, netdev@...r.kernel.org,
        Jay Vosburgh <j.vosburgh@...il.com>,
        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 15:44:19 -0700 Stephen Hemminger wrote:
> On Tue, 17 May 2022 16:31:19 -0400
> Jonathan Toppins <jtoppins@...hat.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.

Dunno. I think pointing at the bad attr + exposing per-attr netlink
parsing policy + a string for a human worked pretty well so far.
IMHO printf() is just a knee jerk reaction, especially when converting
from netdev_err(). 

Augmenting structured information is much, much better long term.

To me the never ending stream of efforts to improve printk() is a
proof that once we let people printf() at will, efforts to contain 
it will be futile.