From: annie li <annie.li@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: David Vrabel <david.vrabel@citrix.com>,
ian.campbell@citrix.com, netdev@vger.kernel.org,
xen-devel@lists.xen.org, andrew.bennieston@citrix.com,
davem@davemloft.net
Subject: Re: [Xen-devel] [PATCH net-next v2] xen-netfront: clean up code in xennet_release_rx_bufs
Date: Fri, 17 Jan 2014 20:32:29 +0800 [thread overview]
Message-ID: <52D922DD.2060407@oracle.com> (raw)
In-Reply-To: <20140117120810.GA11681@zion.uk.xensource.com>
On 2014-1-17 20:08, Wei Liu wrote:
> On Fri, Jan 17, 2014 at 02:25:40PM +0800, annie li wrote:
>> On 2014/1/16 19:10, David Vrabel wrote:
>>> On 15/01/14 23:57, Annie Li wrote:
>>>> This patch implements two things:
>>>>
>>>> * release grant reference and skb for rx path, this fixex resource leaking.
>>>> * clean up grant transfer code kept from old netfront(2.6.18) which grants
>>>> pages for access/map and transfer. But grant transfer is deprecated in current
>>>> netfront, so remove corresponding release code for transfer.
>>>>
>>>> gnttab_end_foreign_access_ref may fail when the grant entry is currently used
>>>> for reading or writing. But this patch does not cover this and improvement for
>>>> this failure may be implemented in a separate patch.
>>> I don't think replacing a resource leak with a security bug is a good idea.
>>>
>>> If you would prefer not to fix the gnttab_end_foreign_access() call, I
>>> think you can fix this in netfront by taking a reference to the page
>>> before calling gnttab_end_foreign_access(). This will ensure the page
>>> isn't freed until the subsequent kfree_skb(), or the gref is released by
>>> the foreign domain (whichever is later).
>> Taking a reference to the page before calling
>> gnttab_end_foreign_access() delays the free work until kfree_skb().
>> Simply adding put_page before kfree_skb() does not make things
>> different from gnttab_end_foreign_access_ref(), and the pages will
>> be freed by kfree_skb(), problem will be hit in
>> gnttab_handle_deferred() when freeing pages which already be freed.
>>
> I think David's idea is:
>
> get_page
> gnttab_end_foreign_access
> kfree_skb
>
> The get_page is to offset put_page in gnttab_end_foreign_access. You
> don't need to put page before kfree_skb.
Yes, this is what I described as following about David's patch.
>> So put_page is required in gnttab_end_foreign_access(), this will
>> ensure either free is taken by kfree_skb or gnttab_handle_deferred.
>> This involves changes in blkfront/pcifront/tpmfront(just like your
>> patch), this way ensure page is released when ref is end.
But this would has some issue in netfront tx path. Netfront ends all
grant reference of one skb first and then release this skb. If the
gnttab_end_foreign_access_ref fails in gnttab_end_foreign_access(), this
frag page and corresponding grant reference will be put in entry and
release work will be done in the timer routine. If some frag pages of
one skb is free in this timer routine, then dev_kfree_skb_irq will free
pages which have been freed.
So I prefer following way I mentioned, suggestions?
>> Another solution I am thinking is calling
>> gnttab_end_foreign_access() with page parameter as NULL, then
>> gnttab_end_foreign_access will only do ending grant reference work
>> and releasing page work is done by kfree_skb().
Thanks
Annie
next prev parent reply other threads:[~2014-01-17 12:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-15 23:57 [Xen-devel][PATCH net-next v2] xen-netfront: clean up code in xennet_release_rx_bufs Annie Li
2014-01-16 11:10 ` David Vrabel
2014-01-16 13:42 ` annie li
2014-01-17 1:25 ` David Miller
2014-01-17 6:25 ` [Xen-devel] [PATCH " annie li
2014-01-17 6:58 ` annie li
2014-01-17 12:08 ` Wei Liu
2014-01-17 12:32 ` annie li [this message]
2014-01-17 14:02 ` Wei Liu
2014-01-17 15:43 ` annie li
2014-01-17 17:50 ` David Vrabel
2014-01-20 2:33 ` annie li
2014-01-17 15:40 ` David Vrabel
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=52D922DD.2060407@oracle.com \
--to=annie.li@oracle.com \
--cc=andrew.bennieston@citrix.com \
--cc=davem@davemloft.net \
--cc=david.vrabel@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=netdev@vger.kernel.org \
--cc=wei.liu2@citrix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).