From patchwork Fri Dec 1 10:44:09 2023 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: 172411 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp1024986vqy; Fri, 1 Dec 2023 02:44:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IHXaQAxKFuYsAcxH464yz37Bv+M6zjjKbL0k/cHHDmd0lmhyTnMnVUbdQCACKuHdby/zAeJ X-Received: by 2002:aa7:98dd:0:b0:6cd:e189:c0f4 with SMTP id e29-20020aa798dd000000b006cde189c0f4mr6587076pfm.12.1701427461518; Fri, 01 Dec 2023 02:44:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701427461; cv=none; d=google.com; s=arc-20160816; b=L0AXx3EJnw6AFVAKfVBHrx6c5jm7aNxCbrC8Z0LYbX9aU8TXbHQC6OCcJlPBPjGkKN HI3zHBEbbTXUxOtSGh/Hqpr4n7QENoseewVpdX1eZ+KZOeeG6/s0kvSoUBcEC4dAcEm4 AOLD1bmTd9DKh2T/xefb9Ys9EAxdGH7d12Fa1mJIwXXSlejIBzuDr4yRhGoEBJ0hFR1R IBvvBc4EXxuGDUYY22t/JA3y9AjOyRNf11ia/Oj8b6OLFyyQBbvm3CEYalGki1sFRvC9 FOXCoYB3GgLcGosZ/kMWTWJD84NgrwRcYoczk9mL6u0K2NYDQEwA0T3PdOIBesxYM8Pv UPMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:robot-unsubscribe :robot-id:message-id:mime-version:references:in-reply-to:cc:subject :to:reply-to:sender:from:dkim-signature:dkim-signature:date; bh=qPCIzTyiZpaSnXIh/BvFIvvdQAACVmWB9mApE7JKoAs=; fh=iPb43Wieh6hP2mFCB81etjxb2a6CDEhc3QS4tLuQcBU=; b=VhIinmPBu9jvITmdPPcvu+w+zgmMOF2jCCVIn4Ph+gnbq1J3TSXzEC5wqlyxnao00c o2v9xGlIMGioZvUxzcasdfIWVvmRdBwdn3oimeohKMGUe19R84izfDwZPBBJ5LCj4i0C LGr/5rHdrDPpRcoP+YJ0mos5VcovKkV4L6NgZvm7tI3zJ2kpOakME7BqkkyLDlhNSIFC W4+d4q3FVRLMSfd6Hl21yFQeCX1CuXirswx8xQ32WW59gE6vSL1Sz1jjt5WYcs32Hqi6 TFy+YKMktx2t8pI/RH4sQ+i5bT2bJeKWfsn/sTm2J4eU3EpPrq5uGmi5h67ml6MA0epx xvLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=DvakLAAp; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id jc28-20020a056a006c9c00b006cb8daad91csi3224432pfb.187.2023.12.01.02.44.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Dec 2023 02:44:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=DvakLAAp; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 2548C80B6C05; Fri, 1 Dec 2023 02:44:18 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378332AbjLAKoJ (ORCPT + 99 others); Fri, 1 Dec 2023 05:44:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378331AbjLAKoH (ORCPT ); Fri, 1 Dec 2023 05:44:07 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 86281D40; Fri, 1 Dec 2023 02:44:13 -0800 (PST) Date: Fri, 01 Dec 2023 10:44:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1701427450; 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=qPCIzTyiZpaSnXIh/BvFIvvdQAACVmWB9mApE7JKoAs=; b=DvakLAApprtB0OyOTMY42r02WoLgRIQ/ta6o+V3Hwr+e8WxyucftkyCOtIs0dGreeHx/8C 4VexC5Qo83qvFbep6hWE5pgnqtndnXwD1uqZfG9Ph89V1FeVymawKhzsdEtGi6fzxeXQF+ 9UH37eE3ClHq9iNqNxCIo0vWXWqk5GXRGnocuSzsZ6RWJEUXda7FsvH8qzMUfGARF/kAlM mvhgYWByQPu2xsFv9NdmJi9XK8V4p7GvkF/7ESHPf8TPLB7XuFamtobukk9kqlJ55Q5SxJ sCWVEHVSy1swB3tKJKXR5fr2mSZ+fhY1avsYNJoaFaRQ49fcs8tUGB4IFjGvgA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1701427450; 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=qPCIzTyiZpaSnXIh/BvFIvvdQAACVmWB9mApE7JKoAs=; b=F2lG/6euZHkXs93PwgAAg1+EU07oCX9oLV1x9G1eyAL//oYtb7ZABV7ZBBpl4zgjYNf22V DWU5rgKWWP/OIUAA== From: "tip-bot2 for Jann Horn" 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: Document that mutex_unlock() is non-atomic Cc: Jann Horn , Ingo Molnar , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20231130204817.2031407-1-jannh@google.com> References: <20231130204817.2031407-1-jannh@google.com> MIME-Version: 1.0 Message-ID: <170142744948.398.4203675877225809071.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Fri, 01 Dec 2023 02:44:18 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784075325149027536 X-GMAIL-MSGID: 1784076001729920891 The following commit has been merged into the locking/core branch of tip: Commit-ID: a51749ab34d9e5dec548fe38ede7e01e8bb26454 Gitweb: https://git.kernel.org/tip/a51749ab34d9e5dec548fe38ede7e01e8bb26454 Author: Jann Horn AuthorDate: Thu, 30 Nov 2023 21:48:17 +01:00 Committer: Ingo Molnar CommitterDate: Fri, 01 Dec 2023 11:27:43 +01:00 locking/mutex: Document that mutex_unlock() is non-atomic I have seen several cases of attempts to use mutex_unlock() to release an object such that the object can then be freed by another task. This is not safe because mutex_unlock(), in the MUTEX_FLAG_WAITERS && !MUTEX_FLAG_HANDOFF case, accesses the mutex structure after having marked it as unlocked; so mutex_unlock() requires its caller to ensure that the mutex stays alive until mutex_unlock() returns. If MUTEX_FLAG_WAITERS is set and there are real waiters, those waiters have to keep the mutex alive, but we could have a spurious MUTEX_FLAG_WAITERS left if an interruptible/killable waiter bailed between the points where __mutex_unlock_slowpath() did the cmpxchg reading the flags and where it acquired the wait_lock. ( With spinlocks, that kind of code pattern is allowed and, from what I remember, used in several places in the kernel. ) Document this, such a semantic difference between mutexes and spinlocks is fairly unintuitive. [ mingo: Made the changelog a bit more assertive, refined the comments. ] Signed-off-by: Jann Horn Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20231130204817.2031407-1-jannh@google.com --- Documentation/locking/mutex-design.rst | 6 ++++++ kernel/locking/mutex.c | 5 +++++ 2 files changed, 11 insertions(+) diff --git a/Documentation/locking/mutex-design.rst b/Documentation/locking/mutex-design.rst index 78540cd..7572339 100644 --- a/Documentation/locking/mutex-design.rst +++ b/Documentation/locking/mutex-design.rst @@ -101,6 +101,12 @@ 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. Interfaces ---------- diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c index 2deeeca..cbae8c0 100644 --- a/kernel/locking/mutex.c +++ b/kernel/locking/mutex.c @@ -532,6 +532,11 @@ static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigne * This function must not be used in interrupt context. Unlocking * of a not locked mutex is not allowed. * + * The caller must ensure that the mutex stays alive until this function has + * returned - mutex_unlock() can NOT directly be used to release an object such + * that another concurrent task can free it. + * Mutexes are different from spinlocks & refcounts in this aspect. + * * This function is similar to (but not equivalent to) up(). */ void __sched mutex_unlock(struct mutex *lock)