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 D4E2AC27C4F for ; Thu, 13 Jun 2024 17:33:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 576286B0083; Thu, 13 Jun 2024 13:33:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 525F46B00CD; Thu, 13 Jun 2024 13:33:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C79E6B0098; Thu, 13 Jun 2024 13:33:24 -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 18FFB6B00CD for ; Thu, 13 Jun 2024 13:33:24 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AB8C3A11E1 for ; Thu, 13 Jun 2024 17:33:23 +0000 (UTC) X-FDA: 82226561886.15.CE2364A Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by imf13.hostedemail.com (Postfix) with ESMTP id A9DE820016 for ; Thu, 13 Jun 2024 17:33:21 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=a1OtHIae; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.54 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718300000; a=rsa-sha256; cv=none; b=JWR8iRsMYM8GLmwYHZw8d5VbTFyIUv/DyrgjG44IKcJldHJ5aF5QF7xB3bPx+9IdF26CVl yDQfDONRfLTkpP4TOPFV9V7wlkx/o1awGdaeFT9s1W3JUfIZgLu0d51UtMYVgWEBvYXC5m UH263iWnT0DLQEjiG9Gw2gQoXs+A8Gk= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=a1OtHIae; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.54 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=1718300000; 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=4ii4ZY+8PBn+yY1/1MCO+EH7pdZ1b188VW9sApqkczU=; b=QZ+/YUj0p9Uwtu1C+M5wBv6WVC+MfCgFQlHM3vPSS20OVN2NAgRXG+SiQ4AEFfTKVtxDlc tmCy9SWF/gZZ9kAp5Uz+ljqOePof961nmnpYStzMVORrHes2Roi+Mw81hIQuk+oMBaBf8c BbufDMAhvoAhL6xegCyOzGqMbhzlmHY= Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-52bc1261e8fso1608137e87.0 for ; Thu, 13 Jun 2024 10:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718300000; x=1718904800; 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=4ii4ZY+8PBn+yY1/1MCO+EH7pdZ1b188VW9sApqkczU=; b=a1OtHIaeJDPVGYX75G0sOkEvp9Id7RO6FReMyDZl3BTR8IUYknn1T7LzoW+pKuZ/F/ ksGgwG7WdfVoBDSGXXWl1zCTzlcBFiVFCqEg3aOlCvTbVNFdupNnmLIRRkR4UxSEzoH6 CZC3LjBwc//P1wsfFhQbprItKysCqvWrI9hTdH5ls2AXJRjQq26MlH3tfFQL2iWcIkYM TMu5Sy/eFczRhGZu3xwNxWedxuhIAsUZdT+HES65W2ZYR5CnsetcQVT7eRg/FmNrbZdc O9cps6/3JN90HPGcaR/5wdVq3gNUTbGGt0Wm7747zPk0yop68/KdyufyGOBTDOk93xEn 73AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718300000; x=1718904800; 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=4ii4ZY+8PBn+yY1/1MCO+EH7pdZ1b188VW9sApqkczU=; b=d7dg8PRBbdIWvJ4klcm3JkiQ+BmrPUpKYoK2gPlNlTsORt+VK8D0I1L0OW9bUNw0bm aMgFaCaAwFcIupg4bvyKKFQ0DTqJVUDYprwbMuR2Co4l9ocz1ngb9Q3UVBs4s6v4NUaw i0yEB63IGrRzGSaB5wRGGSrHS2AkRIPl9iR77DGpgTrvZ8sBaHBRUycOY11flQsEjw/I u/BQnHCGevOn7qtk1Bcv3C5b4spUmqzHt7GSFfLpbf9LgFs527vyMA+X4UmlPyfaYQt7 LXM7YU++j7KvWaqNQ2CeX3nNJoltIO+4BWnSG41yW1mnbkdFBI9/ElCEmlUDeMRs0fWK 9nLQ== X-Forwarded-Encrypted: i=1; AJvYcCWLzd916m6856gDNihhxgvJ7XJASndpw3oEJp1zWeTVs8q+qao8Ux1VVCQPPMzp8EEmuIfc4oADj1PwJ7xfBvTaqaU= X-Gm-Message-State: AOJu0YxpLgTr1iPnknzgtIozkJ018zFSkcWz+u/2L73LIs3THQnh+h/A 72L+V+DLfYn1QGFH0rB9gK9Y1d2YGYf8uRQ3qAFmt+TAW1SYsWir X-Google-Smtp-Source: AGHT+IG98HI4qEE4jMbTN26+L2Wk9PobS+fctcwhqnSg84S8A8OKwKrR6phVc+FCr6Vkbe1dO/5Oyg== X-Received: by 2002:a05:6512:208d:b0:52b:c296:902a with SMTP id 2adb3069b0e04-52ca6e56364mr265661e87.5.1718299999626; Thu, 13 Jun 2024 10:33:19 -0700 (PDT) Received: from pc636 (host-90-233-218-141.mobileonline.telia.com. [90.233.218.141]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-52ca287231csm298652e87.162.2024.06.13.10.33.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jun 2024 10:33:19 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Thu, 13 Jun 2024 19:33:16 +0200 To: "zhaoyang.huang" Cc: Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Baoquan He , Thomas Gleixner , hailong liu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Zhaoyang Huang , steve.kang@unisoc.com Subject: Re: [Resend PATCHv4 1/1] mm: fix incorrect vbq reference in purge_fragmented_block Message-ID: References: <20240607023116.1720640-1-zhaoyang.huang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240607023116.1720640-1-zhaoyang.huang@unisoc.com> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: A9DE820016 X-Stat-Signature: gwo8xn6a79zrp7mpajjoz7jknwb6w9py X-Rspam-User: X-HE-Tag: 1718300001-8498 X-HE-Meta: U2FsdGVkX1+kFTOQsxW++fqD0PMJwB6N6WBjJq6l5JtSZjJLn3G/jqK/cjg5FFDOucpgR0Xy7GDo+R6xgYbGkfae4PRB0P00HcxobvNTnaCMcNxFbYyk86/JsVMQbWykxJb/7vRy7A2WGsRyTZiZyhFH1ZPJ/3mAtTGnrQgVvIhLGDlh/+OdUvOx0Z4Q4AHyABGY/BVvJIFC0fzMOzQRrO+Livfm9WDFgTNUa7EEZTDvh5nqu7u5GIGrYn9SFdKiUZ8r4gKMSrx2MJ0b+QKTDAMS5sor176mwBh7R27rmxryUnDYZB02NAbpGYU/P+nnn5Dp5Uis0WN6zRh13VZzwC8k/iEnZ3L4YsOWHyVDxo+5lNb0HiUdPOib3aVgrbldXvu+CGLo4cf8RFuIQ6bp3XiRiW5xfXTPH8zIEZKshB2Xa9dayAFNULyEt2WlEk0mX7a1Iq8yVEqG/MpOdwDUGENYGVFGw9Br5tH2CZIJi1QaY0BkI41Rw1yz6O4JOwoquXwxc917URvvLHbN2djbIlJQsEPP7J4gidk+6AzN2dgfVKzCkGTRV4uCCseldpQO8TelAs1WhKB2p07nE++KlCLQs78gGjkqlXbIi8CmDIOtHSGDi+CPOusVk8WGYmiuuIW85IbCgVwhtRBcFI0Po3Y1Fx3iu7wCEVfGUBOELMYo9TSBJImdbb/NSBaM/sqObUjtczsXyWAS/UrTrWAjpIfRmr2CQcGFXkk3vVq8b6hGXw7HTwGGXaQ3fXSmd7UAaEpjPntvyrT3FEvpCdYpIRwexk2ari5BCYZddDbuVl4WXzso3ETScqS3IIt8QkVbL8EU+19CSsTpWzPnlZwwHvAnjtzyD5/Gq/6u5iDmRlVihYL6++5TsCiAKYiiuOloK+XNi+J8wKFYyOX7Z3Vtsdx4aW+kkkOWgsR8Ak2dTS8SxlUgRjcfNASIe1wln/7lNnXMtV/ffuVG7TyBiGj H2HsL2GW YwWuxXrwW+bWXpJ8GFOkQCi2X74J6v6j3CPCa3XxwC6dHUiUQdJ5Slp8bnk67ePg9u6vhPD8BEBN7zE4ldN227vk0PbS7lAK2uT4IlEzpvvUIIzBx9rXdFxRBm7qe5zKaF17l4QoS4Ma6u7KctAAXvrRW06e0jRCXRveQOxkg9g9uufRPMIrQ6M6ihB/75qXSel4Mrjk3P4OrCUddo+oJ0MDMuFs40Apgcat5qf5mcBKM2/KZrE6Wh6JB9o+3kSFLP/6Lbgju6wi9Ak3j90vj5FupdFCiiuX9GCynalKRlqWVTvlOK5uYnEkwsAsWcA5m8yDUWie+fh6R4qQByDy7RJpiEfg/yNkpuBZ4rtxRRgo6jhgBXqUN8sm36Lo0pBfcnSIEzTqDG+qKOwXtq8g8Lh3DjeSkT5MS5Ie5JnBUXhryoqbBdXdBZZhIrEtp0p6ihi4+OU0kFge5PtIwYJUPLHcgKnmN5xm5abGDzzxqZRn8BPbq4l7orPrfX6sp4LEUPscpdyp44iohToggYxdBxEfDrdITl+JpDpKkSxI9PPenYpHe4Mrl0T6mCg/u77v0kl/uYup67/w186mUGuXAOV+gg6fFl7FSDil7VyoYGmrAOd2TYcTuuYCGWKFreoZnCn54PV118HwgrWk= 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, Jun 07, 2024 at 10:31:16AM +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 list > 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 ffffffc0803ebc3c > #8 [ffffffc08006b290] alloc_vmap_area at ffffffc0803e83fc > #9 [ffffffc08006b300] vm_map_ram at ffffffc0803e78c0 > > Fixes: fc1e0d980037 ("mm/vmalloc: prevent stale TLBs in fully utilized blocks") > > For detailed reason of broken list, please refer to below URL > https://lore.kernel.org/all/20240531024820.5507-1-hailong.liu@oppo.com/ > > Suggested-by: Hailong.Liu > Signed-off-by: Zhaoyang Huang > --- > v2: introduce cpu in vmap_block to record the right CPU number > v3: use get_cpu/put_cpu to prevent schedule between core > v4: replace get_cpu/put_cpu by another API to avoid disabling preemption > --- > --- > mm/vmalloc.c | 21 +++++++++++++++------ > 1 file changed, 15 insertions(+), 6 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 22aa63f4ef63..89eb034f4ac6 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 */ > @@ -2585,8 +2586,15 @@ static void *new_vmap_block(unsigned int order, gfp_t gfp_mask) > free_vmap_area(va); > return ERR_PTR(err); > } > - > - vbq = raw_cpu_ptr(&vmap_block_queue); > + /* > + * list_add_tail_rcu could happened in another core > + * rather than vb->cpu due to task migration, which > + * is safe as list_add_tail_rcu will ensure the list's > + * integrity together with list_for_each_rcu from read > + * side. > + */ > + vb->cpu = raw_smp_processor_id(); > + vbq = per_cpu_ptr(&vmap_block_queue, vb->cpu); > spin_lock(&vbq->lock); > list_add_tail_rcu(&vb->free_list, &vbq->free); > spin_unlock(&vbq->lock); > @@ -2614,9 +2622,10 @@ static void free_vmap_block(struct vmap_block *vb) > } > > static bool purge_fragmented_block(struct vmap_block *vb, > - struct vmap_block_queue *vbq, struct list_head *purge_list, > - bool force_purge) > + struct list_head *purge_list, bool force_purge) > { > + struct vmap_block_queue *vbq = &per_cpu(vmap_block_queue, vb->cpu); > + > if (vb->free + vb->dirty != VMAP_BBMAP_BITS || > vb->dirty == VMAP_BBMAP_BITS) > return false; > @@ -2664,7 +2673,7 @@ static void purge_fragmented_blocks(int cpu) > continue; > > spin_lock(&vb->lock); > - purge_fragmented_block(vb, vbq, &purge, true); > + purge_fragmented_block(vb, &purge, true); > spin_unlock(&vb->lock); > } > rcu_read_unlock(); > @@ -2801,7 +2810,7 @@ static void _vm_unmap_aliases(unsigned long start, unsigned long end, int flush) > * not purgeable, check whether there is dirty > * space to be flushed. > */ > - if (!purge_fragmented_block(vb, vbq, &purge_list, false) && > + if (!purge_fragmented_block(vb, &purge_list, false) && > vb->dirty_max && vb->dirty != VMAP_BBMAP_BITS) { > unsigned long va_start = vb->va->va_start; > unsigned long s, e; > -- > 2.25.1 > Yes there is a mess with holding wrong vbq->lock and vmap_blocks xarray. The patch looks good to me. One small nit from my side is a commit message. To me it is vague and it should be improved. Could you please use Hailong.Liu explanation of the issue and resend the patch? See it here: https://lkml.org/lkml/2024/6/2/2 Reviewed-by: Uladzislau Rezki (Sony) -- Uladzislau Rezki