netdev - Re: [PATCH net-next 3/3] bonding: 3ad: Use a more verbose warning for unknown speeds

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] [day] [month] [year] [list]

Message-ID: <20210210201145.GA316147@shredder.lan>
Date:   Wed, 10 Feb 2021 22:11:45 +0200
From:   Ido Schimmel <idosch@...sch.org>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     Nikolay Aleksandrov <razor@...ckwall.org>,
        Netdev <netdev@...r.kernel.org>, roopa@...dia.com,
        idosch@...dia.com, Andy Gospodarek <andy@...yhouse.net>,
        Jay Vosburgh <j.vosburgh@...il.com>,
        Veaceslav Falico <vfalico@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH net-next 3/3] bonding: 3ad: Use a more verbose warning
 for unknown speeds

On Wed, Feb 10, 2021 at 11:44:31AM -0800, Alexander Duyck wrote:
> I'm not really sure making the warning consume more text is really
> going to solve the problem. I was actually much happier with just the
> first error as I don't need a stack trace. Just having the line is
> enough information for me to search and find the cause for the issue.
> Adding a backtrace is just overkill.
> 
> If we really think this is something that is important maybe we should
> move this up to an error instead of a warning. For example why not
> make this use pr_err_once, instead of pr_warn_once? It should make it
> more likely to be highlighted in the system log.

Yea, I expected this comment.

We are currently looking for patterns such as 'BUG', 'WARNING', 'BUG
kmalloc', 'UBSAN' etc in regression. Mostly based on what syzkaller is
doing [1] (which we are also running). We can instead promote this
warning to pr_err_once() and start looking at errors as well. It might
uncover more issues / false positives.

[1] https://github.com/google/syzkaller/blob/42b90a7c596c2b7d8f8d034dff7d8c635631de5a/pkg/report/linux.go#L952