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.7 required=3.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 08D6EC433B4 for ; Wed, 21 Apr 2021 09:11:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4262861409 for ; Wed, 21 Apr 2021 09:11:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4262861409 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 ABC0F6B006C; Wed, 21 Apr 2021 05:11:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A59A76B006E; Wed, 21 Apr 2021 05:11:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8FA3F6B0070; Wed, 21 Apr 2021 05:11:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0100.hostedemail.com [216.40.44.100]) by kanga.kvack.org (Postfix) with ESMTP id 6F3696B006C for ; Wed, 21 Apr 2021 05:11:34 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 32B621813458C for ; Wed, 21 Apr 2021 09:11:34 +0000 (UTC) X-FDA: 78055806108.23.52B35FB Received: from r3-22.sinamail.sina.com.cn (r3-22.sinamail.sina.com.cn [202.108.3.22]) by imf07.hostedemail.com (Postfix) with SMTP id C015BA00038C for ; Wed, 21 Apr 2021 09:11:31 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([221.199.207.227]) by sina.com (172.16.97.32) with ESMTP id 607FEC3F00001E87; Wed, 21 Apr 2021 17:11:29 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 502493628973 From: Hillf Danton To: Marco Elver Cc: Andrew Morton , Alexander Potapenko , Dmitry Vyukov , Jann Horn , Mark Rutland , Hillf Danton , LKML , Linux Memory Management List , kasan-dev Subject: Re: [PATCH 1/3] kfence: await for allocation using wait_event Date: Wed, 21 Apr 2021 17:11:20 +0800 Message-Id: <20210421091120.1244-1-hdanton@sina.com> In-Reply-To: References: <20210419085027.761150-1-elver@google.com> <20210419085027.761150-2-elver@google.com> <20210419094044.311-1-hdanton@sina.com> MIME-Version: 1.0 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: C015BA00038C X-Stat-Signature: gyft5p49p89674k8zca1ano9eqm4x7hc Received-SPF: none (sina.com>: No applicable sender policy available) receiver=imf07; identity=mailfrom; envelope-from=""; helo=r3-22.sinamail.sina.com.cn; client-ip=202.108.3.22 X-HE-DKIM-Result: none/none X-HE-Tag: 1618996291-983787 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.001148, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 19 Apr 2021 11:49:04 Marco Elver wrote: >On Mon, 19 Apr 2021 at 11:44, Marco Elver wrote: >> On Mon, 19 Apr 2021 at 11:41, Hillf Danton wrote: >> > On Mon, 19 Apr 2021 10:50:25 Marco Elver wrote: >> > > + >> > > + WRITE_ONCE(kfence_timer_waiting, true); >> > > + smp_mb(); /* See comment in __kfence_alloc(). */ >> > >> > This is not needed given task state change in wait_event(). >> >> Yes it is. We want to avoid the unconditional irq_work in >> __kfence_alloc(). When the system is under load doing frequent >> allocations, at least in my tests this avoids the irq_work almost >> always. Without the irq_work you'd be correct of course. > >And in case this is about the smp_mb() here, yes it definitely is >required. We *must* order the write of kfence_timer_waiting *before* >the check of kfence_allocation_gate, which wait_event() does before >anything else (including changing the state). One of the reasons why wait_event() checks the wait condition before anyt= hing else is no waker can help waiter before waiter gets themselves on the wait queue head list. Nor can waker without scheduling on the waiter side, even if the waiter is sitting on the list. So the mb cannot make se= nse without scheduling, let alone the mb in wait_event(). >Otherwise the write may >be reordered after the read, and we could potentially never wake up >because __kfence_alloc() not waking us. > >This is documented in __kfence_alloc(). > >> > > + wait_event_timeout(allocation_wait, atomic_read(&kfence_allo= cation_gate), HZ); >> > > + smp_store_release(&kfence_timer_waiting, false); /* Order af= ter wait_event(). */ >> > > +