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 052F8C433EF for ; Thu, 21 Apr 2022 13:29:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 821AD6B0074; Thu, 21 Apr 2022 09:29:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D09A6B0078; Thu, 21 Apr 2022 09:29:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6232B6B007B; Thu, 21 Apr 2022 09:29:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 4ADA76B0074 for ; Thu, 21 Apr 2022 09:29:23 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 14AD123283 for ; Thu, 21 Apr 2022 13:29:23 +0000 (UTC) X-FDA: 79380967806.26.A012634 Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com [209.85.128.171]) by imf13.hostedemail.com (Postfix) with ESMTP id 3C63820033 for ; Thu, 21 Apr 2022 13:29:20 +0000 (UTC) Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-2edbd522c21so51695417b3.13 for ; Thu, 21 Apr 2022 06:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MqWLSGF5u7HAvIurWy83H/sqpyLwV1ABomzO+8j+TCM=; b=U513sTPiMRZGRNSKdjt3QeSvdzbpEHjYq6j9R437lt5/43iCCCTpCQAk5EbfstVV5A 5BJbtKNEKJWzj54bLT2lXzlFAXHgQjXfuI3yrKsh898fIve/BMcP10DAgtcvz3wvRSLA IgKvp7AhyAiVCQSzVdptv40cL65JwQUpw0S3jR5ifQiqkttiCeQlyTyr5ZxQcMzmCy+c QSzf08co3+vu0treKetig1m1Ulmct+CNkECdBoei+kYwVM39D8XRXD2nGGOctdgFOYFP PRIp24rs0EYKLlbrfF+3cO7OoNNSOwrPVJPYwCF/FPFqqaJPsruS8MA/RBQRJE/HVuFI MnWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MqWLSGF5u7HAvIurWy83H/sqpyLwV1ABomzO+8j+TCM=; b=DGhBzu6MQCBGLiGYLOazQ9MrYH3qkszgANqFRMiWjUy7lnAVThozv1MCriK9KEJXJ6 Psbnm3c86oRKqgZbYtgdHTQstv4G8u/rBlICVeafATxSDajMZcYqun4FRPzqQjBYQhod ZVcdviCDyvQHgvKfS84eJM4oHxO0goYRHxSjIteM1e5A/tOb6zsIJAaO6AL68UW8FUWM mNH9GSnJoSTcJ2pVYhvZCqDJm3YgZwVySq9fARHvwelgJqLrmQ19NbHLsorZkhkkrXfF lN1JQGAM6vpBvrwaSxAB7LyJtOe6rtUSWrPNmU04qNaJgEhz89ssZQ61T6ZTS5FRq23z ZP8g== X-Gm-Message-State: AOAM532HiZjB07fZ8+bni3edLHsgfXKhCWKgV0Mm+dJ61LaT9X84HpFc PGh/nUq4lLiUhUDVdODAboTcELEweWGogOnc+mr+UA== X-Google-Smtp-Source: ABdhPJy4N7/P+KHHPG82N6SmhOd/ruIRZ3Gy9NyR1BKf8pZ91u2lynhMt6bjMV3rw2eJ7ostei6X7SL+wdf3ZdVND/A= X-Received: by 2002:a81:f211:0:b0:2eb:9ac6:4dda with SMTP id i17-20020a81f211000000b002eb9ac64ddamr26303415ywm.362.1650547761401; Thu, 21 Apr 2022 06:29:21 -0700 (PDT) MIME-Version: 1.0 References: <20220421121018.60860-1-huangshaobo6@huawei.com> In-Reply-To: From: Marco Elver Date: Thu, 21 Apr 2022 15:28:45 +0200 Message-ID: Subject: Re: [PATCH] kfence: check kfence canary in panic and reboot To: Alexander Potapenko Cc: Shaobo Huang , Andrew Morton , chenzefeng2@huawei.com, Dmitriy Vyukov , kasan-dev , LKML , Linux Memory Management List , nixiaoming@huawei.com, wangbing6@huawei.com, wangfangpeng1@huawei.com, young.liuyang@huawei.com, zengweilin@huawei.com, zhongjubin@huawei.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3C63820033 X-Stat-Signature: nzimr1inmwfgwmmjz4sum7p35fm4ptae Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=U513sTPi; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of elver@google.com designates 209.85.128.171 as permitted sender) smtp.mailfrom=elver@google.com X-HE-Tag: 1650547760-392219 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 21 Apr 2022 at 15:06, Alexander Potapenko wrote: [...] > This report will denote that in a system that could have been running for days a particular skbuff was corrupted by some unknown task at some unknown point in time. > How do we figure out what exactly caused this corruption? > > When we deploy KFENCE at scale, it is rarely possible for the kernel developer to get access to the host that reported the bug and try to reproduce it. > With that in mind, the report (plus the kernel source) must contain all the necessary information to address the bug, otherwise reporting it will result in wasting the developer's time. > Moreover, if we report such bugs too often, our tool loses the credit, which is hard to regain. I second this - in particular we'll want this off in fuzzers etc., because it'll just generate reports that nobody can use to debug an issue. I do see the value in this in potentially narrowing the cause of a panic, but that information is likely not enough to fully diagnose the root cause of the panic - it might however prompt to re-run with KASAN, or check if memory DIMMs are faulty etc. We can still have this feature, but I suggest to make it off-by-default, and only enable via a boot param. I'd call it 'kfence.check_on_panic'. For your setup, you can then use it to enable where you see fit. Thanks, -- Marco