From patchwork Mon Jan 8 09:01:03 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: tip-bot2 for Thomas Gleixner X-Patchwork-Id: 185851 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:37c1:b0:101:2151:f287 with SMTP id y1csp903288dyq; Mon, 8 Jan 2024 01:03:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IFjGFcLscemmlIbc386G6jVU9SINjeDZxpLmrfKZzPhAltHoqChAZQPvXhjopUNAwH9eGMh X-Received: by 2002:a05:6871:a10c:b0:1fb:e5f:c539 with SMTP id vs12-20020a056871a10c00b001fb0e5fc539mr4969113oab.49.1704704601699; Mon, 08 Jan 2024 01:03:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704704601; cv=none; d=google.com; s=arc-20160816; b=0l7KvdGAp6KzgP7Ql/kUHzjveTcwL6PS9ymGUAmbqv7WYZveiBosOm2wqnk8JvEEDL pFNozRpD2uE7/BbnugSQfVET15LP399+oMxuXC+FUA5POoyAhy9W3QRs9QNlE0yP18DN XEJ0dnQqa2WFePyTcQ8SaGDkMEC9VDOgyg15ECzqwvC3ky8/WWxx42nUyhwPMsikmmqB /JpeGpDvWWIMlRVEJaBvxxR+f6uuMHLZNML2Av3E9atuw/qerwj4NApE0IZSECucYMoR aLG6VuLzdy9jtBp4Z2ATb4WRt6/1jgZK1VhHceEZaalWWnotm9r2g/fKi7A8jWoLYlZg ksIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:precedence:robot-unsubscribe:robot-id :message-id:mime-version:list-unsubscribe:list-subscribe:list-id :precedence:references:in-reply-to:cc:subject:to:reply-to:sender :from:dkim-signature:dkim-signature:date; bh=Dyxas6APHfzo9ugShPXhkzsrATg+NmwaWDa+0Gt9Lvs=; fh=l+qdjd4kq7eDThGu3QVzci0uOVDufY76f0MiBeR5+Z4=; b=b2bJwrTTiZRGXuy1VdlDiELXYGLL8Ip+O/6vVydoW5CFgMLTRiMMojlAeIknMlnqP6 GPjg2nhUNeVcNWyzk+m4VzTh3eY1dGtVzLagnWoZBVT86cY1+JGrH3i/VTF1IDOIVmUr +yKFrIQtkD4WsAL9rfWJV9B840Jxbx4eRCwkAzsG5SBzUMKgf/xPx0nlaNQkDxjHLXmp vmsk1negLBxQP4fwCPgKhJtIQQHKb2mc3DmVqN/M6egibtRARBhdwTBy70EW/7LtLVe4 FclIVnLWmzOx1LwpX63TJ2ZFsanGX8SEx0DqWqo6rAdq3eKPihEExVVWHZqkJLpzJ3Lh S6FQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="1Y+cn/bo"; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; spf=pass (google.com: domain of linux-kernel+bounces-19231-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19231-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id b19-20020a63cf53000000b005cdb499ac69si5769866pgj.53.2024.01.08.01.03.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jan 2024 01:03:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-19231-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="1Y+cn/bo"; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; spf=pass (google.com: domain of linux-kernel+bounces-19231-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19231-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id EAE13282932 for ; Mon, 8 Jan 2024 09:01:46 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 63D1613AE2; Mon, 8 Jan 2024 09:01:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="1Y+cn/bo"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="XqA4yX00" X-Original-To: linux-kernel@vger.kernel.org Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 E0D4912B71; Mon, 8 Jan 2024 09:01:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Date: Mon, 08 Jan 2024 09:01:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1704704464; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Dyxas6APHfzo9ugShPXhkzsrATg+NmwaWDa+0Gt9Lvs=; b=1Y+cn/boN8dLNVv6zEVb2/BLwzKX1Ba441831wXTIv14c7UPHuYm/fEWS2ZSZiaCRyPAyY 99uSvUWOLLyMXjk4TF0R0fImIXgZeBjMmhMjN6FYx5ak+KYXKlSmYhLmrZ1MofCBais9k6 CTAEhFj6wMUFbqK/AWuZIk3OTsyYX1W25+D522YISeNkWr56Y+aSyS9yjVSVbeDSZNhBi9 YEh4XW+8SIqgM88WP0ayK2trl8dZNBVH0e17lKhZ/HyquJm5NlvuafwwIRluBU+Bs+3Y+D qX+oBZkPK3mc1dFydIhytme7FOKrmxusEDYO0L7+EHnDcTCLgsHRW30gg+3CCQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1704704464; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Dyxas6APHfzo9ugShPXhkzsrATg+NmwaWDa+0Gt9Lvs=; b=XqA4yX00ob9xNMGUC5ctqwURGJ0GqxO2lRTH8ia/9KRYTTT7bsxPIbZg5CxT3qoVp6W7Z4 frG4HssbHuKuj1CA== From: "tip-bot2 for Ingo Molnar" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: locking/core] locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked Cc: Ingo Molnar , Peter Zijlstra , Jann Horn , Linus Torvalds , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20231201121808.GL3818@noisy.programming.kicks-ass.net> References: <20231201121808.GL3818@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: <170470446336.398.8996133670425061216.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Precedence: bulk X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787512332345104099 X-GMAIL-MSGID: 1787512332345104099 The following commit has been merged into the locking/core branch of tip: Commit-ID: 2b9d9e0a9ba0e24cb9c78336481f0ed8b2bc1ff2 Gitweb: https://git.kernel.org/tip/2b9d9e0a9ba0e24cb9c78336481f0ed8b2bc1ff2 Author: Ingo Molnar AuthorDate: Mon, 08 Jan 2024 09:31:16 +01:00 Committer: Ingo Molnar CommitterDate: Mon, 08 Jan 2024 09:55:31 +01:00 locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked Clarify the mutex lock lifetime rules a bit more. Signed-off-by: Ingo Molnar Cc: Peter Zijlstra Cc: Jann Horn Cc: Linus Torvalds Link: https://lore.kernel.org/r/20231201121808.GL3818@noisy.programming.kicks-ass.net --- Documentation/locking/mutex-design.rst | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/Documentation/locking/mutex-design.rst b/Documentation/locking/mutex-design.rst index 7572339..7c30b4a 100644 --- a/Documentation/locking/mutex-design.rst +++ b/Documentation/locking/mutex-design.rst @@ -101,12 +101,24 @@ features that make lock debugging easier and faster: - Detects multi-task circular deadlocks and prints out all affected locks and tasks (and only those tasks). -Releasing a mutex is not an atomic operation: Once a mutex release operation -has begun, another context may be able to acquire the mutex before the release -operation has fully completed. The mutex user must ensure that the mutex is not -destroyed while a release operation is still in progress - in other words, -callers of mutex_unlock() must ensure that the mutex stays alive until -mutex_unlock() has returned. +Mutexes - and most other sleeping locks like rwsems - do not provide an +implicit reference for the memory they occupy, which reference is released +with mutex_unlock(). + +[ This is in contrast with spin_unlock() [or completion_done()], which + APIs can be used to guarantee that the memory is not touched by the + lock implementation after spin_unlock()/completion_done() releases + the lock. ] + +mutex_unlock() may access the mutex structure even after it has internally +released the lock already - so it's not safe for another context to +acquire the mutex and assume that the mutex_unlock() context is not using +the structure anymore. + +The mutex user must ensure that the mutex is not destroyed while a +release operation is still in progress - in other words, callers of +mutex_unlock() must ensure that the mutex stays alive until mutex_unlock() +has returned. Interfaces ----------