From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 899A5211488 for ; Wed, 22 Jan 2025 10:39:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737542360; cv=none; b=N1K61W/H/lRnQZKFpS+UJQEYIZH5UEvAqrTRRMGtLXT3nvlFRkEeTPcDj4+zs3qikHlfbd6lg0ddQk2YFDkrN5fGvQcUUkw/8Q5xv3hhNOBuuqn9pTa2x7g2i98Gt3qh5GC2ebxqjTk5H1obic0BoCGHhYKFoGXDyBkiezIuPmk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737542360; c=relaxed/simple; bh=b29CrgVwx2/0eLP0KntC7pQ/g0FqW3OYC9TeFkDVQ3A=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pyQBsg4JAPwELxuZ8ymwBVLMgskqqfIxkBBDQpnnHz2bCOCocq0OHy0931VJowO1ZNDu6x5xSnR9n54lTsEsKyT7gC5bozv1WsUc4ZqcQV93p3wf43GYprpC+WCLIs248bYI4A0J/B97iQFer2mv57q0lyQjpCVJP66nQ9DS1N4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=NfuS037T; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="NfuS037T" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=QqnOqYHQ3yJh+il+VMUSNdAm5j5gR3zUff6qSVBFUCg=; b=NfuS037TVixh6GgGb+jXKUnpjt hO1EmG8f/QwubvHv/jVHUNiHeyeNqrBF0izrh01MVNu3Fci3YrL+/gI1xjqHEx07g2syH14MIM1zo d5w1pk/RUVzEz704hnucuFPdP8uX6xzITU4GiASj/UNWr/JkoHglvVL/3r3iiy489Jtse1Oivbvw7 EQFTF7tgmw4cZbDGRG+ZbqEVeOtrSf0CGoqcdMyiapBY2RTPVsNEiyAw6Hn3dhRrp/iw8W4CUAo+9 5BnIf2RCGq8WehcSUq59WayitG6mYoMVel17QCuHtxnMP2VgBGOA6kqh4Qt19iyi1svqVBfxa2lTk aNguGqWA==; Received: from 77-249-17-89.cable.dynamic.v4.ziggo.nl ([77.249.17.89] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1taY8h-0000000DXnd-2dau; Wed, 22 Jan 2025 10:39:15 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 0BA68300599; Wed, 22 Jan 2025 11:39:15 +0100 (CET) Date: Wed, 22 Jan 2025 11:39:14 +0100 From: Peter Zijlstra To: Waiman Long Cc: Ingo Molnar , Will Deacon , Boqun Feng , linux-kernel@vger.kernel.org Subject: Re: [PATCH] locking/semaphore: Use wake_q to wake up processes outside lock critical section Message-ID: <20250122103914.GI7145@noisy.programming.kicks-ass.net> References: <20250122011314.2869715-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250122011314.2869715-1-longman@redhat.com> On Tue, Jan 21, 2025 at 08:13:14PM -0500, Waiman Long wrote: > A circular lock dependency splat has been seen involving down_trylock(). > > [ 4011.795602] ====================================================== > [ 4011.795603] WARNING: possible circular locking dependency detected > [ 4011.795607] 6.12.0-41.el10.s390x+debug > [ 4011.795612] ------------------------------------------------------ > [ 4011.795613] dd/32479 is trying to acquire lock: > [ 4011.795617] 0015a20accd0d4f8 ((console_sem).lock){-.-.}-{2:2}, at: down_trylock+0x26/0x90 > [ 4011.795636] > [ 4011.795636] but task is already holding lock: > [ 4011.795637] 000000017e461698 (&zone->lock){-.-.}-{2:2}, at: rmqueue_bulk+0xac/0x8f0 > > the existing dependency chain (in reverse order) is: > -> #4 (&zone->lock){-.-.}-{2:2}: > -> #3 (hrtimer_bases.lock){-.-.}-{2:2}: > -> #2 (&rq->__lock){-.-.}-{2:2}: > -> #1 (&p->pi_lock){-.-.}-{2:2}: > -> #0 ((console_sem).lock){-.-.}-{2:2}: The whole #3->#4 thing seems dodgy, where is that? Specifically hrtimer_bases.lock is a raw_spinlock, while zone->lock is a spinlock, this is not a valid nesting.