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 1042EECAAD3 for ; Mon, 5 Sep 2022 18:45:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 621E6801FB; Mon, 5 Sep 2022 14:45:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5AA1D801E6; Mon, 5 Sep 2022 14:45:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FC8E801FB; Mon, 5 Sep 2022 14:45:02 -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 2BB1C801E6 for ; Mon, 5 Sep 2022 14:45:02 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id F0BE81C6BE8 for ; Mon, 5 Sep 2022 18:45:01 +0000 (UTC) X-FDA: 79878908802.28.371F96E Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by imf06.hostedemail.com (Postfix) with ESMTP id 9B403180061 for ; Mon, 5 Sep 2022 18:45:01 +0000 (UTC) Received: by mail-pf1-f177.google.com with SMTP id 14so489036pfu.9 for ; Mon, 05 Sep 2022 11:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date; bh=bp7uubPhvNdLHMSt0aPBCCek7261kdyNq09tUdxS+hw=; b=piwDQu/IQn+iTyDmrFAKLLGug2/KVIY0wExpws2cTzWbVzQSAeP21bPvOiuaRqDs2W JQoerfe3i4QQz7Cj1GsYnZVIR1xKCKWMECDAl3eXr+TOFn09Ud17TXz2OPRBNMzXaQ00 bRAB2djvvnCoTXv68Ow/gDY8gNR87B3UphTOmg/nkljGpBLK2Kru1ca9zKlDPQvntNjO mMIzgSHR8yf5hPReChlBzaYVsZgAt1UFpnPZ3NTnb1GPzkwb3HG7zv/BZtSipedU5QQ3 aVcP2YbTWfY0XZEJvLhnxRCKUAZXjcy0d3SAOSR8rLFHgESMgNsb387q+JmPGxUvicyP hisw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=bp7uubPhvNdLHMSt0aPBCCek7261kdyNq09tUdxS+hw=; b=LR/2VrtoL9B+8aL9EVexUAJz7NwchkbuRyRx8pvDY51uWmGPni9eAL61v2THE4bza2 9HAk8DTvrx0QUXEOfeOZMjet/mbcOLMnCt/KPW9ExVf1EEkmO4lSTS8RkIFW/ueZFVqm +5wTOKt16t62n/Xa02I3XF8T2WReUMN/Gd4rSPY993nJGdJWFjFBDH4X99b96AJCXcaU HPJXJ/fxs0H881BefjZoLJ6WbKCtyFcBu6zXpSIa1LPKrYtZj1cNjohSsmgxm4o08ctr nxptSK9UEGA5dAzpiAgdNS3nrdqX7h5C/szVjUCE0NURB6PAuXLVW41Ijgr217PdQTNi RezQ== X-Gm-Message-State: ACgBeo27PEQYQn16HgQrtCYlJ1jN4xiyVWZEyrRAT3EBi3WhSSLqQrVk XGGBD9/0Ot41PiqkWXqlT5Q= X-Google-Smtp-Source: AA6agR5Z0n78WBJ+tl3rvbtMAHs4LRm2iBpVTL/7lQ4Vdk+FtE7G2db+zR5YWnYqEMH87O6DNCB35w== X-Received: by 2002:a65:6cc8:0:b0:3fe:2b89:cc00 with SMTP id g8-20020a656cc8000000b003fe2b89cc00mr43555470pgw.599.1662403500241; Mon, 05 Sep 2022 11:45:00 -0700 (PDT) Received: from smtpclient.apple (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id u15-20020a170903124f00b00176ba091cd3sm1910534plh.196.2022.09.05.11.44.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Sep 2022 11:44:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [RFC PATCH 00/30] Code tagging framework and applications From: Nadav Amit In-Reply-To: <20220831101948.f3etturccmp5ovkl@suse.de> Date: Mon, 5 Sep 2022 11:44:55 -0700 Cc: Kent Overstreet , Peter Zijlstra , Suren Baghdasaryan , Andrew Morton , Michal Hocko , Vlastimil Babka , Johannes Weiner , roman.gushchin@linux.dev, dave@stgolabs.net, Matthew Wilcox , liam.howlett@oracle.com, void@manifault.com, juri.lelli@redhat.com, ldufour@linux.ibm.com, Peter Xu , David Hildenbrand , Jens Axboe , mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, changbin.du@intel.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, Steven Rostedt , bsegall@google.com, bristot@redhat.com, vschneid@redhat.com, cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, 42.hyeyoo@gmail.com, glider@google.com, Marco Elver , dvyukov@google.com, Shakeel Butt , Muchun Song , Arnd Bergmann , jbaron@akamai.com, David Rientjes , minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, Linux MM , iommu@lists.linux.dev, kasan-dev@googlegroups.com, io-uring@vger.kernel.org, linux-arch , xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org, linux-modules@vger.kernel.org, LKML Content-Transfer-Encoding: quoted-printable Message-Id: <8EB7F2CE-2C8E-47EA-817F-6DE2D95F0A8B@gmail.com> References: <20220830214919.53220-1-surenb@google.com> <20220831084230.3ti3vitrzhzsu3fs@moria.home.lan> <20220831101948.f3etturccmp5ovkl@suse.de> To: Mel Gorman X-Mailer: Apple Mail (2.3696.120.41.1.1) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662403501; a=rsa-sha256; cv=none; b=ERQ+4/liR0ea5t8/5RmDslcYwXk3JRt4EQU/j3Ynp0ocEXxwO0qRpmGva5N5G0FP+UK8XS ePZUUbAiquHFtzZzhhEkE26ydB4gwncX7mcwww5iZn3PAx8b/DPlqtuHWNholpYfSY7L2F UvixLkcxyv0YbwGWuKWTVM44GllbwIs= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="piwDQu/I"; spf=pass (imf06.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.210.177 as permitted sender) smtp.mailfrom=nadav.amit@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=1662403501; 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=bp7uubPhvNdLHMSt0aPBCCek7261kdyNq09tUdxS+hw=; b=l8Cpl1XKWGhtjnODCwTy+4saDHGouvMOQxCINVauC//HDx0Js2OJnp1EIjIYWk4ybceCiF wUyd5wGMEuRbtpowMazK/LF8N7+L4xKjxd3UlEU4jPimh2Gaz0txx9O98UJ/3bGxtBx2wI dauQ5ztlvY/gbtajOAgh+nug0xZEtJY= Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="piwDQu/I"; spf=pass (imf06.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.210.177 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam12 X-Stat-Signature: ezc6e4mw7ew96kb8s4cb4gmew6jdmmhh X-Rspamd-Queue-Id: 9B403180061 X-Rspam-User: X-HE-Tag: 1662403501-297806 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 Aug 31, 2022, at 3:19 AM, Mel Gorman wrote: > On Wed, Aug 31, 2022 at 04:42:30AM -0400, Kent Overstreet wrote: >> On Wed, Aug 31, 2022 at 09:38:27AM +0200, Peter Zijlstra wrote: >>> On Tue, Aug 30, 2022 at 02:48:49PM -0700, Suren Baghdasaryan wrote: >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> Code tagging framework >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> Code tag is a structure identifying a specific location in the = source code >>>> which is generated at compile time and can be embedded in an = application- >>>> specific structure. Several applications of code tagging are = included in >>>> this RFC, such as memory allocation tracking, dynamic fault = injection, >>>> latency tracking and improved error code reporting. >>>> Basically, it takes the old trick of "define a special elf section = for >>>> objects of a given type so that we can iterate over them at = runtime" and >>>> creates a proper library for it. >>>=20 >>> I might be super dense this morning, but what!? I've skimmed through = the >>> set and I don't think I get it. >>>=20 >>> What does this provide that ftrace/kprobes don't already allow? >>=20 >> You're kidding, right? >=20 > It's a valid question. =46rom the description, it main addition that = would > be hard to do with ftrace or probes is catching where an error code is > returned. A secondary addition would be catching all historical state = and > not just state since the tracing started. >=20 > It's also unclear *who* would enable this. It looks like it would = mostly > have value during the development stage of an embedded platform to = track > kernel memory usage on a per-application basis in an environment where = it > may be difficult to setup tracing and tracking. Would it ever be = enabled > in production? Would a distribution ever enable this? If it's enabled, = any > overhead cannot be disabled/enabled at run or boot time so anyone = enabling > this would carry the cost without never necessarily consuming the = data. >=20 > It might be an ease-of-use thing. Gathering the information from = traces > is tricky and would need combining multiple different elements and = that > is development effort but not impossible. >=20 > Whatever asking for an explanation as to why equivalent functionality > cannot not be created from ftrace/kprobe/eBPF/whatever is reasonable. I would note that I have a solution in the making (which pretty much = works) for this matter, and does not require any kernel changes. It produces a call stack that leads to the code that lead to syscall failure. The way it works is by using seccomp to trap syscall failures, and then setting ftrace function filters and kprobes on conditional branches, indirect branch targets and function returns. Using symbolic execution, backtracking is performed and the condition = that lead to the failure is then pin-pointed. I hope to share the code soon.