| 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
| ||
|
Message-ID: <d0383f90806302347q702416faxe29901bf0d2cdbbb@mail.gmail.com> Date: Tue, 1 Jul 2008 09:47:23 +0300 From: "Ian Brown" <ianbrn@...il.com> To: netdev@...r.kernel.org Subject: [RFC] UDP SndbufErrors interface and the /proc/net/udp interface. Hello, You can see UDP RcvbufErrors via /proc/net/snmp interface. These are UDP RcvbufErrors per system. A recent patch (from two weeks ago) added the ability to view RcvbufErrors also per port, via /proc/net/udp. This was done by incrementing sk_drops of the sock struct when RcvbufErrors is incremented; see , in udp.c (both in ipv4 and in ipv6) the call to atomic_inc(&sk->sk_drops). see: http://kerneltrap.org/mailarchive/linux-netdev/2008/6/17/2153994 You can see UDP SndbufErrors also via /proc/net/snmp interface. These are UDP SndbufErrors per system. I was wondering if it is worthwhile to enable viewing SndbufErrors per port, via /proc/net/udp interface. It could be done, for example, by adding a member to the sock structure, for example, sk_send_err, (or sk_udp_send_drop) incrementing it when SndbufErrors is incremented, and adding code enable viewing it via /proc/net/udp interface. I wonder: would such a patch (form me or others) in needed ? Or will it be rejected because this idea is not good ? In case this idea is not good, I wonder what is the reason for it. Regards, Ian -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists