Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp6115526rwd; Mon, 5 Jun 2023 13:17:40 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6AhiADYrpJRRGaEVek8j4pslU5beTGjWNaxS98gCEOAK96tN8Bwn4LE4EC4AtOAmhOh8yz X-Received: by 2002:ac8:5b53:0:b0:3f8:496:a601 with SMTP id n19-20020ac85b53000000b003f80496a601mr9687437qtw.3.1685996260503; Mon, 05 Jun 2023 13:17:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685996260; cv=none; d=google.com; s=arc-20160816; b=cqZHwTUgojCyyUVYk1jiQWUT+Uyx9x9KZ2amUt9oMSSHwym9kffkegYD1U5XyNVB+B YwePA0yrUtlpEVdbR7uQHPDXkVYbvUqNSMXRLfC3ASt1hFAP4R1vQauM2GWcKfQBCxIL ZczT3i7xmMRFxDpO0a7ckZIWwZnkCa5dQK7D2KWPUZH+fAOcCULoy1tdIhBxB3+HxEbm JBXg1F09y9AGlI8SBpNCXyv3I2/V3WRioK9u3Aeej/rZnrF3HjpN5OnoDtHkYKZRiNp0 6Jt7Reb/DniySboXl3Dxj4UGbzSsLNN2kDuPLeLNKMWaCtYlYl9cQtY3IoUXoYCSCv29 0eqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=I03V9LL6wy3VgyRgg/zC0hcUQtAfkY257wxzzkjPoYM=; b=a/0eu7YR1fCYjaXfdLxbTqzfnc7H3qGxuOr3+Wqk9aSgybGTXDCy8ep4cyj9xEliD3 sicmbpMs7I/eoNiqbFoZ4Dbl4kv3YVcTDty5F/X4QDExIB4CuPOuQct/Qzh+d+MxUZBj oWMcaYF+BxQYcfz/Ytk5+MSskBGo/EwsjEOxDOWVwBtwB1ytpLxlTZLOH8w334zvI2HY EWfdloiEibKo7V3xSUITHWfU/GjX0HPCRid0QrFoXXn32ZeIbYxpO8CG17bdNhYfSl2G lAzjbUkov44JoJCLaoeMA8HW0fs5qgLmDy45FfLIbl3hU+5WzDRsU5nRSy28t3fNtGqH Z5Ug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=SgFJczam; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i13-20020ac85c0d000000b003eb143c58aasi5216139qti.600.2023.06.05.13.17.26; Mon, 05 Jun 2023 13:17:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=SgFJczam; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229927AbjFEULS (ORCPT + 99 others); Mon, 5 Jun 2023 16:11:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231319AbjFEULQ (ORCPT ); Mon, 5 Jun 2023 16:11:16 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D463699 for ; Mon, 5 Jun 2023 13:11:15 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-30aef0b8837so4374496f8f.1 for ; Mon, 05 Jun 2023 13:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685995874; x=1688587874; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=I03V9LL6wy3VgyRgg/zC0hcUQtAfkY257wxzzkjPoYM=; b=SgFJczamY7iJrnDAAUuSVGa6BF0kI4cEDyzxvkh92/wCJTbBVZ7lEMkoZG+0WOp3wG X98QrAaTnw/JQ/azOsxIcOG+/MQqf4XGvyHjuzmp7uoIGqlOpfABtUrIdpiSh9vQhklZ WpQIYQpSQVDFj8WKJsZ23n45sLWiByIHKLDKSctcNjHoPjmXWXYiBtYfksgqKBVJJIsg IKNsPKu/U8xH++ONujyhcU5xkyHL1Wxq1aEv+IvtxoOwGq99qFjYWUWrmhTS3zUCezy1 6B/Qwdvjt8Yu9mZmwWBSCpnKRFEbBxkzHcbp841/vCQ5vFpfTgnCgTyzPz/UhEvx0Jid Regw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685995874; x=1688587874; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=I03V9LL6wy3VgyRgg/zC0hcUQtAfkY257wxzzkjPoYM=; b=VNj1mpNxunQqcfwh6eDp5q8obcttdVH8wabNNzKAsJyJRwOU+T+LBpIZP2r3TyUNJR s67e0llwkSXMuhkXazHrZQXgnGSeYv7pHnbTR3cT3M8gKsc4Vv9httrajlCeuEyNkQwa vRmtRj3jCHVIYiGN68s4jG9GP6bLHyOjnZlmooa2IzfRZ1pJWedqAeIVZpx1C3p1rOZV JbSqFNkoi42GnnJOg9pjt/deZmZzNiYM6NfpSKdd6nalNjqbTlArLSjKGhjr0eVNegBR e5ihoxm9rm04EM/a3KaykMbjzTRA2YQIPDRbq17V1FWbo/mHQznh+mndMDUnG96FbowL 171Q== X-Gm-Message-State: AC+VfDytK0E9jkg0rCyafrLaq+WrvKlnTji+iZeq7LHHkKVTwVdRdyqR hDqS9DMVkdetobzJKTZJfIA= X-Received: by 2002:a5d:668c:0:b0:30d:5071:b033 with SMTP id l12-20020a5d668c000000b0030d5071b033mr16438wru.31.1685995873994; Mon, 05 Jun 2023 13:11:13 -0700 (PDT) Received: from lucifer.home ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.googlemail.com with ESMTPSA id h7-20020adff4c7000000b002f28de9f73bsm10539756wrp.55.2023.06.05.13.11.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jun 2023 13:11:12 -0700 (PDT) From: Lorenzo Stoakes To: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton Cc: Baoquan He , Uladzislau Rezki , Christoph Hellwig , Vlastimil Babka , Lorenzo Stoakes Subject: [PATCH] mm/vmalloc: do not output a spurious warning when huge vmalloc() fails Date: Mon, 5 Jun 2023 21:11:07 +0100 Message-Id: <20230605201107.83298-1-lstoakes@gmail.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In __vmalloc_area_node() we always warn_alloc() when an allocation performed by vm_area_alloc_pages() fails unless it was due to a pending fatal signal. However, huge page allocations instigated either by vmalloc_huge() or __vmalloc_node_range() (or a caller that invokes this like kvmalloc() or kvmalloc_node()) always falls back to order-0 allocations if the huge page allocation fails. This renders the warning useless and noisy, especially as all callers appear to be aware that this may fallback. This has already resulted in at least one bug report from a user who was confused by this (see link). Therefore, simply update the code to only output this warning for order-0 pages when no fatal signal is pending. Link: https://bugzilla.suse.com/show_bug.cgi?id=1211410 Signed-off-by: Lorenzo Stoakes --- mm/vmalloc.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index ab606a80f475..e563f40ad379 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -3149,11 +3149,20 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, * allocation request, free them via vfree() if any. */ if (area->nr_pages != nr_small_pages) { - /* vm_area_alloc_pages() can also fail due to a fatal signal */ - if (!fatal_signal_pending(current)) + /* + * vm_area_alloc_pages() can fail due to insufficient memory but + * also:- + * + * - a pending fatal signal + * - insufficient huge page-order pages + * + * Since we always retry allocations at order-0 in the huge page + * case a warning for either is spurious. + */ + if (!fatal_signal_pending(current) && page_order == 0) warn_alloc(gfp_mask, NULL, - "vmalloc error: size %lu, page order %u, failed to allocate pages", - area->nr_pages * PAGE_SIZE, page_order); + "vmalloc error: size %lu, failed to allocate pages", + area->nr_pages * PAGE_SIZE); goto fail; } -- 2.40.1