From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dan Magenheimer <dan.magenheimer@oracle.com>
Subject: preemption and locking: why joined at the hip?
Date: Fri, 31 Aug 2012 12:47:21 -0700 (PDT)
Message-ID: <16d6e254-acff-4212-b5ed-0b3dd5b40ea5@default>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: keir@xen.org, xen-devel@lists.xen.org
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>, Konrad Wilk <konrad.wilk@oracle.com>
List-Id: xen-devel@lists.xenproject.org

Tracking down a tmem problem in 4.2.0-rcN that crashes the
hypervisor, I've discovered a 4.2 changeset that forces
a preemption_enable/disable for every lock/unlock.

Tmem has dynamically allocated "objects" that contain a
lock.  The lock is held when the object is destroyed.
No reason to unlock something that's about to be destroyed.
But with the preempt_enable/disable in the generic locking code,
and the fact that do_softirq ASSERTs that preempt_count
must be zero, a crash occurs.

While I'm suitably embarrassed that tmem has not yet
been tested with any recent -unstable, and I note that the
workaround is simple (forcing an unlock before destroying the
object containing the held lock), I have to ask if
this change is really a good idea or is it unnecessary
babysitting?

Dan