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 270B6EE01F0 for ; Wed, 13 Sep 2023 17:07:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B28EC6B020F; Wed, 13 Sep 2023 13:07:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD8A76B0213; Wed, 13 Sep 2023 13:07:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A0776B0246; Wed, 13 Sep 2023 13:07:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 8A7E66B020F for ; Wed, 13 Sep 2023 13:07:36 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5919D1603D9 for ; Wed, 13 Sep 2023 17:07:36 +0000 (UTC) X-FDA: 81232205712.13.9CC97E3 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by imf09.hostedemail.com (Postfix) with ESMTP id 88CD814002F for ; Wed, 13 Sep 2023 17:07:33 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=KhTnBkiC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.215.177 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694624853; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=iAHlwDQj5aLs+kNJzI19rDW68TVeu+jwDvk+z6Yfntc=; b=cMDH/jtI7bOZnEImL2tFB2Zi3Xf1ApC+JH3RVQ2JM7flPbp3vr8SgvGsaQ8MoBFJp/8ilZ Wn8jUJ4EnHRxQjpMSopUZFiL50PaR1tIE7LeorP/7ItXNGd7ll5OYr54FvYE9b3P7eTapJ ZpPDzYqKf0aTUqUmEQFBPE7dEbGAkyA= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=KhTnBkiC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.215.177 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694624853; a=rsa-sha256; cv=none; b=ji7uDvC/mBvbbDStohU2xhYwQnuyIgAYB54d0fBC3VNOp1lwAHtwJGXrgNq4BMmxJLrK03 7YjgLJr9LOMy0YOr7WA9URocrGiuG7noPipPnIvX69t3mnsS1B5iIzh5hfUvRCFKIZiRmx 5XfogRIuHKKDQaslkf5LW6A+qJ71I0I= Received: by mail-pg1-f177.google.com with SMTP id 41be03b00d2f7-570836f1c79so4997521a12.0 for ; Wed, 13 Sep 2023 10:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694624852; x=1695229652; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=iAHlwDQj5aLs+kNJzI19rDW68TVeu+jwDvk+z6Yfntc=; b=KhTnBkiC1X1+9xpOlyK4qJJaKVds3thkgqH/J8oTpg5Y23xGq9dXC5SzdqFqpA1O3q +WAfO90KxqiNOa7rSNA3Jxbzxgk0cuWGqbGRGRWvjjE0P0EFHcNKWGm/B7pmhy9CtPCo Rkc8qroWUIUZ8P4RxeBHQywVHZlIQShQiA6aV/o/AJ/XlG39Qs9m+NfW3y23Ca7focMI k2KUdBRwuw60nWuK6soXKa4+ZuKFuvvYohFoXYdrCxOs9YnC1v6jkMjWV4oQVrAvwLqw 8FS0Li079zertQWc6Nh+p6GUCh0aV3aZ5dl7CWnjlUYK4t56YjnZkEgZ0vZus94NqL2O x2nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694624852; x=1695229652; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iAHlwDQj5aLs+kNJzI19rDW68TVeu+jwDvk+z6Yfntc=; b=u0siceyOOVYkhwd9lXe1si8JqJHC3nR99eJlMxLa+p60Zuo32oTsXzo6HyvIWztr0q qyc1FK5BAIFGwrSw3pnU+U/Llyjnbuxaa5pwK5I+BTSq6xcH74TM2N3CFLOLIjbDBXll n/O9jkDoQTQE4bCl00ml1+JobroHRPGRxl/x4s0WJP6mi/4mJEYoUMG0DxxfMfUtY3/S 2eLzqjNK4MEaplyL/sBJUaaruEH2xpOTo5IZ7ZuX8z9aVNKXenCf2Twd1m1JtRqum87/ bpsLj/lwKosDA1VSEyvcr8UleZJ8ovYC3WPSdXlP2TYkWqbnn6US6YpWqmMEfBo/MMHl w80w== X-Gm-Message-State: AOJu0YxjHhYLFjjMFrsK9Z//+P1xy4ifjA26iOn6MXrXBHlnqVoyRcuH YjLHLtCgXXNGICarXp8MiTXUrmo5TTGGbZqPUtI= X-Google-Smtp-Source: AGHT+IGPAMD8g5fjPw1Tth1zv1pzrljIB/knnIK7hezCiVeflWmosEgEj9S+4EQXjFPVd786gIDuhMQt4oggmeoLt9Y= X-Received: by 2002:a17:90a:887:b0:268:37b:a10e with SMTP id v7-20020a17090a088700b00268037ba10emr2692968pjc.11.1694624852255; Wed, 13 Sep 2023 10:07:32 -0700 (PDT) MIME-Version: 1.0 References: <89c2f64120a7dd6b2255a9a281603359a50cf6f7.1693328501.git.andreyknvl@google.com> In-Reply-To: From: Andrey Konovalov Date: Wed, 13 Sep 2023 19:07:21 +0200 Message-ID: Subject: Re: [PATCH 05/15] stackdepot: use fixed-sized slots for stack records To: Alexander Potapenko Cc: andrey.konovalov@linux.dev, Marco Elver , Dmitry Vyukov , Vlastimil Babka , kasan-dev@googlegroups.com, Evgenii Stepanov , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 88CD814002F X-Stat-Signature: 6u1mm67hxtmm9a1ug5wauakkhmtux4bw X-Rspam-User: X-HE-Tag: 1694624853-16187 X-HE-Meta: U2FsdGVkX18i4TRvs/GxJtEI0GbcJ2LwfIVg4Vtswk78apf4xq102j9HlQhExpVoa7vwlgNi8DkWo6WmJaZW864ddZpv4XM+7YqgLewvzH7SzMPUGumpnJuA/wVpd0QeRdq9d09xcXEeQtQaRNey2+jcvtNOkkmfED5LtGDmdZrpK3Hpu+YhnMQ7UjKd54f2AeomYPT2NFjGuex6fUFcj/NiSyrbIfUuI4XSn71SMZ0pyYrzVV4rd4D4EevFfY8hC5AZmme6dw6HyltG+iBqUi+HWmvUJfvj1uaOejEmAs80Q81Id6J4kE3aNFdf0eUSnG+kH5b3FHfuPOCqQazH+gAyIrL3RWfineqCkoCnUn1ps3QSfyZgJ5Lb6vZvSqdiNpLNn42ClT4syqgkg59+oqdJXAWwgFuBBp/FeqV4qCxWtlC9/dMg5XYbmRLqkfNOkg3HmjEUjueFTCUgDurLbZzm4yOvmJoDzoe/sMT+nF4Gu2c53UOCCJIGn4z2c4GrSfWDygS1ezn9x7jfZ0Z60xSqwcza6+bWNPxqwMK2U2Auj40F6wcyia6KU2C1Ls7/YglH6Dd5viCAKamqz7XuNL85DkuC05n3GD1oLHvF5+rZ7+bwPwizvgirYDZ2SC1S/jS+gnziNFlA4FEvDtkaHsMkUxuzcJBI/o2S1o76+HgLGALsvH4xH+zAQTloU9R6LWRgCWlX52Nn2oNK2pJXRsxCS2mR9hZnmhudCXfZvUUm4D6E84b6aIQDn1pH8i37MKZwrj4i0RHxkmC8tk/sJXE579tZcNtHKNG4wX/wfMSawPGBronXHkFje5AuOIjYZy/QIpyRlvWpaxd2eVU5zI/w+ChRoU6MQFEeG5pIgPXdlCLZTO8SS8MXZeFyGEUkGwtW72kaL8iUljtgYbkqYxqvpx1bpfQWjqTJ1tstq6mp4zJOBuo1qm9twyKBgEhkjb58icc2spEpb8UZ5q8 1Kl6Zffe a8hPaK0u32oJi/+Qr+ON6nrPCY6Rmt/2MVdrIJj3KWj6bE6Q4UM+dq2bsgPSPMwfDM1Bf2bSWRsCs1eI8VuNWgbigTiWyaiaGPUBnHWgMr7OMaqAwsMFekTJNu2qjS6rC/NsQXLqn/Umg0KuMC6aGh/YZOlOaHg9Hc+WR7YcplYYJfwA+RYu7W0WqRB+SuOHhEsnFUUSCfqrBmbhxP5OC3zYNSLVTnpsFgHADsz+IHm1OWVkS+CO4j1fmK8DiG4KNUeBbSE7gbPIQCCLCLa0q5GkN8QabyI9XCfGW/R6EyXWKp08TvzAagVF19U+RdxKNB+j2MduqocxvZBn4XOEYjkV4BR2oqzti3RP2Y34w6eOI6VN34q13giw5eVydD236tdMvqUu4hjHBeyzd8AiREYVUej8RMGnfc1PpPMWQiAMajIOA6ziRaAn4r5SMJz/Fvt6OGrL7Bp1faVoUD0XV7rvx2gv2703GX+sz26822X/AJE9/3YLt/JYSkw== 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 Wed, Aug 30, 2023 at 10:22=E2=80=AFAM Alexander Potapenko wrote: > > On Tue, Aug 29, 2023 at 7:11=E2=80=AFPM wrot= e: > > > > From: Andrey Konovalov > > > > Instead of storing stack records in stack depot pools one right after > > another, use 32-frame-sized slots. > > I am slightly concerned about the KMSAN use case here, which defines > KMSAN_STACK_DEPTH to 64. Hm, indeed. KASAN also defines the depth to 64 actually. I think it's reasonable to change the default value to 64 to cover all the existing users. And whoever wants to save up on memory can change the Kconfig parameter (I'll add one as you suggested). > I don't have a comprehensive stack depth breakdown, but a quick poking > around syzkaller.appspot.com shows several cases where the stacks are > actually longer than 32 frames. Whichever value we choose, some of stack traces will not fit unfortunately. But yeah, 64 seems to be a more reasonable value. > Can you add a config parameter for the stack depth instead of > mandating 32 frames everywhere? Sure, will do in v2. > As a side note, kmsan_internal_chain_origin() > (https://elixir.bootlin.com/linux/latest/source/mm/kmsan/core.c#L214) > creates small 3-frame records in the stack depot to link two stacks > together, which will add unnecessary stackdepot pressure. > But this can be fixed by storing both the new stack trace and the link > to the old stack trace in the same record. Do you mean this can be fixed in KMSAN? Or do you mean some kind of an extension to the stack depot interface?