On Fri, 13 Mar 2026, 02:02 Alexandre Oliva, <[email protected]> wrote:
> On Mar 11, 2026, Jonathan Wakely <[email protected]> wrote: > > > On Wed, 11 Mar 2026 at 10:56, Alexandre Oliva <[email protected]> wrote: > >> > >> On Mar 11, 2026, Jonathan Wakely <[email protected]> wrote: > >> > >> > On Wed, 11 Mar 2026, 05:29 Alexandre Oliva, <[email protected]> > wrote: > >> >> > >> >> compare_exchange_weak is allowed to fail spuriously, and we're > >> >> actually hitting such spurious failures quite often on ppc-vx7r2, > >> >> presumably when random interrupts hit between ll and sc. > >> >> > >> >> Tolerate one such failure, hopefully that will suffice. > >> > >> > This is a bit of a problem, because we can't tell if the padding was > >> > cleared or not. If it was not clear, the first compare_exchange_weak > would > >> > clear it, and the refund would succeed. But we want the test to fail > in > >> > that case. > >> > >> Erhm... My understanding is that, when it returns false, no memory is > >> changed, so the second attempt would start from exactly the same state > >> as the first. > > > "Remarks: A weak compare-and-exchange operation may fail spuriously. > > That is, even when the contents of memory referred to by expected and > > ptr are equal, it may return false and store back to expected the same > > memory contents that were originally there." > > > So `expected` is updated on a spurious failure, even if that doesn't > > change any bits. > > Yeah, but if it stores back what was there to begin with, how can that > be a problem? Is there any reason to expect that "store back [of] the > same memory contents" to not actually mean that, and end up messing with > padding bits? > Yes, i think the wording is wrong and should have been changed by the paper that required us to ignore padding bits in the comparison. I've asked for confirmation from the committee and will open a library issue if needed. > Anyhow, your near-rewrite of the test is also passing consistently. I > suspect it's not just because we're no longer likely to get the timing > just right for an interrupt to cause a spurious failure. I needed a few > tens of retries to hit the problem, now I'm up to 500 without any hits. > Thanks, I'll push it then. > -- > Alexandre Oliva, happy hacker https://blog.lx.oliva.nom.br/ > Free Software Activist FSFLA co-founder GNU Toolchain Engineer > More tolerance and less prejudice are key for inclusion and diversity. > Excluding neuro-others for not behaving ""normal"" is *not* inclusive! >
