On Fri, Jun 05, 2020 at 12:17:54PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > I can reproduce this on a 2017-vintage CPU with ./configure
> > ... USE_SLICING_BY_8_CRC32C=1 and then running "make installcheck-parallel"
> > under valgrind-3.15.0 (as packaged by RHEL 7.8). valgrind.supp has a
> > suppression for CRC calculations, but it didn't get the memo when commit
> > 4f700bc renamed the function. The attached patch fixes the suppression.
>
> I can also reproduce this, on RHEL 8.2 which likewise has valgrind-3.15.0,
> using the same configuration to force use of that CRC function. I concur
> with your diagnosis that this is just a missed update of the pre-existing
> suppression rule. However, rather than
>
> - fun:pg_comp_crc32c
> + fun:pg_comp_crc32c*
>
> as you have it, I'd prefer to use
>
> - fun:pg_comp_crc32c
> + fun:pg_comp_crc32c_sb8
>
> which precisely matches what 4f700bc did. The other way seems like
> it's giving a free pass to problems that could lurk in unrelated CRC
> implementations.
The undefined data is in the CRC input, namely the padding bytes in xl_*
structs. Apparently, valgrind-3.15.0 doesn't complain about undefined input
to _mm_crc32_u* functions. We should not be surprised if Valgrind gains the
features necessary to complain about the other implementations.
Most COMP_CRC32C callers don't have a suppression, so Valgrind still studies
each CRC implementation via those other callers.