netdev - Re: Adding inode field to /proc/net/netlink

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]

Date:	Sun, 28 Feb 2010 18:50:45 +0900 (JST)
From:	Masatake YAMATO <yamato@...hat.com>
To:	davem@...emloft.net
Cc:	netdev@...r.kernel.org
Subject: Re: Adding inode field to /proc/net/netlink

> From: Masatake YAMATO <yamato@...hat.com>
> Date: Sun, 28 Feb 2010 14:45:37 +0900 (JST)
> 
>> The Inode field in /proc/net/{tcp,udp,packet,raw,...} is useful to know the types of 
>> file descriptors associated to a process. Actually lsof utility uses the field.
>> Unfortunately, unlike /proc/net/{tcp,udp,packet,raw,...}, /proc/net/netlink doesn't have the field.
>> This patch adds the field to /proc/net/netlink.
>> 
>> Signed-off-by: Masatake YAMATO <yamato@...hat.com>
> 
> Unfortunately we cannot add new fields without breaking the parsing
> done by existing applications.

I understood but it has been already breaking:

    [yamato@xxx /proc/net]$ uname -a; cat /proc/net/netlink 
    Linux xxx.redhat.com 2.6.29.6-217.2.16.fc11.x86_64 #1 SMP Mon Aug 24 17:17:40 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
    sk       Eth Pid    Groups   Rmem     Wmem     Dump     Locks
    ffff8801bbde0400 0   2758   00000111 0        0        (null) 2
    ...

    [yamato@yyy /proc/net]$ uname -a; cat /proc/net/netlink 
    Linux yyy.redhat.com 2.6.30.10-105.2.23.fc11.x86_64 #1 SMP Thu Feb 11 07:06:34 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
    sk       Eth Pid    Groups   Rmem     Wmem     Dump     Locks     Drops
    ffff8800d83f5800 0   1783   00000001 0        0        (null) 2        0       

Drops field may be added between 2.6.29 and 2.6.30.
Adding one more field is really problem?
In other word, why "Drops" field was acceptable?

lsof uses following technique. It parses the header raw
(here "    sk       Eth Pid    Groups   Rmem     Wmem     Dump     Locks     Drops")
and picks values from columns only if the columns exits in the header raw.
e.g. If "Inode" exists in the header, lsof tries to use Inode value.
With the technique just adding(not deleting or swapping) a new column is not a big problem.

Masatake YAMATO

--
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