All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cong Wang <amwang@redhat.com>
To: Octavian Purdila <opurdila@ixiacom.com>
Cc: David Miller <davem@davemloft.net>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	Linux Kernel Developers <linux-kernel@vger.kernel.org>,
	Neil Horman <nhorman@tuxdriver.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [net-next PATCH v6 0/3] net: reserve ports for applications using fixed port numbers
Date: Mon, 01 Mar 2010 12:15:28 +0800	[thread overview]
Message-ID: <4B8B3F60.8030007@redhat.com> (raw)
In-Reply-To: <1267233952-5856-1-git-send-email-opurdila@ixiacom.com>

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.

      parent reply	other threads:[~2010-03-01  4:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-27  1:25 [net-next PATCH v6 0/3] net: reserve ports for applications using fixed port numbers Octavian Purdila
2010-02-27  1:25 ` [net-next PATCH v6 1/3] sysctl: refactor integer handling proc code Octavian Purdila
2010-02-27  1:25 ` [net-next PATCH v6 2/3] sysctl: add proc_do_large_bitmap Octavian Purdila
2010-02-27  1:25 ` [net-next PATCH v6 3/3] net: reserve ports for applications using fixed port numbers Octavian Purdila
2010-02-27 11:32 ` [net-next PATCH v6 0/3] " David Miller
2010-03-04  8:31   ` Cong Wang
2010-03-04 19:14     ` Eric W. Biederman
2010-03-04 20:11       ` Octavian Purdila
2010-03-04 21:14         ` Eric W. Biederman
2010-03-10  9:23       ` Cong Wang
2010-03-10 12:42         ` Octavian Purdila
2010-03-01  4:15 ` Cong Wang [this message]

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=4B8B3F60.8030007@redhat.com \
    --to=amwang@redhat.com \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=opurdila@ixiacom.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.