Skip to contentSkip to conversation

net: Let inet_diag and friends autoload

PATCH In review Jean Delvare 3 participants 4 messages Oct 16, 2007 – Oct 19, 2007

Subsystems (3)
Networking Network drivers TCP
lore
Share & tools
lore

Jean Delvare

author
#0 lore raw

PATCH 1/2 net: Let inet_diag and friends autoload

By adding module aliases to inet_diag, tcp_diag and dccp_diag, we let them load automatically as needed. This makes tools like "ss" run faster.

Signed-off-by Jean Delvare <[email protected]>
Cc Alexey Kuznetsov <[email protected]>

---
The alias naming scheme for tcp_diag and dccp_diag follows what was done for dccp_ipv4 and dccp_ipv6.

 include/linux/net.h  |    4 ++++
 net/dccp/diag.c      |    1 +
 net/ipv4/inet_diag.c |    7 +++++++
 net/ipv4/tcp_diag.c  |    1 +
 4 files changed, 13 insertions(+)
net/ipv4/inet_diag.c +7 -0
@@ -815,6 +815,12 @@ static int inet_diag_rcv_msg(struct sk_b
 	    nlmsg_len(nlh) < hdrlen)
 		return -EINVAL;
 
+#ifdef CONFIG_KMOD
+	if (inet_diag_table[nlh->nlmsg_type] == NULL)
+		request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
+			       NETLINK_INET_DIAG, nlh->nlmsg_type);
+#endif
+
 	if (inet_diag_table[nlh->nlmsg_type] == NULL)
 		return -ENOENT;
 

@@ -914,3 +920,4 @@ static void __exit inet_diag_exit(void)
 module_init(inet_diag_init);
 module_exit(inet_diag_exit);
 MODULE_LICENSE("GPL");
+MODULE_ALIAS_NET_PF_PROTO(PF_NETLINK, NETLINK_INET_DIAG);
include/linux/net.h +4 -0
@@ -313,6 +313,10 @@ static const struct proto_ops name##_ops
 #define MODULE_ALIAS_NET_PF_PROTO(pf, proto) \
 	MODULE_ALIAS("net-pf-" __stringify(pf) "-proto-" __stringify(proto))
 
+#define MODULE_ALIAS_NET_PF_PROTO_TYPE(pf, proto, type) \
+	MODULE_ALIAS("net-pf-" __stringify(pf) "-proto-" __stringify(proto) \
+		     "-type-" __stringify(type))
+
 #ifdef CONFIG_SYSCTL
 #include <linux/sysctl.h>
 extern ctl_table net_table[];
net/ipv4/tcp_diag.c +1 -0
@@ -56,3 +56,4 @@ static void __exit tcp_diag_exit(void)
 module_init(tcp_diag_init);
 module_exit(tcp_diag_exit);
 MODULE_LICENSE("GPL");
+MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_INET_DIAG, TCPDIAG_GETSOCK);
net/dccp/diag.c +1 -0
@@ -68,3 +68,4 @@ module_exit(dccp_diag_fini);
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Arnaldo Carvalho de Melo <[email protected]>");
 MODULE_DESCRIPTION("DCCP inet_diag handler");
+MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_INET_DIAG, DCCPDIAG_GETSOCK);
Signature · 2 lines
Jean Delvare
Suse L3
maintainer
#1 lore raw

From: Jean Delvare <[email protected]>
Date: Tue, 16 Oct 2007 17:28:23 +0200

Quoted 9 lines

By adding module aliases to inet_diag, tcp_diag and dccp_diag, we let them load automatically as needed. This makes tools like "ss" run faster.

Signed-off-by Jean Delvare <[email protected]>
Cc Alexey Kuznetsov <[email protected]>

---
The alias naming scheme for tcp_diag and dccp_diag follows what was done for dccp_ipv4 and dccp_ipv6.

I'm concerned it might be dangerous to load the module in this context, the RTNL semaphore is held and the module we are requesting could easily try to take it and deadlock.

Currently we are lucky and this won't happen, but if the sub-proto registration is every changed to do so, it will be a nightmare for whoever is so unlucky to try and debug it.

#2 lore raw
Quoted 4 lines · David Miller

I'm concerned it might be dangerous to load the module in this context, the RTNL semaphore is held and the module we are requesting could easily try to take it and deadlock.

We shouldn't be holding the RTNL here. AFAICS we only hold inet_diag_mutex which is used in just one spot.

Cheers,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
maintainer
#3 lore raw

From: Herbert Xu <[email protected]>
Date: Fri, 19 Oct 2007 16:21:23 +0800

Quoted 8 lines
Quoted 4 lines · David Miller

I'm concerned it might be dangerous to load the module in this context, the RTNL semaphore is held and the module we are requesting could easily try to take it and deadlock.

We shouldn't be holding the RTNL here. AFAICS we only hold inet_diag_mutex which is used in just one spot.

You're right.

I'll reconsider these patches.