From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 08A801F44D for ; Mon, 22 Apr 2024 13:12:19 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=Dcy8afZT; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BFD9E3858C98 for ; Mon, 22 Apr 2024 13:12:17 +0000 (GMT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 327983858D35 for ; Mon, 22 Apr 2024 13:11:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 327983858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 327983858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::42c ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713791516; cv=none; b=XvaqDgovLYkUELHuuKuFwH1XhRqoU0NEXJJfRLa/6Mh0ti+KzzUB/digyRZhMoJdVCmXqrV2mzexFM1x1XS2x/boEm4XjCbV5qbOrfcQG0kDmB2dJiyWjOt9xWxO8ryP7px5SwjXPRSM5kDkchQ9oKMmIy5f8Z3YFesL8hnyP0E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713791516; c=relaxed/simple; bh=mopS3SHEivwBZeuJD+1EBuiUsURShhFfSlUlmkuDnbs=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=PT5aC/FsnLtDWpQtUFRe6oOt4rWmn3Xppx3Yu1JA2ieJHJKqkoZKNYSkZGYaJNeVAY4L31CDT0HyzJAMlbcvck4pJtoV4YQyn2WpOZ9HeDkhpbEGnhRxobxm2lTa/lSBzmo/i5WkLRLUGQiuIZbMdsKAsgCPuaZII8DsuCvEQeA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-6f043f9e6d7so4728455b3a.3 for ; Mon, 22 Apr 2024 06:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1713791512; x=1714396312; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=BtHyFiUdQ289iR5zwLlfRKVJ5+LoZ7EVFYpQ/6cGbxA=; b=Dcy8afZTgLJnytKrGBKKkYWPV1yF64oDZHo8OEZ7h123FqU8hvk60Zsv+cDCtJNM4s VwjemvsD3s7oYmlWFD7882aL+9c+eDp05I7MEGoXcjuvib8DUeTAxdzeChe6uJaj8w8+ s7VuONiqgwgKlFfeBha1TXU5di1bphLhqw6jEDaE6VfW/bavFRx++Z4+PLjcjrk+dmH9 TjYwHm5f5/BB5WWiGhcZ5GrmotGoRwUaQwA6kWTEPkG95sQq44K5mJg5UciffOwx/OGM OqOEJsk8mPLAMmcTgwDg2xtUIW3WhgTSdyNDsZT3wbTes44ZRxKND954R3Cc02FQ4TdL CJVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713791512; x=1714396312; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BtHyFiUdQ289iR5zwLlfRKVJ5+LoZ7EVFYpQ/6cGbxA=; b=j3eTpN9W8/J3RWoyAJ8NbKWKOGsN9BsqOoXFcYAii6OflwUD3iit2oPE5YUHI1JWl3 3FsndQRekuFTlfVWOp0saCi6SgpZ4vBNrjBvnup+ERQW5uyD2MTSzPC7ax0U4D7BCMjD oUveJeIt3TGGxZT67xUDHZS3CBFoZDWJS39dJOnJ3j7ahTC6uARa+LKW1bt+jG1pJNRE ff+CTLEIp/UHLeHExnFfR4lLTdenLmtfiQYSZLA1UZjnJoQitj3rio8iAs8BaIjMlzFd 1j/2R/7QY0JNsRE9Cc1ru2IHmJ2mhur5F8g/yejs9mgRY11CJfw11m2fBFdOEn3lRei8 u8uQ== X-Gm-Message-State: AOJu0Yzd+AyjhzFtSJGTmJ+Ze453cKuMzFs/zzw27/db7/T3V7qCA7wf QpcFhM+pW1euRo05QECbP4bWL2gPXK1AD4TSl6omI+TLw4YH/knLUgrNaOgsDVdPjpEXoKFjw5M t X-Google-Smtp-Source: AGHT+IEY5dtlbBbJCNQ9cnfqwZWNSnynQ6PtKpBW/mmaEOM39FSYxe1uP+wbvblyGQ8CPl52EkerKQ== X-Received: by 2002:a05:6a00:179c:b0:6ed:8798:3fa3 with SMTP id s28-20020a056a00179c00b006ed87983fa3mr12934099pfg.15.1713791512000; Mon, 22 Apr 2024 06:11:52 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:6157:ec04:29f5:f994:4bca? ([2804:1b3:a7c1:6157:ec04:29f5:f994:4bca]) by smtp.gmail.com with ESMTPSA id d16-20020a056a0010d000b006ed36f2c0dcsm8000826pfu.90.2024.04.22.06.11.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Apr 2024 06:11:51 -0700 (PDT) Message-ID: Date: Mon, 22 Apr 2024 10:11:47 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] elf: Do not check for loader mmap on tst-decorate-maps (BZ 31553) To: Simon Chopin Cc: libc-alpha@sourceware.org References: <20240326134742.526200-1-adhemerval.zanella@linaro.org> Content-Language: en-US From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org On 22/04/24 07:55, Simon Chopin wrote: > On mar. 26 mars 2024 10:47:42, Adhemerval Zanella wrote: >> On some architectures and depending on the page size, the loader can >> also allocate some memory during dependencies loading and it will be >> marked as 'loader malloc'. However, if the system page size is >> large enough, the initial data page will be enough for all required >> allocation and there will be no extra loader mmap. To avoid false >> negatives, the test does not check for such pages. >> >> Checked on powerpc64le-linux-gnu with 64k pagesize. > > Tested in similar conditions. > Altogether it looks good, I just have one minor whitespace nitpick. > >> --- >> elf/tst-decorate-maps.c | 12 ++++++------ >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/elf/tst-decorate-maps.c b/elf/tst-decorate-maps.c >> index 85ba5ce939..6d04344ba2 100644 >> --- a/elf/tst-decorate-maps.c >> +++ b/elf/tst-decorate-maps.c >> @@ -56,7 +56,6 @@ struct proc_maps_t >> int n_user_threads; >> int n_arenas; >> int n_malloc_mmap; >> - int n_loader_malloc_mmap; > > OK > >> }; >> >> static struct proc_maps_t >> @@ -82,8 +81,12 @@ read_proc_maps (void) >> r.n_arenas++; >> else if (strstr (line, "[anon: glibc: malloc]") != NULL) >> r.n_malloc_mmap++; >> - else if (strstr (line, "[anon: glibc: loader malloc]") != NULL) >> - r.n_loader_malloc_mmap++; >> + /* On some architectures and depending on the page size, the loader can >> + also allocate some memory during dependencies loading and it will be >> + marked as 'loader malloc'. However, if the system page size is large >> + enough, the initial data page will be enough for all required >> + allocation and there will be no extra loader mmap. To avoid false >> + negatives, the test does not check for such pages. */ > > Whitespace mixup here? The first line of the comment block appears to be > using a different indentation to the rest of the block. Hum, I used whitespace because it does not really fit for the indentation of the 'while'. The rest of patch use tab because it then allows it. > > Good call on leaving an explicit comment! > >> } >> free (line); >> xfclose (f); >> @@ -148,8 +151,6 @@ do_test_threads (bool set_guard) >> TEST_COMPARE (r.n_user_threads, num_user_threads); >> TEST_COMPARE (r.n_arenas, expected_n_arenas); >> TEST_COMPARE (r.n_malloc_mmap, 1); >> - /* On some architectures the loader might use more than one page. */ >> - TEST_VERIFY (r.n_loader_malloc_mmap >= 1); > > OK > >> } >> >> /* Let the threads finish. */ >> @@ -164,7 +165,6 @@ do_test_threads (bool set_guard) >> TEST_COMPARE (r.n_user_threads, 0); >> TEST_COMPARE (r.n_arenas, expected_n_arenas); >> TEST_COMPARE (r.n_malloc_mmap, 1); >> - TEST_VERIFY (r.n_loader_malloc_mmap >= 1); > > OK > >> } >> >> free (p); >> -- >> 2.34.1 >>