From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Bert Karwatzki <spasswolf@web.de>
Cc: "Liam R . Howlett" <Liam.Howlett@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 14/21] mm/mmap: Avoid zeroing vma tree in mmap_region()
Date: Wed, 2 Oct 2024 13:13:16 +0100 [thread overview]
Message-ID: <26991b8a-9fc4-4cf9-99de-048c90e7a683@lucifer.local> (raw)
In-Reply-To: <20241001023402.3374-1-spasswolf@web.de>
On Tue, Oct 01, 2024 at 04:34:00AM GMT, Bert Karwatzki wrote:
> I just noticed (via a bisect between v6.11 and v6.12-rc1) that this patch
> (commit f8d112a4e657 in linux-next tree) leads to a severe memory corruption
> error under these (rather rare) circumstances:
> 1. Start a 32bit windows game via steam (which uses proton, steam's version of wine)
> 2. When starting the game you the proton version used has to be updated
>
> The effect is the following: The updating process of proton hangs and the game does
> not start and even after an exit from steam two processes remain, one of them at
> 100% CPU:
> $ ps aux | grep rundll
> bert 222638 1.7 0.1 2054868 87492 ? Ss 23:14 0:01 C:\windows\syswow64\rundll32.exe setupapi,InstallHinfSection Wow64Install 128 \\?\Z:\mnt\data\.steam\debian-installation\steamapps\common\Proton - Experimental\files\share\wine\wine.inf
> bert 222639 99.8 0.0 2054868 2380 ? R 23:14 1:01 C:\windows\syswow64\rundll32.exe setupapi,InstallHinfSection Wow64Install 128 \\?\Z:\mnt\data\.steam\debian-installation\steamapps\common\Proton - Experimental\files\share\wine\wine.inf
>
> When trying to kill those processes with "killall rundll32.exe", these error happen:
[snip]
Starting a new thread because lei is totally breaking with all these dmesg
logs and I'm struggling to be able to reply correctly.
Sorry to make it hard to follow everyone but there we go.
I have tried to recreate the exact series of anon mappings and it is not
triggering for me, so unfortunately I'm going to have to ask you to try
something else.
This does sort of hint at it being maybe an unusual code path with a file
set (possibly...) - could you try the below patch on fresh next 1st oct?
You can grep the dmesg for 'LJS' and just provide that if it triggers,
mostly I want to see if this (unusual) code path triggers. There shouldn't
be any spamming.
Thanks!
----8<----
From 3218f9fae67b8314434445b4939f1cff964da88b Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date: Wed, 2 Oct 2024 13:04:55 +0100
Subject: [PATCH] ljs: add hacky log output
---
mm/mmap.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/mm/mmap.c b/mm/mmap.c
index dd4b35a25aeb..f927744e6384 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1464,9 +1464,17 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
*/
if (unlikely(vm_flags != vma->vm_flags && vmg.prev)) {
vmg.flags = vma->vm_flags;
+
+ pr_err("LJS: HIT CASE [%lx, %lx) orig flags=[%lu] flags=[%lu]\n",
+ vma->vm_start, vma->vm_end, vm_flags, vma->vm_flags);
+
/* If this fails, state is reset ready for a reattempt. */
merge = vma_merge_new_range(&vmg);
+ pr_err("LJS: HIT CASE POST MERGE [%lx, %lx) merge=%s\n",
+ vma->vm_start, vma->vm_end,
+ merge == NULL ? "false" : "success");
+
if (merge) {
/*
* ->mmap() can change vma->vm_file and fput
--
2.46.2
next prev parent reply other threads:[~2024-10-02 12:13 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-01 2:34 Bert Karwatzki
2024-10-01 8:02 ` Lorenzo Stoakes
2024-10-01 8:38 ` Bert Karwatzki
2024-10-01 8:49 ` Lorenzo Stoakes
2024-10-01 8:55 ` Bert Karwatzki
2024-10-01 8:59 ` Lorenzo Stoakes
2024-10-01 9:10 ` Bert Karwatzki
2024-10-01 9:20 ` Lorenzo Stoakes
2024-10-01 9:49 ` Lorenzo Stoakes
2024-10-01 9:57 ` Bert Karwatzki
2024-10-01 10:02 ` Lorenzo Stoakes
2024-10-01 10:22 ` Bert Karwatzki
2024-10-01 10:33 ` Lorenzo Stoakes
2024-10-01 10:42 ` Bert Karwatzki
2024-10-01 11:23 ` Lorenzo Stoakes
2024-10-01 11:56 ` Lorenzo Stoakes
2024-10-01 16:43 ` Bert Karwatzki
2024-10-01 18:01 ` Lorenzo Stoakes
2024-10-02 8:39 ` Lorenzo Stoakes
2024-10-02 8:48 ` Lorenzo Stoakes
2024-10-02 12:13 ` Lorenzo Stoakes [this message]
2024-10-02 13:23 ` Lorenzo Stoakes
2024-10-02 16:13 ` Bert Karwatzki
2024-10-02 17:19 ` Lorenzo Stoakes
2024-10-02 18:28 ` Lorenzo Stoakes
2024-10-02 18:54 ` Lorenzo Stoakes
2024-10-02 20:06 ` Bert Karwatzki
2024-10-02 20:22 ` Lorenzo Stoakes
2024-10-02 20:39 ` Bert Karwatzki
2024-10-02 20:44 ` Lorenzo Stoakes
2024-10-02 21:13 ` Lorenzo Stoakes
-- strict thread matches above, loose matches on Subject: below --
2024-10-13 22:35 Bert Karwatzki
2024-10-14 9:46 ` Lorenzo Stoakes
2024-10-16 10:28 ` Bert Karwatzki
2024-10-16 11:16 ` Lorenzo Stoakes
2024-10-16 14:13 ` Liam R. Howlett
2024-10-04 9:35 Bert Karwatzki
2024-10-04 9:58 ` Lorenzo Stoakes
2024-10-04 14:23 ` Lorenzo Stoakes
2024-10-04 14:26 ` Lorenzo Stoakes
2024-10-04 14:32 ` Lorenzo Stoakes
2024-10-04 14:58 ` Lorenzo Stoakes
2024-10-04 22:41 ` Lorenzo Stoakes
2024-10-05 0:56 ` Bert Karwatzki
2024-10-05 6:21 ` Lorenzo Stoakes
2024-10-05 8:57 ` Bert Karwatzki
2024-10-05 11:11 ` Lorenzo Stoakes
2024-10-04 8:51 Bert Karwatzki
2024-10-04 8:59 ` Lorenzo Stoakes
2024-10-03 17:07 Bert Karwatzki
2024-10-03 17:24 ` Lorenzo Stoakes
2024-10-03 19:32 ` Lorenzo Stoakes
2024-10-04 8:36 ` Lorenzo Stoakes
2024-10-03 13:09 Bert Karwatzki
2024-10-03 13:34 ` Lorenzo Stoakes
2024-10-03 10:51 Bert Karwatzki
2024-10-03 11:17 ` Lorenzo Stoakes
2024-10-03 10:41 Bert Karwatzki
2024-10-03 10:46 ` Lorenzo Stoakes
2024-10-03 8:59 Bert Karwatzki
2024-10-03 9:04 ` Lorenzo Stoakes
2024-10-03 9:27 ` Lorenzo Stoakes
2024-10-02 22:58 Bert Karwatzki
2024-10-03 7:43 ` Lorenzo Stoakes
2024-10-02 22:57 Bert Karwatzki
2024-10-03 8:06 ` Lorenzo Stoakes
2024-10-02 21:58 Bert Karwatzki
2024-10-02 21:48 Bert Karwatzki
2024-10-02 21:41 Bert Karwatzki
[not found] <20241002105131.4545-1-spasswolf@web.de>
2024-10-02 11:19 ` Lorenzo Stoakes
2024-08-30 4:00 [PATCH v8 00/21] Avoid MAP_FIXED gap exposure Liam R. Howlett
2024-08-30 4:00 ` [PATCH v8 14/21] mm/mmap: Avoid zeroing vma tree in mmap_region() Liam R. Howlett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26991b8a-9fc4-4cf9-99de-048c90e7a683@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=spasswolf@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox