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/
Home Products Support Community News


Re: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/fail/pass
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Mon, 02 May 2011 16:45:02 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 02 May 2011 08:45:58 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=DjC7GjCy4HTs/pPcWLqes0MbGj1dpXqiIjVCZBTT/bM=; b=vVV/pQU0LwDZWpsJdT+LraxW4shyq340HPGGxGBFNjbtY9BOF4aYM+Vwuvg2nzxxHd 0jRfeMBzR1rl7hmm0oaXWdF6K4D1EHmYyoFje0qTjOrtoj6lJwVfHYGEE7fRNTGQtQmR FjnLCmh5F8r73K70iXFlV5vNKwCHAFBDuSJRI=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=x8F2mPXtaTO3QP+ERooroJN0wJPAdlJoupEa4ygX4sQoB0rNtbYr4FhW9tDU/cXRT4 8HQERD7iiMdzc9pNyZqDbhi8LJPHHScXIBDzE9UVqr2XiGNBhPNtSsY19X60kziM+DGK fG2Nqi1i3k3d04vAeRNgA29jl/HOFsSeXy5Bw=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DBED61F020000780003F2D3@xxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwI3+Y3Ig6ghvMHykmRdok5Gx5lWg==
Thread-topic: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/fail/pass
User-agent: Microsoft-Entourage/
On 02/05/2011 15:04, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

>> The most straightforward way to convert to RCU with the most similar
>> synchronising semantics would be to add a 'live' boolean flag to each
>> pirq-related struct that is stored in a radix tree. Then:
>>  * insertions into radix tree would be moved before acquisition of the
>> irq_desc lock, then set 'live' under the lock
>>  * deletions would clear 'live' under the lock, then do the actual radix
>> deletion would happen after irq_desc lock release;
>>  * lookups would happen as usual under the irq_desc lock, but with an extra
>> test of the 'live' flag.
> This still leaves unclear to me how an insert hitting a not-yet-deleted
> (but no longer live) entry should behave. Simply setting 'live' again
> won't help, as that wouldn't cover a delete->insert->delete all
> happening before the first delete's grace period expires. Nor would
> this work with populating the new data (prior to setting live) when
> the old data might sill be used.

Yes, this is why in my follow-up email I explained that a secondary lock is
needed that covers both logical and physical insertion/deletion. Then the
case you describe above cannot happen. As you say, event_lock covers us.

> But wait - what you describe doesn't need RCU anymore, at least
> as long as the code paths from radix tree insert to setting 'live'
> (and similarly from clearing 'live' to doing the radix tree delete) are
> fully covered by some other lock (d->event_lock, see below). Am
> I overlooking something?

No, I think you just misunderstand RCU. What I (and now also you, a bit
independently ;-) have described is how to synchronise writers against other
writers -- e.g., someone inserting concurrently with deleting, as you
describe above. What RCU is all about is synchronising *readers* against
writers, without needing a lock. And we still need it because the radix-tree
updates will happen under d->event_lock, which the readers in IRQ context
will not be holding. The main thing that RCU generally needs is that, when a
node is deleted from a structure (radix-tree in this case) it cannot be
freed until an RCU grace period because concurrent lock-free readers may
still hold a pointer to it. There are also other details to consider but
actually the whole RCU issue appears to be handled by Linux's radix-tree
implementation -- we just need to pull an up-to-date version across into

 -- Keir

Xen-devel mailing list

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