From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 12:38:51 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 52CA1E29 for ; Sun, 25 Aug 2013 12:38:51 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 12AE42BA1 for ; Sun, 25 Aug 2013 12:38:50 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id n7so145103qcx.24 for ; Sun, 25 Aug 2013 05:38:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=X5zAqWbInfB2AQu8UDIvgvsToVtR20DBJ3IZkx6c2X0=; b=YvwfrVjn+VpOEHORMo7NsOH7f6XncC88DGTTT5IYcyqggPRbM6Gacd2OeWAtX1qGOF mGX7eDkVkgkSMWnQpjP1/ICH/zeBLjt4z76GDCtL0ZDu31bJxs+rbhIPB7CLpDa7Xt+P mfyEze0XvN5/uobOjPHXNaDj4wizGoIm+X1ZCO3CkodCmU41oUPizfh1/NnFpU6nsWDT t/z2azbjLk8qhKjby/9VJxpdti6Nn86oKvxKcyf4jKX0UqUOlxxqXZbFw/066OA9rrIz B2V3s6vgh6Y6JXT7jO8sHtWgC7t1JHe7RQO3HT0kgKRQl4+i72GFbv0u4+2O3iQwtBOv +i2A== X-Gm-Message-State: ALoCoQlR8sRfSFOCygs93QU6aY/7B4pFNnV8smGA61m9ku1iHruW9G83Hqw2lMFMKGZSROwa79GC MIME-Version: 1.0 X-Received: by 10.49.0.198 with SMTP id 6mr11198379qeg.48.1377434324485; Sun, 25 Aug 2013 05:38:44 -0700 (PDT) Received: by 10.49.8.20 with HTTP; Sun, 25 Aug 2013 05:38:44 -0700 (PDT) In-Reply-To: <20130825131134.11815f5d@bender.Home> References: <201306040921.r549LI8t021617@svn.freebsd.org> <20130825131134.11815f5d@bender.Home> Date: Sun, 25 Aug 2013 14:38:44 +0200 Message-ID: Subject: Re: svn commit: r251370 - head/sys/arm/arm From: Zbigniew Bodek To: Andrew Turner Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Grzegorz Bernacki , src-committers@freebsd.org, "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 12:38:51 -0000 2013/8/25 Andrew Turner > On Tue, 4 Jun 2013 09:21:18 +0000 (UTC) > Grzegorz Bernacki wrote: > > > Author: gber > > Date: Tue Jun 4 09:21:18 2013 > > New Revision: 251370 > > URL: http://svnweb.freebsd.org/changeset/base/251370 > > > > Log: > > Implement pmap_copy() for ARMv6/v7. > > > > Copy the given range of mappings from the source map to the > > destination map, thereby reducing the number of VM faults on fork. > > > > Submitted by: Zbigniew Bodek > > Sponsored by: The FreeBSD Foundation, Semihalf > > > > Modified: > > head/sys/arm/arm/pmap-v6.c > > This change leads to a deadlock when I attempt to run make buildworld > on my PandaBoard. The problem is you are locking > pvh_global_lock, src_pmap, and dst_pmap then calling > pmap_alloc_l2_bucket. > > This may unlock pvh_global_lock and dst_pmap, but it has no knowledge > of src_pmap so it will keep it locked. > > If another thread needs to lock src_pmap, for example the pagedaemon > may in pmap_clearbit, it will lock pvh_global_lock. This will succeed > when pmap_alloc_l2_bucket unlocks it. It will then attempt to lock > src_pmap but, as it is already locked, it will wait for pmap_copy to > unlock it. > > At this point pmap_alloc_l2_bucket will attempt to lock pvh_global_lock > again, however this lock is already held so it waits for the other > thread to unlock it. > > At this point both threads are waiting on each other causing a deadlock. > > I don't know enough about the pmap or vm code to be able to fix this, > other than reverting this commit. > > Andrew > Hello Andrew, Yes, you are right. We've already discussed this with Olivier (who found this and informed me) and decided to comment this out after committing superpages support. Currently there is no other way to fix this due to pmap_alloc_l2_bucket() implementation. If you are in a great hurry with the commit reversal/commenting out pmap_copy() then I see no problem to do so. Best regards Zbyszek Bodek