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 2BBF9C433EF for ; Mon, 18 Jul 2022 22:41:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 668796B0071; Mon, 18 Jul 2022 18:41:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6191D8E0001; Mon, 18 Jul 2022 18:41:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E0F36B0074; Mon, 18 Jul 2022 18:41:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 414B96B0071 for ; Mon, 18 Jul 2022 18:41:20 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 119B01320 for ; Mon, 18 Jul 2022 22:41:20 +0000 (UTC) X-FDA: 79701693120.06.AE87FC3 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf18.hostedemail.com (Postfix) with ESMTP id 8A2F91C0088 for ; Mon, 18 Jul 2022 22:41:19 +0000 (UTC) Received: by mail-qt1-f176.google.com with SMTP id b21so6768432qte.12 for ; Mon, 18 Jul 2022 15:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hV04gJeXIMaTZ1Jk1N+nIbNrqJFTcRn2y0JfEOihkw8=; b=IROMFuz2/wOa2pL4mKbRGtySWdHOHRt4GrNKKn7Bza52koex4HrozURD5wdH+F41eV sR1WHq/Pul3QucGfIc5ruREk7iz0G5aYq9Ud/i5KDg0WpZLVvKV76ej/SmlXqsmG14cW WU9VyBC5wMDUiqu/U7QOigzKsG0LDYMQHYsjJosW96Br9K81jsoXhubNWcclf5LGzLNi /usskXzsOp03JBmav0nT+tn9iYe3tgZ0LsDeWyBjb+RWuxtGFfrwD0uVmtzenKsRws3N USWWtZNslYoqp2iYySx8oLR3I+tzS9lZL1a0m5nNXKwUM/P7Hz6tcJ9nz/gS9LXfKXgj kVug== 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=hV04gJeXIMaTZ1Jk1N+nIbNrqJFTcRn2y0JfEOihkw8=; b=48hVTlZ6jcyCt2cpFo2cLN79zoyuhA5sc2QpDc20k1b/Ahbxc/fUS00O+5MNju4gm4 LXPGrNiGWWPmqTy8Ti5amjgh95ruERzbeOyCmDHPRrrGnSWutziudFU3xvSNtyjkNAcV /8HOX5wXGRAyL6l5eHJCmSTpeiF/+BQpa8VeFc1dRHjeBs18W4z5XnpUNVil+JZAtWKr 3/vFwSyW+rX3BTch5EkeKwcLfds17A2i7f0EHIrAXL8dmKC1Cf40uM/k1Vx/loADbWn9 XaZfs6otk6x96tbi69LyKA/3BQjYtxQD/wJvInyroz07gGt18wKJXdnecwEsP0uk7/TI PfAA== X-Gm-Message-State: AJIora8dOoklpWnt7hU8SjZkR7hbhNlt7TzH7NPjv2ADPGv9hoZP55xH EiksOF/5ZabueA5RMY5FAf8A03tRhG3GhiYzQNs= X-Google-Smtp-Source: AGRyM1vWIRiBCEPaEu8ccu39ek+Op1bAr/9W70rRJyLmqPHafkxRKLHee0UwfKZbMu3aGVJ9euW8FrT3myOm2u/eQgw= X-Received: by 2002:ac8:7fc1:0:b0:31e:c575:a56c with SMTP id b1-20020ac87fc1000000b0031ec575a56cmr22857594qtk.11.1658184078807; Mon, 18 Jul 2022 15:41:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrey Konovalov Date: Tue, 19 Jul 2022 00:41:08 +0200 Message-ID: Subject: Re: [PATCH 00/32] kasan: switch tag-based modes to stack ring from per-object metadata To: Marco Elver Cc: andrey.konovalov@linux.dev, Alexander Potapenko , Dmitry Vyukov , Andrey Ryabinin , kasan-dev , Peter Collingbourne , Evgenii Stepanov , Florian Mayer , Andrew Morton , Linux Memory Management List , LKML , Andrey Konovalov Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658184079; a=rsa-sha256; cv=none; b=dJ1ZaLiIs6BUuAPqCiwoksd0GoHpv1q7/26Ay9+iVzZZAIdBGH3dmJVKnXSU52GIC1TNLL FAoiYPVfEUMRoSjwNpgu+1bdWsqSrQdTm86yaRpgPatH0/O1UUzOruKal8tsR9GK4XORGz zx7fb9x7g411WyCxePX5drEsPBf7gqo= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=IROMFuz2; spf=pass (imf18.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658184079; 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=hV04gJeXIMaTZ1Jk1N+nIbNrqJFTcRn2y0JfEOihkw8=; b=XScIl1daKXMpzga/m22elpqSZ8p9PNM/S2y7WbHbvRivOlSlI1aZriCSwj7HOIF375z/mP cTQR7jX9gxsLTXVXx4wvr1XWj4rNZMJ7FCk19Lmv2D8vDtzlpkY2mNVLvDLUQyM3nH/idW fWDmiLniGXXQzB+tnhVy1WG7CzYVI+M= X-Stat-Signature: m4x7m3q3w91hsu7u5t46yiyw1ttrb5sa X-Rspamd-Queue-Id: 8A2F91C0088 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=IROMFuz2; spf=pass (imf18.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1658184079-342486 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 Fri, Jun 17, 2022 at 11:32 AM Marco Elver wrote: > > > 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. > > Do you have statistics on how how likely this is? Maybe through > identifying what the average lifetime of an entry in the stack ring is? > > How bad is this for very long lived objects (e.g. pagecache)? I ran a test on Pixel 6: the stack ring of size (32 << 10) gets fully rewritten every ~2.7 seconds during boot. Any buggy object that is allocated/freed and then accessed with a bigger time span will not have stack traces. This can be dealt with by increasing the stack ring size, but this comes down to how much memory one is willing to allocate for the stack ring. If we decide to use sampling (saving stack traces only for every Nth object), that will affect this too. But any object that is allocated once during boot will be purged out of the stack ring sooner or later. One could argue that such objects are usually allocated at a single know place, so have a stack trace won't considerably improve the report. I would say that we need to deploy some solution, study the reports, and adjust the implementation based on that. > > Discussion > > ========== > > > > The current 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. > > > > It is unclear to me whether the performance impact from this contention > > is significant compared to the slowdown introduced by collecting stack > > traces. > > I agree, but once stack trace collection becomes faster (per your future > plans below), this might need to be revisited. Ack. Thanks!