* [PATCH v2 02/15] ipv4: declaring udp protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring udp protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv4/udp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index b4c3582..a16c4fa 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1963,6 +1963,7 @@ struct proto udp_prot = {
.compat_getsockopt = compat_udp_getsockopt,
#endif
.clear_sk = sk_prot_clear_portaddr_nulls,
+ .has_own_proc_entry= 1,
};
EXPORT_SYMBOL(udp_prot);
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 15/15] ipx: declaring ipx protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring ipx protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipx/af_ipx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c
index dfd6faa..14be087 100644
--- a/net/ipx/af_ipx.c
+++ b/net/ipx/af_ipx.c
@@ -1345,6 +1345,7 @@ static struct proto ipx_proto = {
.name = "IPX",
.owner = THIS_MODULE,
.obj_size = sizeof(struct ipx_sock),
+ .has_own_proc_entry= 1,
};
static int ipx_create(struct net *net, struct socket *sock, int protocol,
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 14/15] ax25: declaring ax25 protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring ax25 protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ax25/af_ax25.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index 779095d..ff23c8a 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -803,6 +803,7 @@ static struct proto ax25_proto = {
.name = "AX25",
.owner = THIS_MODULE,
.obj_size = sizeof(struct sock),
+ .has_own_proc_entry= 1,
};
static int ax25_create(struct net *net, struct socket *sock, int protocol,
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 13/15] ipv6: declaring rawv6 protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring rawv6 protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv6/raw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index ef0579d..62ac59f 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -1226,6 +1226,7 @@ struct proto rawv6_prot = {
.compat_getsockopt = compat_rawv6_getsockopt,
.compat_ioctl = compat_rawv6_ioctl,
#endif
+ .has_own_proc_entry= 1,
};
#ifdef CONFIG_PROC_FS
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 12/15] ipv6: declaring udplitev6 protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring udplitev6 protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv6/udplite.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/udplite.c b/net/ipv6/udplite.c
index 1d08e21..9013897 100644
--- a/net/ipv6/udplite.c
+++ b/net/ipv6/udplite.c
@@ -57,6 +57,7 @@ struct proto udplitev6_prot = {
.compat_getsockopt = compat_udpv6_getsockopt,
#endif
.clear_sk = sk_prot_clear_portaddr_nulls,
+ .has_own_proc_entry= 1,
};
static struct inet_protosw udplite6_protosw = {
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 10/15] ipv6: declaring tcpv6 protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring tcpv6 protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv6/tcp_ipv6.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index aa41b0e..741cb3b 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -2017,6 +2017,7 @@ struct proto tcpv6_prot = {
#ifdef CONFIG_MEMCG_KMEM
.proto_cgroup = tcp_proto_cgroup,
#endif
+ .has_own_proc_entry= 1,
};
static const struct inet6_protocol tcpv6_protocol = {
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 09/15] netlink: declaring netlink protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring netlink protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/netlink/af_netlink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 5463969..9094be5 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -410,6 +410,7 @@ static struct proto netlink_proto = {
.name = "NETLINK",
.owner = THIS_MODULE,
.obj_size = sizeof(struct netlink_sock),
+ .has_own_proc_entry= 1,
};
static int __netlink_create(struct net *net, struct socket *sock,
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 08/15] unix: declaring unix protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring unix protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/unix/af_unix.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index e4768c1..7f109e6 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -616,6 +616,7 @@ static struct proto unix_proto = {
.name = "UNIX",
.owner = THIS_MODULE,
.obj_size = sizeof(struct unix_sock),
+ .has_own_proc_entry= 1,
};
/*
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 07/15] packet: declaring packet protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring packet protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/packet/af_packet.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index ceaca7c..6a0e47c 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2564,6 +2564,7 @@ static struct proto packet_proto = {
.name = "PACKET",
.owner = THIS_MODULE,
.obj_size = sizeof(struct packet_sock),
+ .has_own_proc_entry= 1,
};
/*
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 06/15] ipv4: declaring tcp protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring tcp protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv4/tcp_ipv4.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index c660d2c..6f36929 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2635,6 +2635,7 @@ struct proto tcp_prot = {
.destroy_cgroup = tcp_destroy_cgroup,
.proto_cgroup = tcp_proto_cgroup,
#endif
+ .has_own_proc_entry= 1,
};
EXPORT_SYMBOL(tcp_prot);
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 05/15] ipv4: declaring raw protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring raw protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv4/raw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index ff0f071..3980a4a 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -901,6 +901,7 @@ struct proto raw_prot = {
.compat_getsockopt = compat_raw_getsockopt,
.compat_ioctl = compat_raw_ioctl,
#endif
+ .has_own_proc_entry= 1,
};
#ifdef CONFIG_PROC_FS
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 03/15] ipv4: declaring icmp protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring icmp protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv4/ping.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 6232d47..c4bb504 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -748,6 +748,7 @@ struct proto ping_prot = {
.unhash = ping_v4_unhash,
.get_port = ping_v4_get_port,
.obj_size = sizeof(struct inet_sock),
+ .has_own_proc_entry= 1,
};
EXPORT_SYMBOL(ping_prot);
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 01/15] net: proc entry showing inodes on sockfs and their types
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
I've worked on improving lsof output on linux both lsof and linux
sides. Sometimes lsof cannot resolve socket descriptors and as the
result it prints them like:
[yamato@localhost]/tmp% sudo lsof | grep dbus | grep iden
dbus-daem 652 dbus 6u sock ... 17812 can't identify protocol
dbus-daem 652 dbus 34u sock ... 24689 can't identify protocol
dbus-daem 652 dbus 42u sock ... 24739 can't identify protocol
dbus-daem 652 dbus 48u sock ... 22329 can't identify protocol
...
lsof refers /proc/net/PROTOCOL files to solve the type of socket for
given socket descriptor. lsof looks up inode column of the files.
lsof cannot resolve the type if there is no PROTOCOL file for PROTOCOL
for the given socket descriptor nor there is PROTOCOL file with no
inode column.
About kernel side, bluetooth protocol families didn't have their own
PROTOCOL files. So I added them. netlink protocol had its own PROTOCOL
file but no inode column. So I added the column to it.
About lsof side, I added code to refer /proc/net/netlink to lsof. I
added code to refer /proc/net/icmp to lsof. I have to added code to
refer /proc/net/PROTOCOL files for bluetooth protocol families.
However, it is far from complete.
$ grep -r '^\(static \)*struct proto ' | wc -l
60
It is difficult for me to deal such many protocols. During working on
improving, newer protocol may be implemented. Further more subsystem
mariners don't want to add inode column to /proc/net/PROTOCOL file for
avoiding file format incompatibility.
This patch introduces /proc/net/sockfs, which shows most of all inodes
on sockfs and their socket type. A socket newly associated with socket
descriptor in kernel is stored to a list named
`proc_sockfs_list'. /proc/net/sockfs shows the element of the list.
If a protocol has its own lsof friendly proc entry, a socket of the
protocol should not be stored to `proc_sockfs_list'; lsof can solve
the socket type via protocol the proc entry. A protocol can declare it
has own proc entry with `has_own_proc_entry' field in struct proto.
If the field is non-zero, the socket of the protocol is never added to
`proc_sockfs_list'.
In v2 patch, unnecessary CONFIG_PROC_FS ifdefs are removed as suggested
by Alan Cox. The patches are rebased to net-next.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
include/linux/net.h | 8 +++
include/net/sock.h | 3 +
net/socket.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 178 insertions(+), 2 deletions(-)
diff --git a/include/linux/net.h b/include/linux/net.h
index 99276c3..c87acff 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -61,6 +61,9 @@ typedef enum {
#include <linux/fcntl.h> /* For O_CLOEXEC and O_NONBLOCK */
#include <linux/kmemcheck.h>
#include <linux/rcupdate.h>
+#ifdef CONFIG_PROC_FS
+#include <linux/list.h>
+#endif
struct poll_table_struct;
struct pipe_inode_info;
@@ -135,6 +138,7 @@ struct socket_wq {
* @file: File back pointer for gc
* @sk: internal networking protocol agnostic socket representation
* @wq: wait queue for several uses
+ * @proc_sockfs_list: list head to link this socket to /proc/net/sockfs
*/
struct socket {
socket_state state;
@@ -150,6 +154,10 @@ struct socket {
struct file *file;
struct sock *sk;
const struct proto_ops *ops;
+
+#ifdef CONFIG_PROC_FS
+ struct list_head proc_sockfs_list;
+#endif
};
struct vm_area_struct;
diff --git a/include/net/sock.h b/include/net/sock.h
index 72132ae..af37a1e 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -955,6 +955,9 @@ struct proto {
void (*destroy_cgroup)(struct mem_cgroup *memcg);
struct cg_proto *(*proto_cgroup)(struct mem_cgroup *memcg);
#endif
+ /* Set non-zero value if this protocol manages its
+ own /proc/net/PROTOCOL entry and the entry has inode column. */
+ int has_own_proc_entry;
};
/*
diff --git a/net/socket.c b/net/socket.c
index dfe5b66..5f4f228 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -104,6 +104,7 @@
#include <linux/route.h>
#include <linux/sockios.h>
#include <linux/atalk.h>
+#include <linux/rwlock_types.h>
static int sock_no_open(struct inode *irrelevant, struct file *dontcare);
static ssize_t sock_aio_read(struct kiocb *iocb, const struct iovec *iov,
@@ -127,6 +128,10 @@ static ssize_t sock_splice_read(struct file *file, loff_t *ppos,
struct pipe_inode_info *pipe, size_t len,
unsigned int flags);
+static int proc_sockfs_init(void);
+static void proc_sockfs_add(struct socket *sock);
+static void proc_sockfs_remove(struct socket *sock);
+
/*
* Socket files have a set of 'special' operations as well as the generic file ones. These don't appear
* in the operation structures but are done directly via the socketcall() multiplexor.
@@ -259,6 +264,7 @@ static struct inode *sock_alloc_inode(struct super_block *sb)
ei->socket.ops = NULL;
ei->socket.sk = NULL;
ei->socket.file = NULL;
+ INIT_LIST_HEAD(&ei->socket.proc_sockfs_list);
return &ei->vfs_inode;
}
@@ -391,8 +397,10 @@ int sock_map_fd(struct socket *sock, int flags)
struct file *newfile;
int fd = sock_alloc_file(sock, &newfile, flags);
- if (likely(fd >= 0))
+ if (likely(fd >= 0)) {
fd_install(fd, newfile);
+ proc_sockfs_add(sock);
+ }
return fd;
}
@@ -512,9 +520,15 @@ const struct file_operations bad_sock_fops = {
void sock_release(struct socket *sock)
{
+ int externally_allocated = test_bit(SOCK_EXTERNALLY_ALLOCATED,
+ &sock->flags);
+
if (sock->ops) {
struct module *owner = sock->ops->owner;
+ if (!externally_allocated)
+ proc_sockfs_remove(sock);
+
sock->ops->release(sock);
sock->ops = NULL;
module_put(owner);
@@ -523,7 +537,7 @@ void sock_release(struct socket *sock)
if (rcu_dereference_protected(sock->wq, 1)->fasync_list)
printk(KERN_ERR "sock_release: fasync list not empty!\n");
- if (test_bit(SOCK_EXTERNALLY_ALLOCATED, &sock->flags))
+ if (externally_allocated)
return;
this_cpu_sub(sockets_in_use, 1);
@@ -1411,7 +1425,9 @@ SYSCALL_DEFINE4(socketpair, int, family, int, type, int, protocol,
audit_fd_pair(fd1, fd2);
fd_install(fd1, newfile1);
+ proc_sockfs_add(sock1);
fd_install(fd2, newfile2);
+ proc_sockfs_add(sock2);
/* fd1 and fd2 may be already another descriptors.
* Not kernel problem.
*/
@@ -1566,6 +1582,7 @@ SYSCALL_DEFINE4(accept4, int, fd, struct sockaddr __user *, upeer_sockaddr,
/* File flags are not inherited via accept() unlike another OSes. */
fd_install(newfd, newfile);
+ proc_sockfs_add(newsock);
err = newfd;
out_put:
@@ -2552,6 +2569,9 @@ static int __init sock_init(void)
err = PTR_ERR(sock_mnt);
goto out_mount;
}
+ err = proc_sockfs_init();
+ if (err)
+ goto out_proc_socfs;
/* The real protocol initialization is performed in later initcalls.
*/
@@ -2567,6 +2587,8 @@ static int __init sock_init(void)
out:
return err;
+out_proc_socfs:
+ kern_unmount(sock_mnt);
out_mount:
unregister_filesystem(&sock_fs_type);
out_fs:
@@ -3380,3 +3402,146 @@ int kernel_sock_shutdown(struct socket *sock, enum sock_shutdown_cmd how)
return sock->ops->shutdown(sock, how);
}
EXPORT_SYMBOL(kernel_sock_shutdown);
+
+#ifdef CONFIG_PROC_FS
+static LIST_HEAD(proc_sockfs_list);
+static DEFINE_RWLOCK(proc_sockfs_lock);
+
+static void proc_sockfs_add(struct socket *sock)
+{
+ struct sock *sk = sock->sk;
+
+ if (!sk->sk_prot_creator->has_own_proc_entry) {
+ write_lock(&proc_sockfs_lock);
+ list_add_tail(&sock->proc_sockfs_list, &proc_sockfs_list);
+ write_unlock(&proc_sockfs_lock);
+ }
+}
+
+static void proc_sockfs_remove(struct socket *sock)
+{
+ struct sock *sk = sock->sk;
+
+ if (!sk)
+ return;
+
+ if (!sk->sk_prot_creator->has_own_proc_entry) {
+ if (!list_empty(&sock->proc_sockfs_list)) {
+ write_lock(&proc_sockfs_lock);
+ list_del_init(&sock->proc_sockfs_list);
+ write_unlock(&proc_sockfs_lock);
+ }
+ }
+}
+
+static void *proc_sockfs_seq_start(struct seq_file *seq, loff_t *pos)
+ __acquires(&proc_sockfs_lock)
+{
+ read_lock(&proc_sockfs_lock);
+ return seq_list_start_head(&proc_sockfs_list, *pos);
+}
+
+static void *proc_sockfs_seq_next(struct seq_file *seq, void *v, loff_t *pos)
+{
+ return seq_list_next(v, &proc_sockfs_list, pos);
+}
+
+static void proc_sockfs_seq_stop(struct seq_file *seq, void *v)
+ __releases(&proc_sockfs_lock)
+{
+ read_unlock(&proc_sockfs_lock);
+}
+
+static int proc_sockfs_seq_show_header(struct seq_file *seq)
+{
+ return seq_printf(seq, "Inode name state family type protocol socket net\n");
+}
+
+static int proc_sockfs_seq_show_socket(struct seq_file *seq, struct socket *sock)
+{
+ struct sock *sk;
+ const char *name;
+
+ sk = sock->sk;
+ BUG_ON(sk == NULL);
+
+ name = sk->sk_prot_creator->name;
+ if (name == NULL || name[0] == '\0')
+ name = "UNKNOWN";
+
+ return seq_printf(seq, "%20lu %-8s %5d %6d %4d %8d %p %p\n",
+ sock_i_ino(sk),
+ name,
+ sock->state,
+ sk->sk_family,
+ sock->type,
+ sk->sk_protocol,
+ sock,
+ sock_net(sk));
+}
+
+static int proc_sockfs_seq_show(struct seq_file *seq, void *v)
+{
+ if (v == &proc_sockfs_list)
+ proc_sockfs_seq_show_header(seq);
+ else {
+ struct socket *sock = list_entry(v, struct socket, proc_sockfs_list);
+ proc_sockfs_seq_show_socket(seq, sock);
+ }
+
+ return 0;
+}
+
+static const struct seq_operations proc_sockfs_seq_ops = {
+ .start = proc_sockfs_seq_start,
+ .next = proc_sockfs_seq_next,
+ .stop = proc_sockfs_seq_stop,
+ .show = proc_sockfs_seq_show,
+};
+
+static int proc_sockfs_seq_open(struct inode *inode, struct file *file)
+{
+ return seq_open(file, &proc_sockfs_seq_ops);
+}
+
+static const struct file_operations proc_sockfs_seq_fops = {
+ .owner = THIS_MODULE,
+ .open = proc_sockfs_seq_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release,
+};
+
+static __net_init int proc_sockfs_init_net(struct net *net)
+{
+ if (!proc_net_fops_create(net, "sockfs", S_IRUGO, &proc_sockfs_seq_fops))
+ return -ENOMEM;
+ return 0;
+}
+
+static __net_exit void proc_sockfs_exit_net(struct net *net)
+{
+ proc_net_remove(net, "sockfs");
+}
+
+static __net_initdata struct pernet_operations proc_sockfs_ops = {
+ .init = proc_sockfs_init_net,
+ .exit = proc_sockfs_exit_net,
+};
+
+static int proc_sockfs_init(void)
+{
+ return register_pernet_subsys(&proc_sockfs_ops);
+}
+#else
+static int proc_sockfs_init(void)
+{
+ return 0;
+}
+static void proc_sockfs_add(struct socket *sock)
+{
+}
+static void proc_sockfs_remove(struct socket *sock)
+{
+}
+#endif /* CONFIG_PROC_FS */
--
1.7.11.2
^ permalink raw reply related
* Re: TCP stalls with 802.3ad + bridge + kvm guest
From: Stephen Hemminger @ 2012-08-11 18:28 UTC (permalink / raw)
To: Peter Samuelson; +Cc: Jesse Brandeburg, Jay Vosburgh, netdev, jgoerzen
In-Reply-To: <20120804224511.GU17572@p12n.org>
On Sat, 4 Aug 2012 17:45:11 -0500
Peter Samuelson <psamuelson@efolder.net> wrote:
>
> > [Jesse Brandeburg]
> > > try
> > > # ethtool -K ethx tso off gso off lro off
>
> Specifically, 'lro off' is the trick. The others don't have a
> noticeable effect. Now I can get 70 MB/s or better most of the time,
> in either direction.
>
> Thanks again,
> Peter
When device is added to bridge, the bridge code does ask the device
to turn LRO off (automatically). Unfortunately some device drivers are
broken.
^ permalink raw reply
* Fw: [Bug 45571] New: The kernel disallows to reuse sockets which have TIME_WAIT pending connections
From: Stephen Hemminger @ 2012-08-11 18:09 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Sat, 4 Aug 2012 11:13:11 +0000 (UTC)
From: bugzilla-daemon@bugzilla.kernel.org
To: shemminger@linux-foundation.org
Subject: [Bug 45571] New: The kernel disallows to reuse sockets which have TIME_WAIT pending connections
https://bugzilla.kernel.org/show_bug.cgi?id=45571
Summary: The kernel disallows to reuse sockets which have
TIME_WAIT pending connections
Product: Networking
Version: 2.5
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation.org
ReportedBy: t.artem@mailcity.com
Regression: No
This is a follow up of the following bug report:
http://bugs.winehq.org/show_bug.cgi?id=26031
It's not Wine's problem, as it can be easily reproduced with native Linux
applications.
Bruno Jesus 2011-11-10 21:35:54 CST wrote:
> Well, after reading a lot of internet pages and trying several different
> attempts I think it's possible to say that it's a kernel bug or a
> characteristic of the kernel tcp implementation.
>
> The attached patch forces SO_REUSEADDR in before every bind in an attempt to
> fix the problem but it only works if the program exits cleanly (so the kernel
> sets the socket to TIME_WAIT), if you do "wineserver -k" the socket will remain
> opened in an unknow broken state and no applications will be able to use it
> (wine or native linux apps).
>
> Output of strace:
> getsockopt(24, SOL_SOCKET, SO_REUSEADDR, [0], [4]) = 0
> setsockopt(24, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> bind(24, {sa_family=AF_INET, sin_port=htons(43012), sin_addr=inet_addr("0.
> 0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
>
> It's possible to see that I'm checking if SO_REUSEADDR is enabled and then
> enable it. But the bind fails anyway.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH 8/8] bridge: use list_for_each_entry() in netpoll functions
From: Stephen Hemminger @ 2012-08-11 18:07 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev
In-Reply-To: <1344263012-4031-9-git-send-email-amwang@redhat.com>
On Mon, 6 Aug 2012 22:23:32 +0800
Cong Wang <amwang@redhat.com> wrote:
> We don't delete 'p' from the list in the loop,
> so we can just use list_for_each_entry().
>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Good idea.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
^ permalink raw reply
* Fw: [Bug 45681] New: no network to ip phones
From: Stephen Hemminger @ 2012-08-11 18:06 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Tue, 7 Aug 2012 05:02:58 +0000 (UTC)
From: bugzilla-daemon@bugzilla.kernel.org
To: shemminger@linux-foundation.org
Subject: [Bug 45681] New: no network to ip phones
https://bugzilla.kernel.org/show_bug.cgi?id=45681
Summary: no network to ip phones
Product: Networking
Version: 2.5
Kernel Version: 3.0.39
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation.org
ReportedBy: slesru@gmail.com
Regression: No
Hello!
I run asterisk on x86 server , with kernel 2.6.39 all is OK, but with 3.0.38
and 3.0.39 after some time server lost connections to sip phones:
[Aug 2 15:02:51] WARNING[5790]: chan_sip.c:3392 __sip_xmit: sip_xmit of
0x9bd88f8 (len 548) to 192.168.26.116:5060 returned -2: Network is down
ping says the same, but other hosts work OK (from any other networks), only sip
phones are affected.
interfaces:
[root@asterisk ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:48:85:5B:0A
inet addr:192.168.22.19 Bcast:192.168.22.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe85:5b0a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:61867 errors:0 dropped:666 overruns:0 frame:0
TX packets:25992 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7013187 (6.6 MiB) TX bytes:3754003 (3.5 MiB)
eth0.9 Link encap:Ethernet HWaddr 00:30:48:85:5B:0A
inet addr:192.168.42.132 Bcast:192.168.42.255 Mask:255.255.255.128
inet6 addr: fe80::230:48ff:fe85:5b0a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:11634 errors:0 dropped:0 overruns:0 frame:0
TX packets:10753 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2407018 (2.2 MiB) TX bytes:2439435 (2.3 MiB)
default gateway is on eth0, i.e. not tagged.
hardware:
[root@asterisk ~]# /sbin/lspci -nn | grep -i net
01:01.0 Ethernet controller [0200]: Intel Corporation 82547GI Gigabit Ethernet
Controller [8086:1075]
02:01.0 Ethernet controller [0200]: Digium, Inc. Wildcard TE122 single-span
T1/E1/J1 card [d161:8001] (rev 11)
03:0a.0 Ethernet controller [0200]: Intel Corporation 82541GI Gigabit Ethernet
Controller [8086:1076]
I use elrepo kernel build, here is there bug report:
http://elrepo.org/bugs/view.php?id=294
I have no idea what can cause this problem :-(
Thank you!
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* hello
From: sani @ 2012-08-11 16:55 UTC (permalink / raw)
Dear,
I apologized, If this mail finds you disturbing,my name is Miss awa sani.I
am contacting you for the investment purposes. I am available as needed to
discuss this further with you at any time. Please let me know how you
wish to proceed.
I look forward to hearing from you soon.
Thanks
awa
^ permalink raw reply
* Re: [RFC PATCH 0/2] net: connect to UNIX sockets from specified root
From: Stanislav Kinsbursky @ 2012-08-11 11:15 UTC (permalink / raw)
To: Pavel Emelyanov
Cc: H. Peter Anvin, Alan Cox, J. Bruce Fields,
Trond.Myklebust@netapp.com, davem@davemloft.net,
linux-nfs@vger.kernel.org, eric.dumazet@gmail.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
viro@zeniv.linux.org.uk, tim.c.chen@linux.intel.com,
devel@openvz.org
In-Reply-To: <5025FA5A.4090403@parallels.com>
11.08.2012 10:23, Pavel Emelyanov пишет:
> On 08/11/2012 03:09 AM, H. Peter Anvin wrote:
>> On 08/10/2012 12:28 PM, Alan Cox wrote:
>>> Explicitly for Linux yes - this is not generally true of the AF_UNIX
>>> socket domain and even the permissions aspect isn't guaranteed to be
>>> supported on some BSD environments !
>> Yes, but let's worry about what the Linux behavior should be.
>>
>>> The name is however just a proxy for the socket itself. You don't even
>>> get a device node in the usual sense or the same inode in the file system
>>> space.
>>
>> No, but it is looked up the same way any other inode is (the difference
>> between FIFOs and sockets is that sockets have separate connections,
>> which is also why open() on sockets would be nice.)
>>
>> However, there is a fundamental difference between AF_UNIX sockets and
>> open(), and that is how the pathname is delivered. It thus would make
>> more sense to provide the openat()-like information in struct
>> sockaddr_un, but that may be very hard to do in a sensible way. In that
>> sense it perhaps would be cleaner to be able to do an open[at]() on the
>> socket node with O_PATH (perhaps there should be an O_SOCKET option,
>> even?) and pass the resulting file descriptor to bind() or connect().
> I vote for this (openat + O_WHATEVER on a unix socket) as well. It will
> help us in checkpoint-restore, making handling of overmounted/unlinked
> sockets much cleaner.
I have to notice, that it's not enough and doesn't solve the issue.
There should be some way how to connect/bind already existent unix
socket (from kernel, at least), because socket can be created in user space.
And this way (sock operation or whatever) have to provide an ability to
lookup UNIX socket starting from specified root to support containers.
>
>> -hpa
> Thanks,
> Pavel
>
^ permalink raw reply
* [PATCH] macvtap: rcu_dereference outside read-lock section
From: Denis Efremov @ 2012-08-11 10:05 UTC (permalink / raw)
To: David S. Miller
Cc: Denis Efremov, Michael S. Tsirkin, Jason Wang, Eric W. Biederman,
Ian Campbell, netdev, linux-kernel, ldv-project
In this case it is not an error. rcu_dereference
occurs in update section. Replacement by
rcu_dereference_protected (with spinlock) in order to
prevent lockdep complaint.
Found by Linux Driver Verification project (linuxtesting.org)
Signed-off-by: Denis Efremov <yefremov.denis@gmail.com>
---
drivers/net/macvtap.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 0737bd4..8ef11a8 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -94,7 +94,8 @@ static int get_slot(struct macvlan_dev *vlan, struct macvtap_queue *q)
int i;
for (i = 0; i < MAX_MACVTAP_QUEUES; i++) {
- if (rcu_dereference(vlan->taps[i]) == q)
+ if (rcu_dereference_protected(vlan->taps[i],
+ lockdep_is_held(&macvtap_lock)) == q)
return i;
}
--
1.7.7
^ permalink raw reply related
* [PATCH net-next] af_packet: remove BUG statement in tpacket_destruct_skb
From: Daniel Borkmann @ 2012-08-11 8:48 UTC (permalink / raw)
To: davem; +Cc: netdev
Here's a quote of the comment about the BUG macro from asm-generic/bug.h:
Don't use BUG() or BUG_ON() unless there's really no way out; one
example might be detecting data structure corruption in the middle
of an operation that can't be backed out of. If the (sub)system
can somehow continue operating, perhaps with reduced functionality,
it's probably not BUG-worthy.
If you're tempted to BUG(), think again: is completely giving up
really the *only* solution? There are usually better options, where
users don't need to reboot ASAP and can mostly shut down cleanly.
In our case, the status flag of a ring buffer slot is managed from both sides,
the kernel space and the user space. This means that even though the kernel
side might work as expected, the user space screws up and changes this flag
right between the send(2) is triggered when the flag is changed to
TP_STATUS_SENDING and a given skb is destructed after some time. Then, this
will hit the BUG macro. As David suggested, the best solution is to simply
remove this statement since it cannot be used for kernel side internal
consistency checks. I've tested it and the system still behaves /stable/ in
this case, so in accordance with the above comment, we should rather remove it.
Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
---
net/packet/af_packet.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index ceaca7c..bbea24c 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1936,7 +1936,6 @@ static void tpacket_destruct_skb(struct sk_buff *skb)
if (likely(po->tx_ring.pg_vec)) {
ph = skb_shinfo(skb)->destructor_arg;
- BUG_ON(__packet_get_status(po, ph) != TP_STATUS_SENDING);
BUG_ON(atomic_read(&po->tx_ring.pending) == 0);
atomic_dec(&po->tx_ring.pending);
__packet_set_status(po, ph, TP_STATUS_AVAILABLE);
^ permalink raw reply related
* Re: [PATCH net-next] af_packet: relax BUG statement in tpacket_destruct_skb
From: Daniel Borkmann @ 2012-08-11 7:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120810.165450.638010040921216276.davem@davemloft.net>
On Sat, Aug 11, 2012 at 1:54 AM, David Miller <davem@davemloft.net> wrote:
> From: Daniel Borkmann <danborkmann@iogearbox.net>
> Date: Thu, 09 Aug 2012 18:39:05 +0200
>
>> Here's a quote of the comment about the BUG macro from asm-generic/bug.h:
>>
>> Don't use BUG() or BUG_ON() unless there's really no way out; one
>> example might be detecting data structure corruption in the middle
>> of an operation that can't be backed out of. If the (sub)system
>> can somehow continue operating, perhaps with reduced functionality,
>> it's probably not BUG-worthy.
>>
>> If you're tempted to BUG(), think again: is completely giving up
>> really the *only* solution? There are usually better options, where
>> users don't need to reboot ASAP and can mostly shut down cleanly.
>>
>> In our case, the status flag of a ring buffer slot is managed from both sides,
>> the kernel space and the user space. This means that even though the kernel
>> side might work as expected, the user space screws up and changes this flag
>> right between the send(2) is triggered when the flag is changed to
>> TP_STATUS_SENDING and a given skb is destructed after some time. Then, this
>> will hit the BUG macro. Instead, we relax this condition with a WARN_ON_ONCE
>> macro, so that the user is aware of this situation. I've tested it and the
>> system still behaves /stable/, so in accordance with the above comment, we
>> should rather relax this behavior with a warning.
>>
>> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
>
> I would like this check to simply be deleted completely.
>
> As you said, it's a user changable value, therefore we cannot use it
> for kernel side internal consistency checks at all.
Thanks for the feedback, I will resend a proper patch!
Best,
Daniel
^ permalink raw reply
* Re: [RFC PATCH 0/2] net: connect to UNIX sockets from specified root
From: Pavel Emelyanov @ 2012-08-11 6:23 UTC (permalink / raw)
To: H. Peter Anvin, Alan Cox, Stanislav Kinsbursky
Cc: J. Bruce Fields,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org,
tim.c.chen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
In-Reply-To: <50259494.8060304-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
On 08/11/2012 03:09 AM, H. Peter Anvin wrote:
> On 08/10/2012 12:28 PM, Alan Cox wrote:
>> Explicitly for Linux yes - this is not generally true of the AF_UNIX
>> socket domain and even the permissions aspect isn't guaranteed to be
>> supported on some BSD environments !
>
> Yes, but let's worry about what the Linux behavior should be.
>
>> The name is however just a proxy for the socket itself. You don't even
>> get a device node in the usual sense or the same inode in the file system
>> space.
>
>
> No, but it is looked up the same way any other inode is (the difference
> between FIFOs and sockets is that sockets have separate connections,
> which is also why open() on sockets would be nice.)
>
> However, there is a fundamental difference between AF_UNIX sockets and
> open(), and that is how the pathname is delivered. It thus would make
> more sense to provide the openat()-like information in struct
> sockaddr_un, but that may be very hard to do in a sensible way. In that
> sense it perhaps would be cleaner to be able to do an open[at]() on the
> socket node with O_PATH (perhaps there should be an O_SOCKET option,
> even?) and pass the resulting file descriptor to bind() or connect().
I vote for this (openat + O_WHATEVER on a unix socket) as well. It will
help us in checkpoint-restore, making handling of overmounted/unlinked
sockets much cleaner.
> -hpa
Thanks,
Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v2] net: remove delay at device dismantle
From: David Miller @ 2012-08-11 5:57 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, therbert, maheshb, ebiederm
In-Reply-To: <1344664487.5158.1.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 11 Aug 2012 07:54:47 +0200
> On Fri, 2012-08-10 at 17:42 +0200, Eric Dumazet wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> I noticed extra one second delay in device dismantle, tracked down to
>> a call to dst_dev_event() while some call_rcu() are still in RCU queues.
>>
> ...
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: Tom Herbert <therbert@google.com>
>> Cc: Mahesh Bandewar <maheshb@google.com>
>> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
>> ---
>> v2: NETDEV_UNREGISTER_FINAL called outside of rtnl lock
>> as its more risky, base this patch on net-next
>
> Also I am leaving for a one week vacation with no access to the
> Internet, so better hold this patch until my return ;)
Ok :)
^ permalink raw reply
* Re: [PATCH net-next v2] net: remove delay at device dismantle
From: Eric Dumazet @ 2012-08-11 5:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Tom Herbert, Mahesh Bandewar, Eric W. Biederman
In-Reply-To: <1344613369.31104.2734.camel@edumazet-glaptop>
On Fri, 2012-08-10 at 17:42 +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> I noticed extra one second delay in device dismantle, tracked down to
> a call to dst_dev_event() while some call_rcu() are still in RCU queues.
>
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Tom Herbert <therbert@google.com>
> Cc: Mahesh Bandewar <maheshb@google.com>
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
> v2: NETDEV_UNREGISTER_FINAL called outside of rtnl lock
> as its more risky, base this patch on net-next
Also I am leaving for a one week vacation with no access to the
Internet, so better hold this patch until my return ;)
Thanks
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox