From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97E11C07E9B for ; Wed, 21 Jul 2021 07:05:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E98EC601FC for ; Wed, 21 Jul 2021 07:05:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E98EC601FC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 466F56B0036; Wed, 21 Jul 2021 03:05:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EFFD6B0070; Wed, 21 Jul 2021 03:05:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26A3F6B0071; Wed, 21 Jul 2021 03:05:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0161.hostedemail.com [216.40.44.161]) by kanga.kvack.org (Postfix) with ESMTP id EC4F66B0036 for ; Wed, 21 Jul 2021 03:05:15 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 728948248047 for ; Wed, 21 Jul 2021 07:05:14 +0000 (UTC) X-FDA: 78385708548.33.7C19200 Received: from mail3-165.sinamail.sina.com.cn (mail3-165.sinamail.sina.com.cn [202.108.3.165]) by imf25.hostedemail.com (Postfix) with SMTP id 58D52B02EA08 for ; Wed, 21 Jul 2021 07:05:08 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([1.24.238.81]) by sina.com (172.16.97.32) with ESMTP id 60F7C71A0000733A; Wed, 21 Jul 2021 15:05:01 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 979613629060 From: Hillf Danton To: Paolo Bonzini Cc: Thomas Gleixner , Sebastian Andrzej Siewior , "Michael S. Tsirkin" , linux-mm@kvack.org, LKML , Al Viro Subject: Re: 5.13-rt1 + KVM = WARNING: at fs/eventfd.c:74 eventfd_signal() Date: Wed, 21 Jul 2021 15:04:52 +0800 Message-Id: <20210721070452.1008-1-hdanton@sina.com> In-Reply-To: <724e7951-59c8-8b2b-37b8-6b0bf696ab04@redhat.com> References: <8dfc0ee9-b97a-8ca8-d057-31c8cad3f5b6@redhat.com> <475f84e2-78ee-1a24-ef57-b16c1f2651ed@redhat.com> <20210715102249.2205-1-hdanton@sina.com> <20210716020611.2288-1-hdanton@sina.com> <20210716075539.2376-1-hdanton@sina.com> <20210716093725.2438-1-hdanton@sina.com> <20210718124219.1521-1-hdanton@sina.com> MIME-Version: 1.0 Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.165 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none X-Rspamd-Server: rspam02 X-Stat-Signature: zsh5edd8gghwmcrg8mzh9ehnqgmowgwc X-Rspamd-Queue-Id: 58D52B02EA08 X-HE-Tag: 1626851108-904610 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 19 Jul 2021 17:38:45 +0200 Paolo Bonzini wrote: >On 18/07/21 14:42, Hillf Danton wrote: >>> It's caused by the missing wakeup, i.e. eventfd_signal not really >>> signaling anything. >>=20 >> Can you please point me to the waiters in the mainline? > >It's irqfd_wakeup. Thanks for your light. With PREEMPT_RT put aside, the race looks like the following. CPU0 CPU1 CPU2 ---- ---- ---- lock waitqueue wake up waiters unlock waitqueue lock waitqueue no waiter unlock waitqueue lock waitqueue add waiter unlock waitqueue If the missing wakeup on CPU1 is bloody critical to the waiter added on C= PU2 then the size of race window is supposed to play magic. The race window c= an be simulated by giving up wakeup if trylock fails. With PREEMPT_RT before your patch, eventfd_wake_count prevents the preemp= ting waker from acquiring the waitqueue lock and ends up with the race window widened because of the certainty of missing wakeup. CPU0 CPU1 ---- ---- lock waitqueue wake up <-- preempt waiters unlock waitqueue lock waitqueue add waiter unlock waitqueue With PREEMPT_RT after your patch, the race window goes back to without PREEMPT_RT because of no occurence of preemption. But the preempting waker can not make sense without the waiter who is blo= ody special. Why is it so in the first place? Or it is not at all but the rac= e existing from Monday to Friday.