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 69A9CC2BBCA for ; Tue, 25 Jun 2024 16:49:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A44216B0085; Tue, 25 Jun 2024 12:49:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F42B6B0088; Tue, 25 Jun 2024 12:49:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8950C6B008A; Tue, 25 Jun 2024 12:49:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 6E16D6B0085 for ; Tue, 25 Jun 2024 12:49:44 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 160E412036D for ; Tue, 25 Jun 2024 16:49:44 +0000 (UTC) X-FDA: 82269997488.10.657A863 Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) by imf29.hostedemail.com (Postfix) with ESMTP id 114E9120008 for ; Tue, 25 Jun 2024 16:49:41 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aZLa5i8x; spf=pass (imf29.hostedemail.com: domain of urezki@gmail.com designates 209.85.218.51 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719334175; 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=i8tcHw7piGXCwRcIpKZBGAUeAPhX7LMHTxD2UwRCUME=; b=4uTlliL+lGy2ZgMdAzv1X4kkU+l2uJGN6tUbgDTXgk9PL42gOxDWRzAKpmVHww8DR4aI54 aabUn928DVc5/xLoz3Yp1+P3LVxNtmfQLDyW59VdseXgMuTnxOzz4mWlPwp+HKdW1Kdqac bpCVy0Tnn65M3vqimQOphx/OJfvqTQQ= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aZLa5i8x; spf=pass (imf29.hostedemail.com: domain of urezki@gmail.com designates 209.85.218.51 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719334175; a=rsa-sha256; cv=none; b=uHuLg0aezsyl/We1WyESZF3F+g1Uj9MDnOjRq0uJ9z3ugbYFOwzna5TKp0ge2WwH01xX1O k+ROAtpmaLBh/QVBis7ZYrBq6jGhug5THiiEJ8Po78kUG6c1aByCg13N/n2ygxh5fHcOGA qK/MJD4qRboRIlvCgldxeeEkgc/ddtg= Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-a725041ad74so153684366b.3 for ; Tue, 25 Jun 2024 09:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719334180; x=1719938980; 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=i8tcHw7piGXCwRcIpKZBGAUeAPhX7LMHTxD2UwRCUME=; b=aZLa5i8xq27ucXlpPpAZMKW9gw5ETLvuIYlEWcj1XizTsRs0wxx+zvexz0f2JVLWgH 0v0ShoU2NZzs+0AfLXGHU4BrgRmS83GpBWOaQXt8Yrx/yKlo+rywcLLRhCpqqvfIsYkM 4+CrRsJl8kEEGJsv4SwMMNP79WjyWQnWdhRsDdnsSxZFnj1EsgzW5xlF8TGV+xgIGgVR QskzCiOv9ljB+ev5MzBt75eceGGfAjs4Uwe7O833XdbS3q0rv3SHh1uioC2ReJOqB1of lnfBynSCCCzzSIJzUqLA0YEBTD1PzJDz8lgh5Lp/DhWrOYQwCQHUxNnKA3FXls0gwuc5 H9jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719334180; x=1719938980; 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=i8tcHw7piGXCwRcIpKZBGAUeAPhX7LMHTxD2UwRCUME=; b=DaVnp2waTFEyNgEjtPPZLfCkNW+h506AQo/ziegMFlsFUmRwzvnWoypOdm8ZdHmgef r6JEHgEx9wjpdWt0p4FNo4UsA3DJlJENQgQekno7lFlgNp5Yyf4ccdfHVMEQfN0fqoX1 5Uemj0X2mmljT/w0Cofv0Cu/yPdvH5XtUWctHtz3219wwCZQuqZ5r1/Qbbrs+KJ3UvkI xkaWN+H8TuuPC+JIRpnytALNN4iGt045lAY1PKiPJkElvCwJpJnnw//x48wEG+1WDmje A2d7iTdow34yI5oOr+iwrekh9v8wIX+G41AwsK56z77UNf5xkoSMQh0Rw+3UH1YQSY+f Oi+w== X-Forwarded-Encrypted: i=1; AJvYcCVR8n3bafXQKjGc1IJLyRqHNhRKmw4x8Coe+rT95/bkN62LEktPBL4aiwau1yHcT8797CPE3Et0m/i3blY0/NnDyTU= X-Gm-Message-State: AOJu0Yw03sWY4Dq5wvRKkYtLf56nSCBEYygT3OdBwDVbB8Byb9bg0tPx ERBx41ie4uKDqck5/RPpA6ARdg8EafbIzKfKTip7VPS4Vd0N6zOk X-Google-Smtp-Source: AGHT+IG1iYnAnB1dQfk+8aYmQF2ecfD43JBj0FrCqW8RDRv+XN+QynXr42cGTxWqNwxe8YLLOqAPmw== X-Received: by 2002:a50:ab5b:0:b0:57d:2659:9143 with SMTP id 4fb4d7f45d1cf-57d4bde078cmr6401540a12.37.1719334180082; Tue, 25 Jun 2024 09:49:40 -0700 (PDT) Received: from pc638.lan (host-185-121-47-193.sydskane.nu. [185.121.47.193]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-57d30583e93sm6095989a12.96.2024.06.25.09.49.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jun 2024 09:49:39 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 25 Jun 2024 18:49:37 +0200 To: Nick Bowler Cc: Uladzislau Rezki , Hailong Liu , Nick Bowler , linux-kernel@vger.kernel.org, Linux regressions mailing list , linux-mm@kvack.org, sparclinux@vger.kernel.org, Andrew Morton Subject: Re: PROBLEM: kernel crashes when running xfsdump since ~6.4 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 114E9120008 X-Stat-Signature: 3zkf4m1k7xx8sw9m58cg8w1yu967ygjq X-HE-Tag: 1719334181-103417 X-HE-Meta: U2FsdGVkX19TQXdyeRyz4ONO+vYWLsQfdxQlE1GgsDsEzTFpQwOJaTSbrJ3ljyZ2yOnkS4AdF7xsNZIV50mVkIIE+GycxVL94g+jOot5GDIhgVoZ1EFjoBUnkXBBeskBN21g64mCgOE3DYImtmuu8/oSx6lR3muBG+M6m45Q6GIyu9koBqp0O3zkEcxy7kU8RvQFdBmme/yONVYAAhXNMboK3hU/INq47YNh+fhJBHsnDTB/KChDJcojDyw+HVYw/IjyHpZABOhsTZTOeFerGqavl08lU7+TqIslbyGqlVXxAtm4SY6qiPp7ETlnLN976J3dO2r4dJYp7tXiF8A0kEILb344FOLg3TCeHkVJqjPwmntSqNOQ9twcYLljZun9VMWpI0rZwTlHZQzpcIQKYmfmGi+H+lc2V8EahGr/dbWoFGFmtjCVNx7KRtmOItWPrwRCoH+WuFAQkrMCNfnkgOSbBJI/KSP7hUrACHYNDBU9Ni6GDX/Xki5qExLe1O0ALAmtNU44dHAI+IDfNKTBAFhrbUA+doe8uslAYrau99ky1vTY+Tb0E9O2u0Tdfy8/NeMGS6uvDtEff3ASmry+SqwAVGnnE3FFKdIUqt7nI2ycNAuItPV3voYRoYsI+PP4EYi3SAfDP/pJjr96DcHcojXZmePfefi/5zgWQctlNqWYUhWniLy8DQSNd53yNpNeym2pCSLdK4t/m1etnFfM4mhgjY3NbBXkWOYPqv3/pZqCdP1dyoLH8x95a6DH1IARSthKVCwYFNQ/NMqVZg84vM8anzw5weiH5lC8E5N87Ho+s2NCSzOmNj/fz5ToK5/7t41XEBOgGrp9ucdLeZ0CwiB/2b5YApWdVOW8kTImZ+Pgm53LBdhKr35SPnfVfndO/E2Ro7pjzglAWa92Rj9epObPcfYsuvo+mfK6+tyg+77E4l3p1S3I3fuSPLs57fafqqt35eDV/M8Orz3OT/t BTg/3dx7 5ZLi2hECuEZh4Mz44YpT/eLNaBpeAEIvHK7j11E1COGcp4kyxzyOT06lXy5p1L58/kDaYYEVxFV+HW3uteg9+en+DSg3FEMbwEn5/OvHgSznm/XGFz8fk9q78f+1HVEdrZXvvJ3uzQ2TwR9o6BU/pm4nVfC6n7uwa7CaJqZtNDHtlHrPFNrCmkCFNjPBbqhHT8yF+0jjdW1qtyNKLaXPyUvtxhLUvnyVlTEOAjlt+XeiDQLdVypdv0UbCvhAmgkcKEUUPQiDrI8jY5KArPNeKDpSDPTybkJT+szkKYehDqU0aRfkI3svYpXuSEd4prMwcEOQKZ3Jq3ub+xlM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000150, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > > > > /** > > > > * cpumask_next - get the next cpu in a cpumask > > > > * @n: the cpu prior to the place to search (i.e. return will be > @n) > > > > * @srcp: the cpumask pointer > > > > * > > > > * Return: >= nr_cpu_ids if no further cpus set. > > > > > > Ah, I got what you mean. In the vbq case, it may not have chance to get > > > a return number as nr_cpu_ids. Becuase the hashed index limits the > > > range to [0, nr_cpu_ids-1], and cpu_possible(index) will guarantee it > > > won't be the highest cpu number [nr_cpu_ids-1] since CPU[nr_cpu_ids-1] must > > > be possible CPU. > > > > > > Do I miss some corner cases? > > > > > Right. We guarantee that a highest CPU is available by doing: % nr_cpu_ids. > > So we do not need to use *next_wrap() variant. You do not miss anything :) > > > > Hailong Liu has proposed more simpler version: > > > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index 11fe5ea208aa..e1e63ffb9c57 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -1994,8 +1994,9 @@ static struct xarray * > > addr_to_vb_xa(unsigned long addr) > > { > > int index = (addr / VMAP_BLOCK_SIZE) % num_possible_cpus(); > > + int cpu = cpumask_nth(index, cpu_possible_mask); > > > > - return &per_cpu(vmap_block_queue, index).vmap_blocks; > > + return &per_cpu(vmap_block_queue, cpu).vmap_blocks; > > > > > > which just takes a next CPU if an index is not set in the cpu_possible_mask. > > > > The only thing that can be updated in the patch is to replace num_possible_cpu() > > by the nr_cpu_ids. > > > > Any thoughts? I think we need to fix it by a minor change so it is > > easier to back-port on stable kernels. > > Yeah, sounds good since the regresson commit is merged in v6.3. > Please feel free to post this and the hash array patch separately for > formal reviewing. > Agreed! The patch about hash array i will post later. > By the way, when I am replying this mail, I check the cpumask_nth() > again. I doubt it may take more checking then cpu_possible(), given most > of systems don't have gaps in cpu_possible_mask. I could be dizzy at > this moment. > > static inline unsigned int cpumask_nth(unsigned int cpu, const struct cpumask *srcp) > { > return find_nth_bit(cpumask_bits(srcp), small_cpumask_bits, cpumask_check(cpu)); > } > Yep, i do not think it is a big problem based on your noted fact. Nick, could you please test your machine with below change? diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 45e1506d58c3..5458fd2290cf 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2542,9 +2542,10 @@ static DEFINE_PER_CPU(struct vmap_block_queue, vmap_block_queue); static struct xarray * addr_to_vb_xa(unsigned long addr) { - int index = (addr / VMAP_BLOCK_SIZE) % num_possible_cpus(); + int index = (addr / VMAP_BLOCK_SIZE) % nr_cpu_ids; + int cpu = cpumask_nth(index, cpu_possible_mask); - return &per_cpu(vmap_block_queue, index).vmap_blocks; + return &per_cpu(vmap_block_queue, cpu).vmap_blocks; } /* Thank you in advance! -- Uladzislau Rezki