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] [day] [month] [year] [list]
Message-ID: <bc10f1fb-22e5-462b-b27c-f1e463d95a21@suse.cz>
Date: Fri, 12 Jul 2024 09:19:11 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Mateusz Guzik <mjguzik@...il.com>, Akinobu Mita <akinobu.mita@...il.com>,
 Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 John Fastabend <john.fastabend@...il.com>,
 Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau
 <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>,
 Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>,
 KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>,
 Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
 Christoph Lameter <cl@...ux.com>, David Rientjes <rientjes@...gle.com>,
 Roman Gushchin <roman.gushchin@...ux.dev>,
 Hyeonggon Yoo <42.hyeyoo@...il.com>, linux-kernel@...r.kernel.org,
 bpf@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 0/2] revert unconditional slab and page allocator fault
 injection calls

On 7/11/24 9:36 PM, Andrew Morton wrote:
> On Thu, 11 Jul 2024 18:35:29 +0200 Vlastimil Babka <vbabka@...e.cz> wrote:
> 
>> These two patches largely revert commits that added function call
>> overhead into slab and page allocation hotpaths and that cannot be
>> currently disabled even though related CONFIG_ options do exist.
> 
> Five years ago.  I assume the overall overhead is small?

Well, what made me look into this in the first place was seeing
should_failslab() in perf profiles at 1-2% even though it was an empty
function that just immediately returned.
In [1] I posted some measurements that was not even a microbenchmark:

    To demonstrate the reduced overhead of calling an empty
    should_failslab() function, a kernel build with
    CONFIG_FUNCTION_ERROR_INJECTION enabled but CONFIG_FAILSLAB disabled,
    and CPU mitigations enabled, was used in a qemu-kvm (virtme-ng) on AMD
    Ryzen 7 2700 machine, and execution of a program trying to open() a
    non-existent file was measured 3 times:

        for (int i = 0; i < 10000000; i++) {
            open("non_existent", O_RDONLY);
        }

    After this patch, the measured real time was 4.3% smaller. Using perf
    profiling it was verified that should_failslab was gone from the
    profile.

Later I found that this CPU mitigations were really important here as
function calls are more expensive. With them disabled that benchmark was in
a noise, so I wasn't sure about claiming that number in the patch itself.
But I assume a microbenchmark would still demonstrate some overhead. Yet
ultimately I think the overhead is just plain unnecessary to pay when error
injection is not being performed, and also CPU mitigations enabled are
usually the default, so it's best get rid of it.

[1]
https://lore.kernel.org/all/20240620-fault-injection-statickeys-v2-0-e23947d3d84b@suse.cz/#t

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ