OpenVZ / Virtuozzo kernel development (devel@openvz.org)
 help / color / mirror / Atom feed
From: "Denis V. Lunev" <den@openvz.org>
To: khorenko@virtuozzo.com
Cc: Andrii Mozharovskyi <andrii.mozharovskyi@virtuozzo.com>,
	devel@openvz.org
Subject: [Devel] [PATCH hci-8.1] ve/proc/net: fix tcp6 and udp6 missing from /proc/net in containers
Date: Fri,  6 Nov 2026 13:19:57 +0100	[thread overview]
Message-ID: <20261106121957.3696406-1-den@openvz.org> (raw)

From: Denis V. Lunev <den@openvz.org>

A container sees /proc/net/tcp and udp but gets ENOENT on tcp6 and udp6,
both at /proc/net and at /proc/<pid>/net. Applications that parse these
tables, like the .NET startup script in JE-76965, fail although IPv6
works and ss lists the sockets over netlink.

In vz7 all of tcp, tcp6, udp, udp6, udplite and udplite6 were created by
tcp_proc_register() and udp_proc_register(), which used the VE helper,
so one call covered every family. Upstream commit 37d849bb4294
("ipv{4,6}/tcp: simplify procfs registration") and commit a3d2599b2446
("ipv{4,6}/udp{,lite}: simplify proc registration") moved each family to
its own proc_create_net_data() call, and the port of the VE patch
converted only the IPv4 tcp and udp ones. udplite and udplite6 are
hidden the same way. icmp6 did not exist in vz7 and was never converted,
while its IPv4 twin icmp is visible.

Register the five entries with the VE helpers. They are per-netns and
their seq iterators skip sockets of other namespaces, so a container
lists only its own sockets.

https://virtuozzo.atlassian.net/browse/VSTOR-153793

Fixes: 68eae6367fdc ("ve/proc/net: virtualize all the network proc entries")
Reported-by: Andrii Mozharovskyi <andrii.mozharovskyi@virtuozzo.com>
Feature: procfs: virtualize /proc/net/* entries
Signed-off-by: Denis V. Lunev <den@openvz.org>
---
 net/ipv4/udplite.c  | 2 +-
 net/ipv6/ping.c     | 2 +-
 net/ipv6/tcp_ipv6.c | 2 +-
 net/ipv6/udp.c      | 2 +-
 net/ipv6/udplite.c  | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/ipv4/udplite.c b/net/ipv4/udplite.c
index af37af3ab727..ee3bb356a0b5 100644
--- a/net/ipv4/udplite.c
+++ b/net/ipv4/udplite.c
@@ -87,7 +87,7 @@ static struct udp_seq_afinfo udplite4_seq_afinfo = {
 
 static int __net_init udplite4_proc_init_net(struct net *net)
 {
-	if (!proc_create_net_data("udplite", 0444, net->proc_net, &udp_seq_ops,
+	if (!proc_ve_create_net_data("udplite", 0444, net->proc_net, &udp_seq_ops,
 			sizeof(struct udp_iter_state), &udplite4_seq_afinfo))
 		return -ENOMEM;
 	return 0;
diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c
index 88b3fcacd4f9..b052d7763b1e 100644
--- a/net/ipv6/ping.c
+++ b/net/ipv6/ping.c
@@ -256,7 +256,7 @@ static const struct seq_operations ping_v6_seq_ops = {
 
 static int __net_init ping_v6_proc_init_net(struct net *net)
 {
-	if (!proc_create_net("icmp6", 0444, net->proc_net, &ping_v6_seq_ops,
+	if (!proc_ve_create_net("icmp6", 0444, net->proc_net, &ping_v6_seq_ops,
 			sizeof(struct ping_iter_state)))
 		return -ENOMEM;
 	return 0;
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 15059ba96eb7..e993c0df377b 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -2290,7 +2290,7 @@ static struct tcp_seq_afinfo tcp6_seq_afinfo = {
 
 int __net_init tcp6_proc_init(struct net *net)
 {
-	if (!proc_create_net_data("tcp6", 0444, net->proc_net, &tcp6_seq_ops,
+	if (!proc_ve_create_net_data("tcp6", 0444, net->proc_net, &tcp6_seq_ops,
 			sizeof(struct tcp_iter_state), &tcp6_seq_afinfo))
 		return -ENOMEM;
 	return 0;
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 1b5ae3938e3e..b2a873dbf954 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1793,7 +1793,7 @@ static struct udp_seq_afinfo udp6_seq_afinfo = {
 
 int __net_init udp6_proc_init(struct net *net)
 {
-	if (!proc_create_net_data("udp6", 0444, net->proc_net, &udp6_seq_ops,
+	if (!proc_ve_create_net_data("udp6", 0444, net->proc_net, &udp6_seq_ops,
 			sizeof(struct udp_iter_state), &udp6_seq_afinfo))
 		return -ENOMEM;
 	return 0;
diff --git a/net/ipv6/udplite.c b/net/ipv6/udplite.c
index a60bec9b14f1..41d4b9d78988 100644
--- a/net/ipv6/udplite.c
+++ b/net/ipv6/udplite.c
@@ -111,7 +111,7 @@ static struct udp_seq_afinfo udplite6_seq_afinfo = {
 
 static int __net_init udplite6_proc_init_net(struct net *net)
 {
-	if (!proc_create_net_data("udplite6", 0444, net->proc_net,
+	if (!proc_ve_create_net_data("udplite6", 0444, net->proc_net,
 			&udp6_seq_ops, sizeof(struct udp_iter_state),
 			&udplite6_seq_afinfo))
 		return -ENOMEM;
-- 
2.53.0

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

             reply	other threads:[~2026-11-06 12:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 12:19 Denis V. Lunev [this message]
2026-11-06 12:23 ` no-reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261106121957.3696406-1-den@openvz.org \
    --to=den@openvz.org \
    --cc=andrii.mozharovskyi@virtuozzo.com \
    --cc=devel@openvz.org \
    --cc=khorenko@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox