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 876D9C388F7 for ; Tue, 10 Nov 2020 14:25:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DBDEC2076E for ; Tue, 10 Nov 2020 14:25:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="gsorfyCV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DBDEC2076E 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 CC79C6B006C; Tue, 10 Nov 2020 09:25:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C9EAE6B0070; Tue, 10 Nov 2020 09:25:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB44C6B0071; Tue, 10 Nov 2020 09:25:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id 8DE6F6B006C for ; Tue, 10 Nov 2020 09:25:27 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1690B8249980 for ; Tue, 10 Nov 2020 14:25:27 +0000 (UTC) X-FDA: 77468731494.02.food62_4d0c659272f5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id E916210097AA0 for ; Tue, 10 Nov 2020 14:25:26 +0000 (UTC) X-HE-Tag: food62_4d0c659272f5 X-Filterd-Recvd-Size: 5386 Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Tue, 10 Nov 2020 14:25:26 +0000 (UTC) Received: by mail-qk1-f195.google.com with SMTP id v143so6999280qkb.2 for ; Tue, 10 Nov 2020 06:25:26 -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=AHqYsPMnh39efaowbWE1u8lOHSCxjgXUEGEjdD/sQII=; b=gsorfyCVgVAhThPqbOTMm18Al8rSfjTDwDQe/aeZtJ7Z+CKqle6LGo2qGHTda39sH+ x0NXYAQkAKaNB/DHQE1bTRZst2psyCFV4KWjzvaYY4rOxG96vutagdnuPQgwYOehVX2u hZTdOSYfj64lXo8ugQ8z0KVEzG8WTe63npkttogXLUaJrdNTKTqR0fNw3bDJxT6HoWEz OCqu0Wurgtb6JsInPRU2hGZIdJEbDeh6gNGs0a64Oo+cOM/HG8KSWNRgtJ9CU7E2cEow z+gdkOytzKX/mK//eod+ycIkPZx6wTTXpsjCxtI4yL6CkXmRjd/E+rX8Re12h4X4jrbE GjkQ== 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=AHqYsPMnh39efaowbWE1u8lOHSCxjgXUEGEjdD/sQII=; b=UaR68kYOxAOy0I1WxtgR7OgO+tkNORRVu6zlEWdFFZ2A4kXmNfcCwRrDWBD4HegvB+ /W+ljkyGqJCmT6JxeULO6irqUw6Lom5c4mlEsK89JoHn+iyBgQtcuW1r7+pSI/xlOEPt /uVHf3ZG5qPxVyDTHruMFRo4JLnlRb7I21On14FM2GWlnto6LGy0imMW+T4DAwdCfQPy szA+uXFkfaG9qajObv1UCq58fJTZdCGtcBxSKUyYd8GijBgDv7qVfaCmXJFXLZqlO79W hxb04VWyq4DDc0dxq4DHqikqrH8ZA/T+RtRvjDKcHwYT3kZsLG+gwcmJCdO9CAauTnNs Ro9A== X-Gm-Message-State: AOAM533/3i0tKO5f7kfHoXNls7PDlTqTYxdYOSqdCfumb1867nNIB4my YehO+VLIxJb5T5ctItZ28Jilehhe8/hx1VuVaIPsfA== X-Google-Smtp-Source: ABdhPJyibywoziBRvE+Zhy1U4WMtxvGQqvGE8BBxY6Qw9MUCSvIkSsbgobK4/c9L5p5M/ffy/qJvLuVitkStkaHf+Ww= X-Received: by 2002:a37:7b44:: with SMTP id w65mr20049707qkc.350.1605018325472; Tue, 10 Nov 2020 06:25:25 -0800 (PST) MIME-Version: 1.0 References: <20201110135320.3309507-1-elver@google.com> In-Reply-To: <20201110135320.3309507-1-elver@google.com> From: Dmitry Vyukov Date: Tue, 10 Nov 2020 15:25:13 +0100 Message-ID: Subject: Re: [PATCH] kfence: Avoid stalling work queue task without allocations To: Marco Elver 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, 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? > /* Disable static key and reset timer. */ > static_branch_disable(&kfence_allocation_key); > -- > 2.29.2.222.g5d2a92d10f8-goog