netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Cong Wang <amwang@redhat.com>
Cc: David Miller <davem@davemloft.net>,
	opurdila@ixiacom.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, nhorman@tuxdriver.com,
	eric.dumazet@gmail.com
Subject: Re: [net-next PATCH v6 0/3] net: reserve ports for applications using fixed port numbers
Date: Thu, 04 Mar 2010 11:14:07 -0800	[thread overview]
Message-ID: <m1vddbdhmo.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4B8F6FF0.5000306@redhat.com> (Cong Wang's message of "Thu\, 04 Mar 2010 16\:31\:44 +0800")

Cong Wang <amwang@redhat.com> writes:

> 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 ... :)

I have looked and it is not easy to tell by simple review if
correctness has been maintained in the proc cleanup patch.
Furthermore the code even after the cleanups still feels like code
that is trying too hard to do too much.


I think the example set by bitmap_parse_user in it's user interface is
a good example to follow when constructing bitmap helper functions.
Including having the actual parsing code should live in lib/bitmap.c

The users of bitmap_parse_user do something very nice.  They allocate
a temporary bitmap.  Parse the userspace value into the temporary
bitmap, and then move that new bitmap into the kernel data structures.
For your large bitmap this seems like the idea way to handle it.  That
guarantees no weird intermediate failure states, and really makes the
the bitmap feel like a single value.

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 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.

Eric

  reply	other threads:[~2010-03-04 19:14 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 [this message]
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

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=m1vddbdhmo.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=amwang@redhat.com \
    --cc=davem@davemloft.net \
    --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 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).