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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A7A7C433EF for ; Sat, 30 Apr 2022 21:08:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B90026B0072; Sat, 30 Apr 2022 17:08:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B3F5B6B0073; Sat, 30 Apr 2022 17:08:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A08416B0074; Sat, 30 Apr 2022 17:08:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 90E316B0072 for ; Sat, 30 Apr 2022 17:08:14 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 5C34180BCC for ; Sat, 30 Apr 2022 21:08:14 +0000 (UTC) X-FDA: 79414783308.06.E479CEE Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf22.hostedemail.com (Postfix) with ESMTP id C9A0BC006F for ; Sat, 30 Apr 2022 21:08:12 +0000 (UTC) From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1651352891; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JYiEoXgZa+1xAFGzJ6pdbgZS9bMkYlHMr5G8hxuq7k0=; b=X5/Hv1szmlnx+Kn4ZVFxkz6yfaMIt6UJ+l1gY8T/a9sG0fqV6nIwpUMxSmWEhoRWuWGkUf pw6spnQlELZ2G7HacGwrDq7/RWAAix7kyb7bHlFcOzjSSClc0GssKym4B0ZdtbB4NUaN3w 0q4BDOIEz6gigZA0s6uqWtNw7Fg/O/O/BvM9Om6BsdyH5Ck7dctYYgArOt0Sp6r32/9X1W GjPXgN99BYpZItZfVhUFqvXd5S8Wz0mB+k7reHJyIp6AxxSU5Y4pby8R+Lme/J7lgCpNVa O6OJ9WgQFC10tOvqwbGyHuRELT8BxVaCvr9J4pvKTkoMimgdw2PUvOpkUQf0zw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1651352891; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JYiEoXgZa+1xAFGzJ6pdbgZS9bMkYlHMr5G8hxuq7k0=; b=P4+uquywNx3JFpUdyBVMRf/LWCCPvN3ivrNp3YBAvJLOvyGr87StS76UpIdomH9o8F0KTN IaZ2p7Pc009IwgBA== To: Marco Elver , Naresh Kamboju , Petr Mladek Cc: Linux-Next Mailing List , open list , lkft-triage@lists.linaro.org, linux-mm , Andrew Morton , Alexander Potapenko , Dmitry Vyukov , Stephen Rothwell , Anders Roxell , Andrey Konovalov , Andrey Ryabinin , Catalin Marinas , Evgenii Stepanov , Mark Rutland , Peter Collingbourne , Vincenzo Frascino , Will Deacon Subject: Re: [next] i386: kunit: ASSERTION FAILED at mm/kfence/kfence_test.c:547 In-Reply-To: References: Date: Sat, 30 Apr 2022 23:14:10 +0206 Message-ID: <87fslup9dx.fsf@jogness.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C9A0BC006F X-Stat-Signature: nzh4jpsqzdd3bq7d8mydobyfok7c1een X-Rspam-User: Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="X5/Hv1sz"; dkim=pass header.d=linutronix.de header.s=2020e header.b=P4+uquyw; spf=pass (imf22.hostedemail.com: domain of john.ogness@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=john.ogness@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de X-HE-Tag: 1651352892-259098 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: Hi Marco, On 2022-04-29, Marco Elver wrote: > And looking at your log [1], it shows that KFENCE is working just > fine, but the logic that is supposed to intercept the kernel log (via > tracepoint) to check that reports are being generated correctly seems > to be broken. > > And this is not only i386-specific, it's also broken on a x86-64 > build. > > At first I thought maybe with the printk changes we'd now have to call > pr_flush(), but that doesn't work, so I'm missing something still: > > | --- a/mm/kfence/kfence_test.c > | +++ b/mm/kfence/kfence_test.c > | @@ -73,11 +73,18 @@ static void probe_console(void *ignore, const char *buf, size_t len) > | } > | > | /* Check if a report related to the test exists. */ > | -static bool report_available(void) > | +static bool __report_available(void) > | { > | return READ_ONCE(observed.nlines) == ARRAY_SIZE(observed.lines); > | } > | > | +/* Check if a report related to the test exists; may sleep. */ > | +static bool report_available(void) > | +{ > | + pr_flush(0, true); > | + return __report_available(); > | +} > | + I am not familiar with how this works. Is the tracepoint getting set on call_console_drivers()? Or on call_console_driver()? If so, there are a couple problems with that. First off, the prototype for that function has changed. Second, that function is called when text is printed, but this is not when the text was created. With the kthreads, the printing can be significantly delayed. Since printk() is now lockless and console printing is delayed, it becomes a bit tricky to parse the records in the existing code using a tracepoint. I wonder if creating a NOP function for the kfence probe to attach to would be more appropriate. In printk_sprint() we get the text after space has been reserved, but before the text is committed to the ringbuffer. This is guaranteed to be called from within the printk() context. Here is an example of what I am thinking... --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -2227,6 +2227,10 @@ static u16 printk_sprint(char *text, u16 size, int facility, } } +#ifdef CONFIG_KFENCE_KUNIT_TEST + printk_kfence_check(text, text_len); +#endif + return text_len; } The probe_console() could attach to a NOP function printk_kfence_check(). John