From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [PATCH 5/6] xen-gntalloc: Userspace grant allocation driver
Date: Wed, 09 Feb 2011 13:52:56 -0500 [thread overview]
Message-ID: <4D52E288.1060300@tycho.nsa.gov> (raw)
In-Reply-To: <20110208224804.GB8321@dumpdata.com>
On 02/08/2011 05:48 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 03, 2011 at 12:19:03PM -0500, Daniel De Graaf wrote:
>> This allows a userspace application to allocate a shared page for
>> implementing inter-domain communication or device drivers. These
>> shared pages can be mapped using the gntdev device or by the kernel
>> in another domain.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>> drivers/xen/Kconfig | 8 +
>> drivers/xen/Makefile | 2 +
>> drivers/xen/gntalloc.c | 486 ++++++++++++++++++++++++++++++++++++++++++++++++
>> include/xen/gntalloc.h | 50 +++++
>> 4 files changed, 546 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/xen/gntalloc.c
>> create mode 100644 include/xen/gntalloc.h
>>
[snip]
>> +static int add_grefs(struct ioctl_gntalloc_alloc_gref *op,
>> + uint32_t *gref_ids, struct gntalloc_file_private_data *priv)
>> +{
>> + int i, rc, readonly;
>> + LIST_HEAD(queue_gref);
>> + LIST_HEAD(queue_file);
>> + struct gntalloc_gref *gref;
>> +
>> + readonly = !(op->flags & GNTALLOC_FLAG_WRITABLE);
>> + rc = -ENOMEM;
>> + for (i = 0; i < op->count; i++) {
>> + gref = kzalloc(sizeof(*gref), GFP_KERNEL);
>> + if (!gref)
>> + goto undo;
>> + list_add_tail(&gref->next_gref, &queue_gref);
>> + list_add_tail(&gref->next_file, &queue_file);
>> + gref->users = 1;
>> + gref->file_index = op->index + i * PAGE_SIZE;
>> + gref->page = alloc_page(GFP_KERNEL|__GFP_ZERO);
>> + if (!gref->page)
>> + goto undo;
>> +
>> + /* Grant foreign access to the page. */
>> + gref->gref_id = gnttab_grant_foreign_access(op->domid,
>> + pfn_to_mfn(page_to_pfn(gref->page)), readonly);
>> + if (gref->gref_id < 0) {
>> + rc = gref->gref_id;
>> + goto undo;
>> + }
>> + gref_ids[i] = gref->gref_id;
>> + }
>> +
>> + /* Add to gref lists. */
>> + spin_lock(&gref_lock);
>> + list_splice_tail(&queue_gref, &gref_list);
>> + list_splice_tail(&queue_file, &priv->list);
>> + spin_unlock(&gref_lock);
>> +
>> + return 0;
>> +
>> +undo:
>> + spin_lock(&gref_lock);
>> + gref_size -= (op->count - i);
>
> So we decrease the gref_size by the count of the ones that we
> allocated..
No, (op->count - i) is the number that we haven't yet allocated. Those
aren't in queue_file, so __del_gref is never called on them.
>> +
>> + list_for_each_entry(gref, &queue_file, next_file) {
>> + /* __del_gref does not remove from queue_file */
>> + __del_gref(gref);
>
> .. but __del_gref decreases the gref_size by one, so wouldn't
> we decrease by too much?
[snip]
>> +static long gntalloc_ioctl_alloc(struct gntalloc_file_private_data *priv,
>> + struct ioctl_gntalloc_alloc_gref __user *arg)
>> +{
>> + int rc = 0;
>> + struct ioctl_gntalloc_alloc_gref op;
>> + uint32_t *gref_ids;
>> +
>> + pr_debug("%s: priv %p\n", __func__, priv);
>> +
>> + if (copy_from_user(&op, arg, sizeof(op))) {
>> + rc = -EFAULT;
>> + goto out;
>> + }
>> +
>> + gref_ids = kzalloc(sizeof(gref_ids[0]) * op.count, GFP_TEMPORARY);
>> + if (!gref_ids) {
>> + rc = -ENOMEM;
>> + goto out;
>> + }
>> +
>> + spin_lock(&gref_lock);
>> + /* Clean up pages that were at zero (local) users but were still mapped
>> + * by remote domains. Since those pages count towards the limit that we
>> + * are about to enforce, removing them here is a good idea.
>> + */
>> + do_cleanup();
>> + if (gref_size + op.count > limit) {
>> + spin_unlock(&gref_lock);
>> + rc = -ENOSPC;
>> + goto out_free;
>> + }
>> + gref_size += op.count;
>> + op.index = priv->index;
>> + priv->index += op.count * PAGE_SIZE;
>> + spin_unlock(&gref_lock);
>> +
>> + rc = add_grefs(&op, gref_ids, priv);
>> + if (rc < 0)
>> + goto out_free;
>
> Should we cleanup up priv->index to its earlier value?
We could, but this could also introduce a possible race if two threads were
running the ioctl at the same time. There's no harm in letting the index increase,
since it is 64-bit so doesn't have overflow issues.
--
Daniel De Graaf
National Security Agency
next prev parent reply other threads:[~2011-02-09 18:52 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-03 17:18 [PATCH v6] Userspace grant communication Daniel De Graaf
2011-02-03 17:18 ` [PATCH 1/6] xen-gntdev: Change page limit to be global instead of per-open Daniel De Graaf
2011-02-03 17:19 ` [PATCH 2/6] xen-gntdev: Use find_vma rather than iterating our vma list manually Daniel De Graaf
2011-02-03 17:19 ` [PATCH 3/6] xen-gntdev: Add reference counting to maps Daniel De Graaf
2011-02-03 17:19 ` [PATCH 4/6] xen-gntdev: Support mapping in HVM domains Daniel De Graaf
2011-02-14 15:51 ` Konrad Rzeszutek Wilk
2011-02-14 17:43 ` Daniel De Graaf
2011-02-14 18:52 ` Konrad Rzeszutek Wilk
2011-02-03 17:19 ` [PATCH 5/6] xen-gntalloc: Userspace grant allocation driver Daniel De Graaf
2011-02-08 22:48 ` Konrad Rzeszutek Wilk
2011-02-09 18:52 ` Daniel De Graaf [this message]
2011-02-03 17:19 ` [PATCH 6/6] xen/gntalloc, gntdev: Add unmap notify ioctl Daniel De Graaf
2011-02-14 15:37 ` Konrad Rzeszutek Wilk
2011-02-14 18:07 ` Daniel De Graaf
2011-02-03 19:16 ` [PATCH] xen-gntdev: Fix memory leak when mmap fails Daniel De Graaf
2011-02-07 23:14 ` [PATCH v6] Userspace grant communication Konrad Rzeszutek Wilk
2011-02-08 14:14 ` [PATCH] xen-gntdev: Fix unmap notify on PV domains Daniel De Graaf
2011-02-08 22:58 ` Konrad Rzeszutek Wilk
2011-02-09 20:33 ` [PATCH] xen-gntdev: prevent using UNMAP_NOTIFY_CLEAR_BYTE on read-only mappings Daniel De Graaf
2011-02-09 21:09 ` [PATCH v2] " Daniel De Graaf
2011-02-09 22:22 ` [PATCH] " Jeremy Fitzhardinge
2011-02-09 23:11 ` Daniel De Graaf
2011-02-09 23:15 ` [PATCH v3] " Daniel De Graaf
2011-02-08 21:49 ` [PATCH v6] Userspace grant communication Konrad Rzeszutek Wilk
2011-02-09 20:11 ` [PATCH] xen-gntdev: Use map->vma for checking map validity Daniel De Graaf
2011-02-09 20:12 ` [PATCH] xen-gntdev: Avoid unmapping ranges twice Daniel De Graaf
2011-02-09 21:11 ` [PATCH] xen-gntdev: Avoid double-mapping memory Daniel De Graaf
2011-02-14 16:14 ` [PATCH v6] Userspace grant communication Konrad Rzeszutek Wilk
2011-02-14 16:38 ` Konrad Rzeszutek Wilk
2011-02-14 17:56 ` Daniel De Graaf
2011-02-14 19:21 ` Konrad Rzeszutek Wilk
2011-02-14 20:55 ` Daniel De Graaf
2011-02-14 17:55 ` Daniel De Graaf
2011-02-14 19:04 ` Konrad Rzeszutek Wilk
-- strict thread matches above, loose matches on Subject: below --
2011-01-21 15:59 [SPAM] [PATCH v5] " Daniel De Graaf
2011-01-21 15:59 ` [PATCH 5/6] xen-gntalloc: Userspace grant allocation driver Daniel De Graaf
2011-01-27 18:52 ` Konrad Rzeszutek Wilk
2011-01-27 19:23 ` Konrad Rzeszutek Wilk
2011-01-27 19:51 ` Daniel De Graaf
2011-01-27 20:55 ` Daniel De Graaf
2011-01-27 21:29 ` Konrad Rzeszutek Wilk
2010-12-14 14:55 [PATCH v2] Userspace grant communication Daniel De Graaf
2010-12-14 14:55 ` [PATCH 5/6] xen-gntalloc: Userspace grant allocation driver Daniel De Graaf
2010-12-14 21:42 ` Jeremy Fitzhardinge
2010-12-14 22:06 ` Daniel De Graaf
2010-12-14 22:40 ` Jeremy Fitzhardinge
2010-12-15 14:18 ` Daniel De Graaf
2010-12-16 1:05 ` Jeremy Fitzhardinge
2010-12-16 15:22 ` Daniel De Graaf
2010-12-16 19:14 ` Jeremy Fitzhardinge
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=4D52E288.1060300@tycho.nsa.gov \
--to=dgdegra@tycho.nsa.gov \
--cc=Ian.Campbell@citrix.com \
--cc=jeremy@goop.org \
--cc=konrad.wilk@oracle.com \
--cc=xen-devel@lists.xensource.com \
/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).