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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 17 Oct 2022 11:44:08 -0700
From:   Jakub Kicinski <>
To:     Edward Cree <>
Cc:     Jiri Pirko <>,,,,,,,,,
Subject: Re: [RFC PATCH net-next 1/3] netlink: add support for formatted
 extack messages

On Mon, 17 Oct 2022 13:00:55 +0100 Edward Cree wrote:
> > I wonder, wouldn't it be better to just have NL_SET_ERR_MSG_MOD which
> > accepts format string and that's it. I understand there is an extra
> > overhead for the messages that don't use formatting, but do we care?
> > This is no fastpath and usually happens only seldom. The API towards
> > the driver would be more simple.  
> Could do, but this way a fixed string isn't limited to
>  NETLINK_MAX_FMTMSG_LEN like it would be if we tried to stuff it
>  in _msg_buf.  Unless you're suggesting some kind of macro magic
>  that detects whether args is empty and chooses which
>  implementation to use, but that seems like excessive hidden
>  cleverness — better to have driver authors aware of the
>  limitations of each choice.

No macro magic, if we wanna go the extra mile we'd need to run some
analysis. We can choose the limit based on the longest message today.

If spatch could output matches that'd make the analysis pretty trivial
but IDK if it can :S

Powered by blists - more mailing lists