netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wang Weidong <wangweidong1@huawei.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: <davem@davemloft.net>, <vyasevich@gmail.com>,
	<dborkman@redhat.com>, <netdev@vger.kernel.org>
Subject: Re: [PATCH 0/2] sctp: fix a problem with net_namespace
Date: Tue, 28 Jan 2014 16:13:44 +0800	[thread overview]
Message-ID: <52E766B8.3090406@huawei.com> (raw)
In-Reply-To: <20140127114904.GA17143@hmsreliant.think-freely.org>

On 2014/1/27 19:49, Neil Horman wrote:
> On Mon, Jan 27, 2014 at 11:49:01AM +0800, Wang Weidong wrote:
>> fix a problem with net_namespace, and optimize
>> the sctp_sysctl_net_register.
>>
>> Wang Weidong (2):
>>   sctp: fix a missed .data initialization
>>   sctp: optimize the sctp_sysctl_net_register
>>
>>  net/sctp/sysctl.c | 17 ++++++++++-------
>>  1 file changed, 10 insertions(+), 7 deletions(-)
>>
>> -- 
>> 1.7.12
>>
>>
>>
> I don't see that either of these patches are needed.  In sctp_init_net, the
> sctp_hmac_alg pointer gets initalized before calling sctp_sysctl_net_register,
> and sctp_proc_do_hmac_alg is written to specifically expect NULL values, so this
> code may change behavior regarding default cookie selection.
> 
Hi Neil,

Here, I think the sctp_proc_do_hmac_alg will be called only when we change the 
/proc/sys/net/cookie_hmac_alg. So add the .data won't effect the default value.
and the data isn't equal to the "cookie_hmac_alg"?

> This was coded so that poniters to entires in the string table could be used,
> rather than needing to allocate or maintain character buffers.  That said, it
> does look like that for loop in sctp_sysctl_register_table might compute an odd
> offset when cloning the table.  I think the right fix for that is likely to just
> move the sysctl value initalization in sctp_init_net to below the sysctl
> register function.
> 
> Neil
> 

I found the problem is that:
I use "ip netns add netns1/netns2"
In any netns(netns1 or netns2 or init_net) when I change the value of the entry
such as "addip_enable" "max_autoclose" which after the cookie_hmac_alg (contain it),
and the other netns will be effected.

In sctp_sysctl_net_register, kmemdup does cloning the table. The offset of netns1 and
init_net's clt_table.data is the same as two netns offset. So the for(){...} would do
add the offset for every clt_table.data.

The code:
	for (i = 0; table[i].data; i++)
		table[i].data += (char *)(&net->sctp) - (char *)&init_net.sctp;

And I add a pr_info into the for(){...} in sctp_sysctl_net_register and only print 7 times for each ns.
7 is the index of "cookie_preserve_enable" which before the "cookie_hmac_alg". 

As the "cookie_hmac_alg" data is NULL, so we can't add offset to the rest, and all the netns use the same
address of clt_table entry after the "cookie_hmac_alg".

So I think only "move the sysctl value initalization in sctp_init_net to below the sysctl
register function" won't solve the problem, because the problem is at the for() {...}.

Is there something wrong?

The next patch is that, the sctp_net_table is for init_net, So when load the sctp module, we needn't
to do the cloning tables for init_net again. And I found the ipv4 do it in the same way.

I have a doubt : how can I rmmod the sctp? only add '-f' ? If I do "rmmod -f sctp", I will get the
log by dmesg: "Disabling lock debugging due to kernel taint"

Regards,
Wang


> 
> 

  parent reply	other threads:[~2014-01-28  8:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-27  3:49 [PATCH 0/2] sctp: fix a problem with net_namespace Wang Weidong
2014-01-27  3:49 ` [PATCH 1/2] sctp: fix a missed .data initialization Wang Weidong
2014-01-27  3:49 ` [PATCH 2/2] sctp: optimize the sctp_sysctl_net_register Wang Weidong
2014-01-27 11:49 ` [PATCH 0/2] sctp: fix a problem with net_namespace Neil Horman
2014-01-27 13:05   ` Wang Weidong
2014-01-28  8:13   ` Wang Weidong [this message]
2014-01-28 11:57     ` Neil Horman
2014-01-28 14:42       ` Wang Weidong
2014-02-10  2:56       ` Wang Weidong
2014-02-10 12:08         ` Neil Horman

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=52E766B8.3090406@huawei.com \
    --to=wangweidong1@huawei.com \
    --cc=davem@davemloft.net \
    --cc=dborkman@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=vyasevich@gmail.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;
as well as URLs for NNTP newsgroup(s).