WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] netfront leaking two pages on unload?

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] netfront leaking two pages on unload?
From: Andy Grover <andy.grover@xxxxxxxxxx>
Date: Fri, 18 Jan 2008 12:35:15 -0800
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 18 Jan 2008 12:36:47 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3B5295D.1AFD4%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C3B5295D.1AFD4%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2008-01-17 at 15:48 +0000, Keir Fraser wrote:
> On 16/1/08 21:16, "Andy Grover" <andy.grover@xxxxxxxxxx> wrote:

> > Otherwise the pages cannot be freed properly in the guest, right?
> 
> Well, I think you've chosen slightly the wrong place, so I've just committed
> a change that makes the close-down logic more like in blkback. Possibly the
> reason we didn't follow that same logic before is that netif_disconnect()
> also makes the network device in dom0 also go away, which might cause
> unwanted chnages to routing and firewall rules, execution of hotplug
> scripts, etc. But we can separate the concepts of relinquishing frontend
> resources and destroying the backend netdev later if it turns out to be
> necessary.

Thanks for taking a look.

I was going to put together a patch to properly free the 2 pages in
netfront, but it looks like this is already handled inside
gnttab_end_foreign_access().

It seems a little non-intuitive that gnttab_end_foreign_access doesn't
just end foreign access, it frees the page too. This leads to what
confused me -- a driver allocating a page but (seemingly) never freeing
it.

I think it might be clearer to make callers explicitly free the page
after checking gnttab_end_foreign_access's return val for success. Would
you accept a patch doing this, or are there other reasons for the
current code?

Thanks -- Regards -- Andy



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>