Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp2406742ybi; Thu, 18 Jul 2019 07:57:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqwP3B+fCc0SAFwGZ071GwbgQTnRZZGj57scjMlHYovd3QwWC6hPPC0VrcO2ylU2tNJsHu55 X-Received: by 2002:a17:90a:2008:: with SMTP id n8mr50720691pjc.4.1563461852888; Thu, 18 Jul 2019 07:57:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563461852; cv=none; d=google.com; s=arc-20160816; b=JZQjskL7wP5hXzYbHlsc3Dv+RKOJSHrtvA1dly21jYtJ8qwF1GNBCgYskRcs0opkzC LOpuPEO4b18bRF/oKO89O+EOZUR+CSwFVzHrMYntigZXMMLDeKiKnvrt2c8h3GBTxSAe DtlsycLr02R6M90A0ZHGuWdBAhA/s+ge7kuDpMrDbAPmOWqGXwt/m4nU8b4UAKUTbfH9 92H+/vEx0uFMgR1vd3BLL31/FJU68X/aYhKy395Su447681QuuQ/EmB3e3HHgJCuSSPk sEuqlU75GKLR1A6/UAFhfIt/6fIyAQ/xkJPIR6o5eMiRJ7eI5gmt3KYk7zXnPsG2pcHy 1d0Q== 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=13l5gw61mG6mdA2LXlH63qeaCFOjI6x3Y9b/MiVQeLI=; b=VVBjlVkVW2fpRSSbXBP+nEPvQ8VuTF2gvYwAc1Jj5r/sfz2CsdQAqL0WC8yfUFd4yX +0p1ZcEVpWU1lDSVWr03Omyqkv3EXgAd7H01A3vP1Wf3X0cTG6M8RNhxVvzJq6UdDQGx /vUdDoNhMKWTuNNWFq4CfdM8e6iOSOs0/9xi3AX3CUaitB6UVR/rrHlls5IttHzc9c1b IzMVcGLBE2HmAYdTS++lKr1m9meqDZdlLX+7a8dXkMvqHeJW1bidB9em4ywqxYWB76/S li8rsMd+c5IgaKhimdeP3T59g0nAyW2jVkSRTleS+bqf8rHzxfU8QbBmZD6pK7cMQAJA rw5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o8si375160pgj.239.2019.07.18.07.57.19; Thu, 18 Jul 2019 07:57:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727767AbfGRO4s (ORCPT + 99 others); Thu, 18 Jul 2019 10:56:48 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:52432 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727762AbfGRO4s (ORCPT ); Thu, 18 Jul 2019 10:56:48 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1ho7pl-0000NL-DQ; Thu, 18 Jul 2019 22:56:37 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1ho7pi-0006Id-9i; Thu, 18 Jul 2019 22:56:34 +0800 Date: Thu, 18 Jul 2019 22:56:34 +0800 From: Herbert Xu To: Daniel Jordan Cc: Steffen Klassert , Andrea Parri , Boqun Feng , "Paul E . McKenney" , Peter Zijlstra , linux-arch@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Mathias Krause Subject: Re: [PATCH] padata: Replace delayed timer with immediate workqueue in padata_reorder Message-ID: <20190718145634.xagjemdqpoe44xxh@gondor.apana.org.au> References: <20190716163253.24377-1-daniel.m.jordan@oracle.com> <20190717111147.t776zlyhdqyl5dhc@gondor.apana.org.au> <20190717183227.b3hqphukkndqumhw@ca-dmjordan1.us.oracle.com> <20190718033131.4m4ypbq7tiucqcsl@gondor.apana.org.au> <20190718142730.uhdkwx5onigdpxno@ca-dmjordan1.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190718142730.uhdkwx5onigdpxno@ca-dmjordan1.us.oracle.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Thu, Jul 18, 2019 at 10:27:30AM -0400, Daniel Jordan wrote: > > That's what I expected when I first saw it too, but nr_cpumask_bits is returned > to signal the end of the iteration. The patch always passes 0 for the 'start' > argument, so when cpumask_next_wrap is called with the last cpu in the mask, > the end-of-iteration case is triggered. To reassure you and myself :) I ran it > and got the expected crash. > > Passing pd->cpu for the start argument instead avoids that problem, but the > one-cpu-in-mask case still needs handling because cpumask_next_wrap always > signals end of iteration for that, hence the cpumask_weight check. My bad. I should have set start to -1 to make it do the right thing. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt