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 E0ACFE7D0C5 for ; Tue, 26 Sep 2023 06:06:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5C86A8D0018; Tue, 26 Sep 2023 02:06:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5788F8D0005; Tue, 26 Sep 2023 02:06:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 440D98D0018; Tue, 26 Sep 2023 02:06:01 -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 313B88D0005 for ; Tue, 26 Sep 2023 02:06:01 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E756B120FCF for ; Tue, 26 Sep 2023 06:06:00 +0000 (UTC) X-FDA: 81277712880.15.005385E Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by imf11.hostedemail.com (Postfix) with ESMTP id EF3404000E for ; Tue, 26 Sep 2023 06:05:58 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XAMzh87I; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.169 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=1695708359; 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=vgxlFDA/bxmUPsLJjc6g70eWQh+QzFKzh1Zln4PSV60=; b=Fos3PB8bcZs15Qb+HitIo8wSQwPTaq5fnTCSOj8KTe7jNnvAySnMw3vx1H/jD9BHNxPPu4 /wDA1Vc+sYy7UNfujRAr06Txb2402WYq3LjBVwiA0s1G3QlPOgm/1tr/zICUCdv7b32PCf IkO4ATtzOuQzAVH3rudmXj2P2AEU5Kc= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XAMzh87I; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695708359; a=rsa-sha256; cv=none; b=QmnHVAEZyEg9c1NfCgRW5GRj4GgYS7GrKuv4BGmQGZJInttpJ7dXvUt8hVo+TSs7i2NmBc 4PCDLP+ON4U0swI9YnN8f2g7YgLIP5xVfysl+6YmiF0gxg/a57dYOMIIZVyaSsKvu1hEpa Yi2jzrdvkUPW+rkMyo3dUQTJin5fGzE= Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2c16bc71e4cso33437371fa.0 for ; Mon, 25 Sep 2023 23:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695708357; x=1696313157; 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=vgxlFDA/bxmUPsLJjc6g70eWQh+QzFKzh1Zln4PSV60=; b=XAMzh87IhhvICZsj3nLV2kJMqRrBkVV1MdyaWSHgg3vHnKFeth1v1Xqz2qoy6xX5NP XJZvu/GS3y50J6jaLiFsHu39y7ETS4mEdXIXvxzI+73/aeqi6PGkov8OzUTpGiVvTkTI jed5J6zJEplJ1S1urIyVL2LMP7a466LhfJwdaqR763jRgr6Fb/LxiClOOhi+SVG+5mc6 zh4Ihp8vla1sEEYMqjnc59BVkrvvX3ibSQct5bDQPUDUfLYHDt4JIsTOroLTc800rO3H WBKIkTVairWgaA7uy5pnR1u5cBpTFzYDDl3qtyHMAwIhvOdG1iIlOEa/0no5JFWivFiA wTWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695708357; x=1696313157; 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=vgxlFDA/bxmUPsLJjc6g70eWQh+QzFKzh1Zln4PSV60=; b=KPVPm5fXtt19jpcGeF9fkWke6nWhi44lWo8ubOY0wIOAU54UN01CZDJwTZRgVq4uoQ ypjxbEvTZN9HACFQ6uTWzLpzh9z2p76S/HJDl4SQT+tkfMgwUxVpfTb7V5N90xLK2Fr8 W8bLeT9YGz8tAgFh7kQrp+ebVdIapef33E2PlyVehEYApqDKpobt6fd+sTdgPcLFUjLK 1aptcu9ItD10w1aKsOmJSHtkacL+rNULOppGCoB/83NsZp/eax9r/rcbQC8D1l1rybCH Z92iyr5rzXOomOr9on9RqXWlxhPtLwBu0YH9W5rw36A7i0bzqaWTgFRZ4rGq4zi9ncZj fiFA== X-Gm-Message-State: AOJu0YynYDaoowLQ9PQY+hNJq55VU1KEE/EuXNwvWVH9HNAmA8YmST7h RpoxcmIcOZML7bmR47rVqPg= X-Google-Smtp-Source: AGHT+IHYJRSkCqz+BcxPGgEWjVl/4ojbM6zIh2FG6lWZYKDBV1zfelKRAqeEmELB2VyZHlnWmgoeBw== X-Received: by 2002:a2e:9b42:0:b0:2be:54b4:ff87 with SMTP id o2-20020a2e9b42000000b002be54b4ff87mr7163447ljj.40.1695708356809; Mon, 25 Sep 2023 23:05:56 -0700 (PDT) Received: from pc636 ([155.137.26.201]) by smtp.gmail.com with ESMTPSA id a7-20020a05651c010700b002b6daa3fa2csm2426964ljb.69.2023.09.25.23.05.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 23:05:56 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 26 Sep 2023 08:05:54 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230926052158epcms1p7fd7f3e3f523e5209977d3f5c62e85afa@epcms1p7> X-Rspamd-Queue-Id: EF3404000E X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: fm7uurc4inmayzjaa4awxd65nbx4wxsm X-HE-Tag: 1695708358-569231 X-HE-Meta: U2FsdGVkX1+qnQCtlstOs2BtiklSlS9AEE3mXJZihCLgIem6Zqq0tUrsK2O1xEHMSOzQhraIJIiIDu9MirvhuzLKbquhrTHkJc7PWWJyLfeDAQqjXK+37RPTkX/tk3l34IMn5ygmU/K5snQdRcwpHhYNb8Ye3xP2yPxy2IEprP0949DKsnXOUEf7oWYWe3LD8n+q/Au7sCBAWcsyZDKbYtGgEiwOxOtviwtLgMiyAgffwFcz5EKO/K0OebkQliSfxrxonfxXWq+il+05/u/1BI99cJ737GPhlwRrXcz8BUiuwzUdsF/GcbwohSXIYfW1hfVIrBE58MQxY8Fr5DnSHnaFS5KsfWYNt9GNo7svPVpGYEeC7OLKut9nZVCbPMc/K02QHd368/vDTEnDpJN4buZHCkx/O7BEux4BfDhpexMn6C/4wk7HQlqs4UWkemjN3kNVZ1oz0AKuX7CpZIpXgpWir7bcO+eVdGK4D4JljK5bS7uDBzlp5V8r1j+HRGgeNZQqgo2Uqqy172xrgUMRYYqI9582uXpLeRnmEfXXLuVo05ATx4jtAKh9hZAaQJ2JWEkwC3c4Vnak0qcYswiYTX6Y4QMi4L2juJy9ThNJe725T3/nG7JFGZKWpXB6VI7WtoowvmXwmf/RKHagA+s45PC0cY7uicQeA6z0R1x/iFJysbzvn7i4illnmdwCSgmSZxyaHchN/49ixMwuQlT/6OeA+3r6efKTq114JUthJ3osW+Stnwx6WLkpmzhRVJekSO+zBJbsCcDUNPRUsilzC+HU9pOVtJGLTLeYY81J9LHm+77Xsds8TRO5Dv6cC4VqIt0qaZjTQ3uzXjjc82N4JUhcilYYSwPYKLJLp7EckcuhFNH+SzWcdIiRlrOiUbmF9Rt8WM9msGuKvwvk5/dSL+W8dVDmqfqOGRVQZDEpg2qzYOy69TvpGqGGR6bOPmetQXYBxkz/zRDjBIAW1Tg dkQaxnoe mip6b56zP5k+TaJE4fTBCDj17JKeScRwDRVh1ANfgdBo8EN+7Ubu8RLIhdmt4wYfhmqoy4288RQX6BbKNCBa/YnEyc1a0CAY/LRMlhZpVEAW2RhywurZo7oYCGMSinPAqo5IJwXxbazjotdVgmxjqXSx4KqtQBrRPactJMkG2rON/1Owc9N/HS09z7ZQTWvmvfSliyWVOHudGitEkd/m5DEvHgRA2mdLXQJ2nphkaMgR2aPoAMZ9+gKzTGCyxt6sU2CJ0ZJwHrPSVOk/ZO6g0RWYjueVEVq9H20Ti+/MR79MyACUFzA39I9+CGl0ZnWEIGAn4lScUyHujM0qX20hVfstaRC7sm+v/M1V+7aEi8xg8/B76Os1fMBK5e++CB84Jl9qq3Au37b3ayYG1mrmufBfPFpLlykaO1yeMtho7XwmrJupHzEjNgQdUfowdWqqEMdw9 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: > > 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 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. > > > > > > > commit 82dd23e84be3ead53b6d584d836f51852d1096e6 > > Author: Uladzislau Rezki (Sony) > > Date: Thu Jul 11 20:58:57 2019 -0700 > > > > mm/vmalloc.c: preload a CPU with one object for split purpose > > > > > > > > Which kernel are you testing? > > I'm currently testing v6.1. > The panic occurred during power on/off test. > Could you please describe in more detail your test sequence, setup and HW? -- Uladzislau Rezki