From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C8D6C3858025; Thu, 26 Jan 2023 19:22:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C8D6C3858025 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1674760964; bh=jCNJeFUvZJ6Eka3JaEYjpZ2CHbf/ZaC4h9+hZcPx8Mc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Pv92viZa/PEOmhOQsGO+0hDfA0AUT4m9vWDvsyFPBUSrklgJ/khWbkoZ1cJUb4Slg rSuy3yOS84YowjNLxSvgsU0Y+ukEa1WemGKxUqUsMV2Yr7jY4CwsbgRZSvZCUcKGOA aP+VIIm7zzfMo52VJsmH6WxQFPJyw8xDvVio1m/I= From: "torvalds@linux-foundation.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/108552] Linux i386 kernel 5.14 memory corruption for pre_compound_page() when gcov is enabled Date: Thu, 26 Jan 2023 19:22:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 11.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: torvalds@linux-foundation.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108552 --- Comment #12 from Linus Torvalds --- So it might be worth pointing explicitly to Vlastimil's email at https://lore.kernel.org/all/2b857e20-5e3a-13ec-a0b0-1f69d2d047a5@suse.cz/ which has annotated objdump output and seems to point to the actual bug (or= at least part of it), which seems to show how the page counting (in register %= ebx) is corrupted by the coverage counts (Vlastimil calls the coverage counts "c= rap" - it's real data, but from an algorithmic standpoint it obviously has no bearing on the output). That would mesh with "on 32-bit x86, the 64-bit coverage counts require a l= ot more effort, and we have few registers, and something gets confused and uses register %rax for two things". The bug apparently only happens with -O2, and I think has only been reported with gcc-11, which is what the intel test robots happened to use=