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
| ||
|
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.
Powered by blists - more mailing lists