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 0ECE2C3DA5D for ; Thu, 25 Jul 2024 09:35:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F4106B007B; Thu, 25 Jul 2024 05:35:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A3836B0082; Thu, 25 Jul 2024 05:35:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66B8A6B0083; Thu, 25 Jul 2024 05:35:08 -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 421F96B007B for ; Thu, 25 Jul 2024 05:35:08 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E6DDAA0EEF for ; Thu, 25 Jul 2024 09:35:07 +0000 (UTC) X-FDA: 82377766254.27.35921D6 Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) by imf21.hostedemail.com (Postfix) with ESMTP id 2F1661C000D for ; Thu, 25 Jul 2024 09:35:05 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TqiuIhw5; spf=pass (imf21.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.169 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721900104; 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=C9yOUnzDlzPd3C7+qAj+S0EJyMFKc+8zKUmimt6IWTY=; b=lfOYvjiUNlfueVaCivYWt/vTlwf9wTRdQ2q6iAVS6QA0uhWD9/L15yn38uN+qKrWSV0vwu lWdRDFgGciTBPvp7sGSqwyVt/24OVqsirB63gMhmN05pGNj4E6VvX49G+O1C9W5pAvTFuy 7skNRRZzFN5tpddIpVdTHb04rlhbpQo= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TqiuIhw5; spf=pass (imf21.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.169 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721900104; a=rsa-sha256; cv=none; b=Ckb3xX7KGhL/N9uK9/65JISSafIXhJVGseKU6xsLlMMkMOrRRGwVzButgmHRNPhYA+Tcpp jJN1KRGa/vSe4sGfSZmlj+/wiO6hB6ZKtpZqchnR06uTbqWGUVINXE1Xfz44KCx+0ORlP0 b0TxmMFrq28RBHDrKjA4Yrd8KSKQFiY= Received: by mail-vk1-f169.google.com with SMTP id 71dfb90a1353d-4ef12e5658bso240865e0c.2 for ; Thu, 25 Jul 2024 02:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721900105; x=1722504905; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=C9yOUnzDlzPd3C7+qAj+S0EJyMFKc+8zKUmimt6IWTY=; b=TqiuIhw5uItQGz1m40I/lg1NkV56qU2/x6DF7d7NeN9+etx6mk1fAL6UTvwA9wEtQt uiwTUht1L6p3hc0TnWHtV0nU6C8XgAkzuem+09Tx12oKUzH+bEbbaWL5ld60OoaQyHhj dyhXT9lQfmagq7dcXJDhxMAVZ8AYehTwKrRNrDb6gKkMDqI2uMxCWKVsWUQKI54V/hWl HJWmnGpztC9t3F4GKSWDfNBylXY9b3bI4eyl/+JqijCAMZhgCNSnX1BJn+iEI++sp7Xw s84f5SueziEl5rzHmIP/etJb9RPNRnliUnMfkmPjKyUKGwOVCRqf3X9oZtPzLmAW6RQp uwbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721900105; x=1722504905; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=C9yOUnzDlzPd3C7+qAj+S0EJyMFKc+8zKUmimt6IWTY=; b=mggBZ0RN8IW4NfjqQzIPRuZbdyS/tRP7FlF7MWBOj6I2NY7kIup7XRkLJDYcJjpO8E TCVIAN3xEKwHoEFgHHLL2uF3hPqnes6ZdBRSf17nzh43dHlVLzNtzI2I9DuAQDb1Yq+9 kSnzsadzmgL0ueGnimNQrh7DUtGNw9h76eHUk21PQeWVVNR+ImJCA2xoNS8X+k9p2EvM CAxPbc4cMX3PI3IeRFzr4TQBTd1PgVWUMnPS6w1LvfwfOQwGKIwYmv5LgzVxWZjsB4EG rXdXPHJIJUgW7/GYNKcwaS7lX0NgKelfUHk++5MJr5JXJO09IcL/lkblwYTMVOA/Dth5 adVQ== X-Forwarded-Encrypted: i=1; AJvYcCXuJUY27WpKoNx1UYeQSRJ5i8UxZfktOXX1JPcqrFkV5t9eoqAdSayXNmQiy5TSCD+UczI129YzNBQlaLNcpRCBfVQ= X-Gm-Message-State: AOJu0YzAY66qbz/QD57tdbmXqxW367Vi550jqUi7oGRh0bdezPp+OpDr LnFjeA+C8A6JZk3hAooIiD7WJfCXA19RIBNoiRT/39WbovSMZ/Ha1LKAm00d78HiI1E5tcK1A/j vbHiSk0gA+uJHBmMu2dP414loFJI= X-Google-Smtp-Source: AGHT+IGFSkmHvph99nWdKLrDFzDlpZHGJpTz2ErGoL9sqk+PNUJlRz4I6GWG0kJGTUG6ZfxcTuDdzEe+k+Jc9faNN7c= X-Received: by 2002:a05:6122:2094:b0:4f5:d98:5ef2 with SMTP id 71dfb90a1353d-4f6ca2c36f7mr1240963e0c.4.1721900105141; Thu, 25 Jul 2024 02:35:05 -0700 (PDT) MIME-Version: 1.0 References: <20240725035318.471-1-hailong.liu@oppo.com> <20240725091703.tsjpgltwgu3jwy5e@oppo.com> In-Reply-To: <20240725091703.tsjpgltwgu3jwy5e@oppo.com> From: Barry Song <21cnbao@gmail.com> Date: Thu, 25 Jul 2024 21:34:52 +1200 Message-ID: Subject: Re: [RFC PATCH v2] mm/vmalloc: fix incorrect __vmap_pages_range_noflush() if vm_area_alloc_pages() from high order fallback to order0 To: Hailong Liu Cc: Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Vlastimil Babka , Michal Hocko , Baoquan He , Matthew Wilcox , "Tangquan . Zheng" , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 54nn9nayznxg7pyauxhke1mcj1xt3u1u X-Rspamd-Queue-Id: 2F1661C000D X-Rspamd-Server: rspam11 X-HE-Tag: 1721900105-808338 X-HE-Meta: U2FsdGVkX1/+iAQRXK8Nu2WKjDpweNSh6Ufuxsdf73cI2BYEP4Xig654Q02E4tRRT1oN4GcXFdyXFXFX9NFjxffLw1tF5PlsoPihAHnE3qUZFMeT2aWDAwZxdB+zS0/xGAvSBBQNGNoSOSBEnjaHc8ywLgS9eMMSmvoSIk8Kwmvo12KivqpriUrbFPCgWRg01sdaGKz6qqsIRxHZbsi7kXnUVGaQj6jRoST7jiTIyr0uqKB7Zg8hVwITEL2K8NoRVShqCgeKemMB1GKg/y3GNT94uTyZVa5TmHW0bvHxwW+KhMEkp5UfHp+LBTXDePMPYYbXv9QSb86oLFAh4xKBofG3YwJyAK6TvQvf397EYvucJHoHc41n0pXpnupGU+mY2MwaCYUrzs9oFe6lxUzDH2X0H6mnJhEIxdxALo6Ms/BXGQPj2lFH37327o+1rvwMTMqbVloTcQlxaSaVQ9wd2YbR8Xew8S02NGGryiYYf6SBBHoAfrhSy3pp4jeLKBH/3JwGDKXKveAyePZPzmulb4262A769aPg5TlrBXblIUp8VUFe6EtnyYKRprd3G4KcUYQPblZY8iMvtMTVrfSxbMQKV7Gnjsh8PCvw9d8ksdAj/Z6hJXq6e4vzhY/zT6ekhetK+a+f/KIrnTb7F73aGsl4LvkT9unZnJ19gjCQ9scNbqp61yji9nkDxL4tn/0DkyDiaxnAoU15Rt4U3U3/LYe4W+GddoRyKz7yLXMPHkCFpgEgbHNmoBZzEBkJxlOK1P+oKL2r13sbp2Nle1A3D9BQZw7eSstUgTSzQPziMRoFq0R+KX3TD1id96p3giiEXZK82GrJS5F7GEyRCZPaTrbMmQZkqc8IFDocnCadO7GHYgzxRFbzOG/zOx0khR1N4JP9bpc+VacLieIdJ05WsHsA2V0sFNLciNLf9aZljz7sr6Rb/i7IJcJtAc5xAy+AXLcbDzi65BL606/byfc cJarXIml XS2DtTf+R7kxpqasmo8yvjhx5hzJXaOJei2kOPIVU9dk9icXlnmkmt/WaubiVth9Nikk1BQJl9YJRWhs4Oh5HlZOfSyYmzt91pz92qzGwv1lDWfoh0UxQ8ItFz1MeX2jYkb3IoQck1jz5XHP2OyGhq/fTTldrbGECEZqDI7GJpyF3bPZPmBVLvKB73iq5A7PVf9B1UXXuF57waOOI5n6oHZ3cECOgravCXfZRntDeSX6534V+aPyfxsjZ7L4LvhChtHMsCK730GMGba9tZhcA2lZ8NDFYa6eJjajAoJIGbMxJ5AyDcictMOsr67e9Rb+Tzwkbu+IlNO6cviLAlpFSJ80zBJuLMwpN2RDPdj2VlowYtdZO1Iex1wrktiakJINvjeEscO2tzXkA2cIHbkGAHC91+D1qsW03hCaSEIG0DHWtBYfSn2vME7Od6quUd2OCan1bcYFLQ2b/jWM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000204, 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 Thu, Jul 25, 2024 at 9:17=E2=80=AFPM Hailong Liu = wrote: > > On Thu, 25. Jul 18:21, Barry Song wrote: > > On Thu, Jul 25, 2024 at 3:53=E2=80=AFPM wrote: > [snip] > > > > This is still incorrect because it undoes Michal's work. We also need t= o break > > the loop if (!nofail), which you're currently omitting. > > IIUC, the origin issue is to fix kvcalloc with __GFP_NOFAIL return NULL. > https://lore.kernel.org/all/ZAXynvdNqcI0f6Us@dhcp22.suse.cz/T/#u > if we disable huge flag in kmalloc_node, the issue will be fixed. No, this just bypasses kvmalloc and doesn't solve the underlying issue. Pro= blems can still be triggered by vmalloc_huge() even after the bypass. Once we reorganize vmap_huge to support the combination of PMD and PTE mapping, we should re-enable HUGE_VMAP for kvmalloc. I would consider dropping VM_ALLOW_HUGE_VMAP() for kvmalloc as an short-term "optimization" to save memory rather than a long-term fix. Th= is 'optimization' is only valid until we reorganize HUGE_VMAP in a way similar to THP. I mean, for a 2.1MB kvmalloc, we can map 2MB as PMD and 0.1 as PTE. > > > > To avoid reverting Michal's work, the simplest "fix" would be, > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index caf032f0bd69..0011ca30df1c 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -3775,7 +3775,7 @@ void *__vmalloc_node_range_noprof(unsigned long > > size, unsigned long align, > > return NULL; > > } > > > > - if (vmap_allow_huge && (vm_flags & VM_ALLOW_HUGE_VMAP)) { > > + if (vmap_allow_huge && (vm_flags & VM_ALLOW_HUGE_VMAP) & > > !(gfp_mask & __GFP_NOFAIL)) { > > unsigned long size_per_node; > > > > /* > > > > > > [1] https://lore.kernel.org/lkml/20240724182827.nlgdckimtg2gwns5@oppo= .com/ > > > 2.34.1 > > > > Thanks > > Barry > > -- > help you, help me, > Hailong.