[PATCH net-next] sctp: fix compile issue with disabled CONFIG_NET_NS

struct seq_net_private has no struct net
if CONFIG_NET_NS is not enabled

Signed-off-by: Ulrich Weber <redacted>
---
 net/sctp/proc.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index 3e62ee5..d9cb2ab 100644
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c

@@ -199,7 +199,6 @@ static void * sctp_eps_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 /* Display sctp endpoints (/proc/net/sctp/eps). */
 static int sctp_eps_seq_show(struct seq_file *seq, void *v)
 {
-	struct seq_net_private *priv = seq->private;
 	struct sctp_hashbucket *head;
 	struct sctp_ep_common *epb;
 	struct sctp_endpoint *ep;

@@ -216,7 +215,7 @@ static int sctp_eps_seq_show(struct seq_file *seq, void *v)
 	sctp_for_each_hentry(epb, node, &head->chain) {
 		ep = sctp_ep(epb);
 		sk = epb->sk;
-		if (!net_eq(sock_net(sk), priv->net))
+		if (!net_eq(sock_net(sk), seq_file_net(seq)))
 			continue;
 		seq_printf(seq, "%8pK %8pK %-3d %-3d %-4d %-5d %5d %5lu ", ep, sk,
 			   sctp_sk(sk)->type, sk->sk_state, hash,

@@ -307,7 +306,6 @@ static void * sctp_assocs_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 /* Display sctp associations (/proc/net/sctp/assocs). */
 static int sctp_assocs_seq_show(struct seq_file *seq, void *v)
 {
-	struct seq_net_private *priv = seq->private;
 	struct sctp_hashbucket *head;
 	struct sctp_ep_common *epb;
 	struct sctp_association *assoc;

@@ -324,7 +322,7 @@ static int sctp_assocs_seq_show(struct seq_file *seq, void *v)
 	sctp_for_each_hentry(epb, node, &head->chain) {
 		assoc = sctp_assoc(epb);
 		sk = epb->sk;
-		if (!net_eq(sock_net(sk), priv->net))
+		if (!net_eq(sock_net(sk), seq_file_net(seq)))
 			continue;
 		seq_printf(seq,
 			   "%8pK %8pK %-3d %-3d %-2d %-4d "

@@ -423,7 +421,6 @@ static void sctp_remaddr_seq_stop(struct seq_file *seq, void *v)
 
 static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
 {
-	struct seq_net_private *priv = seq->private;
 	struct sctp_hashbucket *head;
 	struct sctp_ep_common *epb;
 	struct sctp_association *assoc;

@@ -438,7 +435,7 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
 	sctp_local_bh_disable();
 	read_lock(&head->lock);
 	sctp_for_each_hentry(epb, node, &head->chain) {
-		if (!net_eq(sock_net(epb->sk), priv->net))
+		if (!net_eq(sock_net(epb->sk), seq_file_net(seq)))
 			continue;
 		assoc = sctp_assoc(epb);
 		list_for_each_entry(tsp, &assoc->peer.transport_addr_list,

-- 
1.7.9.5

Ulrich Weber [off-list ref] writes:

struct seq_net_private has no struct net
if CONFIG_NET_NS is not enabled

My mistake.

Reviewed-by: "Eric W. Biederman" <redacted>

Signed-off-by: Ulrich Weber <redacted>

Ulrich do you get any performance advantage by disabling the network
namespace?

I am wondering if there is any benefit to keeping it possible to disable
the network namespace?

The original reason for the option was so that distributions and
other who wanted to avoid new code could protect their users, and
that reasons seems to have long since passed.

On Thu, 2012-08-16 at 11:58 -0700, Eric W. Biederman wrote:

Ulrich Weber [off-list ref] writes:

quoted

struct seq_net_private has no struct net
if CONFIG_NET_NS is not enabled

My mistake.

Reviewed-by: "Eric W. Biederman" <redacted>

quoted

Signed-off-by: Ulrich Weber <redacted>

Ulrich do you get any performance advantage by disabling the network
namespace?

I am wondering if there is any benefit to keeping it possible to disable
the network namespace?

The original reason for the option was so that distributions and
other who wanted to avoid new code could protect their users, and
that reasons seems to have long since passed.

[...]

Network namespaces are now used by common applications such as Chrome/
Chromium and vsftpd (which flushed out some of the early implementation
problems).  They undoubtedly have some overhead that some users would
like to avoid, but I wouldn't expect distributions to disable the
option.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Ben Hutchings [off-list ref] writes:

On Thu, 2012-08-16 at 11:58 -0700, Eric W. Biederman wrote:

quoted

Ulrich Weber [off-list ref] writes:

quoted

struct seq_net_private has no struct net
if CONFIG_NET_NS is not enabled

My mistake.

Reviewed-by: "Eric W. Biederman" <redacted>

quoted

Signed-off-by: Ulrich Weber <redacted>

Ulrich do you get any performance advantage by disabling the network
namespace?

I am wondering if there is any benefit to keeping it possible to disable
the network namespace?

The original reason for the option was so that distributions and
other who wanted to avoid new code could protect their users, and
that reasons seems to have long since passed.

[...]

Network namespaces are now used by common applications such as Chrome/
Chromium and vsftpd (which flushed out some of the early implementation
problems).  They undoubtedly have some overhead that some users would
like to avoid, but I wouldn't expect distributions to disable the
option.

When the network namespace code was merged we could not mearsure the
overhead, at least not on gigabit ethernet.  And there is very little
code change when network namespaces go away.

So I am starting to look for people who care.  Especially for people who
can measure overhead associated with network namespaces.

Eric

From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 16 Aug 2012 11:58:34 -0700

Ulrich Weber [off-list ref] writes:

quoted

struct seq_net_private has no struct net
if CONFIG_NET_NS is not enabled

My mistake.

Reviewed-by: "Eric W. Biederman" <redacted>

quoted

Signed-off-by: Ulrich Weber <redacted>

Applied.

Hi Eric,

On 08/16/2012 08:58 PM, Eric W. Biederman wrote:

Ulrich do you get any performance advantage by disabling the network 
namespace? I am wondering if there is any benefit to keeping it 
possible to disable the network namespace? The original reason for the 
option was so that distributions and other who wanted to avoid new 
code could protect their users, and that reasons seems to have long 
since passed.

we just disable most of the options we don't use. I have no idea,
if there are any performance advantages here...

Cheers
Ulrich

-- 
Ulrich Weber | ulrich.weber@sophos.com | Senior Software Engineer
Astaro - a Sophos company | Amalienbadstr 41 | 76227 Karlsruhe | Germany
Phone +49-721-25516-0 | Fax –200 | www.astaro.com