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 29AADE7E62E for ; Tue, 26 Sep 2023 12:35:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F3C06B01A0; Tue, 26 Sep 2023 08:35:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A3CD6B01A2; Tue, 26 Sep 2023 08:35:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56B956B01A3; Tue, 26 Sep 2023 08:35:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 420F96B01A0 for ; Tue, 26 Sep 2023 08:35:29 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C2BA01CA050 for ; Tue, 26 Sep 2023 12:35:28 +0000 (UTC) X-FDA: 81278694336.03.AAFDE7F Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf19.hostedemail.com (Postfix) with ESMTP id A51011A0017 for ; Tue, 26 Sep 2023 12:35:26 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=htG3MKkt; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695731726; 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=HKytEP9mjvDlE1ed/dW4EbuXyf3+xZ0haz2NXKtUfpU=; b=cKI1itEdVcTjH8Yje+OOXkKb9AZ53GKjW4q4/RJzZ/OXgS86SULw5o9uMnWv9hQnQEo8/L i3tftUdi6ee30wkqBER13sNXGEHijwPHb+s6A3zYg6WHE99rM8JIE27+sSfaHYhVfcz7pW JHldVLRNF8d3p51ls7MenzR0PMh7PHo= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=htG3MKkt; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695731726; a=rsa-sha256; cv=none; b=xQ+8oAe0qBs3SNFqcwoe1UdPQ8SbNmgN6xazD091A0GDvbLOfBJAMUglGDJu+53s9lEnks pBez3NG89ajilE+om741dNQi1MWM26EKsNVTIkS1lokkNl38kT8H9C7WuPWOKEm06cjrqO EXIeMLWMX3QMacg0MKBEbDiMWGVvPiU= Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-503056c8195so14494823e87.1 for ; Tue, 26 Sep 2023 05:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695731725; x=1696336525; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=HKytEP9mjvDlE1ed/dW4EbuXyf3+xZ0haz2NXKtUfpU=; b=htG3MKktXYrDBnOdRcFzqSvdGq24FbUWV7KWj2XA+6lRS9LptxY3ULZPlK7a8Z8QPx mDSXpaKoYIddksmfqi6o0C8AR+NVPSMyPetpA8gy6SbqhKlDfL0N7E5r0NrrwXXHxtOp e3nNcJaV01TxUgztkBsrcXWzoDpCdFlJym3aRBePI4u/Eoohy/PzneR/fcwSShy/PAM+ EfJ1lp3xU7JUi6zGhuDlS4HnO6pfkCgGpQdypj6kTXOzjBqdsSiXTnyVZV38U7l5Fp51 1J2R6d9gM2jxrveh4NF2LuoSBSGkPa8i7zfl/JJrYtSaMYREj6ksIetFHM5tSq8Uhx95 Wznw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695731725; x=1696336525; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HKytEP9mjvDlE1ed/dW4EbuXyf3+xZ0haz2NXKtUfpU=; b=NLNBX6U6mFmuezYu9PTKzUMSGeYq2Ik5DrE1S3HflcZ97ySvx91WVLrpCSo4BJM2O/ qkXVUo3Z9v5/s1qU1EAqZZsoKv63W9EezwRTiAe2MblHR00cxmgFTKITbXfAq69aAF7w xDd7voqYXLYSahn7iPxr7ENaDXBVMf3xeBYpKUhJwDbUAvQ7jgE8HGcoftVsWdAnUL8T X+Kfy0zOw74vt/7x3htnvjzOPzhEyCpg4ysv0cdzya7GzGhzuiZ9lkwqWI/1+3bfGKhZ bVEVmPqO2/SDcRxFS/KOir5dRB2VZbg1iM8+UhaAQt9+Xv+OvElKUNBN2MhbotROy44j 34Tg== X-Gm-Message-State: AOJu0Yz9ek9TPlouADP5X3L0E5x0GGpI4Y/7xeVaZwVszSVdCqD6950w IstSYoNBA5bYm0PPI6Lchg4= X-Google-Smtp-Source: AGHT+IGEFFN4pVSwp61qEtfdTWgJfugjKiyaj40HflNZcDPvJ1bwM7/5jpqeCT8IC7rE0kSvLozNZA== X-Received: by 2002:a19:674a:0:b0:4fb:8939:d95c with SMTP id e10-20020a19674a000000b004fb8939d95cmr7534378lfj.30.1695731724346; Tue, 26 Sep 2023 05:35:24 -0700 (PDT) Received: from pc636 (host-90-233-214-51.mobileonline.telia.com. [90.233.214.51]) by smtp.gmail.com with ESMTPSA id w21-20020ac24435000000b0050307304a80sm2210559lfl.205.2023.09.26.05.35.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Sep 2023 05:35:24 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 26 Sep 2023 14:35:21 +0200 To: Jaeseon Sim Cc: Uladzislau Rezki , "bhe@redhat.com" , "akpm@linux-foundation.org" , "hch@infradead.org" , "lstoakes@gmail.com" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Jaewon Kim Subject: Re: [PATCH] mm/vmalloc: Remove WARN_ON_ONCE related to adjust_va_to_fit_type Message-ID: References: <20230922062704epcms1p1722f24d4489a0435b339ce21db754ded@epcms1p1> <20230925105154epcms1p782c335c2355f39a9b583489c56e972f6@epcms1p7> <20230926052158epcms1p7fd7f3e3f523e5209977d3f5c62e85afa@epcms1p7> <20230926120549epcms1p4d41733c1c3698bd00eaa7e5ea0de041d@epcms1p4> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230926120549epcms1p4d41733c1c3698bd00eaa7e5ea0de041d@epcms1p4> X-Rspamd-Queue-Id: A51011A0017 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: ptmh6kraxw41aetk1xnyxdtwrrzoncgq X-HE-Tag: 1695731726-539738 X-HE-Meta: U2FsdGVkX18rEOaj2VvCyvp9pHb25u9RcVn5G4/1anCDfwF5XyiL6JOZ4t2Ek3Q6o4agL91OBarmjdfsdIwIt1dGitg5a9/vHFIB+REI8gSyHUAGkj5pDe1PhqE5ypMhN3ZXPb7VO0mEs79JEANmiItcOsGu0AWD68VfZ91MQFJlnl3Ez4Tx82yQaYPmY34kDHz4eiQl3c64i9MZO+QYL3uKsatuMbeLBx3XiprAi5A8DihWwsgUiMPZwxJVM46i0NN6q9jzYLLZnIBCnppRVQTt/jNNSdZhS6SWfdJsO7nQjdyg1fodBHoh6m7WzPQA7/128jY2qUIZ8ColTkVMvzkS5ygNhHvhvJzQhpLytveOnC385V+WK5RStB7d5Lq9lRhUvwqzI3J03ZL6Lnn+DJSBh41XDm4yplt83plP7ZHOeS0Y4VXLdzyBttMbKejkLwLk2a0SCnd6is4VT5cZTR3h6i0KVEvIOXziFieItRUSvtLuDwAWuaiIMT2XRbKoH2NRPHcnVQ7KddseiVJnaGT4b0X2Bj+8sQuedseBlkT87sYVop5R/T5oIC4WMrfjU1gBohFigCtdNwE70OKorX3jBOZN5VydXIkoK1yWSZx97j/0K37CAnkNXDIcgwHLHL24StEEw2CLIF983ERugNhA2hzhC10O6tJdM4WwO+QJ09bPM96RyW1W6qZvlmMADfjA5LryB/rfZV6C29mOnseO97dcSI2vO3rBA9+6ghV1/6BybiO6ethzAxMYRXeFgk3khTV+XemfUyFJX6y0NLYBg2k+1QGBX5Gkw6tjb3qOeG3rqbSpCA0UWVIgKEv+hy/FxpFkBDvfSpScAqYuw0xV8b2qFmRdp8eSZyUB2KshLNP9IXg7yAVJVKSP/IsQT5a4//VO9rBmEt9qCrPbcJNYtdPYH6DcWt753l5sU4XQKy61Ju9xYvgQOVGDbU0np45C3gFWXTpVyymo4io meSkR139 hshcAWGba4SCYh94CsTwAo3fa/MphgidLWKalI2nU0hySoyg234m/UsdhayooRKzViV+yJ2PIScctHsIzzPg4PnxBgmkzE/7nOL9HxIIWYhb6QO1wuaYSHBeqIOfs2O4zVTfYXeACK0G1wWPDcpCd9QE9bx42T+zCZ22pcvriTbKoMYQ9ba+3Rx+A7O29wuO3J6x2UAJmE4BxTZqlos8nNlov7MocyfFdONP3EkErRoSToOFh9aRlarq3lEOtqH8pL4Ow17uakjQ8SxBBFLtUzHgqSF9dFe01VsduQMK5uJoVNzso6v3LlBDYjpehoUj/IgGjUyOTiG4U9BzTmpH4hDsq3Ayjh5/n5wULyHKQtM809jg3Mmrop4VZsapK3EpYfJ3zRUL8LX8aJMKzCg0nNmfsMB+XImbl1+oJ20NLwi3E73Ijx8OhUuANF0UWjYPpfUNKGs99FhurfSihXvNnkk2Vt1Z4uuw/afWYMvK66vVwUhwen1OEeHpytwHlkXKKg6EuBDierHnOgfc= 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: On Tue, Sep 26, 2023 at 09:05:49PM +0900, Jaeseon Sim wrote: > > > > We do not have above code anymore: > > > Sorry, I tried to say it in a simplified way and it caused a misunderstanding. > > > > > > > > > static __always_inline int > > > adjust_va_to_fit_type(struct rb_root *root, struct list_head *head, > > > struct vmap_area *va, unsigned long nva_start_addr, > > > unsigned long size) > > > > > > } else if (type == NE_FIT_TYPE) { > > > /* > > > * Split no edge of fit VA. > > > * > > > * | | > > > * L V NVA V R > > > * |---|-------|---| > > > */ > > > lva = __this_cpu_xchg(ne_fit_preload_node, NULL); > > > if (unlikely(!lva)) { > > > /* > > > * For percpu allocator we do not do any pre-allocation > > > * and leave it as it is. The reason is it most likely > > > * never ends up with NE_FIT_TYPE splitting. In case of > > > * percpu allocations offsets and sizes are aligned to > > > * fixed align request, i.e. RE_FIT_TYPE and FL_FIT_TYPE > > > * are its main fitting cases. > > > * > > > * There are a few exceptions though, as an example it is > > > * a first allocation (early boot up) when we have "one" > > > * big free space that has to be split. > > > * > > > * Also we can hit this path in case of regular "vmap" > > > * allocations, if "this" current CPU was not preloaded. > > > * See the comment in alloc_vmap_area() why. If so, then > > > * GFP_NOWAIT is used instead to get an extra object for > > > * split purpose. That is rare and most time does not > > > * occur. > > > * > > > * What happens if an allocation gets failed. Basically, > > > * an "overflow" path is triggered to purge lazily freed > > > * areas to free some memory, then, the "retry" path is > > > * triggered to repeat one more time. See more details > > > * in alloc_vmap_area() function. > > > */ > > > lva = kmem_cache_alloc(vmap_area_cachep, GFP_NOWAIT); > > > if (!lva) > > > return -1; > > > } > > > > > > > > > Above allocation fail will meet WARN_ON_ONCE in the current kernel now. > > > Should It be handled by alloc_vmap_area()?, as you described in a comment. > > > > > WARN_ONCE_ONCE() is a warning and not a panic, though your kernel config > > considers it as a panic. Right, we go on retry path and we can remove > > Right, only in case panic_on_warn is enabled.. > > > the warning only for GFP_NOWAIT-alloc-error. From the other hand we > > should still have possibility to trigger a warning if an allocation > > is not successful: no vmap space or low memory condition, thus no > > physical memory. > > Yes, but GFP_NOWAIT-alloc-error can easily occur for low-memory device. > Agree. You are really in a low memory condition. We end up here only if pre-loading also has not succeeded, i.e. GFP_KERNEL also fails. But i agree with you, we should "improve the warning" because we drain and repeat. > How about changing fix as below?: > > > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -1468,6 +1468,7 @@ adjust_va_to_fit_type(struct rb_root *root, struct list_head *head, > */ > va->va_start = nva_start_addr + size; > } else { > + WARN_ON_ONCE(1); > return -1; > } > > @@ -1522,7 +1523,7 @@ __alloc_vmap_area(struct rb_root *root, struct list_head *head, > > /* Update the free vmap_area. */ > ret = adjust_va_to_fit_type(root, head, va, nva_start_addr, size); > - if (WARN_ON_ONCE(ret)) > + if (ret) > return vend; > > #if DEBUG_AUGMENT_LOWEST_MATCH_CHECK > @@ -4143,7 +4144,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets, > ret = adjust_va_to_fit_type(&free_vmap_area_root, > &free_vmap_area_list, > va, start, size); > - if (WARN_ON_ONCE(unlikely(ret))) > + if (unlikely(ret)) > /* It is a BUG(), but trigger recovery instead. */ > goto recovery; > > > It will WARN_ONCE_ONCE() only if classify_va_fit_type() is "(type == NOTHING_FIT)". > This is good but i think it should be improved further. We need to understand from the warning when no memory and when there is no a vmap space, so: - if NOTHING_FIT, we should WARN() for sure; - Second place in the pcpu_get_vm_area(), we do not use NE_FIT. Only in the begging after boot, but potentially we can trigger -ENOMEM and we should warn in this case. Otherwise you just hide it; - And last one if after repeating we still do not manage to allocate. -- Uladzislau Rezki