netdev - Re: [RFC 0/4] netfilter conntrack sysctls pernet support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090309190744.GA18357@localhost>
Date:	Mon, 9 Mar 2009 22:07:44 +0300
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	davem@...emloft.net, netdev@...r.kernel.org,
	linux-next@...r.kernel.org, xemul@...nvz.org, adobriyan@...il.com,
	Netfilter Development Mailinglist 
	<netfilter-devel@...r.kernel.org>
Subject: Re: [RFC 0/4] netfilter conntrack sysctls pernet support

[Patrick McHardy - Mon, Mar 09, 2009 at 07:47:28PM +0100]
> First off, *please* CC netfilter-devel on patches relating to netfilter.
> I've said this a hundred times in direction of the container guys
> (not sure whether you specifically) and it keeps getting ignored.

Ugh... sorry Patrick, my fault, I've noticed this address in
MAINTEINERS but NETFILTER section contains 3 list so I messed
in which one I should choose. Sorry again.

>
> Cyrill Gorcunov wrote:
>> Hi here are a few patches to bring in per-net functionality
>> for several conntrack protocols: DCCP, SCTP, UDPlite.
>>
>> Since these protos could be built as modules I've put
>> per-net operations to module init/exit routines. The change
>> I would like you point the attention is that module static
>> variables being marked as __read_mostly become now as dynamically
>> allocated -- is it acceptable trade off?
>
> Well, there's no other choice I guess.

Actually, the possibility I see is to make some union on _all_
structures I put in pernet section so this union will contain
max possible size of structure allocated and then create one
global slab for this (HW cache aligned). But it would be ugly hack I
believe and until we have no other choise I would prefer to not
play with this idea :)

>
>> For protocols being built in (like TCP, UDP, ICMP) for which I made
>> patches too but they are in a bit 'rought' state: in original
>> code there some kind of reference counter to sysctl tables being
>> registered (and they don't have any kind of mb, didn't check if it
>> could be a problem for SMP since they are mostly __init functions)
>> so I need some kind of same functionality to count per-net calls.
>
> The tables are shared between IPv4 and IPv6, this keeps track of the
> number of current users to avoid unregistering it while the AF-specific
> module for either one is loaded. This would still be a global counter
> with containers I think since module loading is global and they should
> be visible in all containers if IPv4 or IPv6 conntrack is loaded.

Yes, I even thought about kref usage here but kref doesn't have a few
function I need.

>
>> Will send RFC for these protocols soon.
>>
>> So eventually I would like to hear some kind of feedback on this.
>> Ideas and any kind of comments are highly appreciated.
>
>> +	sn->sysctl_table[0].data = &sn->sctp_timeouts[SCTP_CONNTRACK_CLOSED];
>> +	sn->sysctl_table[1].data = &sn->sctp_timeouts[SCTP_CONNTRACK_COOKIE_WAIT];
>> +	sn->sysctl_table[2].data = &sn->sctp_timeouts[SCTP_CONNTRACK_COOKIE_ECHOED];
>> +	sn->sysctl_table[3].data = &sn->sctp_timeouts[SCTP_CONNTRACK_ESTABLISHED];
>> +	sn->sysctl_table[4].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_SENT];
>> +	sn->sysctl_table[5].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_RECD];
>> +	sn->sysctl_table[6].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_ACK_SENT];
>
> Please use an iteration to avoid these repetitve overly long lines.
>

Ah, thanks a lot! Indeed.

	- Cyrill -
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html