From patchwork Thu May 11 16:49:39 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Siddhesh Poyarekar X-Patchwork-Id: 20414 Received: (qmail 124295 invoked by alias); 11 May 2017 16:49:46 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 124275 invoked by uid 89); 11 May 2017 16:49:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=thursday, yours X-HELO: homiemail-a56.g.dreamhost.com Subject: Re: [PATCH v1.1 0/7] aarch64: Allow overriding HWCAP_CPUID feature check To: Adhemerval Zanella , libc-alpha@sourceware.org References: <1494514306-4167-1-git-send-email-siddhesh@sourceware.org> <89658c48-db20-8e5d-d3e9-b810e6f44768@linaro.org> From: Siddhesh Poyarekar Message-ID: Date: Thu, 11 May 2017 22:19:39 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <89658c48-db20-8e5d-d3e9-b810e6f44768@linaro.org> On Thursday 11 May 2017 09:08 PM, Adhemerval Zanella wrote: > It has fixed x86 build, however I am still seeing a runtime failure with: > > FAIL: elf/tst-env-setuid > > Which basically does: > > $ env GCONV_PATH=/home/azanella/Projects/glibc/build/x86_64-linux-gnu/iconvdata LOCPATH=/home/azanella/Projects/glibc/build/x86_64-linux-gnu/localedata LC_ALL=C MALLOC_CHECK_=2 MALLOC_MMAP_THRESHOLD_=4096 LD_HWCAP_MASK=0xffffffff /home/azanella/Projects/glibc/build/x86_64-linux-gnu/elf/tst-env-setuid > : error while loading shared libraries: cannot create capability list: Cannot allocate memory > > It is failing on elf/dl-hwcaps.c: > > 201 /* The result structure: we use a very compressed way to store the > 202 various combinations of capability names. */ > 203 *sz = 1 << cnt; > 204 result = (struct r_strlenpair *) malloc (*sz * sizeof (*result) + total); > 205 if (result == NULL) > 206 _dl_signal_error (ENOMEM, NULL, NULL, > 207 N_("cannot create capability list")); > > With a total value being way too large. I am still digesting why exactly > this value is being too large. Heh, I think I know what is going on. There are two places where it fails with the exact same error, and both can be reached when there are too many bits set in DL_HWCAP_IMPORTANT. Setting LD_HWCAP_MASK to 0xffffffff in the test case is crossing both limits I assume. The fact that I don't see the failure and you do seems to be because of malloc not failing on my system and failing on yours. This may be due to differences in overcommit behaviour. Fix is to reduce the number of bits set in the test, so really just this (untested) patch should do, can you please confirm? Thanks, Siddhesh ChangeLog: * elf/Makefile (tst-env-setuid-ENV): Set LD_HWCAP_MASK to 0x1. diff --git a/elf/Makefile b/elf/Makefile index baf9678..14a4c27 100644 --- a/elf/Makefile +++ b/elf/Makefile @@ -1399,6 +1399,6 @@ $(objpfx)tst-nodelete-dlclose.out: $(objpfx)tst-nodelete-dlclose-dso.so \ $(objpfx)tst-nodelete-dlclose-plugin.so tst-env-setuid-ENV = MALLOC_CHECK_=2 MALLOC_MMAP_THRESHOLD_=4096 \ - LD_HWCAP_MASK=0xffffffff + LD_HWCAP_MASK=0x1 tst-env-setuid-tunables-ENV = \ GLIBC_TUNABLES=glibc.malloc.check=2:glibc.malloc.mmap_threshold=4096