Re: [Qemu-devel] [PATCH] fix the memory leak for share hugepage

[Daniel P. Berrange]

On Sat, Oct 18, 2014 at 11:20:13AM +0800, Linhaifeng wrote:
> 
> 
> On 2014/10/17 21:26, Daniel P. Berrange wrote:
> > On Fri, Oct 17, 2014 at 04:57:27PM +0800, Linhaifeng wrote:
> >>
> >>
> >> On 2014/10/17 16:33, Daniel P. Berrange wrote:
> >>> On Fri, Oct 17, 2014 at 04:27:17PM +0800, address@hidden wrote:
> >>>> From: linhaifeng <address@hidden>
> >>>>
> >>>> The VM start with share hugepage should close the hugefile fd
> >>>> when exit.Because the hugepage fd may be send to other process
> >>>> e.g vhost-user If qemu not close the fd the other process can
> >>>> not free the hugepage otherwise exit process,this is ugly,so
> >>>> qemu should close all shared fd when exit.
> >>>>
> >>>> Signed-off-by: linhaifeng <address@hidden>
> >>>
> >>> Err, all file descriptors are closed automatically when a process
> >>> exits. So manually calling close(fd) before exit can't have any
> >>> functional effect on a resource leak.
> >>>
> >>> If QEMU has sent the FD to another process, that process has a
> >>> completely separate copy of the FD. Closing the FD in QEMU will
> >>> not close the FD in the other process. You need the other process
> >>> to exit for the copy to be closed.
> >>>
> >>> Regards,
> >>> Daniel
> >>>
> >> Hi,daniel
> >>
> >> QEMU send the fd by unix domain socket.unix domain socket just install the 
> >> fd to
> >> other process and inc the f_count,if qemu not close the fd the f_count is 
> >> not dec.
> >> Then the other process even close the fd the hugepage would not freed 
> >> whise the other process exit.
> > 
> > The kernel always closes all FDs when a process exits. So if this FD is
> > not being correctly closed then it is a kernel bug. There should never
> > be any reason for an application to do close(fd) before exiting.
> > 
> > Regards,
> > Daniel
> > 
> Hi,daniel
> 
> I don't think this is kernel's bug.May be this a problem about usage.
> If you open a file you should close it too.

No, the standard UNIX semantics are that the kernel will close all
file descriptors when a process exits. There is *no* requirement to
manually close any file descriptors before exiting.

The only time you need to close files is if you are using a higher
level API (eg C library "FILE *" ) and you need to explicitly flush
any buffered I/O operations before exiting. This doesn't apply in the
case of huge pages.

> Run the first VM.QEMU deal with hugepage as follow steps:
> 1.open
> 2.unlink
> 3.mmap
> 4.use memory of hugepage and send the fd to vapp with unix domain 
> socket.After this step the meminfo is:

If the QEMU process has exited then the kernel has closed the FD that
QEMU had open. The logical implication is that the 'vapp' process still
has its copy of the file descriptor open even after QEMU has exited.

Another possibility is that whatever launched QEMU has not done a waitpid
and thus leaving QEMU in a zombie state where file descriptors are not
yet cleaned up.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|