net: reserve ports for applications using fixed port numbers [Kernel]

Prev: [PATCH v3 2/7] net: remove old tcp_optlen function
Next: Loan Offer

From: Cong Wang on 20 Feb 2010 21:00

Octavian Purdila wrote:
> On Saturday 20 February 2010 10:20:53 you wrote:
>
>>> +unsigned long *sysctl_local_reserved_ports;
>>> +EXPORT_SYMBOL(sysctl_local_reserved_ports);
>>> +
>> Sorry, this looks somewhat weird, why not just export
>> inet_is_reserved_local_port()?
>>
>
> My understanding is that if we do that than we won't be able to inline
> inet_is_reserved_local_port(). And as David said previously that will have a
> significant impact on performance.

Oh, that would be true probably, so just leave as it is.

Thanks.

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

From: Cong Wang on 21 Feb 2010 01:40

From: Cong Wang on 28 Feb 2010 23:20

Octavian Purdila wrote:
> This patch introduces /proc/sys/net/ipv4/ip_local_reserved_ports which
> allows users to reserve ports for third-party applications.
>
> The reserved ports will not be used by automatic port assignments
> (e.g. when calling connect() or bind() with port number 0). Explicit
> port allocation behavior is unchanged.
>
> Changes from the previous version:
> - be more strict on accepted input (only comma separators, no spaces allowed)
> - add to the docs a paragraph about ip_local_port_range and
> ip_local_reserved_ports relationship
> - fix a few corner cases with parsing
>

Thanks for keeping working on this!

Then this version should be fine now.

> There are still some miss behaviors with regard to proc parsing in odd
> invalid cases (for "40000\0-40001" all is acknowledged but only 40000
> is accepted) but they are not easy to fix without changing the current
> "acknowledge how much we accepted" behavior.

I think this is the right behavior.

>
> Because of that and because the same issues are present in the
> existing proc_dointvec code as well I don't think its worth holding
> the actual feature (port reservation) after such petty error recovery
> issues.
>
> For the sake of discussion, I think Eric was right: the model we are
> using is messy, we should only accept all input or none. If we can
> (ABI implications) and you think its worth switching to this model I
> can give it a try in a future patch.
>

Well, this depends, for things like "40000b", we should reject it,
since it is invalid, for "40000\0-40001", I think returning 5 is alright.

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

From: Cong Wang on 4 Mar 2010 03:30

David Miller wrote:
> Eric B., could you look over the first two patches (which touch the
> sysctl core) and give some review and ACK/NACK?
>

ping Eric W. Biederman ... :)

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

From: Cong Wang on 10 Mar 2010 04:30

Eric W. Biederman wrote:
>
> I would add the restriction that the values in the list of ranges
> always must be increasing, and in general restrict the set of accepted
> values as much as possible. If we don't accept it now we don't have
> to worry about some userspace application relying on some unitended
> side effect a few years into the future.

I don't think this is good.

Suppose that when I just want to add one port into the list and keep the
original ones, I want to do this:

orig=$(cat ip_local_reserved_ports)
new_list="$orig, $new_one"
echo "$new_list" > ip_local_reserved_ports

If we add this restriction, the above could be failed if the new port
is lower than the original ones. This will be not convenient.

>
>
> I think it is a serious bug that you clear the destination bitmap
> in the middle of parsing it. That will either open or close all
> ports in the middle of parsing, and I can't see how that would
> ever be a good thing.
>

Agreed.

By the way, Octavian, any new updates?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

First | Prev |
Pages: 1 2 3
Prev: [PATCH v3 2/7] net: remove old tcp_optlen function
Next: Loan Offer