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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CF8A8C433EF for ; Thu, 25 Nov 2021 07:18:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232838AbhKYHV0 (ORCPT ); Thu, 25 Nov 2021 02:21:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353367AbhKYHTQ (ORCPT ); Thu, 25 Nov 2021 02:19:16 -0500 Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13DE1C061761 for ; Wed, 24 Nov 2021 23:16:05 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id b5-20020a9d60c5000000b0055c6349ff22so8102969otk.13 for ; Wed, 24 Nov 2021 23:16:05 -0800 (PST) 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=1Q5EhbqpeXowwDK0bUK5avmicbNdhuUZQON4VKkJTMQ=; b=GzRzqrIBzWGcvP1Auwp1VXRcp4X8VC1mu+jSXH07xcJQeusu5bqWLVLXJwn6Ddm7Y+ ySt17kNB2JcMxmjfVRJmHKKNo1AZS4/AJ+qPafMBP020Xy0Zfnm4gy08vhfX5CYWEqat wK2imHXkPB2La3jed1lOojxxsOMJspL2YW1i9+KvC/BxoyGjne6yBHBa982lSsibyzhb vu6vx7hUnWsgaw1D1KIRMn/oGuCDd0SWhFbRgZAHiIY7IL+yv1CKKTKixmhTMQCcU9ut cERYwLjexgIgCfbKfS6h3hBYALUHq1hGfSrqSbvco8a3aZ6EsMnC3Qe8yuXGOXZsLjde A1zg== 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=1Q5EhbqpeXowwDK0bUK5avmicbNdhuUZQON4VKkJTMQ=; b=YBz40t63wck4outrpTSOI4G9bxKW7AaPKb6Y3CEO7NXxMGS2cUh1eC1go+Cttbp9O1 992qyG+vZv+t1OoQt0nTVJQlrEN6q8M/HiD15YsgZ2EOJlxjVghYRvSKRNjcQFrIR5E9 g0WdbvnTmmaKIL4rYaB/MCphNY2BPhJ4MbGmYz3Beylraedxw4g27Pm1S6jVZuXI0rPS MWuuG89dQbXeJlPQQhAnpSRTN30PAo0k9XucD/OSzFnjsMX7OXmTgXipTz70lHj6fLEx g6jNHqPJSHUonRjGBbEbATK3p67qvVMOhr+X+GfIV+9Dznakr3Cgu4hV6JkqUuraRTaG nY0Q== X-Gm-Message-State: AOAM531CKQda4syI36Kck4XZpYs5r2GW6IGpAVV3HCneC9pAtO4el0Ff axkmXtmNwEIsi2Z2tXkVAXPtGRoZjR0UG3h995FF7A== X-Google-Smtp-Source: ABdhPJzktIh4+dq3UQufJIs6YMgj/PNxm7+EyCyGeCajzNTglQ0v/PYqTM1bKWwC8ZzM6ZCMeoLzuGDBUulDS5SISjM= X-Received: by 2002:a05:6830:2425:: with SMTP id k5mr19508104ots.319.1637824564135; Wed, 24 Nov 2021 23:16:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dmitry Vyukov Date: Thu, 25 Nov 2021 08:15:52 +0100 Message-ID: Subject: Re: [PATCH] kasan: distinguish kasan report from generic BUG() To: Marco Elver Cc: Jiri Kosina , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Andrew Morton , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jslaby@suse.cz Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 24 Nov 2021 at 19:06, Marco Elver wrote: > > On Wed, 24 Nov 2021 at 18:41, Jiri Kosina wrote: > > > > From: Jiri Kosina > > > > The typical KASAN report always begins with > > > > BUG: KASAN: .... > > > > in kernel log. That 'BUG:' prefix creates a false impression that it's an > > actual BUG() codepath being executed, and as such things like > > 'panic_on_oops' etc. would work on it as expected; but that's obviously > > not the case. > > > > Switch the order of prefixes to make this distinction clear and avoid > > confusion. > > > > Signed-off-by: Jiri Kosina > > I'm afraid writing "KASAN: BUG: " doesn't really tell me this is a > non-BUG() vs. "BUG: KASAN". Using this ordering ambiguity to try and > resolve human confusion just adds more confusion. > > The bigger problem is a whole bunch of testing tools rely on the > existing order, which has been like this for years -- changing it now > just adds unnecessary churn. For example syzkaller, which looks for > "BUG: : report". > > Changing the order would have to teach all kinds of testing tools to > look for different strings. The same format is also used by other > dynamic analysis tools, such as KCSAN, and KFENCE, for the simple > reason that it's an established format and testing tools don't need to > be taught new tricks. Yes, lots of kernel testing systems may be looking just for "BUG:" and start missing KASAN bugs. Or they may be doing more special things when they see the current "BUG: KASAN:". > Granted, there is a subtle inconsistency wrt. panic_on_oops, in that > the debugging tools do use panic_on_warn instead, since their > reporting behaviour is more like a WARN. But I'd also not want to > prefix them with "WARNING" either, since all reports are serious bugs > and shouldn't be ignored. KASAN has more fine-grained control on when > to panic, see Documentation/dev-tools/kasan.rst. > > If the problem is potentially confusing people, I think the better > solution is to simply document all kernel error reports and their > panic-behaviour (and flags affecting panic-behaviour) in a central > place in Documentation/. > > Thanks, > -- Marco