Adding inode field to /proc/net/netlink

Adding inode field to /proc/net/netlink

[Masatake YAMATO]

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@redhat.com>

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 4c5972b..320d042 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1978,12 +1978,12 @@ static int netlink_seq_show(struct seq_file *seq, void *v)
 	if (v == SEQ_START_TOKEN)
 		seq_puts(seq,
 			 "sk       Eth Pid    Groups   "
-			 "Rmem     Wmem     Dump     Locks     Drops\n");
+			 "Rmem     Wmem     Dump     Locks     Drops     Inode\n");
 	else {
 		struct sock *s = v;
 		struct netlink_sock *nlk = nlk_sk(s);
 
-		seq_printf(seq, "%p %-3d %-6d %08x %-8d %-8d %p %-8d %-8d\n",
+		seq_printf(seq, "%p %-3d %-6d %08x %-8d %-8d %p %-8d %-8d %-8lu\n",
 			   s,
 			   s->sk_protocol,
 			   nlk->pid,
@@ -1992,7 +1992,8 @@ static int netlink_seq_show(struct seq_file *seq, void *v)
 			   sk_wmem_alloc_get(s),
 			   nlk->cb,
 			   atomic_read(&s->sk_refcnt),
-			   atomic_read(&s->sk_drops)
+			   atomic_read(&s->sk_drops),
+			   sock_i_ino(s)
 			);
 
 	}

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

[David Miller]

From: Masatake YAMATO <yamato@redhat.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@redhat.com>

Unfortunately we cannot add new fields without breaking the parsing
done by existing applications.

Sorry.

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

[Eric Dumazet]

Le dimanche 28 février 2010 à 01:00 -0800, David Miller a écrit :
> From: Masatake YAMATO <yamato@redhat.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@redhat.com>
> 
> Unfortunately we cannot add new fields without breaking the parsing
> done by existing applications.

Hmm we already did such expansion last year with commit 38938bfe when
Pablo Neira Ayuso added the Drops column

Extract of its Changelog :

 This patch also includes the use of sk_drop to account the number of
 netlink messages drop due to overrun. This value is shown in
 /proc/net/netlink.

So yes, some applications might break but they probably already broke
one year ago and their maintainers should know that adding new fields at
the end of lines is expected ?

Acked-by: Eric Dumazet <eric.dumazet@gmail.com>

Thanks

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

[David Miller]

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 28 Feb 2010 10:13:51 +0100

> Hmm we already did such expansion last year with commit 38938bfe when
> Pablo Neira Ayuso added the Drops column
> 
> Extract of its Changelog :
> 
>  This patch also includes the use of sk_drop to account the number of
>  netlink messages drop due to overrun. This value is shown in
>  /proc/net/netlink.
> 
> So yes, some applications might break but they probably already broke
> one year ago and their maintainers should know that adding new fields at
> the end of lines is expected ?
> 
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>

That's a good point.

Ok, I'll apply this.

Thanks.

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

[Eric Dumazet]

Le dimanche 28 février 2010 à 18:50 +0900, Masatake YAMATO a écrit :

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

Indeed :)

I am a big fan of Vic Abell lsof tool that I used before Linux was even
born :)

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

[Masatake YAMATO]

> From: Masatake YAMATO <yamato@redhat.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@redhat.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

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

[Masatake YAMATO]

>> 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
>> 
> 
> Indeed :)
> 
> I am a big fan of Vic Abell lsof tool that I used before Linux was even
> born :)

Thank you for supporting my patch.
I've already written a patch for lsof to use /proc/net/netlink. I'll submit it to him later.

I have not inspected well yet but there may be some protocols that /proc/net don't have
Inode field.
    
    # lsof | grep identi
    rpcbind   1555       rpc    4u     sock                0,5      0t0      13303 can't identify protocol
    dbus-daem 1570      dbus    7u     sock                0,5      0t0      13326 can't identify protocol
    cupsd     1590      root    3u     sock                0,5      0t0      13401 can't identify protocol
    bluetooth 1864      root    5u     sock                0,5      0t0      14749 can't identify protocol
    bluetooth 1864      root    8u     sock                0,5      0t0      14832 can't identify protocol
    bluetooth 1864      root    9u     sock                0,5      0t0      14846 can't identify protocol
    bluetooth 1864      root   10u     sock                0,5      0t0      14888 can't identify protocol
    bluetooth 1864      root   13u     sock                0,5      0t0      14947 can't identify protocol
    libvirtd  1972      root    7u     sock                0,5      0t0      15341 can't identify protocol

lsof deals following protocols:
    ax25
    ipx
    packet
    raw
    sockstat
    tcp
    udp
    udplite
    raw6
    sockstat6
    tcp6
    udp6
    udp6lite
    unix
    netlink

Masatake YAMATO