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 5F7E8C433EF for ; Thu, 31 Mar 2022 03:53:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B64DA6B0074; Wed, 30 Mar 2022 23:53:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B12776B0075; Wed, 30 Mar 2022 23:53:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9DA3C8D0001; Wed, 30 Mar 2022 23:53:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0221.hostedemail.com [216.40.44.221]) by kanga.kvack.org (Postfix) with ESMTP id 8EEA26B0074 for ; Wed, 30 Mar 2022 23:53:28 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 440368249980 for ; Thu, 31 Mar 2022 03:53:28 +0000 (UTC) X-FDA: 79303311696.29.5404B31 Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by imf21.hostedemail.com (Postfix) with ESMTP id 845691C0004 for ; Thu, 31 Mar 2022 03:53:27 +0000 (UTC) Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-2e5e176e1b6so240565627b3.13 for ; Wed, 30 Mar 2022 20:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ak2t2jCNQu1M2/jAOYEZkhc3R1ocF5/1qJQ+3hjAnME=; b=tkvUPecqmQulNzBQqTFmi7Dei2Lz6Mn445nrLTgnye7JELzViZqpIsbrhlyTvAs+Dc O2PzcrgIEqVcpVDVfjoBCzrwz8cX6owQtgn4k6W0tHNglJN4AxjMI4S42ir904Ky4cYz h8wULYh2QFZ3as3p2woAyxMFzGQCOFFEEsBnQAM8d1aloqJodsljEyX78x1pTQqYRTrp k2dHlWyyTA+IYWWBvIymhVYCJxorN4SNj1SlOo3wDa71/kBxms27NThdj/CmV/nrhGaF nwZr/ZqIWMYjR/DW2zaK8s6hVwv9+iUUYlf4yoK3QkMztFkKtOTVhQ/LBO/KJC3rdAKn BlhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ak2t2jCNQu1M2/jAOYEZkhc3R1ocF5/1qJQ+3hjAnME=; b=Gtg+GTf3JIf/4BSK4OEgAcT8PL9+dm2qO/1XYRMvniR2l6Jblzt1DoCkW+rNiNfZqj YfZDs5QMAUqtX8aUzJsT9+ij8m8zgJdJJorPuCpLNjQwNB3IrmJQlN0cS2139gcLKVXY t44w/k/jqcEFzRBjDHei+l2AZCjHwkc5FfHSzl59epZQ62sb+5F3tGx0SiJnAO+7D5Zd ZqXsFRQ0MIxmeAgd4cCnle/Sowr5NY6mOeNg/JnM42KxiORPD7XnK0bKQE4KnxLPcq9C jqEgzxt2k/nkWSvoGWlvaldI9NOUNL/dXMuZ0D/pgLO1sTch75I6wL1KUp/BPjbYuT8a 34bQ== X-Gm-Message-State: AOAM533Uw4lc9nmvwf2TBFAfyLYGAUNKWMieTuawwH6hr0h+EwkFE0Xv Xwigm4Nln/APWmjbVrOvV155XjDkb2VMKHjFtJBRmA== X-Google-Smtp-Source: ABdhPJxHjh8wcw0AdvJ2RbvjPxEo4eKx9G8Z+IYtVJqziw69Fb+8Y8BoQ0j4XCRCr056HsXRwjqBvkq5wyqIZqUk8Dk= X-Received: by 2002:a0d:f685:0:b0:2e2:22e6:52d7 with SMTP id g127-20020a0df685000000b002e222e652d7mr3190538ywf.418.1648698806850; Wed, 30 Mar 2022 20:53:26 -0700 (PDT) MIME-Version: 1.0 References: <20220228122126.37293-1-songmuchun@bytedance.com> <20220228122126.37293-13-songmuchun@bytedance.com> <164869718565.25542.15818719940772238394@noble.neil.brown.name> In-Reply-To: <164869718565.25542.15818719940772238394@noble.neil.brown.name> From: Muchun Song Date: Thu, 31 Mar 2022 11:52:50 +0800 Message-ID: Subject: Re: [PATCH v6 12/16] mm: list_lru: replace linear array with xarray To: NeilBrown Cc: Matthew Wilcox , Andrew Morton , Johannes Weiner , Michal Hocko , Vladimir Davydov , Shakeel Butt , Roman Gushchin , Yang Shi , Alex Shi , Wei Yang , Dave Chinner , trond.myklebust@hammerspace.com, anna.schumaker@netapp.com, jaegeuk@kernel.org, chao@kernel.org, Kari Argillander , Vlastimil Babka , linux-fsdevel , LKML , Linux Memory Management List , linux-nfs@vger.kernel.org, Qi Zheng , Xiongchun duan , Fam Zheng , Muchun Song Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 845691C0004 X-Stat-Signature: wqwysqrn8zge1zxfpa7x4rp9wsdk5f3d X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=tkvUPecq; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf21.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com X-HE-Tag: 1648698807-562816 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 Thu, Mar 31, 2022 at 11:26 AM NeilBrown wrote: > > On Mon, 28 Feb 2022, Muchun Song wrote: > > If we run 10k containers in the system, the size of the > > list_lru_memcg->lrus can be ~96KB per list_lru. When we decrease the > > number containers, the size of the array will not be shrinked. It is > > not scalable. The xarray is a good choice for this case. We can save > > a lot of memory when there are tens of thousands continers in the > > system. If we use xarray, we also can remove the logic code of > > resizing array, which can simplify the code. > > > > Signed-off-by: Muchun Song > > Hi, > I've just tried some simple testing on NFS (xfstests generic/???) and > it reliably crashes in this code. > Specifically in list_lru_add(), list_lru_from_kmem() returns NULL, > which results in a NULL deref. > list_lru_from_kmem() returns NULL because an xa_load() returns NULL. Did you test with the patch [1]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ae085d7f9365de7da27ab5c0d16b12d51ea7fca9 > > The patch doesn't make any sense to me. It replaces an array of > structures with an xarray, which is an array of pointers. > It seems to assume that all the pointers in the array get magically > allocated to the required structures. I certainly cannot find when > the 'struct list_lru_node' structures get allocated. So xa_load() will > *always* return NULL in this code. struct list_lru_node is allocated via kmem_cache_alloc_lru(). > > I can provide more details of the failure stack if needed, but I doubt > that would be necessary. > If the above fix cannot fix your issue, would you mind providing the .config and stack trace? Thanks for your report.