RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1641981 - glibc: Incorrect analysis of x86 CPU properties selects wrong string functions
Summary: glibc: Incorrect analysis of x86 CPU properties selects wrong string functions
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc
Version: 7.7
Hardware: x86_64
OS: Unspecified
Target Milestone: pre-dev-freeze
: ---
Assignee: Florian Weimer
QA Contact: Carlos O'Donell
Depends On: 1641980 1641982
Blocks: 1660844
TreeView+ depends on / blocked
Reported: 2018-10-23 10:00 UTC by Florian Weimer
Modified: 2019-08-06 12:49 UTC (History)
7 users (show)

Fixed In Version: glibc-2.17-282.el7
Doc Type: No Doc Update
Doc Text:
Clone Of: 1641980
Last Closed: 2019-08-06 12:49:05 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:2118 0 None None None 2019-08-06 12:49:33 UTC
Sourceware 23709 0 P2 RESOLVED glibc 2.25 lacks sse2 optimized strstr() 2020-11-04 05:27:10 UTC

Description Florian Weimer 2018-10-23 10:00:52 UTC
+++ This bug was initially created as a clone of Bug #1641980 +++

The RTM override also drops setting the performance feature flags for modern Intel CPU generations, which is incorrect and leads to the selection of the wrong implementation for strstr, for example.

Comment 3 Florian Weimer 2018-11-22 15:36:09 UTC
Upstream commit:

commit c3d8dc45c9df199b8334599a6cbd98c9950dba62
Author: Adhemerval Zanella <adhemerval.zanella>
Date:   Thu Oct 11 15:18:40 2018 -0300

    x86: Fix Haswell strong flags (BZ#23709)
    Th commit 'Disable TSX on some Haswell processors.' (2702856bf4) changed the
    default flags for Haswell models.  Previously, new models were handled by the
    default switch path, which assumed a Core i3/i5/i7 if AVX is available. After
    the patch, Haswell models (0x3f, 0x3c, 0x45, 0x46) do not set the flags
    Fast_Rep_String, Fast_Unaligned_Load, Fast_Unaligned_Copy, and
    Prefer_PMINUB_for_stringop (only the TSX one).
    This patch fixes it by disentangle the TSX flag handling from the memory
    optimization ones.  The strstr case cited on patch now selects the
    __strstr_sse2_unaligned as expected for the Haswell cpu.
    Checked on x86_64-linux-gnu.
            [BZ #23709]
            * sysdeps/x86/cpu-features.c (init_cpu_features): Set TSX bits
            independently of other flags.

Comment 4 Florian Weimer 2019-03-01 16:47:42 UTC
With glibc-2.17-260.el7_6.3.x86_64, I see:

(gdb) print/x _rtld_global_ro._dl_x86_cpu_features 
$2 = {kind = 0x1, max_cpuid = 0xf, cpuid = {{eax = 0x306f2, ebx = 0x3100800, 
      ecx = 0x7ffefbff, edx = 0xbfebfbff}, {eax = 0x0, ebx = 0x37ab, 
      ecx = 0x0, edx = 0x9c000000}, {eax = 0x0, ebx = 0x0, ecx = 0x0, 
      edx = 0x0}}, family = 0x6, model = 0x3f, xsave_state_size = 0x380, 
  feature = {0xcc8}}

With (upcoming) glibc-2.17-282.el7.x86_64, I get instead:

(gdb) print/x _rtld_global_ro._dl_x86_cpu_features 
$1 = {kind = 0x1, max_cpuid = 0xf, cpuid = {{eax = 0x306f2, ebx = 0x5100800, 
      ecx = 0x7ffefbff, edx = 0xbfebfbff}, {eax = 0x0, ebx = 0x37ab, 
      ecx = 0x0, edx = 0x9c000000}, {eax = 0x0, ebx = 0x0, ecx = 0x0, 
      edx = 0x0}}, family = 0x6, model = 0x3f, xsave_state_size = 0x380, 
  feature = {0xcfb}}

0xcc8 ^ 0xcfb == 0x33, and the new bits correspond to:

#define bit_Fast_Rep_String		(1 << 0)
#define bit_Fast_Copy_Backward		(1 << 1)

#define bit_Fast_Unaligned_Load		(1 << 4)
#define bit_Prefer_PMINUB_for_stringop	(1 << 5)

This corresponds to the newly reached switch case in init_cpu_features in sysdeps/x86/cpu-features.c:

		|= (bit_Fast_Rep_String
		    | bit_Fast_Copy_Backward
		    | bit_Fast_Unaligned_Load
		    | bit_Prefer_PMINUB_for_stringop);

I do not know if the verification method from bug 1641982 comment 6 will work for Red Hat Enterprise Linux 7 because strstr selects string functions differently in the first place, which is likely why this regression was only found during internal code review and not reported by customers yet.

Comment 6 Sergey Kolosov 2019-06-25 14:46:53 UTC
Verified, based on https://bugzilla.redhat.com/show_bug.cgi?id=1641981#c4. In glibc-2.17-282.el7 flags: bit_Fast_Rep_String, bit_Fast_Copy_Backward, bit_Fast_Unaligned_Load, bit_Prefer_PMINUB_for_stringop were properly setup on Haswell CPU.

Comment 8 errata-xmlrpc 2019-08-06 12:49:05 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.