From: David Vrabel <david.vrabel@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
Cc: Keir Fraser <keir@xen.org>,
Ian Campbell <ian.campbell@citrix.com>,
Christoph Egger <chegger@amazon.de>, Tim Deegan <tim@xen.org>,
Matt Wilson <msw@amazon.com>,
xen-devel@lists.xenproject.org,
Malcolm Crossley <malcolm.crossley@citrix.com>
Subject: Re: [PATCHv8 2/3] gnttab: per-active entry locking
Date: Tue, 19 May 2015 14:46:43 +0100 [thread overview]
Message-ID: <555B3EC3.9060702@citrix.com> (raw)
In-Reply-To: <555B1007020000780007B772@mail.emea.novell.com>
On 19/05/15 09:27, Jan Beulich wrote:
>>>> On 12.05.15 at 16:15, <david.vrabel@citrix.com> wrote:
>> @@ -546,15 +554,28 @@ static void mapcount(
>>
>> *wrc = *rdc = 0;
>>
>> + /*
>> + * N.B.: while taking the local maptrack spinlock prevents any
>> + * mapping changes, the remote active entries could be changing
>> + * while we are counting. The caller has to hold the grant table
>> + * write lock, or some other mechanism should be used to prevent
>> + * concurrent changes during this operation. This is tricky
>> + * because we can't promote a read lock into a write lock.
>> + */
>> + ASSERT(rw_is_locked(&rd->grant_table->lock));
>
> So both callers only hold the read lock - what is this "other mechanism"
> that they employ?
This comment is just nonsense. We must hold the grant table write lock
for mapcount() to be safe -- the maptrack lock doesn't help and as you
say, this "other mechanism" just doesn't exist.
I think the callers of mapcount() need to be refactored so iommu updates
and the mapcount() call are done with the write lock held only (the
maptrack nor active entry locks are relevant here).
David
next prev parent reply other threads:[~2015-05-19 13:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-12 14:15 [PATCHv8 0/3] gnttab: Improve scaleability David Vrabel
2015-05-12 14:15 ` [PATCHv8 1/3] gnttab: Introduce rwlock to protect updates to grant table state David Vrabel
2015-05-19 8:02 ` Jan Beulich
2015-05-19 13:20 ` David Vrabel
2015-05-19 13:31 ` Jan Beulich
2015-05-12 14:15 ` [PATCHv8 2/3] gnttab: per-active entry locking David Vrabel
2015-05-19 8:27 ` Jan Beulich
2015-05-19 13:46 ` David Vrabel [this message]
2015-05-12 14:15 ` [PATCHv8 3/3] gnttab: use per-VCPU maptrack free lists David Vrabel
2015-05-19 7:36 ` [PATCHv8 0/3] gnttab: Improve scaleability Jan Beulich
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=555B3EC3.9060702@citrix.com \
--to=david.vrabel@citrix.com \
--cc=JBeulich@suse.com \
--cc=chegger@amazon.de \
--cc=ian.campbell@citrix.com \
--cc=keir@xen.org \
--cc=malcolm.crossley@citrix.com \
--cc=msw@amazon.com \
--cc=tim@xen.org \
--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 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.