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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 BCE64C433DB for ; Fri, 15 Jan 2021 10:18:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 550E3235F9 for ; Fri, 15 Jan 2021 10:18:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 550E3235F9 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 CEC118D0155; Fri, 15 Jan 2021 05:18:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C75788D0023; Fri, 15 Jan 2021 05:18:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B63658D0155; Fri, 15 Jan 2021 05:18:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0038.hostedemail.com [216.40.44.38]) by kanga.kvack.org (Postfix) with ESMTP id 983B48D0023 for ; Fri, 15 Jan 2021 05:18:52 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6BF9733C4 for ; Fri, 15 Jan 2021 10:18:52 +0000 (UTC) X-FDA: 77707610904.14.comb82_0f1118a2752e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 4FC8518229818 for ; Fri, 15 Jan 2021 10:18:52 +0000 (UTC) X-HE-Tag: comb82_0f1118a2752e X-Filterd-Recvd-Size: 6040 Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Fri, 15 Jan 2021 10:18:51 +0000 (UTC) Received: by mail-qv1-f47.google.com with SMTP id p5so3704796qvs.7 for ; Fri, 15 Jan 2021 02:18:51 -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=ccivHPXPZm7za6CxMewEAR4fuE99UUFG/9IwgtB77NU=; b=uo1dSCvmZPsHPZ6jxqO+IuQMcCL2/T9xiHyCoBb8ZMS3+fpZaU+iTpCFsP6JW0JCOn 1vyQf5tFXjOw0KXULmXDNkqQZAZ5uAEeEqiHwQx11N3zAd/4tBg0mhhToIxKE8QnMUlo pB2jkgOHCuic0ucyT9tMYSeo2qyWZ96+F85aVXlDdFc+35Odo7YP6PHOZoCF9xDbXnhq cdT8x9x2RZVIjOoNg4DrtnC+k48yaOz6WAmc0/YGQVhw+uvgfoiVrlfJ7YR0QBVrH8hQ 6GZ7Q1w6VxFpC/PHfzDfISQv4W8uzeVSh/jI66OVa/L717sjASAJGLmxZn+xJUoqSuvh ny1g== 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=ccivHPXPZm7za6CxMewEAR4fuE99UUFG/9IwgtB77NU=; b=B5Yo7aQZRXPjqtzf1GML6Cxpa+xDveOGCagDmQcG60rqRrtR70/AsZIsx0HJPZ+/xx zjlxPKj+GBWeZA87YBE1tpAR43eRu3nKbljQTYB0wyHOVnoadonoKS2YoyT+3ZLo+AuJ rpLd/IYjgfQisNz8BsJo3u2EwZUI0/T1PaABImQtUf6phLwzAB00ht0TnrNdbmc5caYL Qu9qVhJxP7+HYxBlrZAIiM/GiUZrU42q15nGnEDUUldrWjzJaQfTex+UowCne9WMVilB pAn1CW2UJY4shAcxsPE9mqDVpXJwr9ieEN98JK+kyY7gs7x8+wtpvlRkm83peUco2tsg u3zA== X-Gm-Message-State: AOAM532441jMOEyYm1z6UaPRgEecBKq/MQUIMPj+hN0bheHrnfit6gOE InJ9TYoYWZgoOJZvEBfh+Z37OdohQ7AMc5s5oOL36A== X-Google-Smtp-Source: ABdhPJyL4bnK7DqSx1oVKrhp+leBeNzcqxbQ7JPj4EaChQSuBbxh1MheeX7oEcc4IwuO2Qo6PaEmUeXoqDKtBK+VzdQ= X-Received: by 2002:a0c:e90a:: with SMTP id a10mr11514765qvo.38.1610705930918; Fri, 15 Jan 2021 02:18:50 -0800 (PST) MIME-Version: 1.0 References: <20210113091657.1456216-1-glider@google.com> <20210113091657.1456216-3-glider@google.com> <20210113160612.32f8b67494521ce23cc9cba5@linux-foundation.org> In-Reply-To: From: Alexander Potapenko Date: Fri, 15 Jan 2021 11:18:39 +0100 Message-ID: Subject: Re: [PATCH 2/4] lib: add error_report_notify to collect debugging tools' reports To: Andrew Morton Cc: LKML , Marco Elver , Andrey Konovalov , Dmitry Vyukov , Ingo Molnar , Petr Mladek , Steven Rostedt , Sergey Senozhatsky , Linux Memory Management List 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 Thu, Jan 14, 2021 at 10:51 AM Alexander Potapenko wrote: > > On Thu, Jan 14, 2021 at 1:06 AM Andrew Morton wrote: > > > > On Wed, 13 Jan 2021 10:16:55 +0100 Alexander Potapenko wrote: > > > > > With the introduction of various production error-detection tools, such as > > > MTE-based KASAN and KFENCE, the need arises to efficiently notify the > > > userspace OS components about kernel errors. Currently, no facility exists > > > to notify userspace about a kernel error from such bug-detection tools. > > > The problem is obviously not restricted to the above bug detection tools, > > > and applies to any error reporting mechanism that does not panic the > > > kernel; this series, however, will only add support for KASAN and KFENCE > > > reporting. > > > > > > All such error reports appear in the kernel log. But, when such errors > > > occur, userspace would normally need to read the entire kernel log and > > > parse the relevant errors. This is error prone and inefficient, as > > > userspace needs to continuously monitor the kernel log for error messages. > > > On certain devices, this is unfortunately not acceptable. Therefore, we > > > need to revisit how reports are propagated to userspace. > > > > > > The library added, error_report_notify (CONFIG_ERROR_REPORT_NOTIFY), > > > solves the above by using the error_report_start/error_report_end tracing > > > events and exposing the last report and the total report count to the > > > userspace via /sys/kernel/error_report/last_report and > > > /sys/kernel/error_report/report_count. > > > > > > Userspace apps can call poll(POLLPRI) on those files to get notified about > > > the new reports without having to watch dmesg in a loop. > > > > It would be nice to see some user-facing documentation for this, under > > Documentation/. How to use it, what the shortcomings are, etc. > > Good point, will do. Added in v2. > > For instance... what happens when userspace is slow reading > > /sys/kernel/error_report/last_report? Does that file buffer multiple > > reports? Does the previous one get overwritten? etc. Words on how > > this obvious issue is handled... > > Yes, there can be issues with overwriting, and the recommended way to > handle them would be to check the value in > /sys/kernel/error_report/report_count before and after reading the > report. After looking closer it occurs to me that sysfs retains the buffer returned by the attribute's show() method, so that one can read the whole report up to the end even if the file contents change. > > There's really nothing "memory" specific about this? Any kernel > > subsystem could use it? > > Indeed. Perhaps it's better to emphasize "production" here, because > users of debugging tools are more or less happy with dmesg output. Changed to "error reports from debugging tools".