* [PATCH net-next] sctp: fix compile issue with disabled CONFIG_NET_NS
@ 2012-08-16 11:24 Ulrich Weber
2012-08-16 18:58 ` Eric W. Biederman
0 siblings, 1 reply; 6+ messages in thread
From: Ulrich Weber @ 2012-08-16 11:24 UTC (permalink / raw)
To: davem; +Cc: netdev, ebiederm
struct seq_net_private has no struct net
if CONFIG_NET_NS is not enabled
Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
---
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
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH net-next] sctp: fix compile issue with disabled CONFIG_NET_NS
2012-08-16 11:24 [PATCH net-next] sctp: fix compile issue with disabled CONFIG_NET_NS Ulrich Weber
@ 2012-08-16 18:58 ` Eric W. Biederman
2012-08-16 19:36 ` Ben Hutchings
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Eric W. Biederman @ 2012-08-16 18:58 UTC (permalink / raw)
To: Ulrich Weber; +Cc: davem, netdev
Ulrich Weber <ulrich.weber@sophos.com> writes:
> struct seq_net_private has no struct net
> if CONFIG_NET_NS is not enabled
My mistake.
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
> Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
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.
> ---
> 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,
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH net-next] sctp: fix compile issue with disabled CONFIG_NET_NS
2012-08-16 18:58 ` Eric W. Biederman
@ 2012-08-16 19:36 ` Ben Hutchings
2012-08-16 20:00 ` Eric W. Biederman
2012-08-16 20:36 ` David Miller
2012-08-17 12:07 ` Ulrich Weber
2 siblings, 1 reply; 6+ messages in thread
From: Ben Hutchings @ 2012-08-16 19:36 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Ulrich Weber, davem, netdev
On Thu, 2012-08-16 at 11:58 -0700, Eric W. Biederman wrote:
> Ulrich Weber <ulrich.weber@sophos.com> writes:
>
> > struct seq_net_private has no struct net
> > if CONFIG_NET_NS is not enabled
>
> My mistake.
>
> Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> > Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
>
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net-next] sctp: fix compile issue with disabled CONFIG_NET_NS
2012-08-16 19:36 ` Ben Hutchings
@ 2012-08-16 20:00 ` Eric W. Biederman
0 siblings, 0 replies; 6+ messages in thread
From: Eric W. Biederman @ 2012-08-16 20:00 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Ulrich Weber, davem, netdev
Ben Hutchings <bhutchings@solarflare.com> writes:
> On Thu, 2012-08-16 at 11:58 -0700, Eric W. Biederman wrote:
>> Ulrich Weber <ulrich.weber@sophos.com> writes:
>>
>> > struct seq_net_private has no struct net
>> > if CONFIG_NET_NS is not enabled
>>
>> My mistake.
>>
>> Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>
>> > Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
>>
>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net-next] sctp: fix compile issue with disabled CONFIG_NET_NS
2012-08-16 18:58 ` Eric W. Biederman
2012-08-16 19:36 ` Ben Hutchings
@ 2012-08-16 20:36 ` David Miller
2012-08-17 12:07 ` Ulrich Weber
2 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2012-08-16 20:36 UTC (permalink / raw)
To: ebiederm; +Cc: ulrich.weber, netdev
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 16 Aug 2012 11:58:34 -0700
> Ulrich Weber <ulrich.weber@sophos.com> writes:
>
>> struct seq_net_private has no struct net
>> if CONFIG_NET_NS is not enabled
>
> My mistake.
>
> Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
>> Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
Applied.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net-next] sctp: fix compile issue with disabled CONFIG_NET_NS
2012-08-16 18:58 ` Eric W. Biederman
2012-08-16 19:36 ` Ben Hutchings
2012-08-16 20:36 ` David Miller
@ 2012-08-17 12:07 ` Ulrich Weber
2 siblings, 0 replies; 6+ messages in thread
From: Ulrich Weber @ 2012-08-17 12:07 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-08-17 12:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-08-16 11:24 [PATCH net-next] sctp: fix compile issue with disabled CONFIG_NET_NS Ulrich Weber
2012-08-16 18:58 ` Eric W. Biederman
2012-08-16 19:36 ` Ben Hutchings
2012-08-16 20:00 ` Eric W. Biederman
2012-08-16 20:36 ` David Miller
2012-08-17 12:07 ` Ulrich Weber
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).