From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andres Lagar-Cavilla" Subject: Re: [PATCH] x86/PoD: fix (un)locking after 24772:28edc2b31a9b Date: Mon, 13 Aug 2012 08:22:22 -0700 Message-ID: <2a0c4a6bbbb7050073e8d5de103ef129.squirrel@webmail.lagarcavilla.org> References: <50290B0C0200007800094750@nat28.tlf.novell.com> <5029303F020000780009480B@nat28.tlf.novell.com> Reply-To: andres@lagarcavilla.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5029303F020000780009480B@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: George Dunlap , Tim Deegan , Andres Lagar-Cavilla , xen-devel List-Id: xen-devel@lists.xenproject.org >>>> On 13.08.12 at 14:11, "Jan Beulich" wrote: >> That c/s introduced a double unlock on the out-of-memory error path of >> p2m_pod_demand_populate(). > > I also wonder how correct that changeset's elimination of the page > alloc lock in a number of places here is - p2m_pod_set_mem_target()'s > calculations, for example, involve d->tot_pages, which with that lock > not held can change under its feet. afaict, access to d->tot_pages was not protected by the page_alloc lock even prior to 24772. Back when, I thought those unprotected tot_pages accesses should either be locked or atomic_read(). Slipped through the cracks. Andres > > Jan > >