From: "Jan Beulich" <JBeulich@suse.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: julien.grall@citrix.com,
xen-devel <xen-devel@lists.xenproject.org>,
Ian.Campbell@citrix.com
Subject: Re: [PATCH 3/4] xen/arm: introduce XENMEM_cache_flush
Date: Thu, 02 Oct 2014 12:00:58 +0100 [thread overview]
Message-ID: <542D4C8A020000780003BE5E@mail.emea.novell.com> (raw)
In-Reply-To: <1412244158-12124-3-git-send-email-stefano.stabellini@eu.citrix.com>
>>> On 02.10.14 at 12:02, <stefano.stabellini@eu.citrix.com> wrote:
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1134,6 +1134,98 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
> case XENMEM_get_sharing_shared_pages:
> case XENMEM_get_sharing_freed_pages:
> return 0;
> + case XENMEM_cache_flush:
Blank line missing above this one.
> + {
> + struct xen_cache_flush cflush;
> + struct domain *d, *owner;
> + struct page_info *page;
> + uint64_t mfn, end;
> + uint64_t offset, size;
> + void *v;
> + int ret = 0;
> +
> + if ( copy_from_guest(&cflush, arg, 1) )
> + return -EFAULT;
> +
> + d = rcu_lock_current_domain();
> + if ( d == NULL )
> + return -ESRCH;
I think this should be the last check prior to the loop below,
simplifying error handling (break instead of goto).
> +
> + if ( (cflush.size >> PAGE_SHIFT) > (1U<<MAX_ORDER) )
The why is size a uint64_t in the first place?
> + {
> + printk(XENLOG_G_ERR "invalid size %llx\n", cflush.size);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + if ( cflush.size == 0 || cflush.op == 0 )
> + {
> + ret = 0;
> + goto out;
> + }
> +
> + if ( cflush.op & ~(XENMEM_CACHE_INVAL|XENMEM_CACHE_CLEAN) )
> + {
> + printk(XENLOG_G_ERR "invalid op %x\n", cflush.op);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + end = cflush.addr + cflush.size;
As said in various contexts before: Such an addition can overflow,
and (even if this doesn't matter here due to the earlier check) you
can't express "the entire address space" with a (base,size) pair
either. Representing arbitrary ranges is better done using inclusive
pairs of addresses/MFNs/whatever.
> + while ( cflush.addr < end )
> + {
> + mfn = cflush.addr >> PAGE_SHIFT;
> + offset = cflush.addr & ~PAGE_MASK;
> +
> + if ( !mfn_valid(mfn) )
> + {
> + printk(XENLOG_G_ERR "mfn=%llx is not valid\n", mfn);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + page = mfn_to_page(mfn);
> + if ( !page )
> + {
> + printk(XENLOG_G_ERR "couldn't get page for mfn %llx\n", mfn);
> + ret = -EFAULT;
> + goto out;
> + }
> +
> + owner = page_get_owner(page);
> + if ( !owner )
> + {
> + printk(XENLOG_G_ERR "couldn't get owner for mfn %llx\n", mfn);
> + ret = -EFAULT;
> + goto out;
> + }
> +
> + if ( owner != d && !grant_map_exists(d, owner->grant_table, mfn) )
> + {
> + printk(XENLOG_G_ERR "mfn %llx hasn't been granted by %d to %d\n", mfn, owner->domain_id, d->domain_id);
Long line. But - do you really need all these printk()s?
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + v = map_domain_page(mfn);
> + v += offset;
> + size = cflush.size - cflush.addr;
> + if ( size > PAGE_SIZE - offset )
> + size = PAGE_SIZE - offset;
> +
> + if ( cflush.op & XENMEM_CACHE_INVAL )
> + invalidate_xen_dcache_va_range(v, size);
> + if ( cflush.op & XENMEM_CACHE_CLEAN )
> + clean_xen_dcache_va_range(v, size);
Is this really the right sequence when both flags are set? Of course
I can only guess a what "clean" and "invalidate" here mean (nothing
more specific is being said alongside their definition), but I'd expect
you to want to clean (flush) cache contents _before_ invalidating.
> + unmap_domain_page(v);
> +
> + cflush.addr += PAGE_SIZE - offset;
> + }
> +
> +out:
Labels should be indented by at least one space. But you don't
really need the label anyway if you follow the suggestion above.
Jan
next prev parent reply other threads:[~2014-10-02 11:01 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-02 10:01 [PATCH 0/4] xen/arm: introduce XENMEM_cache_flush Stefano Stabellini
2014-10-02 10:02 ` [PATCH 1/4] xen/arm: introduce invalidate_xen_dcache_va_range Stefano Stabellini
2014-10-02 11:57 ` Julien Grall
2014-10-03 14:00 ` Ian Campbell
2014-10-03 13:39 ` Ian Campbell
2014-10-02 10:02 ` [PATCH 2/4] xen: introduce grant_map_exists Stefano Stabellini
2014-10-02 10:17 ` Tim Deegan
2014-10-02 10:42 ` Stefano Stabellini
2014-10-02 11:30 ` Jan Beulich
2014-10-02 11:37 ` Stefano Stabellini
2014-10-02 11:45 ` Jan Beulich
2014-10-02 11:41 ` Tim Deegan
2014-10-02 11:59 ` Jan Beulich
2014-10-02 14:01 ` Tim Deegan
2014-10-03 13:47 ` Stefano Stabellini
2014-10-03 14:05 ` Stefano Stabellini
2014-10-03 15:41 ` Jan Beulich
2014-10-02 10:45 ` Jan Beulich
2014-10-02 11:34 ` Stefano Stabellini
2014-10-02 11:42 ` Jan Beulich
2014-10-02 10:02 ` [PATCH 3/4] xen/arm: introduce XENMEM_cache_flush Stefano Stabellini
2014-10-02 11:00 ` Jan Beulich [this message]
2014-10-02 11:34 ` Jan Beulich
2014-10-02 11:41 ` Stefano Stabellini
2014-10-02 11:49 ` Jan Beulich
2014-10-02 11:57 ` Stefano Stabellini
2014-10-02 12:11 ` Jan Beulich
2014-10-02 12:59 ` Stefano Stabellini
2014-10-02 12:17 ` Julien Grall
2014-10-03 13:41 ` Ian Campbell
2014-10-02 10:02 ` [PATCH 4/4] Revert "xen/arm: introduce XENFEAT_grant_map_identity" Stefano Stabellini
2014-10-02 11:02 ` Jan Beulich
2014-10-03 13:42 ` Ian Campbell
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=542D4C8A020000780003BE5E@mail.emea.novell.com \
--to=jbeulich@suse.com \
--cc=Ian.Campbell@citrix.com \
--cc=julien.grall@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xenproject.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).