linux-kernel - Re: [PATCH 00/13] SCTP: Enable netns

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: <87txwfipt1.fsf@xmission.com>
Date:	Mon, 06 Aug 2012 16:06:02 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Vlad Yasevich <vyasevich@...il.com>
Cc:	David Miller <davem@...emloft.net>, jan.ariyasu@...il.com,
	linux-sctp@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, jan.ariyasu@...com
Subject: Re: [PATCH 00/13] SCTP: Enable netns

Vlad Yasevich <vyasevich@...il.com> writes:

> On 08/06/2012 04:47 PM, David Miller wrote:
>> From: ebiederm@...ssion.com (Eric W. Biederman)
>> Date: Mon, 06 Aug 2012 12:50:46 -0700
>>
>>> Vlad Yasevich <vyasevich@...il.com> writes:
>>>
>>>
>>>> Hi Eric
>>>>
>>>> Associations are looked up by ports, but then verifyed by addresses.
>>>> Also, associations belong to sockets and simply validating the socket
>>>> namespace should be sufficient.
>>>
>>> True.  Your set of patches isn't quite as likely to malfunction as it
>>> looked at first glance.  It requires address reuse which happens accross
>>> namespaces but not too frequently.
>>>
>>> As for validating the socket namespace I agree that is the fix and my
>>> patchset winds up doing it.
>>
>> FWIW I much prefer Eric's patch set, it was so significantly easier to
>> read and validate than Jan's.
>>
>
> Yes, but Eric's patch set is missing a very significant piece which is per-net
> sctp tunables/globals.  I think adding that piece in will introduce some of the
> complexities of Jan's patch.

And Jan's patchset is missing the per net snmp counters, as well
as the per net checks when looking in the hash tables.  Things that look
like fairly fundamental correctness issues.

No offense but I think Jan's patchset has minor but significant
structural flaws and correctness issues that would require the patchset
to be respun, after review even if my patches did not exist.

The poor movement of variables from their global context into the per
net context is one of those problems.

The fact that after Jan's patchset all of the tunables despite being
made per net remain in struct sctp_globals and sit their unused is a
recipe for confusion.

So I think the simplest path forward would be to merge my patches, and
then merge Jan's tunable work after she has had a chance to rebase it.

> Also, I noticed that Eric went the route of placing sctp netns into struct net,
> but Jan used a generic pointer.  Which one should be used? Is there some
> guidance?

Placing things directly in struct net is more efficient.  Using net
generic is more convenient for development as using net generic does not
require a kernel recompile.

For minor things and especially where it does not have an impact on
performance net generic is the way to go.

It looked to me that sctp was fundamental enough and had enough
important data structures on the hot path that placing the variables
in struct net directly seemed sensible.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/