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 86434C47073 for ; Thu, 4 Jan 2024 10:42:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D8E916B02D9; Thu, 4 Jan 2024 05:42:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D19726B02DE; Thu, 4 Jan 2024 05:42:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B92A96B02DF; Thu, 4 Jan 2024 05:42:52 -0500 (EST) 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 A4A8D6B02D9 for ; Thu, 4 Jan 2024 05:42:52 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 57C27A1E55 for ; Thu, 4 Jan 2024 10:42:52 +0000 (UTC) X-FDA: 81641290584.11.E3CFAAB Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf05.hostedemail.com (Postfix) with ESMTP id B08FA100016 for ; Thu, 4 Jan 2024 10:42:50 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=34A3G1Zq; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of elver@google.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704364970; 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=LolWQ4Jrb+Z7IGxXTLsLvRDIA9OucvvsNX3g5Br+h1s=; b=Xq36ZSC5QL04UGElUV5rXnA+o6TA+Bx+6MciXAJmCf36c+/QDtJ7xpKoG2YPMe2quMd6TZ tNIndo7NunLUF4ZAln8y53hBdedloFyhiFbr0vgHlAlMcKPXHVIajTe0dGsTuG+1Tkh74r MT2+xhIxP8qgfGMES0YXPO0YCqS0se8= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=34A3G1Zq; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of elver@google.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704364970; a=rsa-sha256; cv=none; b=glSn7HdKtUQl8zqmXWHNj0ikOb25JRiwkKdRpfZMmQ6cESNmsBZMmYHK4JdSgiPRWCdfmH IrHFG90immiSDQ6rFiXCFOTV7uuSUEUcLFqULj0Z8dG4MT+qzPyjRT6eU62tfTdS8PKSbn TlPxL9ICEgt02zcPjiPAz/RWOr9Phkk= Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-4b3288df490so87740e0c.3 for ; Thu, 04 Jan 2024 02:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1704364970; x=1704969770; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LolWQ4Jrb+Z7IGxXTLsLvRDIA9OucvvsNX3g5Br+h1s=; b=34A3G1ZqduOwmtPqemISjwGyp1UaMndsAOrbHVFEYzxD8JY5eVzLWA/oquNsYYDIy+ 46N+LVObo4dy7NGwB16CML61RcCuOQnrvZstP/AfPiLXOLClUhp/yaPO5a8nocZXBYgl T22Cj3npfoi1CoZcdYfUqj2bI0nsDPtFNaOeobR5k4QxIZg1zetsz6H6rFDPnappbXqH Tvwu5uZSSVYDYG/8FvllKFFKTcWMzGsECfILXnqAs71e0wyYZIsfgG3w57Ta/Uzrn1Nb hswHyv4Ww3kjBCx3t2r3LhqXxFcUlfif4b4VF7d8Pbc1kNUKlJQg7917oMbezfGAtPSR LFCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704364970; x=1704969770; h=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=LolWQ4Jrb+Z7IGxXTLsLvRDIA9OucvvsNX3g5Br+h1s=; b=GPqBJqzVtWRpVp6TLY8ISrYQVMciELKfPRZu9kuL4WzTlJlcdiL6HEDRQnG5f+iJsK QHERkf2/hGTJS3NyFwZjlB98D2cmL9aX3fYLnfvNxxwAOxwImHZI2AL7txd8MeosjyUD Ahm/gyhuBRvKTzqjRFOgaLjXEu3x9UHez6T1b1e23QE24LLPxK14MLFdV/TicMTIymRW fIiUwLIaTiieg0z6iDzxof3jjYEHFoFypBkoNOhSsOy8z6ccWrXZHuf9/kEGRYXOCQTg WRVORsBl9YwKAHVMorbmXeZqff1wrq9qgRNW6rlIoKXEo0QAU/B4U6RPv4gLz4U2uMA9 VIbQ== X-Gm-Message-State: AOJu0YyTceWvzha9H7aUMkOGOj2OqleldhGwxKwIa+B6ZFNVhk/CnjOq Fv9BWUVaWZs+MUJgylGj9sLtb0HA3azbPpZ4EpdCPcy3XKtt X-Google-Smtp-Source: AGHT+IHRbgq83scPnGoNOMQVhsBQFaBLOBRHtuOw/QohbmSJuWeKgX3B38tkPgZeXgthkyBiNqZdN0GvPubaSh3kUww= X-Received: by 2002:a05:6122:3181:b0:4b6:e60e:e080 with SMTP id ch1-20020a056122318100b004b6e60ee080mr162069vkb.30.1704364969684; Thu, 04 Jan 2024 02:42:49 -0800 (PST) MIME-Version: 1.0 References: <1d1ad5692ee43d4fc2b3fd9d221331d30b36123f.1700502145.git.andreyknvl@google.com> In-Reply-To: From: Marco Elver Date: Thu, 4 Jan 2024 11:42:11 +0100 Message-ID: Subject: Re: [PATCH v4 17/22] lib/stackdepot: allow users to evict stack traces To: Oscar Salvador Cc: andrey.konovalov@linux.dev, Andrew Morton , Andrey Konovalov , Alexander Potapenko , Dmitry Vyukov , Vlastimil Babka , kasan-dev@googlegroups.com, Evgenii Stepanov , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: B08FA100016 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: b75euujx9byeo4cwwtmpjhwxdty3fh5k X-HE-Tag: 1704364970-182994 X-HE-Meta: U2FsdGVkX198JJDwjrwv405MfPw20zAgjH8O8aXEBJNIBf32xCZqb/29Xo68UeNpzbsZ2mXmAI1U//KkGTgv4lE3nGa5DGVOAY7JzWXrFKmAmaQuDX9QcP6YWQRf+pMz5JbMw1At9/gdZbNoE5qvK73RRWH9EWUiTsVj8sFSJDzJxZUzarV4TOdZgFYU6tJiTQkIs6LJ4O57iCNoXZQG89Q6Rle5NqReywbpLO2wDLTXh9166vSWJlMXEY0Zkzj4RXNV+Quy4m7wzl6HeUhRQFfs6Z1bQohW/LFL1SXivD/2F4khSkqqUaaGJeTB0ySN/or+is86gKNZd44Dqd3FZeNl/Lj2TipS01S14CKNo4n5jtlIiRI1rH/F6lR64Hprf4/BBVYbxzv/jJY0LzFlewu9/Pw/mjQuSUYGph+mtf+1b4OJn+SycnHrQlIuwXpekADv3GbcRBzpiwC5VWLY1D2HPeYMh1zs2H/8TY1Ys6sWvV62dKi6AluU/touyVkGf94NL8K5nRPCB3dmtGZzyH1g37dYOd/9Fs2E6esRuDKb/QJ4GR0PsGwTvrA+mDQ2g7boujrSNACHy7a4CezGnkL3jpR3lI463GfJXBcBPtWd5E7H/gde1H5VcdvUALMvFPriycTFhrCrioEDlL9pOJz87Z/VEXlgsghptS8kXVEvSb8nmEtkNry5O35NbWev3gDGzg+X0mn9whM/ExHHwG77x9KwvlWpxtPIoGJSpt3seUSz5xwqj0Z45NHUgD0p+xI2rZ93dm01qM6zh2MBJI6qbcE0xxbksjOKKN9ARbDYClVl66wRhUJtVHuWcpNTIkLTGP+JX9zv8joGz5SPA6yoYxMX8vNNuvDoqu96NMfoKMMNziUZliC/DBxyTFmxmPz2gsGqWv4QUYEz+O+Q25btwf86eSu2DKDhnlXtRGgVolcIsUL6klfOIl4nMK7O/RkBfxFDhn4CQe/Jn/O fvWd9j7t uDjbIykq5HAB6cxrbv5n5svfFzRUaNCk/6nVulm5Ajh6k+63+4W+WWdCl9KzkiNaS2gnUYQ4Wzpxy+co72mwjWi0nEtRGgIJ3ozG21A+ioh6r1MNENck5wQq8UlXXpV1b9yv8Qfhfv/ktlyu0wZdsvrugnqs8ULbwhQtZKyulxfMhsql+YR7XE5X7LOAbaQFdcralj16y9+nnC0zG1DhvSoegeh1fZssBhyFqzyQARNV8Zib7MeTSp+/924PPJx9IWqJ/0GYiHiD2Egyr2ElbagLLNbgIEoTPp9su 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: List-Subscribe: List-Unsubscribe: On Thu, 4 Jan 2024 at 11:18, Oscar Salvador wrote: > > On Thu, Jan 04, 2024 at 10:25:40AM +0100, Marco Elver wrote: > > I think a boolean makes the interface more confusing for everyone > > else. At that point stack_depot_put merely decrements the refcount and > > becomes a wrapper around refcount_dec, right? > > Thanks Marco for the feedback. > > Fair enough. > > > I think you want to expose the stack_record struct anyway for your > > series, so why not simply avoid calling stack_depot_put and decrement > > the refcount with your own helper (there needs to be a new stackdepot > > function to return a stack_record under the pool_rwlock held as > > reader). > > Yeah, that was something I was experimenting with my last version. > See [0], I moved the "stack_record" struct into the header so page_owner > can make sense of it. I guess that's fine right? Not exposing the internals would be better, but at this point I think your usecase looks like it's doing something that is somewhat out of the bounds of the stackdepot API. I also don't see that it makes sense to add more helpers to the stackdepot API to deal with such special cases. As such, I'd reason that it's ok to expose the struct for this special usecase. > If so, I'd do as you mentioned, just decrementing it with my own helper > so no calls to stack_depot_put will be needed. > > Regarding the locking, I yet have to check the patch that implements > the read/write lock, but given that page_owner won't be evicting > anything, do I still have to fiddle with the locks? You need to grab the lock as a reader to fetch the stack_record and return it. All that should be hidden behind whatever function you'll introduce to return the stack_record (stack_depot_find()?). > > Also, you need to ensure noone else calls stack_depot_put on the stack > > traces you want to keep. If there is a risk someone else may call > > stack_depot_put on them, it obviously won't work (I think the only > > option then is to introduce a way to pin stacks). > > Well, since page_owner won't call stack_depot_put, I don't see > how someone else would be able to interfere there, so I think > I am safe there. > > [0] https://patchwork.kernel.org/project/linux-mm/patch/20231120084300.4368-3-osalvador@suse.de/ > > -- > Oscar Salvador > SUSE Labs