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 6D52C30C160; Thu, 20 Aug 2026 07:33:43 +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=1787211226; cv=none; b=VTYsSVrifGa7QbmnZp9VkAA/tuVXrJcBl/jWh3tMU2doOItpHARWKVddsJeHiJWftgaH84aIHE/587fBxQdO2vG0BRmW2SR0kZQJzjjdMuKXknRX+ZaIf8uuEiTgwgWt1dYyzWacVMYuTk1sXsmGKq5egnm5eEzpgCqv0Pc2PtE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787211226; c=relaxed/simple; bh=3aLoH0UPWOX6g/DIpcdu/D0RGZvtQwzAWXKiQnAjO+s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fKpt7cpuTaUbTdXt0iJZbo3Z49Z9K6a+7NfEHZaMqHLCD3P32gz0aqjFxH9ql/u2dkhQMBuYcHdsj3b4QRV8yqDmKAxw+zGQqfOct2/XqHYH47ItIOS9YfCe5bvzqMFJJ2x4j7J+0wx45mDk77y0gtyF5ekPI6mJfv102sjjEbI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=WULNicnc; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="WULNicnc" 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=wJRBXH5HBdzU1+TJJ8HukY/EDbkthd34sEpJxZXTzPU=; b=WULNicnc/HsstdCLsTGm7d2EBu Gum2bWIBPrdeX7QTwMfauTyyGI9L/0aY5G+73geE8SPxGqMqvhzQ+QLy0GpfYBTCKsYYfqlgpcRTG YXFKhnPyUuMaLda404B+Rg8eJTPuEp3LlHe6f2xIerJEOqlNYFqO3ykA5Dh7el17GkzhSKj2/FKKy YNV6bajhtSUj213an5c76QGb8wlgc7lILfgyUBOl4MN6ou12uOpTUQdv51HOxenMiGR/HvHUlxr+9 1DlQH9Rq56c9VdyM9eHR+snsVLXSUDeV3+0TPteYkcBr0QN2YbxnjDnCvRBEU0OEfjUkrh/I31Xxu sC4eCupA==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1wwxHO-00000002vDB-0pJo; Thu, 20 Aug 2026 07:33:38 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 4AB993006FA; Thu, 20 Aug 2026 09:33:37 +0200 (CEST) Date: Thu, 20 Aug 2026 09:33:37 +0200 From: Peter Zijlstra To: Yao Kai Cc: syzbot , syzkaller-bugs@googlegroups.com, linux-kernel@vger.kernel.org, Ingo Molnar , Thomas Gleixner , andrealmeid@igalia.com, dave@stgolabs.net, dvhart@infradead.org, liuyongqiang13@huawei.com, syzbot@lists.linux.dev Subject: Re: [PATCH] futex: Fix might_sleep() warning in futex_pivot_pending() Message-ID: <20260820073337.GL1247881@noisy.programming.kicks-ass.net> References: <515ea00f-a081-4b9a-bcb3-f5517fd4e565@mail.kernel.org> <20260814133803.GA687043@noisy.programming.kicks-ass.net> <20260818104658.GE1246887@noisy.programming.kicks-ass.net> <681d9e21-d408-4acb-8c51-b8a86d599e0f@huawei.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: <681d9e21-d408-4acb-8c51-b8a86d599e0f@huawei.com> On Tue, Aug 18, 2026 at 08:24:07PM +0800, Yao Kai wrote: > > + __wq_head = __var_waitqueue(mm); > > + init_wait_var_entry(&__wbq_entry, mm, 0); > > + __wbq_entry.wq_entry.func = woken_wake_bit_function; > > + add_wait_queue(__wq_head, &__wbq_entry.wq_entry); > > + > > + /* > > + * add_wait_queue() futex_ref_put() > > + * MB (this) MB (implied) > > + * futex_pivot_pending() wake_up_var() > > + * waitqueue_active() > > + * > > + * Notably, it must not be possible to see > > + * !futex_pivot_pending() && !waitqueue_active(). > > + */ > > + smp_mb__after_spinlock(); > > I still think we should use smp_mb() here, smp_mb__after_spinlock() only > orders accesses preceding the lock acquisition against later accesses. The > waitqueue insertion happens after that acquisition, so I don't think > smp_mb__after_spinlock() covers it here. I can definitely make it smp_mb() just to make you feel better, this is not a fast path. But the smp_mb__after_spinlock() is sufficient in this case. Specifically, the situation is LOCK(&waitq->lock) [STORE] list_add() UNLOCK(&waitq->lock) smp_mb__after_spinlock() LOCK(&mmph->lock) [LOAD] refcount UNLOCK(&mmph->lock) That means the STORE and LOAD are separated by UNLOCK+LOCK, and on every architecture *EXCEPT* PPC that implies smp_mb(). On PPC we need the extra smp_mb() to 'upgrade' the LWSYNC to SYNC. Specifically, on TSO (x86,s390,sparc64) the atomic op in LOCK implies a full barrier, on ARM64 RELEASE+ACQUIRE is RCsc, etc. There is a section on LOCKING in tools/memory-model/Documentation/explanation.txt on this very subject. > > + > > + while (!futex_pivot_pending(mm) && > > + wait_woken(&__wbq_entry.wq_entry, TASK_UNINTERRUPTIBLE, > > + MAX_SCHEDULE_TIMEOUT)) > > + /* empty */; > > Since MAX_SCHEDULE_TIMEOUT never returns zero, so I think this can be: > > while (!futex_pivot_pending(mm)) > wait_woken(&__wbq_entry.wq_entry, TASK_UNINTERRUPTIBLE, > MAX_SCHEDULE_TIMEOUT)); Well, you missed the '&&', but that is exactly what I wrote, no? I just put the ';' behind a comment, to indicate it was an empty loop on purpose. Some people (and static checkers/linters/etc.) get upset/confused if there is no body on a loop construct. Anyway, I've tested all this, selftests/futex trips this WARN without, and runs to completion with this patch, so it must be perfect. Let me go write a Changelog.