Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1435937ybz; Wed, 29 Apr 2020 22:31:40 -0700 (PDT) X-Google-Smtp-Source: APiQypJ3B29lfwV4aI32VljI15h3365TfK+Nje3d6FqcWxyJ6WNgQ/x7xO3ZBr043w93Fg4oqHUF X-Received: by 2002:a17:906:b2c2:: with SMTP id cf2mr1075662ejb.262.1588224700394; Wed, 29 Apr 2020 22:31:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588224700; cv=none; d=google.com; s=arc-20160816; b=J8WGyKYOHlag6Munx1QbFVa4Vmv7AFY4FGblGAZk0dcrQTBwJtL2IlkjGUw/UrLsbU SQjom1t6FN8WrwGJOw7xFh4XbD4P3cCcIyfiuEoumUnVI5iyWK+R7luyItu3kdABVA8+ jbVj9awSNdOdFfKI/2jDtckuspcrnqHwm9cBK/FeAWO7tV7idQQBuUzZn2hH5/GPCY2c QU1vI+nMdzuHMEgSiVgSX0eINyDRYiULjafpxLKFeKETtyvoFkXX27dnaz79fC5VE1G3 EJ7x8TUuK+EwuI/Ev8MiFtH0kk9mubAAujeEJLbU03S3WY6gqAoZ3cO2Y54bct04AuJj SyBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=dcOOxNfu0ViENKnUyaeLGnZhhavqrvMGBY7XOn+LjK8=; b=MAbBO94hLrRpfVesYS1nqdZa20t6/gkjbLvAISo3cEKIrK+PNnLy374zrccgKGFkh7 5/XbLuzIzZW873BXEWpD6hVY1pL2bToOufeS5OcyI7kChVzwKKMPJMBd0bj+EnMd4ine FrdgRs2bvj8U+GBV8DCslrClVxMGliOR8KVGCWZ3fdOp4inZ5HTPN2Jn3VhpiTOtd8hK Ae0CZEECwNtAsp62ClZQNxuecp6PmuJb42NJavUR2Ou6llgbdKYv46vkavtloVoTDwXb JFjHmNgTbjeryB2f9tfReK20uLInCsc4+i5Md1x7lLnYkTvI0OhYdBatNMxpl+aHvGy8 7oPg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jt10si5446200ejb.446.2020.04.29.22.31.17; Wed, 29 Apr 2020 22:31:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726404AbgD3Fag (ORCPT + 99 others); Thu, 30 Apr 2020 01:30:36 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:60320 "EHLO fornost.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726395AbgD3Faf (ORCPT ); Thu, 30 Apr 2020 01:30:35 -0400 Received: from gwarestrin.me.apana.org.au ([192.168.0.7] helo=gwarestrin.arnor.me.apana.org.au) by fornost.hmeau.com with smtp (Exim 4.89 #2 (Debian)) id 1jU1kf-0005J1-9j; Thu, 30 Apr 2020 15:28:50 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Thu, 30 Apr 2020 15:29:42 +1000 Date: Thu, 30 Apr 2020 15:29:42 +1000 From: Herbert Xu To: Daniel Jordan Cc: Steffen Klassert , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] padata: add separate cpuhp node for CPUHP_PADATA_DEAD Message-ID: <20200430052942.GA11738@gondor.apana.org.au> References: <20200421163455.2177998-1-daniel.m.jordan@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200421163455.2177998-1-daniel.m.jordan@oracle.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Tue, Apr 21, 2020 at 12:34:55PM -0400, Daniel Jordan wrote: > Removing the pcrypt module triggers this: > > general protection fault, probably for non-canonical > address 0xdead000000000122 > CPU: 5 PID: 264 Comm: modprobe Not tainted 5.6.0+ #2 > Hardware name: QEMU Standard PC > RIP: 0010:__cpuhp_state_remove_instance+0xcc/0x120 > Call Trace: > padata_sysfs_release+0x74/0xce > kobject_put+0x81/0xd0 > padata_free+0x12/0x20 > pcrypt_exit+0x43/0x8ee [pcrypt] > > padata instances wrongly use the same hlist node for the online and dead > states, so __padata_free()'s second cpuhp remove call chokes on the node > that the first poisoned. > > cpuhp multi-instance callbacks only walk forward in cpuhp_step->list and > the same node is linked in both the online and dead lists, so the list > corruption that results from padata_alloc() adding the node to a second > list without removing it from the first doesn't cause problems as long > as no instances are freed. > > Avoid the issue by giving each state its own node. > > Fixes: 894c9ef9780c ("padata: validate cpumask without removed CPU during offline") > Signed-off-by: Daniel Jordan > Cc: Herbert Xu > Cc: Steffen Klassert > Cc: linux-crypto@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: stable@vger.kernel.org # v5.4+ > --- > include/linux/padata.h | 6 ++++-- > kernel/padata.c | 14 ++++++++------ > 2 files changed, 12 insertions(+), 8 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt