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 C75DEC77B7C for ; Wed, 2 Jul 2025 17:20:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5FF766B00A7; Wed, 2 Jul 2025 13:20:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B5696B00A9; Wed, 2 Jul 2025 13:20:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49DDA6B00AB; Wed, 2 Jul 2025 13:20:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 35C5E6B00A7 for ; Wed, 2 Jul 2025 13:20:15 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CCFE7105D30 for ; Wed, 2 Jul 2025 17:20:14 +0000 (UTC) X-FDA: 83619987948.06.152D581 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf25.hostedemail.com (Postfix) with ESMTP id 9381BA000C for ; Wed, 2 Jul 2025 17:20:12 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="X/t4FIDx"; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf25.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751476812; a=rsa-sha256; cv=none; b=GFk7xBqkzuQdLyRx0BCty3VFgWY0c+0xr+ecmtJ/qDMrXVy4FkrhVpMHjeyIQwy6Gy7miW tWh9x+QBVDBJW0zM3yKpnNpyfHalB+3p+5N2h2lVE9wT5e5W56v3E2WBcFWuzmMSXaB9e8 KLDyYoGQP6chMshwq6X42MAaKqJ4TU4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="X/t4FIDx"; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf25.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751476812; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=X4OXeIMkVHqZr0TmFdZKIZ9QEBYkowbL9PbKefie20c=; b=JiSlDV7jqSREHOwgjHujf05AmruiCjwIqZJ17xjBGIX03dCJ7EqxMV9ok6pwnGgjCMKtzJ 2I2rVGtCqRCVZf/XchpZ50Mcr3uIacP6DyKIQDJ3OrJG45JnBeaPOkJJ99cuKm4jiNEiJ7 svGRI4V+jN95oYJpk2FgnAX3k5+PsnQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1751476811; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=X4OXeIMkVHqZr0TmFdZKIZ9QEBYkowbL9PbKefie20c=; b=X/t4FIDxRRiA/I3KNv3K/l9iPZ7d6mJ3nhwE4658gk8zF3X7Pt340BiRPc7sX1/zMU/ZIa md3pQ36I+BK6wrq2deXiMlXsQtzGUeiMUaq4Tzv0Mt+M5lcrkZ/8mB1Gk3QB1SdSglJ+ir C2gSNc6boQ8efCfnIMArlSOdqxh6WaM= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-14-PS3gLCG_MJ2qnsJ_ScQWmQ-1; Wed, 02 Jul 2025 13:20:10 -0400 X-MC-Unique: PS3gLCG_MJ2qnsJ_ScQWmQ-1 X-Mimecast-MFC-AGG-ID: PS3gLCG_MJ2qnsJ_ScQWmQ_1751476810 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-7c955be751aso1085514285a.2 for ; Wed, 02 Jul 2025 10:20:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751476810; x=1752081610; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=X4OXeIMkVHqZr0TmFdZKIZ9QEBYkowbL9PbKefie20c=; b=A8ujfFTxqwz8JxZ9/3/aUA1IeC4xvp7US7Eqygeh1OyGsBRgvL2OlncUoGd3Zcy1DK bDW8K7Q9E1Z/hBHGErNHoXOeIZTornNAB4EepPY0vrLCZuvfxD1bGPSiz6HNflt/2j6b KSAMa3X00wrwrtXYWP5SZfI7wchILaGhYM7dgSWp6m9mjtyZQ/sRpY2qjPklcsLdqpTF qd8V0hGdw3hBGNtZKnv9xqJi08fkvRnZiEfx/rQEcp5c0Y+2Cfgw7/Q3nekKFXRnQJVu BiuLz+GYGReOz5bB8McUwfrCnSEpyyTZKxf+4ZG8xVp6+IvrsyU6dfK5iQugBBWJeLnp sfhQ== X-Forwarded-Encrypted: i=1; AJvYcCU6mhPj49XW1bBoTH7H/rCvk2uobvDR/bO/NnjwG5LgwjElijANUq2pt/gDAL2wx7JwibcGVpWtMA==@kvack.org X-Gm-Message-State: AOJu0Yyv8aNsM25SUPovl+UVYSEK7Xmkp+NPgJJJ/fG1F7ZmdcmGjYN+ 33SrXOZJ05CRMZ+2i9/UR8lEgVQrSQIVvcVz3QFNFM1TtNj9XWmJkM0/N5C+d/Cll9L7u22Ttbs Vh4s++1yXleznKkw7B88YSOah/oPehgo4i1jm5YU8dlzcucRQU4J2 X-Gm-Gg: ASbGncuDiQyqZANBlXGCyxuVYxnI/XqZOzpyMD6eu5i7D+oVFYtICh3G+wXiLtIRhOk S0XhtmpsSx1Y1oIg7rpqJUzSmlnrdCd7DeUJ0DG01UknH/vKF5eTGqdItgpuKvLhesP/T3u8pCQ A9ap7lDkXmu1niie8LjNCfKlYHC+kSFEDS15w0sjm2b4U6LG2dDsU1j7wNrV70VRr6DkOnB6XD6 5y/mOCF3qszQBu4sY8iQh1g9aGXy3VIhYrI5SHYsVc2mppP4zlmicNfzeKcUUSp0KwBgm9H/wDm oRWwyJzeSfEIyg== X-Received: by 2002:a05:620a:2493:b0:7cd:45ed:c4a5 with SMTP id af79cd13be357-7d5c462ac6bmr497721285a.0.1751476810084; Wed, 02 Jul 2025 10:20:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEABzvdSXcUcA35EvmAadp6Gl0tgp7duV0eKH1z56ocBWqywdOnkcWFAdC7968vXYiaa2gJNQ== X-Received: by 2002:a05:620a:2493:b0:7cd:45ed:c4a5 with SMTP id af79cd13be357-7d5c462ac6bmr497717285a.0.1751476809650; Wed, 02 Jul 2025 10:20:09 -0700 (PDT) Received: from x1.local ([85.131.185.92]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7d443134f32sm971947685a.12.2025.07.02.10.20.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Jul 2025 10:20:09 -0700 (PDT) Date: Wed, 2 Jul 2025 13:20:05 -0400 From: Peter Xu To: "Liam R. Howlett" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Huacai Chen , Thomas Bogendoerfer , Muchun Song , Oscar Salvador , loongarch@lists.linux.dev, linux-mips@vger.kernel.org, Jason Gunthorpe , David Hildenbrand Subject: Re: [PATCH] mm/hugetlb: Remove prepare_hugepage_range() Message-ID: References: <20250627160707.2124580-1-peterx@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: AEXJhQ3YZm9eLUm26TVE9Oepk2jJCud8SCjLu5abrrw_1751476810 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9381BA000C X-Stat-Signature: j6hhm8i8aokerqtphudhd5yimh6ackdt X-HE-Tag: 1751476812-569290 X-HE-Meta: U2FsdGVkX1+WM+Weg1UcSPoZTUzGsKC+oTb4Ig49mOvfsOP89U/ydyXc8IiGLMJ6xdi6uKKR3iFktdPML4R/Ne2YoqSV9mj4w8J7TIJuSOOa2av0tUGOF1ko2Ry8vDBi7x7mrYqsvk5QLU0llSi3To66SfWxZfgbIfkMecyr1IgsJVoPr67iH+cfaZ05sbYAkDEY1RJ3bMD/acwfE6MHsUkObjnJqYjDOXvHFk+KwCBDrtb1ehlyz4VE6b6+ZUMPANKYCgp434un4fSMeTuH/kA1UFrISQ83GeHlhxd3D662UNyzQcLQhXV6tHzAxt177HBEHqC7B+mENvCMFIp0bfOiSx18XlAJ1aOeIr3yla1u4MG9MreUEiUeqVy/WLT7y6zM+Z/OKAYEwi4XWZvZtHbNpaDU7aL6NSEKyCUA4jPBXj3WtPXToPadzgNfx/RE6kNpCsznX87NoV8UdnFbzQwwTQxEuhE47yrNX5psKTqMmttHZlREM/sfpLL4g3giGjgdnf7KWIqdgo4ukWZ6iCHl7MDRmtkq4DHE9vb7Tbstg9LiJFYazrPzz5ZXkAfOT0EzAQKY4eRc4jNU/uAj27DmoEVUTRm26iltOFjm3kvsgM9O5hajxJWf3ry0nEasibZ2rSFaNVz3bLPatWf8T3wB3rYzNXyXbq1ZCDc+BdIKM4zqujttMkcRvIoOhNEUt4FBYi7Dqdd7orkwI09pRUBfgyC3eIHWJrw6MhTxxiMEW8/nrdalkwF2qDQ6lfGH+D3AUHh+sbuGGcNSP3uMeGIJSCBJxHjHjb6fLeFLFbo6cLjCcw9rq+kKQTAO4R3QEBk5PES8xtX9kyXoo2UFVJX+Gpg9rAPcflHPNZlKrW6+Z8ncFC9NhoLyKc142nPtiEgxcHLzUMqg5KwrDmbJY05lR8YtfHySoa2q9/aDOrK9jZi4VP0WeyhW52kMQ9KchKkfIrFCFvZaXhAO22e uLQvflH3 rSLBOWUKVJ5IvKHT5aoTJH+GNsr70traXmHu45B+UloLCIFQZzRhCiAYzykNkMeAQZRXCLz7Kk8AU4kc0ejHDIdZuTbmVOZJgqKYQVddToMJy+thBMee6wAG1vgfsJJg6I03KIwsjdOz6z11HStdB+WVZHR146aF5/H0PZWcXFBQhlDi+LU2hp4T/D44B7bYrttm2Bv5Vn5/lfM8AETWyR3Ws4wOA7rfHItg8/bWmNZFu+ccC2PtDbqjXcsK1cT/CfweDSN+3T+u+fIYMZotqPljhOKY4K1NHx0Pnk9bsSTYCm2EajPUA+dKnPuoUD8mrXhd6ziuYUuVfHGs31mgp2NZkPONnKLuYLZeRczFkMObA+SOymbIlw9xMtC2JfxxRSymVA/QFtFaBAFwkMWFOKBHtAL4bUeSk2yONF/9kInDtlz9WjKHsBKyvH/49f42vG+W6R/mUKeGmrcO9vwNkvC4EmaKIsOOZ+28bZ1b1GMlcy322x41r/7EeASXEsoeV/t8zqosszne/gg4= 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: On Mon, Jun 30, 2025 at 10:26:13AM -0400, Liam R. Howlett wrote: > * Peter Xu [250627 12:07]: > > Only mips and loongarch implemented this API, however what it does was > > checking against stack overflow for either len or addr. That's already > > done in arch's arch_get_unmapped_area*() functions, even though it may not > > be 100% identical checks. > > > > For example, for both of the architectures, there will be a trivial > > difference on how stack top was defined. The old code uses STACK_TOP which > > may be slightly smaller than TASK_SIZE on either of them, but the hope is > > that shouldn't be a problem. > > > > It means the whole API is pretty much obsolete at least now, remove it > > completely. > > Thanks for rewording this change, apologies for the late response on > your change log. I think it's fine. That's totally OK, thanks for keeping an eye. > > I think the only meaningful difference is that the failure would have > aborted entirely if stack_top - len < addr, but with this change it will > attempt to search in the opposite direction. Unless I missed something? IIUC the prepare_hugepage_range() API shouldn't affect the direction of VA allocation yet, but rather a (likely proven unnecessary by this patch) way to fail fast for hugetlbfs for no good reason. It is currently only invoked with MAP_FIXED, and if it returns 0 it'll further move on to the core VA allocator. Then the allocation can happen either TOP->DOWN or DOWN->TOP. So "stack_top - len < addr" check is meaningful no matter if MMF_TOPDOWN or not, because we want to make sure it won't overflow in any direction. It's just that it's already covered at least by the two archs providing this hugetlbfs specific hook. > > I suspect that this wasn't meant to happen in the first place anyways, > and I bet there are no tests for it and no real-world harm in changing > an error scenario into a potential successful mapping. Yes, checking stack for hugetlbfs so far just looks redundant. Maybe keep digging the history we may found why we had it before, but so far it looks not useful at all. > > Reviewed-by: Liam R. Howlett Thanks, -- Peter Xu