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 27AE7C83F09 for ; Tue, 8 Jul 2025 15:47:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD1C86B0096; Tue, 8 Jul 2025 11:47:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B82C86B0098; Tue, 8 Jul 2025 11:47:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABFB56B0099; Tue, 8 Jul 2025 11:47:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9A2F56B0096 for ; Tue, 8 Jul 2025 11:47:27 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 4F856BA8FD for ; Tue, 8 Jul 2025 15:47:27 +0000 (UTC) X-FDA: 83641526934.29.AAFDBB8 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by imf10.hostedemail.com (Postfix) with ESMTP id 67CA7C000C for ; Tue, 8 Jul 2025 15:47:25 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=NbDUfJrA; spf=pass (imf10.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751989645; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KDL7RR2TbvEX2mJHggUryr42QulPV6Bkphf4Js6vNb4=; b=N8SLeBaXOMhz754/MAEcLE1+TwCq5BE0W7G9EGSMiyaD4/CNYysstG/82sF9Y9BBCM6ZgA LRZFXyryXNZCmxF9QfFpgjyclVFd5bp9tWRLNHVA4xI808opgOm/Pmg9uYyauh5DPbeuAL 9y13ELbG+zOJWcQ+8qe/s3I+2j5mnFc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751989645; a=rsa-sha256; cv=none; b=2DfoE9wYYutmqhYOW4XErfogDyeVvxTwvusKXH3H6N0vU3d426SBkb9GNOo+QzWkAHeNEa XYcfcmEUxcP7Zev+eWokdBvhHKYOb1GTBvS/mpH2c2pd/m5zRIaY3muYwn6WGD9KQNc4i6 q2hLG6Z9Tzr1fCFydAUODKBcvMVfy2U= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=NbDUfJrA; spf=pass (imf10.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-450cfb790f7so34853655e9.0 for ; Tue, 08 Jul 2025 08:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1751989644; x=1752594444; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=KDL7RR2TbvEX2mJHggUryr42QulPV6Bkphf4Js6vNb4=; b=NbDUfJrAXaTJIqvfhZK16Tuo26h6Jy4eYMm6aD2H0+0iDoemypJ7skxD1fvEpyekIQ DSC4aH/tAIEHvt1MKQBSZH/1AbUkg7hrbC7JCdLNjwCbyH96EbuV/QDYzPvKqZ5QrSI2 hVg4j7XaVZ4ns0td5Cyye5Cidg0kWI7vpvT6bkhLRcXZi9vNKvMKEEoV70B1H+B4YIly PMM4nGw4nQyXpABDYonj3h186dGDl1HJZoN6e/BSO80kQVc/PbPL/LGY3X+rL8/8PH15 hL4xYmSyOjHJ/ZlmRJs4Nv6j9s/TpB3HUXwrmTQogIXjn2GtCd4H8HIKYA4WC0Sc2Zg/ rChg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751989644; x=1752594444; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KDL7RR2TbvEX2mJHggUryr42QulPV6Bkphf4Js6vNb4=; b=qJ0citttsQo7XSgZ2Ca/7x2kiTrvz8yj7aw7j0AXPzmfYRe+61UwwboFW5eaTVpdZf av7Meao+YcTlQvKJlqgwBaxebkSm3oYHUnn9Qaf8qY+LR0iE2e0UL1xTn/Yt0Sub/UAd KsC4W1mIk1X2RvjI6u77pcXcqtyp6LIrFKohW/Vz5E3gXRS+QRrqvs9yDgd+inHIczVw yU65BvQFbqhWAJRCbH1i07gLWo6/ZzqeOQJItRTNpAXFEsNI0xrngpHRngMIlPTQqSsc 3ag0wqofhz0+UD5AkwG3d23saj/GZg67LKXo3UU75Bf707v2kX/CX+U9MCn/65Ezp2J1 V8jw== X-Gm-Message-State: AOJu0Yz03cQijudLjxrW98Xd0ww5Ebp173uSdJDE+vUTv53jNpFwWxt7 xkgq/rho+fIqVVJw03y2GNzBRnk+jHWJ9EzfYc/gnBziU34uVJSir5QxjvkFKBEc6tBLQ4PWgsT itNmmdG8= X-Gm-Gg: ASbGnctZO5ezW2rgpbG9H6zF4THgbQTDVoAXQcpxOKsjz/A/xLrY8KlF0y7u6KGXs8A pFvRBrZY9RjvY/iK82Ulx8vgMl2cDtJCzJtZTk9sD+cEVL0yDVRmC4KA5yMTixWKk16agoUpqpq SpIaedRYTy79KcXZjloLSH1MJXjToNJfS4YdSWdt57AjEHRys/av/5sd5jVlKFmHHeVukCF9lHt 6/+CJtPN/+WebTA4AQ1ymHfvHG6F3RvNkRbApnWNSgXDEJcJDlzT9Foq3oMnUkgU1+H8t2thdDT 7no5cN6thI3s5jKvMPQ9aehW91W7gpXgcRD2ljOTxsDBJjytyJfIkUIPn4yChSvU2NsIFTHSYaE = X-Google-Smtp-Source: AGHT+IHX8KpFEImVvtc79+YaRCiWXT+RTSp4DWGywBuxO2GfgOkMoYd7/TDZb/9ReafohN/p1bzf0g== X-Received: by 2002:a05:600c:3b84:b0:43c:fc04:6d35 with SMTP id 5b1f17b1804b1-454d3623459mr1627035e9.4.1751989643697; Tue, 08 Jul 2025 08:47:23 -0700 (PDT) Received: from localhost (109-81-17-167.rct.o2.cz. [109.81.17.167]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3b4708d0beesm13495616f8f.36.2025.07.08.08.47.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Jul 2025 08:47:23 -0700 (PDT) Date: Tue, 8 Jul 2025 17:47:21 +0200 From: Michal Hocko To: "Uladzislau Rezki (Sony)" Cc: linux-mm@kvack.org, Andrew Morton , LKML , Baoquan He Subject: Re: [RFC 6/7] mm/vmalloc: Support non-blocking GFP flags in __vmalloc_area_node() Message-ID: References: <20250704152537.55724-1-urezki@gmail.com> <20250704152537.55724-7-urezki@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250704152537.55724-7-urezki@gmail.com> X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 67CA7C000C X-Stat-Signature: z3uff5a51j9ka6bzuoerd5e3h3qad4ti X-HE-Tag: 1751989645-603364 X-HE-Meta: U2FsdGVkX18wRBbU0N8FU2ZUyUwJVHoJYMAjLECb3c0MLpzSTbKbXv8W7xcoA1SDOBUupqheLOHKwm4sy3BdD669LlXm0BUJ/btbeC9FS368meIUt80HmQUobvVyxTFauSUDUeX6uIAhR1sOhAbgE1XB3MDK8Db1EmjqlHyqSvCqRQ+2jnUc3vw5J8eCxU0MMx7y7GqsfsVtPzjSCXIw8FMetoTWXs3z+dIMGWRMovg0Vrqpd4lKOo71NvFZDnO4/xaecGCsDfoO6IGOzgLMjCMjfEKG7Xj2ogOnuqywfFDoUNC/KzlaJG6JOJlGV8U1Czyz3LFEN+tuNAehmGYZuUmM6Fox7Qj6C+npqaH5vw2JZddVd8GJBkdMtrnMXZ7SiLMcXwvTibtYfHxaj9KpxkIuyKkD+gI1z7JQkYCgYxqJoK6TwOKFtTwqQ32onrdUxzLNE1YyQOWU5EpL0sq9FeKCDg2dC8JIiVbAbfLYxKm+J/MNsBMEtbMhJwO+EaBAB0CfA8crYPopQozdgHDal6TGkiNxVmD7/6Vc6KVdNyQn6OzxPRDfWA2AA7Pihb+554/DZoMPBQFiqbiXPPt5AflqIMrfCa17feHoKFiw7Toj1zoK3PYKbeymfscTYflhn35GycHtt3xUccLFIJOHolKGVYfWuf7WDYY1GqrgW88jxZOrPNeANuJASWrTHXPEX/Otu3C7GVL2/xw3Cm88vyypDGbidR1pY0rVQfCp2BpwrLNJCipDHgU6VWoUoqSzpgB5X5zwJSkhzFOLjpxY+1Iij15PngknpdbNMfmqa0hVBIL+fBdBufQ7Je7sX+Nt3Y+FGUeSR1ezifu7yH/aFsp/Nz1Be/FleVZGZEke8wa5hAzsARNUlxfUWS2DBchkjCglV34lGL9lAml6wlrJwQK3MFF4DEy0TPHQtUJJyY13VrvI5N7/NNOxbAPy9V5rIXQU7ooz3rJhH5ft5xC hY+mKecP jKUx8LHMPTtjYXUZOjWHTGnjGHE3SUf6PdOw5C1CjFEeH9iE4OBnzoeuRFhcfFNOhifvFlbO1NyYU6viX+GDC84aBPrPsf6a8pOsYA8ibgWS0JyEytZ23o/k1uONQrlp2QEpERGL4irDkmDKBwlqgzvY4BpM7GO2x3UTxXUXkCww4wRNtGRlS33ttXTxyhqFxE7LryAxtJIwx7u01GG3QMuoaWCJtgaWrySeqoy5qpSwcQq6aT3D9H+yDEB5d9yuryslRnZ0kIBFLF1mJWaAcKMydoVTwjcBuO43fxJO/gYHSlI7ghP60qlL45YIHHf4CAv3UCLgMOnN1O5VylCoMq8oJSO2PmZkEOFyPktR+g69iVDn94Erwvtr9vdN01juXCRa+YVKJNpNlyNXA97GC9XpyHzZs8yHsVI4D 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 Fri 04-07-25 17:25:36, Uladzislau Rezki wrote: > This patch makes __vmalloc_area_node() to correctly handle non-blocking > allocation requests, such as GFP_ATOMIC and GFP_NOWAIT. Main changes: > > - nested_gfp flag follows the same non-blocking constraints > as the primary gfp_mask, ensuring consistency and avoiding > sleeping allocations in atomic contexts. > > - if blocking is not allowed, __GFP_NOFAIL is forcibly cleared > and warning is issued if it was set, since __GFP_NOFAIL is > incompatible with non-blocking contexts; > > - Add a __GFP_HIGHMEM to gfp_mask only for blocking requests > if there are no DMA constraints. > > - in non-blocking mode we use memalloc_noreclaim_save/restore() > to prevent reclaim related operations that may sleep while > setting up page tables or mapping pages. > > This is particularly important for page table allocations that > internally use GFP_PGTABLE_KERNEL, which may sleep unless such > scope restrictions are applied. For example: > > > #define GFP_PGTABLE_KERNEL (GFP_KERNEL | __GFP_ZERO) > > __pte_alloc_kernel() > pte_alloc_one_kernel(&init_mm); > pagetable_alloc_noprof(GFP_PGTABLE_KERNEL & ~__GFP_HIGHMEM, 0); > > > Signed-off-by: Uladzislau Rezki (Sony) > --- > mm/vmalloc.c | 30 +++++++++++++++++++++++++----- > 1 file changed, 25 insertions(+), 5 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 2eaff0575a9e..fe1699e01e02 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -3711,7 +3711,7 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, > pgprot_t prot, unsigned int page_shift, > int node) > { > - const gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO; > + gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO; > bool nofail = gfp_mask & __GFP_NOFAIL; > unsigned long addr = (unsigned long)area->addr; > unsigned long size = get_vm_area_size(area); > @@ -3719,12 +3719,28 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, > unsigned int nr_small_pages = size >> PAGE_SHIFT; > unsigned int page_order; > unsigned int flags; > + bool noblock; > int ret; > > array_size = (unsigned long)nr_small_pages * sizeof(struct page *); > + noblock = !gfpflags_allow_blocking(gfp_mask); > > - if (!(gfp_mask & (GFP_DMA | GFP_DMA32))) > - gfp_mask |= __GFP_HIGHMEM; > + if (noblock) { > + /* __GFP_NOFAIL is incompatible with non-blocking contexts. */ > + WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL); > + gfp_mask &= ~__GFP_NOFAIL; Btw. we already ignore GFP_NOFAIL for atomic allocations and warn about that at the page allocator level (__alloc_pages_slowpath) What we can do though is to add a pr_warn + dump_stack for request with size that would require (in the worst case) page tables allocation larger than a portion of min_free_kbytes (to scale with different memory sizes). That should be plenty for any reasonable non blocking vmalloc. We would have means to catch abusers in that way. -- Michal Hocko SUSE Labs