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 9527CE8181E for ; Tue, 26 Sep 2023 05:22:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E7608D0028; Tue, 26 Sep 2023 01:22:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2968E8D0005; Tue, 26 Sep 2023 01:22:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 15EE68D0028; Tue, 26 Sep 2023 01:22:07 -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 EA1648D0005 for ; Tue, 26 Sep 2023 01:22:06 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9482440F42 for ; Tue, 26 Sep 2023 05:22:06 +0000 (UTC) X-FDA: 81277602252.03.605980E Received: from mailout4.samsung.com (mailout4.samsung.com [203.254.224.34]) by imf30.hostedemail.com (Postfix) with ESMTP id 1E55480006 for ; Tue, 26 Sep 2023 05:22:02 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=gla8zA8q; dmarc=pass (policy=none) header.from=samsung.com; spf=pass (imf30.hostedemail.com: domain of jason.sim@samsung.com designates 203.254.224.34 as permitted sender) smtp.mailfrom=jason.sim@samsung.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695705724; h=from:from:sender:sender:reply-to: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=Ae3csVniCNOtjKr88euFOzMx2vv3dPx0MYaEJq/LpAo=; b=PeMWk+6zLggxZ/zJSADO860YxpSuKj0Tba9ujwUTmf8EnT75YhogYxfwjUM7C5AUnH5l3g 8BNHo3pTzVcj49yjSlPmhZXqX3JQZT4B2hI9Rg91bR8OWlf55Fysb+L27yFL4j23fdNmti T9x13408wizmozpw4q7voZSk1DSzJqA= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=gla8zA8q; dmarc=pass (policy=none) header.from=samsung.com; spf=pass (imf30.hostedemail.com: domain of jason.sim@samsung.com designates 203.254.224.34 as permitted sender) smtp.mailfrom=jason.sim@samsung.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695705724; a=rsa-sha256; cv=none; b=7rjjK8sYyxgVMAd1LMGhCyu5auIr9NwJirU1g9FMXnhnX/tsuchNB0iRnxT20MlldM+ica P1aSVmBPNki+Oj79XbvmmDhsZ++jaLwcIIRlr5IQUaAAn7xfAHGP48HfZaPUJkehvzddSx AEVfizHTogvWhC/K2EHJ2agRyWKTrgk= Received: from epcas1p2.samsung.com (unknown [182.195.41.46]) by mailout4.samsung.com (KnoxPortal) with ESMTP id 20230926052159epoutp0429adc6a7dc90500bd44af6c3b70e8e09~IW14d-qEG2285522855epoutp04N for ; Tue, 26 Sep 2023 05:21:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout4.samsung.com 20230926052159epoutp0429adc6a7dc90500bd44af6c3b70e8e09~IW14d-qEG2285522855epoutp04N DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1695705719; bh=Ae3csVniCNOtjKr88euFOzMx2vv3dPx0MYaEJq/LpAo=; h=Subject:Reply-To:From:To:CC:In-Reply-To:Date:References:From; b=gla8zA8qMvNF7CHu8mcgO4vFftD0Vi7RQ+2UHWCmD5bnTuZ+uUTewPFTlObaSnMgZ qkvIn9Tu7NkyvvikbFysgUpWOm/2+Hrs93YgF8SwAK60dGHA8yqM2gAc1/XPR27MJh B4NfiL7SEb91kTtkcNJguxhXXCcq2sDEsW1apRUU= Received: from epsnrtp2.localdomain (unknown [182.195.42.163]) by epcas1p2.samsung.com (KnoxPortal) with ESMTP id 20230926052158epcas1p2f56142adfac6451bad63f56b67d5d326~IW134ulon1275612756epcas1p2-; Tue, 26 Sep 2023 05:21:58 +0000 (GMT) Received: from epsmges1p4.samsung.com (unknown [182.195.36.222]) by epsnrtp2.localdomain (Postfix) with ESMTP id 4Rvp5L33snz4x9Px; Tue, 26 Sep 2023 05:21:58 +0000 (GMT) X-AuditID: b6c32a38-28bff700000027b3-cb-65126a76827a Received: from epcas1p2.samsung.com ( [182.195.41.46]) by epsmges1p4.samsung.com (Symantec Messaging Gateway) with SMTP id A3.ED.10163.67A62156; Tue, 26 Sep 2023 14:21:58 +0900 (KST) Mime-Version: 1.0 Subject: Re: [PATCH] mm/vmalloc: Remove WARN_ON_ONCE related to adjust_va_to_fit_type Reply-To: jason.sim@samsung.com From: Jaeseon Sim To: Uladzislau Rezki CC: "bhe@redhat.com" , "akpm@linux-foundation.org" , "hch@infradead.org" , "lstoakes@gmail.com" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Jaewon Kim X-Priority: 3 X-Content-Kind-Code: NORMAL In-Reply-To: X-Drm-Type: N,general X-Msg-Generator: Mail X-Msg-Type: PERSONAL X-Reply-Demand: N Message-ID: <20230926052158epcms1p7fd7f3e3f523e5209977d3f5c62e85afa@epcms1p7> Date: Tue, 26 Sep 2023 14:21:58 +0900 X-CMS-MailID: 20230926052158epcms1p7fd7f3e3f523e5209977d3f5c62e85afa Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Sendblock-Type: SVC_REQ_APPROVE CMS-TYPE: 101P X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIJsWRmVeSWpSXmKPExsWy7bCmnm5ZllCqwb6HYhZz1q9hszj/4Beb xekJi5gset+/YrK4vGsOm8W9Nf9ZLe58m8dusfoiiwOHx85Zd9k9Nq/Q8tj0aRK7x4kZv1k8 3u+7yubRt2UVo8fnTXIB7FHZNhmpiSmpRQqpecn5KZl56bZK3sHxzvGmZgaGuoaWFuZKCnmJ uam2Si4+AbpumTlANykplCXmlAKFAhKLi5X07WyK8ktLUhUy8otLbJVSC1JyCswK9IoTc4tL 89L18lJLrAwNDIxMgQoTsjNm3f7BXrBRuWLCrvPsDYxnpboYOTkkBEwkZl67yNTFyMUhJLCD UeL/3h4gh4ODV0BQ4u8OYRBTWCBcYuOecpByIQF5ibNbGhhBbGEBbYlTKy8yg9hsApoSXRe2 sIPYIgLqEg8f/GQGGckscJpJonPfdmaIXbwSM9qfskDY0hLbl29lBJnPKaAqcW5rMURYVOLm 6rfsMPb7Y/MZIWwRidZ7Z6HGCEo8+LkbKi4lcaZtCdTIYon1a64zQdg1Ekef7IeKm0s0vF3J BmLzCvhKvPvcxQaylgVo7dHN5RAlLhLHD50DK2EGenH72znMICXMQG+t36UPUaIosfP3XEaI Ej6Jd197WGGe2jHvCdRWZYmP3y6APSUhICkxYZc5RNhDYufTlayQMN7FJNE68zrzBEaFWYhg noVk8SyExQsYmVcxiqUWFOempxYbFpjAYzY5P3cTIzhtalnsYJz79oPeIUYmDsZDjBIczEoi vL+e8aUK8aYkVlalFuXHF5XmpBYfYjQF+ngis5Rocj4wceeVxBuaWBqYmBmZWBhbGpspifMe e9WbIiSQnliSmp2aWpBaBNPHxMEp1cBk5HV700OtFQUV2a5dmWrFf/R39TDP2Lq+0OhT4M3D pi+e8/Z4m1g89ruzcf2hYiWPRJFH6rGzp8+wrpz1gj32oekv5UdbNb6tLw+bKx49k3PprRfG niy+2UzCe597Tuko95zKrWdSNueG04b0C16r69pSbTOWc+tIKAYrN7WpaDies99zUzkmblNB feWjn4faV3s9zlrkObtct+t82vLaypNr8ng5Pa+lPP7auXOHjsCxGJ6U5iMMurskV2WteCXI Pr8u9enPUHvz+h6hW5GPyh79TBCd8DNJat2fW4XWVza/vHVBepNYTsym+KKuyokeXQdzmNsP Op1eFrpw13ym4/delP37antkxoeg+3eVWIozEg21mIuKEwGO5+evJAQAAA== DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20230922061715epcms1p7cd5a37f4bba0abf4bc159b844bd8ee65 References: <20230922062704epcms1p1722f24d4489a0435b339ce21db754ded@epcms1p1> <20230925105154epcms1p782c335c2355f39a9b583489c56e972f6@epcms1p7> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 1E55480006 X-Stat-Signature: rborh1homdghbqemwatnyh5e1338on46 X-Rspam-User: X-HE-Tag: 1695705722-934453 X-HE-Meta: U2FsdGVkX18Zng6I3yfjLBWfTGWAeuwFLwsz3BJbCTtRqUSZ6JGNzePQFQXe0SLzOchmXRPTpPO/ezIA/2I6u9HPF8eulucoagD3AN2e2Qb7u6mcsw97Dn3E4T4W9CBSbX9xweatAoJ1Z/s/gda/63QIDipOZoya/vsfOfRs4hLrzbM9kKYSE0GJ9ptMEU62o0ZbY5TMUtRxa14zo/4OY8usX2+h4uZ90MVUmcVloUY/vB60BruHlGWPkcOhJxRzoNDxl0aNLKlbEetgKcxaZWOOx8BU4JKi1u3OLTvHo8xJh60eEMZdq1MYF/MJ07lKNVsELNGjWbmpbcoL1F5t4i0vkCXQbnlU6gTF3HriIDIT15CqdgzEoJS6Cm2IxRrs1ZPZWY/xVlm6HtoLoO4+khAP2xn129HhbZDklgmWWhML85VeSRU7/g0QcC68RJKrz+nOTB7Nc2OYmYWfRpUtrEpq3YUbzR+nyetT28CnLhHtE/TJApFuduW/aBLAc+R74G6C3x3sxkYBqs30ENiSMzFibQtrRbl1IcIPCCwZrtyXOG8BHw8jaSpVb+WxWz0EYi/XpVtLwxUDBQz5UA/CsN/Ao9gMnUCyDyCj/CxhXmIW7UIB9iXHPiSF9m7au2dEUhr865MGUK6iiELu3TVHXTaHhZLo8/ox5NsOnpeHoS/h3nnUqBuGcTv+7MC42ZIXGCvipO8cxttJgAqFqcjddedRL1XtL/sWHmWfcfUISlLHTmNjzgvQ/tmQJJt7NBZZqzg412haNR+yFDOYS1+DvFEATpZBn30kkzUlXcgcc0hgdsmbO8/lXFAlpbp7OMzcyeDGmqFvlN1pZNT12sAFivC1Z3P25N8evJsQzPqgd/U147zPZ+o5mTajN+utv8ehsKpt1NRt2xjazHDkfoJuvYjFZnLjYszNFFm2AbxFekqInh1Z6nY3bdIW0eLzywwwP5BykOfnPAJUG/gXB2i xW3CI9TO Aq0+6aN4izeoN3QEgf1uBOdaFIiTp28p9Yks4L7HT4Tgo+iuc6NEb8Mu596GKLIwsCVf7YsxOYkJhHTL8h1/vR3iD+wgQgav+aScomOu+4i4ZTFOenRVss7kTjvie40n7ZIZVTwCQWGhuh6Aw63JaErnVEc2ejLheXGJg5805ravwudXyRGDXXne62DQzclb1BZTA1B7WoIul/RxNuKTJpJerTwiKud/v62cxKqVz53Q3nm55sHDCE5L9EA3rGCSUcpX2Yznlu0tEQ0WVDOZT1CuadFM+iaw3MMxDrToRzwxM46Thv4wGDAWCYQ== 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 Mon, Sep 25, 2023 at 07:51:54PM +0900, Jaeseon Sim wrote: > > > On 09/22/23 at 05:34pm, Baoquan He wrote: > > > > Hi Jaeseon, > > Hello Baoquan, > > > > > > > > On 09/22/23 at 03:27pm, Jaeseon Sim wrote: > > > > > There's panic issue as follows when do alloc_vmap_area: > > > > > > > > > > Kernel panic - not syncing: kernel: panic_on_warn set ... > > > > > > > > > > page allocation failure: order:0, mode:0x800(GFP_NOWAIT) > > > > > Call Trace: > > > > > warn_alloc+0xf4/0x190 > > > > > __alloc_pages_slowpath+0xe0c/0xffc > > > > > __alloc_pages+0x250/0x2d0 > > > > > new_slab+0x17c/0x4e0 > > > > > ___slab_alloc+0x4e4/0x8a8 > > > > > __slab_alloc+0x34/0x6c > > > > > kmem_cache_alloc+0x20c/0x2f0 > > > > > adjust_va_to_fit_type > > > > > __alloc_vmap_area > > > > > alloc_vmap_area+0x298/0x7fc > > > > > __get_vm_area_node+0x10c/0x1b4 > > > > > __vmalloc_node_range+0x19c/0x7c0 > > > > To Uladzislau, > > Sorry. The path is as below. > > > > Call trace: > > alloc_vmap_area+0x298/0x7fc > > __get_vm_area_node+0x10c/0x1b4 > > __vmalloc_node_range+0x19c/0x7c0 > > dup_task_struct+0x1b8/0x3b0 > > copy_process+0x170/0xc40 > > > > > > > > > > > > Commit 1b23ff80b399 ("mm/vmalloc: invoke classify_va_fit_type() in > > > > > adjust_va_to_fit_type()") moved classify_va_fit_type() into > > > > > adjust_va_to_fit_type() and used WARN_ON_ONCE() to handle return > > > > > value of adjust_va_to_fit_type(), just as classify_va_fit_type() > > > > > was handled. > > > > > > > > I don't get what you are fixing. In commit 1b23ff80b399, we have > > > ~~ s/In/Before/, typo > > > > "if (WARN_ON_ONCE(type == NOTHING_FIT))", it's the same as the current > > > > code. You set panic_on_warn, it will panic in old code before commit > > > > 1b23ff80b399. Isn't it an expected behaviour? > > There is a call path which didn't panic in old code, but does on the current. > > > > static __always_inline int adjust_va_to_fit_type() > > > > } else if (type == NE_FIT_TYPE) { > > lva = kmem_cache_alloc(vmap_area_cachep, GFP_NOWAIT); > > if (!lva) > > return -1; > > > > > 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. Thanks! Jaeseon > > > 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. > > Thanks! > > -- > Uladzislau Rezki