From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Nyashka Surovski <nyashka.surovski@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: xc_map_foreign_bulk() memory leak in ARM version?
Date: Mon, 20 May 2013 15:39:32 -0400 [thread overview]
Message-ID: <20130520193932.GA29900@phenom.dumpdata.com> (raw)
In-Reply-To: <CAOM=f9_B9m_4wx7ABtazjUBJVr9rbVnGAzqh6NNTqBR78vF8iw@mail.gmail.com>
On Mon, May 20, 2013 at 11:55:48AM +0400, Nyashka Surovski wrote:
> Oh.. We have found out the root of the problem.
> In our version of code there was a mistake in condition inside
> privcmd_close().
>
> It was:
> if (!xen_feature(XENFEAT_auto_translated_physmap || !numpgs || !pages))
>
> But the right one is:
> if (!xen_feature(XENFEAT_auto_translated_physmap) || !numpgs || !pages)
>
> Looks like typo.
>
> git blame shows that this version of code was added in commit
> d71f513985c22f1050295d1a7e4327cf9fb060da on Oct 17 2012, so you can check
> it.
the fix for that is going to be sent to Linus shortly.
>
> Thanks for your replies!
>
> Best regards,
> Nyashka
>
>
> 2013/5/17 Mukesh Rathor <mukesh.rathor@oracle.com>
>
> > On Fri, 17 May 2013 11:14:00 +0100
> > Ian Campbell <ian.campbell@citrix.com> wrote:
> >
> > > On Thu, 2013-05-16 at 19:36 +0400, Nyashka Surovski wrote:
> > > > Hi Xen folks!
> > > >
> > > >
> > > > I've faced with one strange thing in ARM version of Xen: when I use
> > > > xc_map_foreign_bulk() to map some memory from domU to dom0, after
> > > > unmap() for previous returned address - memory is not freed at all.
> > > >
> > > >
> > > > Let's look at call stack:
> > > >
> > > >
> > > > xc_map_foreign() ->
> > > > linux_privcmd_map_foreign_bulk() ->
> > > > {
> > > > addr = mmap(fd);
> > > > ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2 );
> > > > } ->
> > > > alloc_empty_pages() ->
> > > > alloc_xenballoned_pages();
> > > >
> > > > So, I think that unmap(addr) must call free_xenballoned_pages(), but
> > > > this doesn't happen. =(
> > > > Let me note, that mmap() knows about privcmd_close() function, and
> > > > it is the place where free_xenballoned_pages() is called, So we
> > > > have that unmap() doesn't call privcmd_close() at all. It's
> > > > something strange for me.
> > > >
> > > > Can somebody show me the place of my misunderstanding, or is it a
> > > > real bug?
> > >
> > > Do you mean munmap()?
> > >
> > > I think munmap will eventually end up calling close, when the
> > > references to the vma etc are gone. Since the code path is a bit
> > > twisty I'd be tempted to throw in a debug printk to confirm though.
> > >
> > > Can you share your usercode?
> >
> > I dealt with that a lot during PVH debug. Yes, munmap will call close.
> > If the process exits without calling munmap, then do_exit -> exit_mm will
> > result in call to privcmd_close.
> >
> > hope that helps.
> > Mukesh
> >
> >
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
prev parent reply other threads:[~2013-05-20 19:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-16 15:36 xc_map_foreign_bulk() memory leak in ARM version? Nyashka Surovski
2013-05-17 10:14 ` Ian Campbell
2013-05-17 19:13 ` Mukesh Rathor
2013-05-20 7:55 ` Nyashka Surovski
2013-05-20 9:19 ` Ian Campbell
2013-05-20 19:39 ` Konrad Rzeszutek Wilk [this message]
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=20130520193932.GA29900@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=nyashka.surovski@gmail.com \
--cc=xen-devel@lists.xen.org \
/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.