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]
Date: Tue, 30 Jan 2024 03:25:25 +0500
From: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
To: Marco Elver <elver@...gle.com>
Cc: glider@...gle.com, dvyukov@...gle.com, eugenis@...gle.com, 
	Oscar Salvador <osalvador@...e.de>, Vlastimil Babka <vbabka@...e.cz>, 
	Andrew Morton <akpm@...ux-foundation.org>, 
	Linux List Kernel Mailing <linux-kernel@...r.kernel.org>, 
	Linux Memory Management List <linux-mm@...ck.org>, Andrey Konovalov <andreyknvl@...il.com>
Subject: Re: regression/bisected commit 773688a6cb24b0b3c2ba40354d883348a2befa38
 make my system completely unusable under high load

On Fri, Jan 19, 2024 at 10:54 PM Mikhail Gavrilov
<mikhail.v.gavrilov@...il.com> wrote:
>
I continued to search regressions in 6.8 kernel.
And found another one.

cc478e0b6bdffd20561e1a07941a65f6c8962cab is the first bad commit
commit cc478e0b6bdffd20561e1a07941a65f6c8962cab
Author: Andrey Konovalov <andreyknvl@...il.com>
Date:   Tue Jan 9 23:12:34 2024 +0100

    kasan: avoid resetting aux_lock

    With commit 63b85ac56a64 ("kasan: stop leaking stack trace handles"),
    KASAN zeroes out alloc meta when an object is freed.  The zeroed out data
    purposefully includes alloc and auxiliary stack traces but also
    accidentally includes aux_lock.

    As aux_lock is only initialized for each object slot during slab creation,
    when the freed slot is reallocated, saving auxiliary stack traces for the
    new object leads to lockdep reports when taking the zeroed out aux_lock.

    Arguably, we could reinitialize aux_lock when the object is reallocated,
    but a simpler solution is to avoid zeroing out aux_lock when an object
    gets freed.

    Link: https://lkml.kernel.org/r/20240109221234.90929-1-andrey.konovalov@linux.dev
    Fixes: 63b85ac56a64 ("kasan: stop leaking stack trace handles")
    Signed-off-by: Andrey Konovalov <andreyknvl@...il.com>
    Reported-by: Paul E. McKenney <paulmck@...nel.org>
    Closes: https://lore.kernel.org/linux-next/5cc0f83c-e1d6-45c5-be89-9b86746fe731@paulmck-laptop/
    Reviewed-by: Marco Elver <elver@...gle.com>
    Tested-by: Paul E. McKenney <paulmck@...nel.org>
    Cc: Alexander Potapenko <glider@...gle.com>
    Cc: Andrey Ryabinin <ryabinin.a.a@...il.com>
    Cc: Dmitry Vyukov <dvyukov@...gle.com>
    Cc: Liam R. Howlett <Liam.Howlett@...cle.com>
    Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>

 mm/kasan/generic.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)


Here I spotted a dropped FPS in the game "Shadow of the Tomb Raider".
For measuring performance I used an internal benchmark.
Before commit cc478e0b6bdffd20561e1a07941a65f6c8962cab was 111FPS on
commit aaa2c9a97c22af5bf011f6dd8e0538219b45af88 [1].
On commit cc478e0b6bdffd20561e1a07941a65f6c8962cab I has only 63FPS [2]
And unfortunately the stackdepot patchset which I applied on top of
6.8-rc2 didn't restore initial performance [3].

[1] https://i.postimg.cc/tgvwPTkz/c11-aaa2c9a97c22af5bf011f6dd8e0538219b45af88.png
[2] https://i.postimg.cc/pX8vHDCM/c10-cc478e0b6bdffd20561e1a07941a65f6c8962cab.png
[3] https://i.postimg.cc/hvWCb7dV/6-8-0-0-rc2-with-stackdepot.png

-- 
Best Regards,
Mike Gavrilov.

Download attachment "bisect-performance-regression-in-games2.zip" of type "application/zip" (1235 bytes)

Download attachment ".config.zip" of type "application/zip" (65242 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ