From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 32A583858C2F; Fri, 27 Jan 2023 17:01:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 32A583858C2F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1674838860; bh=cTv9Z0BV0dDKlR1jLs8wrLGMAzfKN/Krsbdwi701w64=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KItSk395aXgL7yofT8NNx9NwQDGeaVVJr7dfpr0ZZCAjCzKvDc6e27FJ6puu40+9y TUkK29hcPWUOXkdtMHglV6QCWzGlKZEQt9Z2cjQ5BYI0XEv2jShCAlplWNxUg1Tgao VJdd8I7V8qCqU736dTVnpweiBmalXUcBRp5HBlkw= From: "torvalds@linux-foundation.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/108552] Linux i386 kernel 5.14 memory corruption for pre_compound_page() when gcov is enabled Date: Fri, 27 Jan 2023 17:00:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 11.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: torvalds@linux-foundation.org X-Bugzilla-Status: NEW 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 #30 from Linus Torvalds --- (In reply to Richard Biener from comment #26) > And yes, to IV optimization the gcov counter for the loop body is just > another IV candidate that can be used, and in this case it allows to elide > the otherwise > unused original IV. Ouch. So we really don't mind the data race - the gcov data is obviously not prim= ary - but I don't think anybody expected the data race on the gcov data that is= n't "semantically visible" to then affect actual semantics. And yeah, atomic updates would be too expensive even on 64-bit architecture= s, so we pretty much *depend* on the data race being there. And on 32-bit architectures (at least i386), atomic 64-bit ones go from "expensive" to "ludicrously complicated" (ie to get a 64-bit atomic update you'd need to s= tart doing cmpxchg8b loops or something). So I think the data race is not just what we expected, it's fundamental. Ju= st the "mix it with semantics" ends up being less than optimal.=20 Having the gcov data be treated as 'volatile' would be one option, but prob= ably cause horrendous code generation issues as Jakub says. Although I have several times hit that "I want to just update a volatile in memory, I wish gcc would just be happy to combine a 'read-modify-update' to= a single instruction". So in a perfect world, that would be fixed too. I guess from a kernel perspective, we might need to really document that GC= OV has these issues, and you can't use it for any real work. We have just been lucky this hasn't hit us (admittedly because it's fairly odd that an expect= ed end gcov value would end up being used in that secondary way as a loop variable).=