From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKCzZ-0000qH-LV for qemu-devel@nongnu.org; Fri, 05 Oct 2012 14:51:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TKCzY-0004aq-Cp for qemu-devel@nongnu.org; Fri, 05 Oct 2012 14:51:21 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:57833) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKCzY-0004am-8V for qemu-devel@nongnu.org; Fri, 05 Oct 2012 14:51:20 -0400 Received: from /spool/local by e1.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 5 Oct 2012 14:51:19 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q95Ip0ao17956964 for ; Fri, 5 Oct 2012 14:51:00 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q95Iox0o006487 for ; Fri, 5 Oct 2012 15:50:59 -0300 Message-ID: <506F2C12.1000000@linux.vnet.ibm.com> Date: Fri, 05 Oct 2012 14:50:58 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1349460425-30601-1-git-send-email-coreyb@linux.vnet.ibm.com> <1349460425-30601-2-git-send-email-coreyb@linux.vnet.ibm.com> <506F285F.1000405@redhat.com> In-Reply-To: <506F285F.1000405@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/4] monitor: Less restrictive fd matching for fd sets List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: libvir-list@redhat.com, kwolf@redhat.com, qemu-devel@nongnu.org On 10/05/2012 02:35 PM, Eric Blake wrote: > On 10/05/2012 12:07 PM, Corey Bryant wrote: >> Currently, in order to use a file descriptor that resides in an >> fd set, the access mode flag of the qemu_open() call has to be >> an exact match of the access mode flag of an fd in the requested >> fd set. >> >> This patch lightens up that restriction. For example, if QEMU >> attempts to qemu_open() "/dev/fdset/2" with O_RDONLY or O_WRONLY, >> and an fd in fd set 2 has O_RDWR, the call will now be successful. > > I was right for wondering if we'd need this, back when fdsets were first > implemented. :) Yeah yeah yeah :) > > However... > >> >> Signed-off-by: Corey Bryant >> --- >> monitor.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/monitor.c b/monitor.c >> index a0e3ffb..34a968c 100644 >> --- a/monitor.c >> +++ b/monitor.c >> @@ -2304,7 +2304,8 @@ int monitor_fdset_get_fd(int64_t fdset_id, int flags) >> return -1; >> } >> >> - if ((flags & O_ACCMODE) == (mon_fd_flags & O_ACCMODE)) { >> + if ((mon_fd_flags & O_ACCMODE) == O_RDWR || >> + (mon_fd_flags & O_ACCMODE) == (flags & O_ACCMODE)) { >> return mon_fdset_fd->fd; >> } > > Is this always the right fd to return? Suppose I create a set that > contains two fds, one O_RDONLY and another O_RDWR; and that the current > qemu_open() is requesting O_RDONLY. It feels like we would want to get > the O_RDONLY fd returned, even if it comes later in the set, since it is > nominally safer. > > That is, I wonder if this should really be implemented as an iteration > over the set that selects the best possible match, where more than one > fd can match, but at the end of the iteration, we have the closest match > possible, rather than the first (possibly inexact) match. > Actually I think we can go back to requiring an exact match if we use your new proposal of adding a new command that allows multiple fd's to be added to an fd set over the command line. -- Regards, Corey Bryant