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 CC294C433F5 for ; Wed, 16 Feb 2022 23:26:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238372AbiBPX0v (ORCPT ); Wed, 16 Feb 2022 18:26:51 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:57450 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231585AbiBPX0t (ORCPT ); Wed, 16 Feb 2022 18:26:49 -0500 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BFEA22D1CF for ; Wed, 16 Feb 2022 15:26:34 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id y129so9431349ybe.7 for ; Wed, 16 Feb 2022 15:26:34 -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=yl++UbQHvu031O88qjaOvVPH96zPax6XyUywms3AfE8=; b=du1dfzkCVyYJKstpFmIAxK2VNbKxzZZ6BqvK/vaUaaHusJhtDgI8Zx2SL2BK83cgC0 yjx7jgQd+h2bjjVfymSN82w/XWqXpRoMuoaQyPKCRg5Ig5iW6S6yy/+/mNRLIvex4SnI 2mrF33ukku/kGa51F8cAwgK/AE9FUo0IjGDPucJWRd8WnTg1g+0verMaJSCRb0T953UF Da31rWgY2Pqx/0IPX3Yxlrz4zMDvsyUxHyZnBFPT5w/gYZJMmG0UcnvWxAn55S/GISKq yf/+sau0mzPk2xw1Mk2yEyxC5GtlGCTV+bj8rBFxae37maEgxLhVfh2RZYGXkYu0OzUB Ek4A== 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=yl++UbQHvu031O88qjaOvVPH96zPax6XyUywms3AfE8=; b=ZJQwrTrKjNL5Wi2QfVZljY3PyT5JeQwd63xokvAhmMV0GbMXvQe0lNIF4/vip2qenf HRW+AP89KfUO8Hw2FbVqWlL0Daru9JW0qADd8dpz6WOtcgf7B4Au0IMIHGdxo70RKDSS 0LXDU/T46+7NEY3/vyKNADltVuwpSE3aZHZvcL3dCiCXcWXD13U5QxdKd9UTtTFjR8AO 9fNd6cNGtSv7FnKIYbZFKWs+DRpRhaLs54zg00kPlT5d21nyTYX0+Fq4Rcnosoe8wmaY qxLDzZvEKdwga7YAa/uuD8qxwYg+CqEsvvUk0+40bloognGCJTjpTL5hjoVFrocwLydI x6yA== X-Gm-Message-State: AOAM533kKM4GJgDlBbivtxK8cC12HzH2vsW+VmIS0qk/BInlqK4PfscJ 4J7R4D5amFfWlvqETF5puIFSdSfEa88GWGlQDuZfAw== X-Google-Smtp-Source: ABdhPJwjoTHWombbeiuCgd+bm9lJ6I8IV5xERt6WrfekPcH+1L/91PJDXxGq1mQj3Rwwc+WX88bk3+QQzDWQ+x8mhKg= X-Received: by 2002:a25:28a:0:b0:620:e848:af9b with SMTP id 132-20020a25028a000000b00620e848af9bmr218531ybc.374.1645053993763; Wed, 16 Feb 2022 15:26:33 -0800 (PST) MIME-Version: 1.0 References: <5b120f7cadcc0e0d8d5f41fd0cff35981b3f7f3a.1645038022.git.andreyknvl@google.com> In-Reply-To: From: Marco Elver Date: Thu, 17 Feb 2022 00:26:22 +0100 Message-ID: Subject: Re: [PATCH mm] kasan: print virtual mapping info in reports To: Andrey Konovalov Cc: andrey.konovalov@linux.dev, Alexander Potapenko , Andrew Morton , Dmitry Vyukov , Andrey Ryabinin , kasan-dev , Vincenzo Frascino , Catalin Marinas , Linux Memory Management List , LKML , Andrey Konovalov Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 16 Feb 2022 at 21:42, Andrey Konovalov wrote: > > On Wed, Feb 16, 2022 at 8:31 PM Marco Elver wrote: > > > > On Wed, 16 Feb 2022 at 20:01, wrote: > > > > > > From: Andrey Konovalov > > > > > > Print virtual mapping range and its creator in reports affecting virtual > > > mappings. > > > > > > Also get physical page pointer for such mappings, so page information > > > gets printed as well. > > > > > > Signed-off-by: Andrey Konovalov > > > > > > --- > > > > > > Note: no need to merge this patch into any of the KASAN vmalloc patches > > > that are already in mm, better to keep it separate. > > > --- > > > mm/kasan/report.c | 12 +++++++++++- > > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c > > > index 137c2c0b09db..8002fb3c417d 100644 > > > --- a/mm/kasan/report.c > > > +++ b/mm/kasan/report.c > > > @@ -260,8 +260,18 @@ static void print_address_description(void *addr, u8 tag) > > > pr_err(" %pS\n", addr); > > > } > > > > > > + if (is_vmalloc_addr(addr)) { > > > + struct vm_struct *va = find_vm_area(addr); > > > + > > > + pr_err("The buggy address belongs to the virtual mapping at\n" > > > + " [%px, %px) created by:\n" > > > + " %pS\n", va->addr, va->addr + va->size, va->caller); > > > > Can you show an example of what this looks like? > > [ 20.883723] The buggy address belongs to the virtual mapping at > [ 20.883723] [ffff8000081c9000, ffff8000081cb000) created by: > [ 20.883723] vmalloc_oob+0xd8/0x4dc > > > It's not showing a stack trace, > > No, only a single frame. > > > so why not continue the line and just say "... created by: %pS\n" > > Putting it on a separate line makes the line lengths looks more balanced. > > Also, printing a frame on a separate line is consistent with the rest > of KASAN reporting code. That's reasonable, thanks. Reviewed-by: Marco Elver