From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4760C7115B for ; Thu, 19 Jun 2025 15:32:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1DD8D6B0088; Thu, 19 Jun 2025 11:32:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B5506B0089; Thu, 19 Jun 2025 11:32:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A3E26B008A; Thu, 19 Jun 2025 11:32:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EADCB6B0088 for ; Thu, 19 Jun 2025 11:32:21 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 754191604A4 for ; Thu, 19 Jun 2025 15:32:21 +0000 (UTC) X-FDA: 83572541682.06.60BAF00 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf17.hostedemail.com (Postfix) with ESMTP id D8F784000A for ; Thu, 19 Jun 2025 15:32:18 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=d15rC5N6; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf17.hostedemail.com: domain of donettom@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=donettom@linux.ibm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750347139; a=rsa-sha256; cv=none; b=cJt7srARhe6DxjAYxR0anQBxwpyku1rJ+lU4XL8ZyOVAk7+zlNpqAae6+S2HoSjwLEkA1c 0SW8hz9Ffi4yk2ve6aGYKwZAM/czdo5M9KUs4NY1s5fYe8sR8a+nbVcu+a2lLY1M6gQovr xEeUQCFixnN+aWS69KwqjB7RmlI3g90= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=d15rC5N6; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf17.hostedemail.com: domain of donettom@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=donettom@linux.ibm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750347139; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JK0h6qzleQucRALkrfKvbSaIkEuI+QqioAw45QRuuQg=; b=6uqYYpwu88gqK/HALrBfXVvEBc0O/tFIiEy7ZSYa/mYfDrrHfTqpmjpGT/ByGf7qcSvbHP gyQ3AqPrvjadJleLqA7OJpGtYL6GC1trZrUnmiEzWG0xj8xfK3jBc+64JUbbOfGrF5PcHT y5cMrxPz59Bo5Ll6Z4dMolHI9UpxVf8= Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55JB4QHm029477; Thu, 19 Jun 2025 15:32:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=JK0h6q zleQucRALkrfKvbSaIkEuI+QqioAw45QRuuQg=; b=d15rC5N6QNpPLZyEUmrLFl hPKuL9zv3b6VHa2tnQgo5mBnS2eDY9NOgPZSfN+ezdUsq3Jc7MFHKZWDIDpdWGkE ZO7WoFCxjizM2EBCjt94M8vFy4qb6zIXieOrNtMyKkySNzNuxO0PKSLROvZl2GXn H69aw4n9Zb81ZowSKrZaRrwrkK5dUYjTuH7Ti8ItbsMUroKbOrPGqdzKuJy5+ri1 FnWC1wHrHpo5B/3ZZuRZaN4ka/oOIroc28UTOSt2um9o0Hr0gG65dhTBQHC5dgHc jJVD4vEZTjFV2iilhbjdOZUXOGtKAbHdaYkAJI32RvdUimQbsZVKoY8VAqSeumeA == Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4790ktxfen-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Jun 2025 15:32:11 +0000 (GMT) Received: from m0360083.ppops.net (m0360083.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55JFRRfn001458; Thu, 19 Jun 2025 15:32:11 GMT Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4790ktxfeg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Jun 2025 15:32:11 +0000 (GMT) Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 55JF6DwB011331; Thu, 19 Jun 2025 15:32:10 GMT Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 479kdtpy6j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Jun 2025 15:32:10 +0000 Received: from smtpav03.fra02v.mail.ibm.com (smtpav03.fra02v.mail.ibm.com [10.20.54.102]) by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 55JFW8O219726732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Jun 2025 15:32:08 GMT Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 822DF20043; Thu, 19 Jun 2025 15:32:08 +0000 (GMT) Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9B97D20040; Thu, 19 Jun 2025 15:32:04 +0000 (GMT) Received: from li-06431bcc-2712-11b2-a85c-a6fe68df28f9.ibm.com (unknown [9.124.208.8]) by smtpav03.fra02v.mail.ibm.com (Postfix) with ESMTPS; Thu, 19 Jun 2025 15:32:04 +0000 (GMT) Date: Thu, 19 Jun 2025 21:01:57 +0530 From: Donet Tom To: Dev Jain Cc: Lorenzo Stoakes , Aboorva Devarajan , akpm@linux-foundation.org, Liam.Howlett@oracle.com, shuah@kernel.org, pfalcato@suse.de, david@redhat.com, ziy@nvidia.com, baolin.wang@linux.alibaba.com, npache@redhat.com, ryan.roberts@arm.com, baohua@kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, ritesh.list@gmail.com Subject: Re: [PATCH 1/6] mm/selftests: Fix virtual_address_range test issues. Message-ID: References: <79bdd993-0e9c-4d7d-b42c-4b5750eff140@lucifer.local> <8e23c5d3-6ce3-4fe8-b6fe-69658d5d0727@lucifer.local> <815793f1-6800-4b9a-852e-f13d6308f50f@arm.com> <2756fa2b-e8bf-4c66-bf9b-c85dc63dfc33@lucifer.local> <41d9a70d-9791-4212-af23-5b13d8e4a47d@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-GUID: -AGxg226a1W1BoHdjzh0mnUYkkdqeudo X-Proofpoint-ORIG-GUID: IttxmOtD5-Er_wDH8ObdLR2gawgidXqt X-Authority-Analysis: v=2.4 cv=KaDSsRYD c=1 sm=1 tr=0 ts=68542d7b cx=c_pps a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17 a=IkcTkHD0fZMA:10 a=6IFa9wvqVegA:10 a=ZvAkLkJfXhtqqUnwYFwA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjE5MDEyNyBTYWx0ZWRfX4EWS1qLVqvpU EConTVdIDP4YgNvuxRZjqH1I3yBWEorQiw9zYqKMUUL022luyiVcKRaR+iGxxoVNmxsacqSfH2/ z3tkZTfC3O4ndeMqu13E06lI9kWj4MhF7YWaDZLFedw7jHBXzTdopMJu5oip6FpiynHR1ZmIF4n H4x5Ie85eXDQvJz9fG5bw3VOOk8Jby1Wm5pusUReVVfoYlOYh7CFO32f7ImMXOP1oQMzWc0JLnu nmcAwAgq2fmIuv4YQH4AGPV+eU8CmYhbxzru3zWVo9OvROF4QzwSwoDng40cMpuC4JsWN5C0v0p PXmdx3lgBZSo7K1vW+uWmrEXv3GPj/GXlpXi3fC3NhvoT11OoRbVm85IbqAHVc/OJpy6/kbWKPY tW+pgktK8gyggWacUnRd3cU0CitK5w8puAAYLG9VihKc07FCU+MhlmhFwa2hSNU1LdegF+i5 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-19_05,2025-06-18_03,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxscore=0 spamscore=0 clxscore=1015 malwarescore=0 lowpriorityscore=0 suspectscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 phishscore=0 priorityscore=1501 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2505280000 definitions=main-2506190127 X-Stat-Signature: 9inx4a1mpzc6xwwwax7eoezbfawrpcsf X-Rspamd-Queue-Id: D8F784000A X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1750347138-949886 X-HE-Meta: U2FsdGVkX18vJJRwcHL88LtmIPKelje5RpyCr2KVoNwV7YN55bZ6uxvAzaP9AnfJ2Q2RgrI6iDmfOoSbkrWw85rWh/vjE4lwQGAY4DcW7qn4jdYGqYNuyt7jsFqItw4O/nl34/QSLvPMKHXu2bwyDPtwzQ+c+4VSScf5xTadhGN3COCcHPqSjiA+fVn2fpFuivSYxXjyj6eLIyGe40GqUCsez6s9rFzVECVwJ/ZS/7E/Q+K/ryyZdGn3jSaldoUm9zrYV7U/LK6nogzT7G42JF6CTO/ekW8I7Chuvg5CxzSU8tI7jwnA9V5LuXbzezQqsnvKgvhSiTPmKJh18+AAKFBchqKG1xXqYWeNDs/1coLqX6XjDbtmbx0eyKIPCmB2295uERkj3cUpooaVguUhqWEEAClnbNnPKGNygiBX6KG4S32UoJHVk84bJsRtRsOXTUXnDhfiOHjrv2dO7i73FC2/LSE4NZYPwnzoBryvLP36VpTdb0O0408JgkiNFemr08FwJFSww2/10RoWJlAKmLX/1zblnmviZEBwLFkEnCVoQMTFCaeaVLrLfayr08f+JqnHGWaOCkoyx9/ukFEGSIXi3QjA7+HjfVf0MV7mF4cQcPFiY41wyhFF1ixDKY/IriIP6Hz+gJSmkRZklVLMZ5n/y1FJ392TjXPIf8Zhr6FqzDIA5FKQ4NOP/EHZHuEfoa8/4rjr3yYT3r1Zfd+XhZJ6DjuQhwAU2vuNPkgZYzBvY+bCaz+bBwBd45OQy0yqm1QDW/AW0qZZ9ZWpYfRdGHHEFPDwfx6g215UiUvnBpCfjHbKd2MMTgWiqIZ7T4wIqxyY6fGczz/GM+zrgkGn+xb6m8bA/Fm/YbqNlneUGAuzPBVPs/52Zau9eNsV8diW6N72OEvOr1R3h69CBhdxCE38MmaqINVJBBOGz86Cy3kYilu+4uDe/O2EFJ852CB/wmFwmsd5dxeO3BNXVa0 /HoDWjT7 eIhEkfrd5ScOfjBPOpjjPNdlESCnzQ3tRkQGVXDYpDlBxiNA6qgvwiFcMRO55wldhqS++Y+DknwpsMYT3HQwe8Afitw+1ld05WIXDji7UL1AKwRoney/UcI3oWRL2iqMbe6JoH183FO+tPDFMO+CkWvsU2dCPib+OW0zADKd2hrOAh5WhVm/3CfpR5Shka1Flkf4hisZU/r/ScZkCCo4Oo1XQvHsLx7U+yE7WCht9OVynfvrMa2SXenCiy/YsALjx9RiV/sDc7rKsP76MKRAzjGi6jNJKOmMCIjO5CNcF5JRvO9pU9xKODFFC3taUNoIt977Dov/3+PeOjbDEDCpGkX48wrUAIh2698enbip+6cq22JeszAkngwsGGfU9IUPQFSBzJqlv8fm4b5y1/H2q5uy1LV8Cy+6Vn1Hl9li1AIFbdssTP7PZLOuzAoekdQ1q7sQ6X0lWrTPpIrs85LP8PBinq2FEBmkPOJ2fBbkMcCHFglJ+wnf/94MJew== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: eOn Thu, Jun 19, 2025 at 02:32:19PM +0530, Dev Jain wrote: > > On 19/06/25 1:53 pm, Donet Tom wrote: > > On Wed, Jun 18, 2025 at 08:13:54PM +0530, Dev Jain wrote: > > > On 18/06/25 8:05 pm, Lorenzo Stoakes wrote: > > > > On Wed, Jun 18, 2025 at 07:47:18PM +0530, Dev Jain wrote: > > > > > On 18/06/25 7:37 pm, Lorenzo Stoakes wrote: > > > > > > On Wed, Jun 18, 2025 at 07:28:16PM +0530, Dev Jain wrote: > > > > > > > On 18/06/25 5:27 pm, Lorenzo Stoakes wrote: > > > > > > > > On Wed, Jun 18, 2025 at 05:15:50PM +0530, Dev Jain wrote: > > > > > > > > Are you accounting for sys.max_map_count? If not, then you'll be hitting that > > > > > > > > first. > > > > > > > run_vmtests.sh will run the test in overcommit mode so that won't be an issue. > > > > > > Umm, what? You mean overcommit all mode, and that has no bearing on the max > > > > > > mapping count check. > > > > > > > > > > > > In do_mmap(): > > > > > > > > > > > > /* Too many mappings? */ > > > > > > if (mm->map_count > sysctl_max_map_count) > > > > > > return -ENOMEM; > > > > > > > > > > > > > > > > > > As well as numerous other checks in mm/vma.c. > > > > > Ah sorry, didn't look at the code properly just assumed that overcommit_always meant overriding > > > > > this. > > > > No problem! It's hard to be aware of everything in mm :) > > > > > > > > > > I'm not sure why an overcommit toggle is even necessary when you could use > > > > > > MAP_NORESERVE or simply map PROT_NONE to avoid the OVERCOMMIT_GUESS limits? > > > > > > > > > > > > I'm pretty confused as to what this test is really achieving honestly. This > > > > > > isn't a useful way of asserting mmap() behaviour as far as I can tell. > > > > > Well, seems like a useful way to me at least : ) Not sure if you are in the mood > > > > > to discuss that but if you'd like me to explain from start to end what the test > > > > > is doing, I can do that : ) > > > > > > > > > I just don't have time right now, I guess I'll have to come back to it > > > > later... it's not the end of the world for it to be iffy in my view as long as > > > > it passes, but it might just not be of great value. > > > > > > > > Philosophically I'd rather we didn't assert internal implementation details like > > > > where we place mappings in userland memory. At no point do we promise to not > > > > leave larger gaps if we feel like it :) > > > You have a fair point. Anyhow a debate for another day. > > > > > > > I'm guessing, reading more, the _real_ test here is some mathematical assertion > > > > about layout from HIGH_ADDR_SHIFT -> end of address space when using hints. > > > > > > > > But again I'm not sure that achieves much and again also is asserting internal > > > > implementation details. > > > > > > > > Correct behaviour of this kind of thing probably better belongs to tests in the > > > > userland VMA testing I'd say. > > > > > > > > Sorry I don't mean to do down work you've done before, just giving an honest > > > > technical appraisal! > > > Nah, it will be rather hilarious to see it all go down the drain xD > > > > > > > Anyway don't let this block work to fix the test if it's failing. We can revisit > > > > this later. > > > Sure. @Aboorva and Donet, I still believe that the correct approach is to elide > > > the gap check at the crossing boundary. What do you think? > > > > > One problem I am seeing with this approach is that, since the hint address > > is generated randomly, the VMAs are also being created at randomly based on > > the hint address.So, for the VMAs created at high addresses, we cannot guarantee > > that the gaps between them will be aligned to MAP_CHUNK_SIZE. > > > > High address VMAs > > ----------------- > > 1000000000000-1000040000000 r--p 00000000 00:00 0 > > 2000000000000-2000040000000 r--p 00000000 00:00 0 > > 4000000000000-4000040000000 r--p 00000000 00:00 0 > > 8000000000000-8000040000000 r--p 00000000 00:00 0 > > e80009d260000-fffff9d260000 r--p 00000000 00:00 0 > > Just confirming, the correct way to test this will be, put a sleep > after the VA gets exhausted by the test, and then examine /proc/pid/maps - > are you doing something similar? > Yes. I am doing the same. > The random generation of the hint addr should not be a problem - if we > cannot satisfy the request at addr, then the algorithm falls back to > the original approach. > > FYI in arch/x86/kernel/sys_x86_64.c : > > * If hint address is above DEFAULT_MAP_WINDOW, look for unmapped area > * in the full address space. > Yes. Got it. I ran the same test on x86, and what I am seeing is that mmap with a hint in this test is always failing and exiting the loop and no high VMA is getting created. Ideally mmap should be succeed with hint right? > Same happens for arm64; if we give a high addr hint, and the high VA space > has been exhausted, then we look for free space in the low VA space. So, in the test program, is the second mmap (with hint) returning a mapped address, or is it failing in your case? > The only thing I am not sure about is the border. I remember witnessing weird > behaviour when I used to test with 16K page config on arm64, across the > border. > > > > > I have a different approach to solve this issue. > > > > From 0 to 128TB, we map memory directly without using any hint. For the range above > > 256TB up to 512TB, we perform the mapping using hint addresses. In the current test, > > we use random hint addresses, but I have modified it to generate hint addresses linearly > > starting from 128TB. > > > > With this change: > > > > The 0–128TB range is mapped without hints and verified accordingly. > > > > The 128TB–512TB range is mapped using linear hint addresses and then verified. > > > > Below are the VMAs obtained with this approach: > > > > 10000000-10010000 r-xp 00000000 fd:05 135019531 > > 10010000-10020000 r--p 00000000 fd:05 135019531 > > 10020000-10030000 rw-p 00010000 fd:05 135019531 > > 20000000-10020000000 r--p 00000000 00:00 0 > > 10020800000-10020830000 rw-p 00000000 00:00 0 > > 1004bcf0000-1004c000000 rw-p 00000000 00:00 0 > > 1004c000000-7fff8c000000 r--p 00000000 00:00 0 > > 7fff8c130000-7fff8c360000 r-xp 00000000 fd:00 792355 > > 7fff8c360000-7fff8c370000 r--p 00230000 fd:00 792355 > > 7fff8c370000-7fff8c380000 rw-p 00240000 fd:00 792355 > > 7fff8c380000-7fff8c460000 r-xp 00000000 fd:00 792358 > > 7fff8c460000-7fff8c470000 r--p 000d0000 fd:00 792358 > > 7fff8c470000-7fff8c480000 rw-p 000e0000 fd:00 792358 > > 7fff8c490000-7fff8c4d0000 r--p 00000000 00:00 0 > > 7fff8c4d0000-7fff8c4e0000 r-xp 00000000 00:00 0 > > 7fff8c4e0000-7fff8c530000 r-xp 00000000 fd:00 792351 > > 7fff8c530000-7fff8c540000 r--p 00040000 fd:00 792351 > > 7fff8c540000-7fff8c550000 rw-p 00050000 fd:00 792351 > > 7fff8d000000-7fffcd000000 r--p 00000000 00:00 0 > > 7fffe9c80000-7fffe9d90000 rw-p 00000000 00:00 0 > > 800000000000-2000000000000 r--p 00000000 00:00 0 -> High Address (128TB to 512TB) > > > > diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c > > index 4c4c35eac15e..0be008cba4b0 100644 > > --- a/tools/testing/selftests/mm/virtual_address_range.c > > +++ b/tools/testing/selftests/mm/virtual_address_range.c > > @@ -56,21 +56,21 @@ > > #ifdef __aarch64__ > > #define HIGH_ADDR_MARK ADDR_MARK_256TB > > -#define HIGH_ADDR_SHIFT 49 > > +#define HIGH_ADDR_SHIFT 48 > > #define NR_CHUNKS_LOW NR_CHUNKS_256TB > > #define NR_CHUNKS_HIGH NR_CHUNKS_3840TB > > #else > > #define HIGH_ADDR_MARK ADDR_MARK_128TB > > -#define HIGH_ADDR_SHIFT 48 > > +#define HIGH_ADDR_SHIFT 47 > > #define NR_CHUNKS_LOW NR_CHUNKS_128TB > > #define NR_CHUNKS_HIGH NR_CHUNKS_384TB > > #endif > > -static char *hint_addr(void) > > +static char *hint_addr(int hint) > > { > > - int bits = HIGH_ADDR_SHIFT + rand() % (63 - HIGH_ADDR_SHIFT); > > + unsigned long addr = ((1UL << HIGH_ADDR_SHIFT) + (hint * MAP_CHUNK_SIZE)); > > - return (char *) (1UL << bits); > > + return (char *) (addr); > > } > > static void validate_addr(char *ptr, int high_addr) > > @@ -217,7 +217,7 @@ int main(int argc, char *argv[]) > > } > > for (i = 0; i < NR_CHUNKS_HIGH; i++) { > > - hint = hint_addr(); > > + hint = hint_addr(i); > > hptr[i] = mmap(hint, MAP_CHUNK_SIZE, PROT_READ, > > MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); > > > > > > > > Can we fix it this way? >