This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
Bug 2227140 - glibc: valgrind strcmp warning during getpwuid_r NSS function lookup in pcp tests
Summary: glibc: valgrind strcmp warning during getpwuid_r NSS function lookup in pcp t...
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: glibc
Version: 9.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: glibc team
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-07-28 07:21 UTC by Jan Kurik
Modified: 2023-08-11 14:43 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-11 14:43:46 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker   RHEL-1190 0 None Migrated None 2023-08-11 14:43:16 UTC
Red Hat Issue Tracker RHELPLAN-163731 0 None None None 2023-07-28 07:22:16 UTC

Description Jan Kurik 2023-07-28 07:21:50 UTC 
Description of problem:
During testing of PCP a possible glibc bug has been discovered. PCP is using valgrind for some tests. One of these tests failed with the following valgrind log:

> Conditional jump or move depends on uninitialised value(s)
> at 0x4040410: strcmp (strcmp.S:76)
> by 0x4017E1B: check_match (dl-lookup.c:88)
> by 0x4017E1B: do_lookup_x (dl-lookup.c:447)
> by 0x4BC707B: do_dlsym (in /usr/lib64/libc.so.6)
> by 0x4BC6B97: _dl_catch_exception (in /usr/lib64/libc.so.6)
> by 0x4BC6CA7: _dl_catch_error (in /usr/lib64/libc.so.6)
> by 0x4030D87: _rtld_catch_error (dl-error-skeleton.c:260)
> by 0x4BC7367: __libc_dlsym (in /usr/lib64/libc.so.6)
> by 0x4B9C09F: module_load (in /usr/lib64/libc.so.6)
> by 0x4B9C853: __nss_module_get_function (in /usr/lib64/libc.so.6)
> by 0x4B9934F: __nss_lookup (in /usr/lib64/libc.so.6)
> by 0x4B9AFB7: __nss_passwd_lookup2 (in /usr/lib64/libc.so.6)
> by 0x4B12F5B: getpwuid_r@@GLIBC_2.17 (in /usr/lib64/libc.so.6)
> {
>    <insert_a_suppression_name_here>
>    Memcheck:Cond
>    fun:strcmp
>    fun:check_match
>    fun:do_lookup_x
>    fun:do_dlsym
>    fun:_dl_catch_exception
>    fun:_dl_catch_error
>    fun:_rtld_catch_error
>    fun:__libc_dlsym
>    fun:module_load
>    fun:__nss_module_get_function
>    fun:__nss_lookup
>    fun:__nss_passwd_lookup2
>    fun:getpwuid_r@@GLIBC_2.17
> }

Version-Release number of selected component (if applicable):
RHEL compose: RHEL-9.3.0-20230726.0
glibc: glibc-2.34-72.el9
valgrind: valgrind-3.21.0-7.el9
pcp: pcp-6.0.5-2.el9

How reproducible:
Seen on aarch64 and ppc64le architectures only.
I do not know how to directly reproduce this.
This issue appeared during automated testing of PCP and I was not successful to reproduce it manually.

Steps to Reproduce:
1. Unknown

Actual results:
A valdrind reports an issue in glibc.

Expected results:
No valgrind issues are reported.

Additional info:
Comment 6 Carlos O'Donell 2023-08-11 13:45:49 UTC 
Hitting this will depend on the values in the remainder of the page the string is on.

 70 /* OK. We've hit the end of the string. We need to be careful that
 71    we don't compare two strings as different because of gunk beyond
 72    the end of the strings...  */
 73 #ifdef __LITTLE_ENDIAN__
 74 L(endstring):
 75         addi    rTMP2, rTMP, -1
 76         beq     cr1, L(equal)
            ^^^^^^^^^^^^^^^^^^^^^
 77         andc    rTMP2, rTMP2, rTMP
 78         rldimi  rTMP2, rTMP2, 1, 0
 79         and     rWORD2, rWORD2, rTMP2   /* Mask off gunk.  */
 80         and     rWORD1, rWORD1, rTMP2
 81         cmpd    cr1, rWORD1, rWORD2
 82         beq     cr1, L(equal)
 83         xor     rBITDIF, rWORD1, rWORD2 /* rBITDIF has bits that differ.  */

Valgrind needs a suppression for this.

In the ppc64le strcmp.S code we compare potentially uninitialized data in the event that it is equal, but if it's not equal then we mask off the uninitialized bits. We don't waste the cycles doing the masking unless it compares unequal.

It's not exactly clear why upstream does this, there is a balance here between branch prediction and the cycles it takes to do the load and mask operation. Either this was cargo-culted from earlier implementations or this was verified to produce better performance.
Comment 8 RHEL Program Management 2023-08-11 14:43:46 UTC 
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues.
Note You need to log in before you can comment on or make changes to this bug.