From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by dpdk.org (Postfix) with ESMTP id E03F6C398 for ; Fri, 10 Jul 2015 16:50:02 +0200 (CEST) Received: by wicmv11 with SMTP id mv11so15970316wic.1 for ; Fri, 10 Jul 2015 07:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mirantis.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jUNTTWqfEKQzaox7mnxu/xvfVQ1nl8Ljtya34iJ5Dzk=; b=DzV9AjjKuQtIinDuXaeAxmPA0hUQXwf1LvjkjL3Lu65GXSyM/L88+kDs1WC3odi53m 3CpNrvNf+ZB9fVAQwqXFHqFuHTtaQS4JJqn1o2BaJ02eaSkvULC8gS0NnfZIl9wUaLGx JGl01i3C7FjtbPW6TjiFc3wMilc8zMQ5Y2qqc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jUNTTWqfEKQzaox7mnxu/xvfVQ1nl8Ljtya34iJ5Dzk=; b=e5GMQh951E4B46TdAA/OEeJDqZOhsNC4BRnZhfQso39DGQxwdmMG21NrjT7Y4qMaNg 9zfEkBN3udnKYvkCO+aK7RPcLsX89RA8+QwJwmcuBkowgvJczr1XQ3py/JEBOMk88Bsh rcasEiKWBK2/RarxjTM5XKrekYjD3zBqFkGNpX6ru0ETBPvGVYsQ8Nu/fK8BcVIPnGJ2 sHWmS/RpeQ0tSxzpld9rt/tPTYf9FsKtexq0YqbFMKM1/W4wOgwEs3taKuqXgH6amT7J XcaXJp9Mst0pqvUiKbRS6WTb1c7dXcW20apuFte54n2TaSTRxNsUmgmSNE+9I1ZFsk4a IMuw== X-Gm-Message-State: ALoCoQm2mOo4fiApTtYBjBTEFJ7cEuYHKMwxAdPi4WNrbxj6W0Ce9+avDLlxyiSN8XPR7h98spmJ MIME-Version: 1.0 X-Received: by 10.194.63.20 with SMTP id c20mr4661714wjs.134.1436539802745; Fri, 10 Jul 2015 07:50:02 -0700 (PDT) Received: by 10.194.64.102 with HTTP; Fri, 10 Jul 2015 07:50:02 -0700 (PDT) In-Reply-To: References: <1427994080-10163-1-git-send-email-pboldin@mirantis.com> <1429184910-30186-5-git-send-email-pboldin@mirantis.com> <1665929.SfCu3BinAE@xps13> Date: Fri, 10 Jul 2015 17:50:02 +0300 Message-ID: From: Pavel Boldin To: "Xie, Huawei" X-Mailman-Approved-At: Fri, 10 Jul 2015 16:55:40 +0200 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v5 4/5] vhost: eventfd_link: replace copy-pasted sys_close X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 14:50:03 -0000 Xie, Regarding the patches: 1. The replaced code in fourth patch is checked to be a copy-paste of the `sys_close` syscall. 2. It is not uncommon for the applications to close FD making it allocated for a different file. In our particular case the file is closed in the *source* process and *added* to a target process, so matching fds should not be the problem. 3. There is an implementation of the exact same thing in the SCM_RIGHTS [1] that can be used as the reference code. [1] https://github.com/torvalds/linux/blob/master/net/core/scm.c#L248 Pavel On Fri, Jul 10, 2015 at 5:27 PM, Xie, Huawei wrote: > On 6/17/2015 11:24 PM, Thomas Monjalon wrote: > > 2015-05-07 06:54, Xie, Huawei: > >> On 4/16/2015 7:48 PM, Pavel Boldin wrote: > >>> + /* Closing the source_fd */ > >>> + ret = sys_close(eventfd_copy.source_fd); > >> Pavel: > >> Here we close the fd and re-install a new file on this fd later. > >> sys_close does all cleanup. > >> But, for instance, if we allocate new fd later, normally it will reuse > >> the just freed fds by sys_close, is there issue here? > > Pavel, Huawei, > > Could we come to a conclusion on this patch series please? > For the previous 3 patches, i am OK except that i don't think inline is > needed explicitly for non-performance critical function. > For this patch, didn't check the fs code. > > > > > > >