linux-kernel - Re: [PATCH v3 00/35] Memory allocation profiling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4bb7b1e4-d107-4708-bb65-ac44d4af9959@suse.cz>
Date: Wed, 14 Feb 2024 11:20:26 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Kent Overstreet <kent.overstreet@...ux.dev>,
 Suren Baghdasaryan <surenb@...gle.com>
Cc: David Hildenbrand <david@...hat.com>, Michal Hocko <mhocko@...e.com>,
 akpm@...ux-foundation.org, hannes@...xchg.org, roman.gushchin@...ux.dev,
 mgorman@...e.de, dave@...olabs.net, willy@...radead.org,
 liam.howlett@...cle.com, corbet@....net, void@...ifault.com,
 peterz@...radead.org, juri.lelli@...hat.com, catalin.marinas@....com,
 will@...nel.org, arnd@...db.de, tglx@...utronix.de, mingo@...hat.com,
 dave.hansen@...ux.intel.com, x86@...nel.org, peterx@...hat.com,
 axboe@...nel.dk, mcgrof@...nel.org, masahiroy@...nel.org, nathan@...nel.org,
 dennis@...nel.org, tj@...nel.org, muchun.song@...ux.dev, rppt@...nel.org,
 paulmck@...nel.org, pasha.tatashin@...een.com, yosryahmed@...gle.com,
 yuzhao@...gle.com, dhowells@...hat.com, hughd@...gle.com,
 andreyknvl@...il.com, keescook@...omium.org, ndesaulniers@...gle.com,
 vvvvvv@...gle.com, gregkh@...uxfoundation.org, ebiggers@...gle.com,
 ytcoode@...il.com, vincent.guittot@...aro.org, dietmar.eggemann@....com,
 rostedt@...dmis.org, bsegall@...gle.com, bristot@...hat.com,
 vschneid@...hat.com, cl@...ux.com, penberg@...nel.org,
 iamjoonsoo.kim@....com, 42.hyeyoo@...il.com, glider@...gle.com,
 elver@...gle.com, dvyukov@...gle.com, shakeelb@...gle.com,
 songmuchun@...edance.com, jbaron@...mai.com, rientjes@...gle.com,
 minchan@...gle.com, kaleshsingh@...gle.com, kernel-team@...roid.com,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 iommu@...ts.linux.dev, linux-arch@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
 linux-modules@...r.kernel.org, kasan-dev@...glegroups.com,
 cgroups@...r.kernel.org
Subject: Re: [PATCH v3 00/35] Memory allocation profiling

On 2/14/24 00:08, Kent Overstreet wrote:
> On Tue, Feb 13, 2024 at 02:59:11PM -0800, Suren Baghdasaryan wrote:
>> On Tue, Feb 13, 2024 at 2:50 PM Kent Overstreet
>> <kent.overstreet@...ux.dev> wrote:
>> >
>> > On Tue, Feb 13, 2024 at 11:48:41PM +0100, David Hildenbrand wrote:
>> > > On 13.02.24 23:30, Suren Baghdasaryan wrote:
>> > > > On Tue, Feb 13, 2024 at 2:17 PM David Hildenbrand <david@...hat.com> wrote:
>> > > If you think you can easily achieve what Michal requested without all that,
>> > > good.
>> >
>> > He requested something?
>> 
>> Yes, a cleaner instrumentation. Unfortunately the cleanest one is not
>> possible until the compiler feature is developed and deployed. And it
>> still would require changes to the headers, so don't think it's worth
>> delaying the feature for years.
> 
> Hang on, let's look at the actual code.
> 
> This is what instrumenting an allocation function looks like:
> 
> #define krealloc_array(...)                     alloc_hooks(krealloc_array_noprof(__VA_ARGS__))
> 
> IOW, we have to:
>  - rename krealloc_array to krealloc_array_noprof
>  - replace krealloc_array with a one wrapper macro call
> 
> Is this really all we're getting worked up over?
> 
> The renaming we need regardless, because the thing that makes this
> approach efficient enough to run in production is that we account at
> _one_ point in the callstack, we don't save entire backtraces.
> 
> And thus we need to explicitly annotate which one that is; which means
> we need _noprof() versions of functions for when the accounting is done
> by an outer wraper (e.g. mempool).
> 
> And, as I keep saying: that alloc_hooks() macro will also get us _per
> callsite fault injection points_, and we really need that because - if
> you guys have been paying attention to other threads - whenever moving
> more stuff to PF_MEMALLOC_* flags comes up (including adding
> PF_MEMALLOC_NORECLAIM), the issue of small allocations not failing and
> not being testable keeps coming up.

How exactly do you envision the fault injection to help here? The proposals
are about scoping via a process flag, and the process may then call just
about anything under that scope. So if our tool is per callsite fault
injection points, how do we know which callsites to enable to focus the
fault injection on the particular scope?