netdev - Re: [PATCH net-next v1 2/2] net/core: refactor promiscuous mode message

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]

Message-ID: <89c60b9f14e3450f14a5337e8dfd6c3972c7be22.camel@redhat.com>
Date:   Thu, 16 Feb 2023 10:10:50 +0100
From:   Paolo Abeni <pabeni@...hat.com>
To:     Jesse Brandeburg <jesse.brandeburg@...el.com>, kuba@...nel.org,
        davem@...emloft.net
Cc:     netdev@...r.kernel.org, intel-wired-lan@...ts.osuosl.org,
        edumazet@...gle.com
Subject: Re: [PATCH net-next v1 2/2] net/core: refactor promiscuous mode
 message

On Tue, 2023-02-14 at 13:01 -0800, Jesse Brandeburg wrote:
> The kernel stack can be more consistent by printing the IFF_PROMISC
> aka promiscuous enable/disable messages with the standard netdev_info
> message which can include bus and driver info as well as the device.
> 
> typical command usage from user space looks like:
> ip link set eth0 promisc <on|off>
> 
> But lots of utilities such as bridge, tcpdump, etc put the interface into
> promiscuous mode.
> 
> old message:
> [  406.034418] device eth0 entered promiscuous mode
> [  408.424703] device eth0 left promiscuous mode
> 
> new message:
> [  406.034431] ice 0000:17:00.0 eth0: entered promiscuous mode
> [  408.424715] ice 0000:17:00.0 eth0: left promiscuous mode
> 
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@...el.com>
> ---
> I'm unsure about this one because it's changing a long standard kernel
> message to a slightly different format. I think the new way looks better
> and has more information.

I guess the relevant question here is if such kind of messages are
somewhat implicitly part of uAPI.

AFAIK the answer is "no", at least for info-level msg, so the patch
LGTM.

Thanks,

Paolo