From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZsR4u-0002Kq-EF for qemu-devel@nongnu.org; Sat, 31 Oct 2015 03:59:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZsR4r-0002un-7u for qemu-devel@nongnu.org; Sat, 31 Oct 2015 03:59:56 -0400 Received: from mga02.intel.com ([134.134.136.20]:43956) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZsR4r-0002ui-2y for qemu-devel@nongnu.org; Sat, 31 Oct 2015 03:59:53 -0400 References: <1446184587-142784-1-git-send-email-guangrong.xiao@linux.intel.com> <1446184587-142784-10-git-send-email-guangrong.xiao@linux.intel.com> <56337DD1.8010509@virtuozzo.com> From: Xiao Guangrong Message-ID: <56347361.4030300@linux.intel.com> Date: Sat, 31 Oct 2015 15:53:05 +0800 MIME-Version: 1.0 In-Reply-To: <56337DD1.8010509@virtuozzo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6 09/33] exec: allow file_ram_alloc to work on file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy , pbonzini@redhat.com, imammedo@redhat.com Cc: ehabkost@redhat.com, kvm@vger.kernel.org, mst@redhat.com, gleb@kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, dan.j.williams@intel.com, rth@twiddle.net On 10/30/2015 10:25 PM, Vladimir Sementsov-Ogievskiy wrote: > On 30.10.2015 08:56, Xiao Guangrong wrote: >> Currently, file_ram_alloc() only works on directory - it creates a file >> under @path and do mmap on it >> >> This patch tries to allow it to work on file directly, if @path is a >> directory it works as before, otherwise it treats @path as the target >> file then directly allocate memory from it >> >> Signed-off-by: Xiao Guangrong >> --- >> exec.c | 80 ++++++++++++++++++++++++++++++++++++++++++------------------------ >> 1 file changed, 51 insertions(+), 29 deletions(-) >> >> diff --git a/exec.c b/exec.c >> index 3ca7e50..f219010 100644 >> --- a/exec.c >> +++ b/exec.c >> @@ -1174,14 +1174,60 @@ void qemu_mutex_unlock_ramlist(void) >> } >> #ifdef __linux__ >> +static bool path_is_dir(const char *path) >> +{ >> + struct stat fs; >> + >> + return stat(path, &fs) == 0 && S_ISDIR(fs.st_mode); >> +} >> + >> +static int open_file_path(RAMBlock *block, const char *path, size_t size) > > I think the name should be more descriptive, as it is very special function in common exec.c and it > doesn't "just open file path'.. May be open_ram_file_path Okay, good to me. :) > > >> +{ >> + char *filename; >> + char *sanitized_name; >> + char *c; >> + int fd; >> + >> + if (!path_is_dir(path)) { >> + int flags = (block->flags & RAM_SHARED) ? O_RDWR : O_RDONLY; >> + >> + flags |= O_EXCL; >> + return open(path, flags); >> + } > > Was not there old scenarios when path is file? statfs will success for any file withing mounted > filesystem. > Yes. The old scenarios will create a temporary file under the @path that stop regular file's work. > Also, may be we shouldn't warn about "Memory is not allocated from HugeTlbfs.\n" in case of > !path_is_dir ? > A file from hugetlbfs and attach it as backend memory is a valid case to users.