From: Paolo Bonzini <pbonzini@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: Yann Droneaud <ydroneaud@opteya.com>,
Gleb Natapov <gleb@redhat.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Alex Williamson <alex.williamson@redhat.com>,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag
Date: Mon, 26 Aug 2013 07:39:14 +0000 [thread overview]
Message-ID: <521B0622.9090208@redhat.com> (raw)
In-Reply-To: <3557EF65-4327-4DAE-999A-B0EE13C433F5@suse.de>
Il 25/08/2013 17:04, Alexander Graf ha scritto:
>
> On 24.08.2013, at 21:14, Yann Droneaud wrote:
>
>> KVM uses anon_inode_get() to allocate file descriptors as part
>> of some of its ioctls. But those ioctls are lacking a flag argument
>> allowing userspace to choose options for the newly opened file descriptor.
>>
>> In such case it's advised to use O_CLOEXEC by default so that
>> userspace is allowed to choose, without race, if the file descriptor
>> is going to be inherited across exec().
>>
>> This patch set O_CLOEXEC flag on all file descriptors created
>> with anon_inode_getfd() to not leak file descriptors across exec().
>>
>> Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
>> Link: http://lkml.kernel.org/r/cover.1377372576.git.ydroneaud@opteya.com
>
> Reviewed-by: Alexander Graf <agraf@suse.de>
>
> Would it make sense to simply inherit the O_CLOEXEC flag from the
> parent kvm fd instead? That would give user space the power to keep
> fds across exec() if it wants to.
Does it make sense to use non-O_CLOEXEC file descriptors with KVM at
all? Besides fork() not being supported by KVM, as described in
Documentation/virtual/kvm/api.txt, the VMAs of the parent process go
away as soon as you exec(). I'm not sure how you can use the inherited
file descriptor in a sensible way after exec().
Paolo
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: Yann Droneaud <ydroneaud@opteya.com>,
kvm@vger.kernel.org, Gleb Natapov <gleb@redhat.com>,
linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org,
Alex Williamson <alex.williamson@redhat.com>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/2] ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag
Date: Mon, 26 Aug 2013 09:39:14 +0200 [thread overview]
Message-ID: <521B0622.9090208@redhat.com> (raw)
In-Reply-To: <3557EF65-4327-4DAE-999A-B0EE13C433F5@suse.de>
Il 25/08/2013 17:04, Alexander Graf ha scritto:
>
> On 24.08.2013, at 21:14, Yann Droneaud wrote:
>
>> KVM uses anon_inode_get() to allocate file descriptors as part
>> of some of its ioctls. But those ioctls are lacking a flag argument
>> allowing userspace to choose options for the newly opened file descriptor.
>>
>> In such case it's advised to use O_CLOEXEC by default so that
>> userspace is allowed to choose, without race, if the file descriptor
>> is going to be inherited across exec().
>>
>> This patch set O_CLOEXEC flag on all file descriptors created
>> with anon_inode_getfd() to not leak file descriptors across exec().
>>
>> Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
>> Link: http://lkml.kernel.org/r/cover.1377372576.git.ydroneaud@opteya.com
>
> Reviewed-by: Alexander Graf <agraf@suse.de>
>
> Would it make sense to simply inherit the O_CLOEXEC flag from the
> parent kvm fd instead? That would give user space the power to keep
> fds across exec() if it wants to.
Does it make sense to use non-O_CLOEXEC file descriptors with KVM at
all? Besides fork() not being supported by KVM, as described in
Documentation/virtual/kvm/api.txt, the VMAs of the parent process go
away as soon as you exec(). I'm not sure how you can use the inherited
file descriptor in a sensible way after exec().
Paolo
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: Yann Droneaud <ydroneaud@opteya.com>,
Gleb Natapov <gleb@redhat.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Alex Williamson <alex.williamson@redhat.com>,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag
Date: Mon, 26 Aug 2013 09:39:14 +0200 [thread overview]
Message-ID: <521B0622.9090208@redhat.com> (raw)
In-Reply-To: <3557EF65-4327-4DAE-999A-B0EE13C433F5@suse.de>
Il 25/08/2013 17:04, Alexander Graf ha scritto:
>
> On 24.08.2013, at 21:14, Yann Droneaud wrote:
>
>> KVM uses anon_inode_get() to allocate file descriptors as part
>> of some of its ioctls. But those ioctls are lacking a flag argument
>> allowing userspace to choose options for the newly opened file descriptor.
>>
>> In such case it's advised to use O_CLOEXEC by default so that
>> userspace is allowed to choose, without race, if the file descriptor
>> is going to be inherited across exec().
>>
>> This patch set O_CLOEXEC flag on all file descriptors created
>> with anon_inode_getfd() to not leak file descriptors across exec().
>>
>> Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
>> Link: http://lkml.kernel.org/r/cover.1377372576.git.ydroneaud@opteya.com
>
> Reviewed-by: Alexander Graf <agraf@suse.de>
>
> Would it make sense to simply inherit the O_CLOEXEC flag from the
> parent kvm fd instead? That would give user space the power to keep
> fds across exec() if it wants to.
Does it make sense to use non-O_CLOEXEC file descriptors with KVM at
all? Besides fork() not being supported by KVM, as described in
Documentation/virtual/kvm/api.txt, the VMAs of the parent process go
away as soon as you exec(). I'm not sure how you can use the inherited
file descriptor in a sensible way after exec().
Paolo
next prev parent reply other threads:[~2013-08-26 7:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-24 20:14 [PATCH 0/2] kvm: use anon_inode_getfd() with O_CLOEXEC flag Yann Droneaud
2013-08-24 20:14 ` Yann Droneaud
2013-08-24 20:14 ` Yann Droneaud
2013-08-24 20:14 ` [PATCH 1/2] " Yann Droneaud
2013-08-25 6:49 ` Paolo Bonzini
2013-08-24 20:14 ` [PATCH 2/2] ppc: " Yann Droneaud
2013-08-24 20:14 ` Yann Droneaud
2013-08-24 20:14 ` Yann Droneaud
2013-08-25 15:04 ` Alexander Graf
2013-08-25 15:04 ` Alexander Graf
2013-08-25 15:04 ` Alexander Graf
2013-08-26 7:39 ` Paolo Bonzini [this message]
2013-08-26 7:39 ` Paolo Bonzini
2013-08-26 7:39 ` Paolo Bonzini
2013-08-26 8:23 ` [PATCH 2/2] ppc: kvm: use anon_inode_getfd( =?UTF-8?Q?=29=20with=20O=5FCLOEXEC Yann Droneaud
2013-08-26 8:23 ` [PATCH 2/2] ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag Yann Droneaud
2013-08-26 8:23 ` Yann Droneaud
2013-08-26 8:28 ` Paolo Bonzini
2013-08-26 8:28 ` Paolo Bonzini
2013-08-26 8:28 ` Paolo Bonzini
2013-08-26 10:20 ` [PATCH 0/2] " Gleb Natapov
2013-08-26 10:20 ` Gleb Natapov
2013-08-26 10:20 ` Gleb Natapov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=521B0622.9090208@redhat.com \
--to=pbonzini@redhat.com \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=gleb@redhat.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
--cc=ydroneaud@opteya.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.