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 3B57FECAAA1 for ; Sun, 11 Sep 2022 11:50:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6704A8000E; Sun, 11 Sep 2022 07:50:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 61ED280008; Sun, 11 Sep 2022 07:50:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E6808000E; Sun, 11 Sep 2022 07:50:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3EF5580008 for ; Sun, 11 Sep 2022 07:50:15 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C7D0C1202CC for ; Sun, 11 Sep 2022 11:50:14 +0000 (UTC) X-FDA: 79899636348.04.75A884D Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by imf23.hostedemail.com (Postfix) with ESMTP id 76711140094 for ; Sun, 11 Sep 2022 11:50:14 +0000 (UTC) Received: by mail-qv1-f53.google.com with SMTP id s13so4816233qvq.10 for ; Sun, 11 Sep 2022 04:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=o0NomSJrd+We+cA0E2POE4mJvtyH0veoDgu14xHBABY=; b=Pp9lyLfWT0KtFM0AeWo+3VXMLLCDOJ45kj5tKR8HN3LHR9KS/v1qQDYrN+CLFAEULv VVonzvH8r3D/posWDedCCZ1NJ+/yWwtlmZcmy2J8eMW0eO90VzaFlyZhxZjZ+yf6T/NV uopfI59iOR5oeDXyuJ8rQbjE1pq8h8zRnPcl8+AFO/GMJk3/JJCHl7AeaQsbZG94BK3p RAvl1WbB1e+ySRPsytspHPKfBv9dJfEpVAlh0Uwj6+DWyPNStXoG9L6buUdLLjQS3luR +YuXiBMwLKK+dqJlEkXQuIOP+GasUjOP6jIBb9Rryli6vEaI+KrzPceI40IU2TPIP+Ap 93Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=o0NomSJrd+We+cA0E2POE4mJvtyH0veoDgu14xHBABY=; b=bcG7xGS/gUNwQVcnjPnt2gWznYlkFwNtByDVgEEipyBYTm2TLxfoTSNaBX0WXA+M0l q90/2MeOYwJLw+5rGMQRwJEw46RHn1A9VuSIBDtnYUkl9jw9BENbVQ8ncA8yXV0jFU96 wxwQh3uHna0NOJMpchsByZVbm4twXnAT79n4bFYV4Bl3ta87h/XoN9bETpOtklpoRvFM oGhWayKHvC8CPa8upOnO9CBXqM0h8s52E0UMEJ0T2MACFX0cj7p2cpCm3r6QiBaGmcZN XblvHmN28Wsl5ggX1XuIhY0yQtKpkzY9hlB64xvjRGJOPR1MdxEOjYGaRiV2zbxa6L6O Y7FA== X-Gm-Message-State: ACgBeo34yPU3hsj4vJ6uaLHSN70DPA4HaqzNnV3eKcw840eNg9PczicD uGWm1QmQ/VFuBdrTu0sGddKiOENiCE2dNjfM3TY= X-Google-Smtp-Source: AA6agR7/UuRd30ILIGK8EmCGtvCb25BL9Ss3QDk7CaEG7fb7O+sQihMLNbeBbL+kICpDyLIToo3Lim2Bi4QJeilZOrA= X-Received: by 2002:a05:6214:c48:b0:4ac:b18d:c101 with SMTP id r8-20020a0562140c4800b004acb18dc101mr849569qvj.107.1662897013746; Sun, 11 Sep 2022 04:50:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrey Konovalov Date: Sun, 11 Sep 2022 13:50:03 +0200 Message-ID: Subject: Re: [PATCH mm v3 00/34] kasan: switch tag-based modes to stack ring from per-object metadata To: Andrew Morton Cc: Marco Elver , Alexander Potapenko , Dmitry Vyukov , Andrey Ryabinin , kasan-dev , Peter Collingbourne , Evgenii Stepanov , Florian Mayer , Linux Memory Management List , LKML , Andrey Konovalov , andrey.konovalov@linux.dev Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Pp9lyLfW; spf=pass (imf23.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.219.53 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662897014; a=rsa-sha256; cv=none; b=Wp9/FP2zHn7QEVkG5LBIpDK1CXVzHDmwGWeaVcC/BYEH8RUbtIyE0RpL3vUAaanPEOrYm+ Ey92xxnpjuxsl+DcyI9gy5/tqDd7CR5yqPYWVR6FDqkg8eHMr7lx010Ypst38ok/dV9uYD pzfLNI2l5IL32RxA6BdkDNxHRjLfhP8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662897014; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=o0NomSJrd+We+cA0E2POE4mJvtyH0veoDgu14xHBABY=; b=gk7lnDUhQJynqTWWpdJ3dCb0bpQX4BlYdtJ6OwP34Ms0Uykx7kWMLew49FgumkVPLzg025 +Fb5K/UwWsfzzXuYxqrfJpL6bxtddnfyunvr3Qg15/prkJepXCR1FEWqXSFtWy4UsaaoZY LJlIacEquGCFxiI4q94IAAtqE9G+YH8= Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Pp9lyLfW; spf=pass (imf23.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.219.53 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: xmud8uyfu11xwquuttq68efoc9cd7z33 X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 76711140094 X-HE-Tag: 1662897014-268531 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 Mon, Sep 5, 2022 at 11:05 PM wrote: > > From: Andrey Konovalov > > This series makes the tag-based KASAN modes use a ring buffer for storing > stack depot handles for alloc/free stack traces for slab objects instead > of per-object metadata. This ring buffer is referred to as the stack ring. > > On each alloc/free of a slab object, the tagged address of the object and > the current stack trace are recorded in the stack ring. > > On each bug report, if the accessed address belongs to a slab object, the > stack ring is scanned for matching entries. The newest entries are used to > print the alloc/free stack traces in the report: one entry for alloc and > one for free. > > The advantages of this approach over storing stack trace handles in > per-object metadata with the tag-based KASAN modes: > > - Allows to find relevant stack traces for use-after-free bugs without > using quarantine for freed memory. (Currently, if the object was > reallocated multiple times, the report contains the latest alloc/free > stack traces, not necessarily the ones relevant to the buggy allocation.) > - Allows to better identify and mark use-after-free bugs, effectively > making the CONFIG_KASAN_TAGS_IDENTIFY functionality always-on. > - Has fixed memory overhead. > > The disadvantage: > > - If the affected object was allocated/freed long before the bug happened > and the stack trace events were purged from the stack ring, the report > will have no stack traces. > > Discussion > ========== > > The proposed implementation of the stack ring uses a single ring buffer for > the whole kernel. This might lead to contention due to atomic accesses to > the ring buffer index on multicore systems. > > At this point, it is unknown whether the performance impact from this > contention would be significant compared to the slowdown introduced by > collecting stack traces due to the planned changes to the latter part, > see the section below. > > For now, the proposed implementation is deemed to be good enough, but this > might need to be revisited once the stack collection becomes faster. > > A considered alternative is to keep a separate ring buffer for each CPU > and then iterate over all of them when printing a bug report. This approach > requires somehow figuring out which of the stack rings has the freshest > stack traces for an object if multiple stack rings have them. > > Further plans > ============= > > This series is a part of an effort to make KASAN stack trace collection > suitable for production. This requires stack trace collection to be fast > and memory-bounded. > > The planned steps are: > > 1. Speed up stack trace collection (potentially, by using SCS; > patches on-hold until steps #2 and #3 are completed). > 2. Keep stack trace handles in the stack ring (this series). > 3. Add a memory-bounded mode to stack depot or provide an alternative > memory-bounded stack storage. > 4. Potentially, implement stack trace collection sampling to minimize > the performance impact. > > Thanks! Hi Andrew, Could you consider picking up this series into mm? Most of the patches have a Reviewed-by tag from Marco, and I've addressed the last few comments he had in v3. Thanks!