On Fri 15.Jul'16 at 6:09:59 +0100, Al Viro wrote:
On Fri, Jul 15, 2016 at 11:18:41AM +0800, Liu Shuo wrote:
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?
On Fri 15.Jul'16 at 6:09:59 +0100, Al Viro wrote:
On Fri, Jul 15, 2016 at 11:18:41AM +0800, Liu Shuo wrote:
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?
On Fri, Jul 15, 2016 at 11:18:41AM +0800, Liu Shuo wrote:
> 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?
Expecting nice behaviour from userland code is
On Fri, Jul 15, 2016 at 11:18:41AM +0800, Liu Shuo wrote:
> 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?
Expecting nice behaviour from userland code is
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
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
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
>
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
>
On Thu 14.Jul'16 at 17:46:47 +0100, Al Viro wrote:
On Tue, Jul 12, 2016 at 12:24:39PM +0200, Paolo Bonzini wrote:
On 12/07/2016 11:38, Liu Shuo wrote:
> The failure of create debugfs of VM will return directly without release
> the anon file. It will leak memory and file descriptors, even
On Thu 14.Jul'16 at 17:46:47 +0100, Al Viro wrote:
On Tue, Jul 12, 2016 at 12:24:39PM +0200, Paolo Bonzini wrote:
On 12/07/2016 11:38, Liu Shuo wrote:
> The failure of create debugfs of VM will return directly without release
> the anon file. It will leak memory and file descriptors, even
On 14/07/2016 18:46, Al Viro wrote:
> On Tue, Jul 12, 2016 at 12:24:39PM +0200, Paolo Bonzini wrote:
>
>> On 12/07/2016 11:38, Liu Shuo wrote:
>>> The failure of create debugfs of VM will return directly without release
>>> the anon file. It will leak memory and file descriptors, even through
On 14/07/2016 18:46, Al Viro wrote:
> On Tue, Jul 12, 2016 at 12:24:39PM +0200, Paolo Bonzini wrote:
>
>> On 12/07/2016 11:38, Liu Shuo wrote:
>>> The failure of create debugfs of VM will return directly without release
>>> the anon file. It will leak memory and file descriptors, even through
On Tue, Jul 12, 2016 at 12:24:39PM +0200, Paolo Bonzini wrote:
> On 12/07/2016 11:38, Liu Shuo wrote:
> > The failure of create debugfs of VM will return directly without release
> > the anon file. It will leak memory and file descriptors, even through
> > be not serious.
> >
> > Signed-off-by:
On Tue, Jul 12, 2016 at 12:24:39PM +0200, Paolo Bonzini wrote:
> On 12/07/2016 11:38, Liu Shuo wrote:
> > The failure of create debugfs of VM will return directly without release
> > the anon file. It will leak memory and file descriptors, even through
> > be not serious.
> >
> > Signed-off-by:
On 12/07/2016 11:38, Liu Shuo wrote:
> The failure of create debugfs of VM will return directly without release
> the anon file. It will leak memory and file descriptors, even through
> be not serious.
>
> Signed-off-by: Liu Shuo
> ---
> virt/kvm/kvm_main.c | 2 ++
> 1
On 12/07/2016 11:38, Liu Shuo wrote:
> The failure of create debugfs of VM will return directly without release
> the anon file. It will leak memory and file descriptors, even through
> be not serious.
>
> Signed-off-by: Liu Shuo
> ---
> virt/kvm/kvm_main.c | 2 ++
> 1 file changed, 2
The failure of create debugfs of VM will return directly without release
the anon file. It will leak memory and file descriptors, even through
be not serious.
Signed-off-by: Liu Shuo
---
virt/kvm/kvm_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
The failure of create debugfs of VM will return directly without release
the anon file. It will leak memory and file descriptors, even through
be not serious.
Signed-off-by: Liu Shuo
---
virt/kvm/kvm_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/virt/kvm/kvm_main.c
18 matches
Mail list logo