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=-17.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham 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 7B552C388F7 for ; Tue, 10 Nov 2020 14:54:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D8AFE206F1 for ; Tue, 10 Nov 2020 14:54:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="mNP/K9iv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D8AFE206F1 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9DE3A6B005D; Tue, 10 Nov 2020 09:54:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 969036B006C; Tue, 10 Nov 2020 09:54:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 830DA6B006E; Tue, 10 Nov 2020 09:54:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0231.hostedemail.com [216.40.44.231]) by kanga.kvack.org (Postfix) with ESMTP id 521226B005D for ; Tue, 10 Nov 2020 09:54:01 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E5F583629 for ; Tue, 10 Nov 2020 14:54:00 +0000 (UTC) X-FDA: 77468803440.16.kite17_160a19b272f6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id AC36A100E691B for ; Tue, 10 Nov 2020 14:54:00 +0000 (UTC) X-HE-Tag: kite17_160a19b272f6 X-Filterd-Recvd-Size: 5772 Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com [209.85.210.66]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Tue, 10 Nov 2020 14:54:00 +0000 (UTC) Received: by mail-ot1-f66.google.com with SMTP id 30so6991103otx.9 for ; Tue, 10 Nov 2020 06:53:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FbcyUD14O34qORQweJ7OM0zfYmKvTkKcQqefmr2UkfI=; b=mNP/K9iv5SYU27emsjB5W17wgZ7cLje94t1rArD5f7lC/L5J98/SvmNImo0623rskX kasAc/JGxTZ5n7ILmHtJbYeD1Umhh05nHDrERl5XklzG/faCGnMqaDT/0wfh/+uibkWC hSHW1p4AoQS82PgP6gXp8Tq0FN+ezzjS9rrzXvvCqdv0INZkid7p2X3A4iKND19XC6VH qQBSxp3kA0i6HVA7WlWhsN8ecJ5h/G9k+7WgvIndzqnR36gler+H9FwJ2SUekC3YH3FF oGx7GLq11eGrqZ+2NCtOHGfP8TfgFv+qPKnI/7GJKEA6f5DtEvEg4kfVjWgcS31A7W8i mnSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FbcyUD14O34qORQweJ7OM0zfYmKvTkKcQqefmr2UkfI=; b=mLRb0/HQl078WvcjVQAN2oAP9LY6f5ZN2hxhfmBzK/zGuv5kri5zoR+0qSjl7KQb0N D12Rz2qn8tzq/4fWcipTD0bXpMZK/E5Cq0EruTP4AAPXYB1rZdJh7/09ajxDQ96/Aj8z 0FhnxXOCyS9VBeoUGiY4k8uxfuVlZ+akhvXcUcwjKCfe0Y/siXQzqOZuOnIdHmRoHqNi wRYgzeQLfM0Vy7wzX/uo0e+11z3KU7F9ZyDxmsERi3a47SbGm1xYnKUMXZt95D72+rSw wOkxrKCbsFnUdANnLV/99oYNyQftV06RGT3tzkMyPRt8rRrOS92h8bShAIIUvZiHQV2z zvzQ== X-Gm-Message-State: AOAM531dVW46PuS6QJhFIpBMtrPUif48ttsVoVLt31iPatSNDjq5Pd6H UDhYG/TM4RaPGw0GdpbgaYOko9wJ8LGZxbQ1MoWe5w== X-Google-Smtp-Source: ABdhPJzuFinlenRa8Bx5uePYypLWzX7wWoUwM8r8lQOjW5+vTNLUDGXOSqq2AKEBjVDLyJoEuP2UPRdRU9h84Bnhw4U= X-Received: by 2002:a9d:f44:: with SMTP id 62mr15154590ott.17.1605020039230; Tue, 10 Nov 2020 06:53:59 -0800 (PST) MIME-Version: 1.0 References: <20201110135320.3309507-1-elver@google.com> In-Reply-To: From: Marco Elver Date: Tue, 10 Nov 2020 15:53:47 +0100 Message-ID: Subject: Re: [PATCH] kfence: Avoid stalling work queue task without allocations To: Dmitry Vyukov Cc: Andrew Morton , Alexander Potapenko , Jann Horn , Mark Rutland , LKML , Linux-MM , kasan-dev , Anders Roxell Content-Type: text/plain; charset="UTF-8" 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 Tue, 10 Nov 2020 at 15:25, Dmitry Vyukov wrote: > On Tue, Nov 10, 2020 at 2:53 PM Marco Elver wrote: > > To toggle the allocation gates, we set up a delayed work that calls > > toggle_allocation_gate(). Here we use wait_event() to await an > > allocation and subsequently disable the static branch again. However, if > > the kernel has stopped doing allocations entirely, we'd wait > > indefinitely, and stall the worker task. This may also result in the > > appropriate warnings if CONFIG_DETECT_HUNG_TASK=y. > > > > Therefore, introduce a 1 second timeout and use wait_event_timeout(). If > > the timeout is reached, the static branch is disabled and a new delayed > > work is scheduled to try setting up an allocation at a later time. > > > > Note that, this scenario is very unlikely during normal workloads once > > the kernel has booted and user space tasks are running. It can, however, > > happen during early boot after KFENCE has been enabled, when e.g. > > running tests that do not result in any allocations. > > > > Link: https://lkml.kernel.org/r/CADYN=9J0DQhizAGB0-jz4HOBBh+05kMBXb4c0cXMS7Qi5NAJiw@mail.gmail.com > > Reported-by: Anders Roxell > > Signed-off-by: Marco Elver > > --- > > mm/kfence/core.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/mm/kfence/core.c b/mm/kfence/core.c > > index 9358f42a9a9e..933b197b8634 100644 > > --- a/mm/kfence/core.c > > +++ b/mm/kfence/core.c > > @@ -592,7 +592,11 @@ static void toggle_allocation_gate(struct work_struct *work) > > /* Enable static key, and await allocation to happen. */ > > atomic_set(&allocation_gate, 0); > > static_branch_enable(&kfence_allocation_key); > > - wait_event(allocation_wait, atomic_read(&allocation_gate) != 0); > > + /* > > + * Await an allocation. Timeout after 1 second, in case the kernel stops > > + * doing allocations, to avoid stalling this worker task for too long. > > + */ > > + wait_event_timeout(allocation_wait, atomic_read(&allocation_gate) != 0, HZ); > > I wonder what happens if we get an allocation right when the timeout fires. > Consider, another task already went to the slow path and is about to > wake this task. This task wakes on timeout and subsequently enables > static branch again. Now we can have 2 tasks on the slow path that > both will wake this task. How will it be handled? Can it lead to some > warnings or something? wake_up() does not require tasks to be in the wait queue, nor is there any requirement that it's exclusive (it takes the appropriate locks unlike wake_up_locked()). One of the wake_up() calls will wake the task, and the other is a noop. So this will work just fine. Thanks, -- Marco