[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1345563433.26596.2.camel@twins>
Date: Tue, 21 Aug 2012 17:37:13 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Rafael Aquini <aquini@...hat.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
virtualization@...ts.linux-foundation.org,
Rusty Russell <rusty@...tcorp.com.au>,
Rik van Riel <riel@...hat.com>, Mel Gorman <mel@....ul.ie>,
Andi Kleen <andi@...stfloor.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Minchan Kim <minchan@...nel.org>,
paulmck <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH v8 3/5] virtio_balloon: introduce migration primitives
to balloon pages
On Tue, 2012-08-21 at 17:40 +0300, Michael S. Tsirkin wrote:
> > + spin_lock(&vb->pages_lock);
> > + page = list_first_or_null_rcu(&vb->pages, struct page, lru);
>
> Why is list_first_or_null_rcu called outside
> RCU critical section here?
It looks like vb->pages_lock is the exclusive (or modification)
counterpart to the rcu-read-lock in this particular case, so it should
be fine.
Although for that same reason, it seems superfluous to use the RCU list
method since we're exclusive with list manipulations anyway.
> > + if (!page) {
> > + spin_unlock(&vb->pages_lock);
> > + break;
> > + }
> > + /*
> > + * It is safe now to drop page->mapping and delete this page
> > + * from balloon page list, since we are grabbing 'pages_lock'
> > + * which prevents 'virtballoon_isolatepage()' from acting.
> > + */
> > + clear_balloon_mapping(page);
> > + list_del_rcu(&page->lru);
> > + spin_unlock(&vb->pages_lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists