linux-kernel - Re: [PATCH net-next 1/3] net: gre_demux: add skb drop reasons to gre

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: <20220316115515.7f1fa90a@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Wed, 16 Mar 2022 11:55:15 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     David Laight <David.Laight@...LAB.COM>
Cc:     David Ahern <dsahern@...nel.org>,
        "menglong8.dong@...il.com" <menglong8.dong@...il.com>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "mingo@...hat.com" <mingo@...hat.com>, "xeb@...l.ru" <xeb@...l.ru>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
        "imagedong@...cent.com" <imagedong@...cent.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kafai@...com" <kafai@...com>,
        "talalahmad@...gle.com" <talalahmad@...gle.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "alobakin@...me" <alobakin@...me>,
        "flyingpeng@...cent.com" <flyingpeng@...cent.com>,
        "mengensun@...cent.com" <mengensun@...cent.com>,
        "dongli.zhang@...cle.com" <dongli.zhang@...cle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Biao Jiang <benbjiang@...cent.com>
Subject: Re: [PATCH net-next 1/3] net: gre_demux: add skb drop reasons to
 gre_rcv()

On Wed, 16 Mar 2022 10:12:00 +0000 David Laight wrote:
> Is it worth considering splitting the 'reason' into two parts?
> Eg x << 16 | y
> One part being the overall reason - and probably a define.
> The other qualifying the actual failing test and probably just
> being a number.
> 
> Then you get an overall view of the fails (which might even
> be counted) while still being able to locate the actual
> failing test.

That popped to my mind, but other than the fact that it "seems fine" 
I can't really convince myself that (a) 2 levels are enough, why not 3;
(b) I personally don't often look at the drops, so IDK what'd fit the
needs of the consumer of this API. TCP bad csum drops are the only ones
I have experience with, and we have those already covered.