From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752439AbcGODSq (ORCPT <rfc822;w@1wt.eu>);
	Thu, 14 Jul 2016 23:18:46 -0400
Received: from mga11.intel.com ([192.55.52.93]:58370 "EHLO mga11.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751279AbcGODSp (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 14 Jul 2016 23:18:45 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.28,366,1464678000"; 
   d="scan'208";a="734522320"
Date: Fri, 15 Jul 2016 11:18:41 +0800
From: Liu Shuo <shuo.a.liu@intel.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Paolo Bonzini <pbonzini@redhat.com>, linux-kernel@vger.kernel.org,
        kvm@vger.kernel.org, Zhang Yanmin <yanmin_zhang@linux.intel.com>,
        He Bo <bo.he@intel.com>, Liu Shuo <shuox.liu@gmail.com>,
        Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
Subject: Re: [PATCH] KVM: release anon file in failure path of vm creation
Message-ID: <20160715031841.GA20887@shuo-desktop.sh.intel.com>
References: <1468316323-23835-1-git-send-email-shuo.a.liu@intel.com>
 <28049c2a-1b49-1909-52ce-105859e14e33@redhat.com>
 <20160714164647.GD14480@ZenIV.linux.org.uk>
 <20160715022204.GA16729@shuo-desktop.sh.intel.com>
 <20160715022603.GG14480@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20160715022603.GG14480@ZenIV.linux.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri 15.Jul'16 at  3:26:03 +0100, Al Viro wrote:
>On Fri, Jul 15, 2016 at 10:22:04AM +0800, Liu Shuo wrote:
>> > You have no warranty whatsoever that descriptor table has not been changed
>> > by that point.  You should *NEVER* use sys_close() on failure exit paths
>> Could you please elaborate why we're not sure descriptor table's changing at the point?
>
>Because that could be called by one thread while another (having guessed the
>descriptor you are about to get) does close()/dup2()/etc.
If there is no such thread (who operates the descriptor based on
guessing), i can think the changing is safe at the point. As the fd has
not been delivered to userspace. Am i right?