From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 4689D3858C2F for ; Thu, 25 Aug 2022 09:55:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4689D3858C2F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27P9sgq9027739 for ; Thu, 25 Aug 2022 09:54:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=content-type : message-id : date : from : subject : to : mime-version; s=pp1; bh=1d06EEBoCg4P+tz3xzRP25WVd4JdltaklxR2L/zt4zk=; b=O+nDyjawXl56gm+KM6l7CbrSr1qWIQiZ9S4o2q/kpPZuWqJijTZuNax6caZMFszItkdm keJHI2GhW7NOivYpbq2EvA0RHngxiwj9UMc3Tk42NJr7GKtjI+k5lX27o2cUFdT84SE7 eoMSqBvDGkZo0lv7qBNLIF4U04C2XCrHNqFmWzzRDvkBGgT3Px54H/0lSh4wlHX2Z8G0 NImwSnIWvtMQ0HGOSle31jaeyd41T491CS6DbRewgrIoetjP4SsQw206gnlWS1KWEOOA eG2mDCfOL3veTkffbZek9LOLEiaYR6shwxQw46M6kb7kPoYSNREeBazWwOKh2aT0cp/N Hw== Received: from ppma06fra.de.ibm.com (48.49.7a9f.ip4.static.sl-reverse.com [159.122.73.72]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3j66v7g042-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 25 Aug 2022 09:54:58 +0000 Received: from pps.filterd (ppma06fra.de.ibm.com [127.0.0.1]) by ppma06fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 27P9pdEx009148 for ; Thu, 25 Aug 2022 09:54:56 GMT Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by ppma06fra.de.ibm.com with ESMTP id 3j2pvjck7v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 25 Aug 2022 09:54:56 +0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 27P9ssNq32833826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 25 Aug 2022 09:54:54 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 363B011C04C for ; Thu, 25 Aug 2022 09:54:54 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1308511C04A for ; Thu, 25 Aug 2022 09:54:54 +0000 (GMT) Received: from [9.171.7.43] (unknown [9.171.7.43]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP for ; Thu, 25 Aug 2022 09:54:53 +0000 (GMT) Content-Type: multipart/mixed; boundary="------------MxMHTFxnyQ6sI178cvN39dEM" Message-ID: <90fa41e3-8d9b-d5c2-916a-3d54fc047e27@linux.ibm.com> Date: Thu, 25 Aug 2022 11:54:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Content-Language: en-US From: Stefan Liebler Subject: Questions regarding manipulation of IFUNC selection and tunables like glibc.cpu.hwcap_mask To: GNU C Library X-TM-AS-GCONF: 00 X-Proofpoint-GUID: ZMC8jtTm1Osbz0045dWPGXkgogn90frX X-Proofpoint-ORIG-GUID: ZMC8jtTm1Osbz0045dWPGXkgogn90frX X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-25_04,2022-08-22_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 adultscore=0 spamscore=0 malwarescore=0 priorityscore=1501 bulkscore=0 mlxlogscore=999 impostorscore=0 clxscore=1015 mlxscore=0 suspectscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208250037 X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is a multi-part message in MIME format. --------------MxMHTFxnyQ6sI178cvN39dEM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, on s390x, the IFUNC'ed functions or other hw-dependent code-paths are usually selected by either the HWCAPs or the facility-list retrieved via stfle-instruction. Now we need a possibility to manipulate the IFUNC selection. As the current IFUNC-resolvers always select the functions for the newest features, we only need a possibility to disable features. According to /manual/tunables.texi: @deftp Tunable glibc.cpu.hwcap_mask This tunable supersedes the @env{LD_HWCAP_MASK} environment variable and is identical in features. The @code{AT_HWCAP} key in the Auxiliary Vector specifies instruction set extensions available in the processor at runtime for some architectures. The @code{glibc.cpu.hwcap_mask} tunable allows the user to mask out those capabilities at runtime, thus disabling use of those extensions. @end deftp But a small testprogram (see attached tst-ifunc-manipulation.c) shows that neither setting the environment variable GLIBC_TUNABLES="glibc.cpu.hwcap_mask=0" nor LD_HWCAP_MASK="0x0 influences the HWCAPs. On s390x, the IFUNC-resolvers get the HWCAPs as argument (the most other architectures don't have this argument). Other code-paths can get the HWCAPs via getauxval(AT_HWCAP). In both cases the HWCAPs are loaded from "GLRO(dl_hwcap)". See: - https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/s390/dl-irel.h;h=20e4887467d80a1b3f95da00bb98386e3eadfe47;hb=HEAD#l33 - https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/getauxval.c;h=714ce5bd62ec33c38356b187e6ec067b72b77afb;hb=HEAD#l32 Is it a bug or the intention that the HWCAP values are not influenced by glibc.cpu.hwcap_mask tunable? If it is a bug, would it be possible to apply the mask after __tunables_init() like this: GLRO(dl_hwcap) &= GET_HWCAP_MASK(); This would affect the IFUNC-resolver, getauxval(AT_HWCAP) and more (e.g. if lock-elision is available or not) on all architectures. This would also change the behavior of programs/libraries using getauxval(AT_HWCAP). As alternative, we could also introduce a new s390-specific tunable like: glibc.cpu.s390.hwcap_mask which influences only the s390-IFUNCS / s390-code-pathes within glibc. The behaviour of programs/libraries using getauxval(AT_HWCAP) is not changed. Independent of the HWCAPs, we need to introduce a new s390-specific tunable like glibc.cpu.s390.stfle_mask in order to influence the s390-IFUNCs within glibc which are dependent on the facility-list. Are there other hints? Thanks in advance, Stefan --------------MxMHTFxnyQ6sI178cvN39dEM Content-Type: text/x-csrc; charset=UTF-8; name="tst-ifunc-manipulation.c" Content-Disposition: attachment; filename="tst-ifunc-manipulation.c" Content-Transfer-Encoding: base64 I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN5cy9h dXh2Lmg+CgovKiBSdW4gd2l0aC93aXRob3V0IGVudmlyb25tZW50IHZhcmlhYmxlcyBkb2Vz IG5vdCBpbmZsdWVuY2UgSFdDQVBzOgoKICAgR0xJQkNfVFVOQUJMRVM9IiIKICAgTERfSFdD QVBfTUFTSz0iIgogICBIV0NBUHMgcGFzc2VkIGFzIGFyZ3VtZW50IHRvIGlmdW5jLXJlc29s dmVyOiAweDY3ZmZmZgogICBIV0NBUHMgZnJvbSBnZXRhdXh2YWwgKEFUX0hXQ0FQKTogMHg2 N2ZmZmYKCiAgIEdMSUJDX1RVTkFCTEVTPSJnbGliYy5jcHUuaHdjYXBfbWFzaz0wIgogICBM RF9IV0NBUF9NQVNLPSIiCiAgIEhXQ0FQcyBwYXNzZWQgYXMgYXJndW1lbnQgdG8gaWZ1bmMt cmVzb2x2ZXI6IDB4NjdmZmZmCiAgIEhXQ0FQcyBmcm9tIGdldGF1eHZhbCAoQVRfSFdDQVAp OiAweDY3ZmZmZgoKICAgR0xJQkNfVFVOQUJMRVM9IiIKICAgTERfSFdDQVBfTUFTSz0iMHgw IgogICBIV0NBUHMgcGFzc2VkIGFzIGFyZ3VtZW50IHRvIGlmdW5jLXJlc29sdmVyOiAweDY3 ZmZmZgogICBIV0NBUHMgZnJvbSBnZXRhdXh2YWwgKEFUX0hXQ0FQKTogMHg2N2ZmZmYKKi8K CnN0YXRpYyB1bnNpZ25lZCBsb25nIGdsb2JhbF9od2NhcHMgPSAwOwoKc3RhdGljIGludCBp bXBsKHZvaWQpCnsKICBwcmludGYgKCJIV0NBUHMgcGFzc2VkIGFzIGFyZ3VtZW50IHRvIGlm dW5jLXJlc29sdmVyOiAweCVseFxuIiwKCSAgZ2xvYmFsX2h3Y2Fwcyk7CiAgcmV0dXJuIDQy Owp9CnN0YXRpYyB2b2lkICpyZXNvbHZlcih1bnNpZ25lZCBsb25nIGh3Y2FwKQp7CiAgZ2xv YmFsX2h3Y2FwcyA9IGh3Y2FwOwogIHJldHVybiBpbXBsOwp9CmludCBpZnVuYyh2b2lkKSBf X2F0dHJpYnV0ZV9fKChpZnVuYygicmVzb2x2ZXIiKSkpOwoKaW50Cm1haW4gKHZvaWQpCnsK ICBwcmludGYgKCJHTElCQ19UVU5BQkxFUz1cIiVzXCJcbiIsIGdldGVudiAoIkdMSUJDX1RV TkFCTEVTIikgPyA6ICIiKTsKICBwcmludGYgKCJMRF9IV0NBUF9NQVNLPVwiJXNcIlxuIiwg Z2V0ZW52ICgiTERfSFdDQVBfTUFTSyIpID8gOiAiIik7CgogIGlmdW5jICgpOwogIHByaW50 ZiAoIkhXQ0FQcyBmcm9tIGdldGF1eHZhbCAoQVRfSFdDQVApOiAweCVseFxuIiwgZ2V0YXV4 dmFsIChBVF9IV0NBUCkpOwoKICByZXR1cm4gRVhJVF9TVUNDRVNTOwp9Cg== --------------MxMHTFxnyQ6sI178cvN39dEM--