From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMJtT-0005sz-81 for qemu-devel@nongnu.org; Thu, 11 Oct 2012 10:37:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TMJtJ-0000Ba-O6 for qemu-devel@nongnu.org; Thu, 11 Oct 2012 10:37:47 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:34642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMJtJ-0000BU-Jw for qemu-devel@nongnu.org; Thu, 11 Oct 2012 10:37:37 -0400 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 11 Oct 2012 10:30:54 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q9BETTPe160550 for ; Thu, 11 Oct 2012 10:29:29 -0400 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q9BETRQX008268 for ; Thu, 11 Oct 2012 08:29:27 -0600 Message-ID: <5076D7C2.1090200@linux.vnet.ibm.com> Date: Thu, 11 Oct 2012 10:29:22 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1349878805-16352-1-git-send-email-coreyb@linux.vnet.ibm.com> <1349878805-16352-2-git-send-email-coreyb@linux.vnet.ibm.com> <5075ED80.3050202@redhat.com> In-Reply-To: <5075ED80.3050202@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1/3] monitor: Allow add-fd to any specified fd set List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, libvir-list@redhat.com, qemu-devel@nongnu.org On 10/10/2012 05:49 PM, Eric Blake wrote: > On 10/10/2012 08:20 AM, Corey Bryant wrote: >> The first call to add an fd to an fd set was previously not >> allowed to choose the fd set ID. The ID was generated as >> the first available and ensuing calls could add more fds by >> specifying the fd set ID. This change allows users to >> choose the fd set ID on the first call. > > Unfortunately, it now allows the user to choose arbitrary integer set > ids with large gaps, where previously, the user could only influence set > ids by populating all intermediate ids. That is, before this patch, a > user would have to create 1000000 sets to have an id of 1000000 (if they > didn't run out of memory first on all the earlier sets), but now they > can have an id that large with just one set. Or, taken further, > previously, a user request of -9223372036854775808 would likely fail (if > not, how beefy is your machine?), but now it can succeed and cause > confusion because of integer wraparound. Arbitrary set ids is not > necessarily bad, but I think you need to add bounds-checking on the > user's requested fdset_id to make sure it is positive. > I agree. I'll add some set ID bounds checking in v3. -- Regards, Corey Bryant