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 101EAC25B75 for ; Fri, 31 May 2024 09:56:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 751616B0082; Fri, 31 May 2024 05:56:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D7936B009A; Fri, 31 May 2024 05:56:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57A8A6B008A; Fri, 31 May 2024 05:56:11 -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 367F36B009A for ; Fri, 31 May 2024 05:56:11 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id DE67C1C2086 for ; Fri, 31 May 2024 09:56:10 +0000 (UTC) X-FDA: 82178235300.13.D6EB2F2 Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by imf13.hostedemail.com (Postfix) with ESMTP id 0842E20013 for ; Fri, 31 May 2024 09:56:08 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bAt9gchT; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717149369; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tKVx7XGBm+o8Fw6YnGhdz2zXhlTIlCI4yh9naXhDehg=; b=2Qy0o1jQIetyGEkN3W2PelBSXJmGxSAyDE9qXImTtPUM9eplD57T/er2bhy9IxrqGfdr5V Us1ynTwPo+i3GUnJil4HRcH89cxAVrwpERV1gQx/WXzjLZEmP4x8yZgV44gjJkL/xWxtDN Plf9GZBlfPkdXhyYctIqtUPePJw3TsQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717149369; a=rsa-sha256; cv=none; b=klbKXY3OW30kSOTgDJzwPXQgl6JZJjlnZxZLNktPbITGUc84rMEzLmtFQGpdXSpUmlT9M9 1mNYqwe4X1GsdYZgE4yBYTRUv69WPkW/JhwKWJm/tf1VDhLFueUR7RcAt+ZAa6XXVqb7be J3qKaI7lcCHT5MLz7vo9xbYsVgBAnoc= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bAt9gchT; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=21cnbao@gmail.com Received: by mail-vs1-f52.google.com with SMTP id ada2fe7eead31-48baea0acfdso481388137.0 for ; Fri, 31 May 2024 02:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717149368; x=1717754168; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tKVx7XGBm+o8Fw6YnGhdz2zXhlTIlCI4yh9naXhDehg=; b=bAt9gchTUnsD43RmJROpNqZcGXyJ8lxjWkEb0nWtRND/65XDpj3h1QwRDw+N6w7pq0 S34jGCOTDEXaVppz/MxObs+bip7yb19TffCPYst2iTKMuM/97cunzOfGkBLY48S2zWoS SwO5NrrekQHZlMkyHPBep/Cijnncsquxr00UlmVjFMKR0duOY6wOPPR2WvEerW4aS6k3 OUTOXhdFWFHiFwPH8NhxnR+gVu4tJdQEHgrGc4LZeQfTVGPYDuXnYiI3D9YUY4Izc+3G IiTEqQoD1pjJgHmn4THwq9gd7r+y10lki5/A6YHIQtF56Hzr71ItmEdsr0hIAb+7X97F MTfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717149368; x=1717754168; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tKVx7XGBm+o8Fw6YnGhdz2zXhlTIlCI4yh9naXhDehg=; b=TUlwlh8O+YUfpHGElj1iAZPohrG2EdB53FQX3C8CYa5sW1r0Wk+qGVZo4URb0J/m09 iv4xYkcdnoBK/6BcFQhfirKRnXr4FlxB51pndcFV6EnDbMkFNnnrTVfCUyoXPnRJQ9tS eyqC1jJipFe1vUICU12Oeo8tDRmBBmIcyWEIjSQtImt9fWBrwtmHzznORIjl3YYTEMTO +zRO7rPzHvcB0wn9K/1HeFdE9TbgH+K+CkxuStGCMORq9PJ3NDMryYpLnBWAHRcZefYM mBbJYSg54Tf3H+IlKhnzkWAcEWgpvSeslLYqy/yi/B5Pk9IXN6gS9WxuIJyWCZshJnXw 4Olw== X-Forwarded-Encrypted: i=1; AJvYcCVbl6fwa3WwG0hs5UbY+1TlgbxbrPCrqZV+NDRDWyYjt/jXbjY5VXuWJA4Q6MaqOjlpHtpg966u6SxWsuyN6E4/uVI= X-Gm-Message-State: AOJu0YxP+a74O7vwX02fEl/S/atbm0bzLBPtDFtriGA1UrOAlWW4LUAG BQQ08OaAYKfP1dg3qBc5fZD5XxakR9jU6UgGpc8AMdszIkGtDOQQKDKMKRWRkDEaU4ZG/9x2iBt /kGKl17lDYNzztcHis0qAB9CX+/8= X-Google-Smtp-Source: AGHT+IE7QADRzsDSKxZVcKYQmnfV+eZbaOv5G9hqVWSP9YXpgJiCW/5H7Z953Bi7OzB6+gQ7jiXAAbTT+R029c1AXVw= X-Received: by 2002:a05:6102:4c0b:b0:47b:bea0:bdf7 with SMTP id ada2fe7eead31-48bc234666cmr1446622137.27.1717149368007; Fri, 31 May 2024 02:56:08 -0700 (PDT) MIME-Version: 1.0 References: <20240531030520.1615833-1-zhaoyang.huang@unisoc.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 31 May 2024 21:55:55 +1200 Message-ID: Subject: Re: [PATCHv3] mm: fix incorrect vbq reference in purge_fragmented_block To: Zhaoyang Huang Cc: Uladzislau Rezki , "zhaoyang.huang" , Andrew Morton , Christoph Hellwig , Lorenzo Stoakes , Baoquan He , Thomas Gleixner , hailong liu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, steve.kang@unisoc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 9bnmiyc5js6aaw647hnztfco4yi9ii4m X-Rspamd-Queue-Id: 0842E20013 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1717149368-621266 X-HE-Meta: U2FsdGVkX1/s9UN4PT5ztrgLerGqQlXoWFJDg0ciTBlEil0ILf1q41CvmkBjdmlxdEtw/+CYjNo265K+JI6zDW2keqTW5U2HgYVpbbaYPDoCelMsKuS27DjK8Pkesmo8cZoH05pGKvg1WK8mm2byRuiWJXit1Q8qBn05KH3CJH3PmFSE6qlPxHwY+nzJIFD1eot6irM21XDUfysCPFukX2zHslt32ja/SD2HNqP32as1JXKxfg0jKyXdhzhjs5ywgnfYq0ROR99R+fZk/JIl0LHzMzKkDJUWvHqqEShIekQ85/av1wO+2z2szRXkZD+fywUWXdnuw3wFDjIrA3Kh8XNdJAXpCk+qZtr00LYDgn/d9rIqVwgJvrtqYAqMxghFj/vo9FdLKtr5iEc1w+bLS5kbx4CZwVK2l4TGwtLdrHHcZqRq4YccnLsDqI6HWjqwPgtj9uUbVxO7LFHKqlm1rKczH77Gq51g9+YLbQBSsK0vw1E8RLkEV/8y3OuAVxOK4x+GW9LSypcfLAd2pUw7B2zhE0GByM3XA9L8i7NkzOnBTTxfzSXlmSpGNd7+eravuw4dS1Fw6Nio9C+K2MUh/bPDct//JdSyCAvpz8ivKQSftCJj/bCP6Uw3Fecup3A0Xm8pFM6eREilN4Ne8RMXwg8e44yl3ToRuiTBea2EJky41lrbaeHDSLxhOKYizgqevlqZDw1I48E7ZidEymYeVil25PUhNOhH10djGx2D2GXSJ1D71uMGZrmKVzf257Wwrp5/zbGF+e/PXJKGXv2fi9TDGze/LEuJ+KdDjBlC2M1BQNeiGUAyP8iUU0d+Ry5Ljvc04RDmXR/iv9SprbGw4PsA+g5ezXrI712UhE69kZa3VSrV+RJH5PxQntEwV59YQ0pxzsG37+aixd/710SC8Pig00h+bXRKBKCLUyzH1WZZxqcMkkAq553YbcgKGIAivQH+/CDXnUeL/fzRZMv Y/Bee7pY meKPQ7TnEAaPuUjV6U50V8WRWvhO2bunwd5fzm8V6on1MitIAA4skSSzfQNELga02d9MMTgK4qf7n4D+ccK2UTmuiAnCZbVIikpm4k2rZKPAjy5xAsitRZyVI82hbrI2qKRzPTE97VQ08XXweyl64MIHIkLMRtP1s457VX5AwNT7bBW8yAr1V2Nlf7E9TmeGyTJavc077tzBdjTFBjTHiyCfahgE/A4yelQoJ8X1vQtvcaubTn0c84CnH0L4JYLQ4rceCybFVobU5VyRH/BD5BoyoDEpQv+nzoe4rtXjK97/lTig3lB77lCM00E0+mMyo2DMHybFOWn2WWbCphkWxymLggE1fK8D86qDvR3Gd6hQhJa1hPaI70J2K7nlqIxUBYsanrjg2FHGOyLBOJcdnzLYsB9TnGpY+wDa5+sCNG2BhGYL4RkcJ7QN3CmoWl1AaGuSL6esvBRp+QO3TVZqaE/xz6BiyN/U+lGBcB5StgXn3JPT+nDWsNI2bjTKajuanBiaRmhZ9jgDpRhYyV9Sf2m52A4fO8HLd5Km2 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: List-Subscribe: List-Unsubscribe: On Fri, May 31, 2024 at 9:13=E2=80=AFPM Zhaoyang Huang wrote: > > On Fri, May 31, 2024 at 4:05=E2=80=AFPM Uladzislau Rezki wrote: > > > > On Fri, May 31, 2024 at 11:05:20AM +0800, zhaoyang.huang wrote: > > > From: Zhaoyang Huang > > > > > > vmalloc area runs out in our ARM64 system during an erofs test as > > > vm_map_ram failed[1]. By following the debug log, we find that > > > vm_map_ram()->vb_alloc() will allocate new vb->va which corresponding > > > to 4MB vmalloc area as list_for_each_entry_rcu returns immediately > > > when vbq->free->next points to vbq->free. That is to say, 65536 times > > > of page fault after the list's broken will run out of the whole > > > vmalloc area. This should be introduced by one vbq->free->next point = to > > > vbq->free which makes list_for_each_entry_rcu can not iterate the lis= t > > > and find the BUG. > > > > > > [1] > > > PID: 1 TASK: ffffff80802b4e00 CPU: 6 COMMAND: "init" > > > #0 [ffffffc08006afe0] __switch_to at ffffffc08111d5cc > > > #1 [ffffffc08006b040] __schedule at ffffffc08111dde0 > > > #2 [ffffffc08006b0a0] schedule at ffffffc08111e294 > > > #3 [ffffffc08006b0d0] schedule_preempt_disabled at ffffffc08111e3f0 > > > #4 [ffffffc08006b140] __mutex_lock at ffffffc08112068c > > > #5 [ffffffc08006b180] __mutex_lock_slowpath at ffffffc08111f8f8 > > > #6 [ffffffc08006b1a0] mutex_lock at ffffffc08111f834 > > > #7 [ffffffc08006b1d0] reclaim_and_purge_vmap_areas at ffffffc0803ebc= 3c > > > #8 [ffffffc08006b290] alloc_vmap_area at ffffffc0803e83fc > > > #9 [ffffffc08006b300] vm_map_ram at ffffffc0803e78c0 > > > > > > Fixes: fc1e0d980037 ("mm/vmalloc: prevent stale TLBs in fully utilize= d blocks") > > > > > > Suggested-by: Hailong.Liu > > > Signed-off-by: Zhaoyang Huang > > > > > Is a problem related to run out of vmalloc space _only_ or it is a prob= lem > > with broken list? From the commit message it is hard to follow the reas= on. > > > > Could you please post a full trace or panic? > Please refer to the below scenario for how vbq->free broken. > step 1: new_vmap_block is called in CPU0 and get vb->va->addr =3D > 0xffffffc000400000 > step 2: vb is added to CPU1's vbq->vmap_block(xarray) by xa =3D > addr_to_vb_xa(va->va_start); > fc1e0d980037 ("mm/vmalloc: prevent stale TLBs in fully > utilized blocks") introduce a per_cpu like xarray mechanism to have vb > be added to the corresponding CPU's xarray but not local. > step 3: vb is added to CPU0's vbq->free by > list_add_tail_rcu(&vb->free_list, &vbq->free); > step 4 : purge_fragmented_blocks get vbq of CPU1 and then get above vb > step 5 : purge_fragmented_blocks delete vb from CPU0's list with > taking the vbq->lock of CPU1 > step 5': vb_alloc on CPU0 could race with step5 and break the CPU0's vbq-= >free > > As fc1e0d980037 solved the problem of staled TLB issue, we need to > introduce a new variable to record the CPU in vmap_block instead of > reverting to iterate the list(will leave wrong TLB entry) > > > > > --- > > > v2: introduce cpu in vmap_block to record the right CPU number > > > v3: use get_cpu/put_cpu to prevent schedule between core > > > --- > > > --- > > > mm/vmalloc.c | 12 ++++++++---- > > > 1 file changed, 8 insertions(+), 4 deletions(-) > > > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > > index 22aa63f4ef63..ecdb75d10949 100644 > > > --- a/mm/vmalloc.c > > > +++ b/mm/vmalloc.c > > > @@ -2458,6 +2458,7 @@ struct vmap_block { > > > struct list_head free_list; > > > struct rcu_head rcu_head; > > > struct list_head purge; > > > + unsigned int cpu; > > > }; > > > > > > /* Queue of free and dirty vmap blocks, for allocation and flushing = purposes */ > > > @@ -2586,10 +2587,12 @@ static void *new_vmap_block(unsigned int orde= r, gfp_t gfp_mask) > > > return ERR_PTR(err); > > > } > > > > > > + vb->cpu =3D get_cpu(); > > > vbq =3D raw_cpu_ptr(&vmap_block_queue); > > > spin_lock(&vbq->lock); > > > list_add_tail_rcu(&vb->free_list, &vbq->free); > > > spin_unlock(&vbq->lock); > > > + put_cpu(); > > > > > Why do you need get_cpu() here? Can you go with raw_smp_processor_id() > > and then access the per-cpu "vmap_block_queue"? get_cpu() disables > > preemption and then a spin-lock is take within this critical section. > > From the first glance PREEMPT_RT is broken in this case. > get_cpu here is to prevent current task from being migrated to other > COREs before we get the per_cpu vmap_block_queue. Could you please > suggest a correct way of doing this? not quite sure if you have to pay the price of disabling preempt. Does the below Hailong suggested fix your problem? vb->cpu =3D raw_smp_processor_id(); vbq =3D per_cpu_ptr(&vmap_block_queue, vb->cpu); > > > > > I am on a vacation, responds can be with delays. > > > > -- > > Uladzislau Rezki Thanks Barry