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 7ABC7C7EE22 for ; Mon, 8 May 2023 20:48:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C51C6B0081; Mon, 8 May 2023 16:48:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 775C26B0082; Mon, 8 May 2023 16:48:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63D15900002; Mon, 8 May 2023 16:48:44 -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 529846B0081 for ; Mon, 8 May 2023 16:48:44 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 22AFB160186 for ; Mon, 8 May 2023 20:48:44 +0000 (UTC) X-FDA: 80768276568.06.66E8EDC Received: from out-48.mta1.migadu.com (out-48.mta1.migadu.com [95.215.58.48]) by imf08.hostedemail.com (Postfix) with ESMTP id E64BC160017 for ; Mon, 8 May 2023 20:48:41 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=JlOqRkPd; spf=pass (imf08.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.48 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683578922; 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=T9yUrg/v5raybQi2xKwTXiJDyugUh7KFNSbnsbVf1ko=; b=68BrCE0BQRGzNxOZ9kip2s1CN94bFnOEwlTckirF3el87e9ldg6zz2rc4rxPZ3srNYDyKp 8whlAZKMb2RSmcA6GH4U2uY+dXVNZK5LuN5BCtEQsoF6S5z+5aKux9MQa5vDjxkFiiZk+v BwsBPCCyTmO+uoh7KYz1Q5rgmPpYK/w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683578922; a=rsa-sha256; cv=none; b=xCgLf4xEtZgTadRDwD3GX7b0I4CgGjvHhyDakIhVxLyp8qod0ugTdlQ0VWQSaEim5iv5K0 CGk8e36wEF4ZXfA/tb8rCcCIpMsYZPXGjQU10Cy1E0+DI2ymbmnIHLLsO5C7OYVSOxeMIS ppjshrTRCR5kPUlqkokO5itHw5/0M+4= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=JlOqRkPd; spf=pass (imf08.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.48 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Mon, 8 May 2023 16:48:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1683578919; h=from:from: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; bh=T9yUrg/v5raybQi2xKwTXiJDyugUh7KFNSbnsbVf1ko=; b=JlOqRkPdzk5AJhxPMwu8AlexUvrKA9kXRniMs6KXFAxkkCykU6KjHBDIF+g4xO4yC/3Xao +RuScEMByhVbOYP7Nl+Ojs+6ZTV4KDzSfRqi3slN82Zdtt1OUgviKekasieY9DgexpymM2 tFWfTgTgTslrvfQsG/FcZTuRpfPmr6I= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Petr =?utf-8?B?VGVzYcWZw61r?= Cc: Michal Hocko , Suren Baghdasaryan , akpm@linux-foundation.org, vbabka@suse.cz, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, corbet@lwn.net, void@manifault.com, peterz@infradead.org, juri.lelli@redhat.com, ldufour@linux.ibm.com, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org, tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org, paulmck@kernel.org, pasha.tatashin@soleen.com, yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, andreyknvl@gmail.com, keescook@chromium.org, ndesaulniers@google.com, gregkh@linuxfoundation.org, ebiggers@google.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, 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, elver@google.com, dvyukov@google.com, shakeelb@google.com, songmuchun@bytedance.com, jbaron@akamai.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kasan-dev@googlegroups.com, cgroups@vger.kernel.org Subject: Re: [PATCH 00/40] Memory allocation profiling Message-ID: References: <20230501165450.15352-1-surenb@google.com> <20230508175206.7dc3f87c@meshulam.tesarici.cz> <20230508180913.6a018b21@meshulam.tesarici.cz> <20230508205939.0b5b485c@meshulam.tesarici.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230508205939.0b5b485c@meshulam.tesarici.cz> X-Migadu-Flow: FLOW_OUT X-Stat-Signature: r8fzd3q1awabrun6p4m6mze99oeqajz4 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E64BC160017 X-Rspam-User: X-HE-Tag: 1683578921-869655 X-HE-Meta: U2FsdGVkX1+WFVx1sabwG7hkpBWnX+wlqRqPQFdjHu4BRcorn1TDk/0hUJUv/OjDd5kh9An4WWeIeUd22RSiddy88r3earVeuir1aJwzZ+u48kSyGrRzVfd0gmvIo5wvU2Chx0x4hZCWEgF4cFYXScoTj1Ap2BEsXk800qDyh//T02i2uEvrYXFsRDNQoPJS2XeTA78T7w8OJJoM4hzqfmKT2qC5iBK79h63gLTADipV6awSV4th/G+ZP/Kg2IpR8dI8ypJ/COIhfccMtLjyrlQsdWwTt7TJdzIJ+oDof/k8r4QPB/siZx8id937HCKSKeeMElihSNh9mjMrWNSKHOYOgdawnxWNccgStmPCSgc40h6hezNN149wXgW4JESxuDvg1LkUi3kHHeJGK+K/bpQatDjF8oSkbGR4nYON3fviGQ3mlIw2c+TpJ1xt+mtrGux/Xfd81f/YM7jsRNi/kx6QsowZZJ+lcwQe0FQzxA3UBFFfzP6y5u024zSwFlwKQSPjDCJAQyKyOwJiTroxkyBFzWZlalCa1/lBZ1j5RTC62mF3Iywtel724fbVR5+3Hgm84Qx8s5Gao1Ha7FY3YQi6M+/y2IBHd2V7reW3Qu2ltqrLBeIHdP7wTDf5iwsPY7XRZiwho3YHwfHl8Vcm7rmuEREz1vf5RF5s2I08SDSgghGoNFg6ggnhGXut6fbQ8J4uyGAw8MF5lV746E3G+eDdjriEhZpmftIkj6bIKbP9PvexqMIz+TUoercPUx154rlrnArTW54UHKJKTq2D6U+mAnR0p85L5t6tRGf2uvp1AjU3mEk1xvcdtfovsrWKRhK/YACu3EvSmXBrSSc6qB7CeSv1nBJle4fCWgJ55xqfYqcrkXCXn0HLNJ/Oi02ddi57V2TFgXDITB/VPd/5m377hC5z3K0Nd/eU4wEaBKMX2criZ5doiI9802Tp1ITXlvgTIeVcTnqfLGvH2Xv Pkn8xZXt Ky4ovUT8QmBm31sPgYOxZHFde16K2WtUXo8hsj1J5kkKFrpMaN9FeKjNFCC+YUxXvUjV/Oqbifu3iMigj180U98h364XroGJoNh/uwt23K9Ac7VUkGYBGJ0q/Cw== 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, May 08, 2023 at 08:59:39PM +0200, Petr Tesařík wrote: > On Mon, 8 May 2023 12:28:52 -0400 > Kent Overstreet wrote: > > > On Mon, May 08, 2023 at 06:09:13PM +0200, Petr Tesařík wrote: > > > Sure, although AFAIK the index does not cover all possible config > > > options (so non-x86 arch code is often forgotten). However, that's the > > > less important part. > > > > > > What do you do if you need to hook something that does conflict with an > > > existing identifier? > > > > As already happens in this patchset, rename the other identifier. > > > > But this is C, we avoid these kinds of conflicts already because the > > language has no namespacing > > This statement is not accurate, but I agree there's not much. Refer to > section 6.2.3 of ISO/IEC9899:2018 (Name spaces of identifiers). > > More importantly, macros also interfere with identifier scoping, e.g. > you cannot even have a local variable with the same name as a macro. > That's why I dislike macros so much. Shadowing a global identifier like that would at best be considered poor style, so I don't see this as a major downside. > But since there's no clear policy regarding macros in the kernel, I'm > merely showing a downside; it's perfectly fine to write kernel code > like this as long as the maintainers agree that the limitation is > acceptable and outweighed by the benefits. Macros do have lots of tricky downsides, but in general we're not shy about using them for things that can't be done otherwise; see wait_event(), all of tracing... I think we could in general do a job of making the macros _themselves_ more managable, when writing things that need to be macros I'll often have just the wrapper as a macro and write the bulk as inline functions. See the generic radix tree code for example. Reflection is a major use case for macros, and the underlying mechanism here - code tagging - is something worth talking about more, since it's codifying something that's been done ad-hoc in the kernel for a long time and something we hope to refactor other existing code to use, including tracing - I've got a patch already written to convert the dynamic debug code to code tagging; it's a nice -200 loc cleanup. Regarding the alloc_hooks() macro itself specifically, I've got more plans for it. I have another patch series after this one that implements code tagging based fault injection, which is _far_ more ergonomic to use than our existing fault injection capabilities (and this matters! Fault injection is a really important tool for getting good test coverage, but tools that are a pain in the ass to use don't get used) - and with the alloc_hooks() macro already in place, we'll be able to turn _every individual memory allocation callsite_ into a distinct, individually selectable fault injection point - which is something our existing fault injection framework attempts at but doesn't really manage. If we can get this in, it'll make it really easy to write unit tests that iterate over every memory allocation site in a given module, individually telling them to fail, run a workload until they hit, and verify that the code path being tested was executed. It'll nicely complement the fuzz testing capabilities that we've been working on, particularly in filesystem land.