Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp387728ybe; Fri, 6 Sep 2019 00:44:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqy7VLcnN0aIxEI7eW8jICIIlgEi6MgR0/mTyRSA6gjVTK2tqpyrJlHi5IKFNIHev7IJff5F X-Received: by 2002:a62:834c:: with SMTP id h73mr9226331pfe.183.1567755897912; Fri, 06 Sep 2019 00:44:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567755897; cv=none; d=google.com; s=arc-20160816; b=DZEnPsZlKZ9Z7zvIJtwC2Jut6LtOFB8qMnPhWKRmDl+6J+y+YKWP7y54bkAYiob/51 3R2Mwa25//R1Ul013Ng7fR+/ob8O2unuurnxFXPqcA53uft3zl7ofbqq+trgqb90m7jH zMzI/++rajnEPbfqkHt3mZC6e/ISAnq3tm+B+DUSPBbC2AFnANKNxKBqRHDwTNuz/ta/ 5WQevlf8bsO9MtfdtwV3H6P9G9AN1QFL+InEHP1yeHeEJ3846iaeNSmcg08/A6I+VF52 oflWoO49vtyYI99vEu5Z1TnEpoy3c8fp2wwrgqFop2DKzSJXIRGRxX46H+V7D24MohEY 7RYQ== 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:dkim-signature; bh=SMr5Wa1/JRqleE5iB2SBJYc1hjMDbWANCCSO+yo7+7A=; b=XOa/4HGpLNlDBOn3t3lSZGKvRlQe5OyLqdiWQt5Qj9Ci0LzKUHFpYOUz2J/AFao4r7 uiYzouMtYTcPbeGxI/Z6iIre+w+/CDP4UfBZpyycoi3GeHbRN3X0Z2RGhld1nIintc6P Y8jPZvPTQN0L7Vy5WAFYLKj/u+AN6ccviGndBj5v/GbiakSxghq00ZHJPV0pqWbJHQaF YgE0vzTZUGDna9n8MWdQTXs4H5bpo37XscJYwP9QE4bEh7bvXiNJDEVDfvtfgWVhApdm VmFL8RipPAhgDjCAW3myrI50IYahyvM1+6iqULmFhsPO59V8I8Nsn8k+CCWzirAvK4IQ uiLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2019-08-05 header.b=gd36TohF; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v16si2746773pfn.271.2019.09.06.00.44.38; Fri, 06 Sep 2019 00:44:57 -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; dkim=pass header.i=@oracle.com header.s=corp-2019-08-05 header.b=gd36TohF; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731969AbfIEWiZ (ORCPT + 99 others); Thu, 5 Sep 2019 18:38:25 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:53212 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726837AbfIEWiZ (ORCPT ); Thu, 5 Sep 2019 18:38:25 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x85MYURF061084; Thu, 5 Sep 2019 22:38:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2019-08-05; bh=SMr5Wa1/JRqleE5iB2SBJYc1hjMDbWANCCSO+yo7+7A=; b=gd36TohFcCgMahV+CDJYj5r05LKAiLCosdVUECyedsnKRj7lvI76xNyOFnwJ3pD3k1s/ TZ3Y1N5bvPtBRXU+iOjyRutGjuBjT6iVUucSN9XiWWTHHA6KJEOFTdew7i4AP/pIo/My UiMQYzi3qDaEGZOZMMcTcWQG+1NaaIpjqmyy6NEhazHwdkr23lyjUcdZQ1z8Vc5k6MtG V/H5uDMp1ViiwRU4lm1omUg0rIfspI0K/iTuOmC9TzUMT/Np//KdX4SayiPsuj8W6Cj2 fnxM2P9YkyqLCN6UpqLanR/pOiTghYtjmRiZPsVqCjLIw2kE+PqF9T1rWv5wgJYkiUhO hw== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 2uub5yr117-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 05 Sep 2019 22:38:06 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x85MYHBO035022; Thu, 5 Sep 2019 22:38:05 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2utpmby59r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 05 Sep 2019 22:38:05 +0000 Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x85Mc3iT012918; Thu, 5 Sep 2019 22:38:03 GMT Received: from ca-dmjordan1.us.oracle.com (/10.211.9.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 05 Sep 2019 15:38:03 -0700 Date: Thu, 5 Sep 2019 18:37:56 -0400 From: Daniel Jordan To: Herbert Xu Cc: Daniel Jordan , Steffen Klassert , Sebastian Andrzej Siewior , Thomas Gleixner , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/5] padata: make flushing work with async users Message-ID: <20190905223756.wmmjkjvztlerjzee@ca-dmjordan1.us.oracle.com> References: <20190828221425.22701-1-daniel.m.jordan@oracle.com> <20190828221425.22701-2-daniel.m.jordan@oracle.com> <20190905041734.GA25330@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190905041734.GA25330@gondor.apana.org.au> User-Agent: NeoMutt/20180716 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9371 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909050210 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9371 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909050210 Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Thu, Sep 05, 2019 at 02:17:35PM +1000, Herbert Xu wrote: > On Wed, Aug 28, 2019 at 06:14:21PM -0400, Daniel Jordan wrote: > > > > @@ -453,24 +456,15 @@ static void padata_free_pd(struct parallel_data *pd) > > /* Flush all objects out of the padata queues. */ > > static void padata_flush_queues(struct parallel_data *pd) > > { > > - int cpu; > > - struct padata_parallel_queue *pqueue; > > - struct padata_serial_queue *squeue; > > - > > - for_each_cpu(cpu, pd->cpumask.pcpu) { > > - pqueue = per_cpu_ptr(pd->pqueue, cpu); > > - flush_work(&pqueue->work); > > - } > > - > > - if (atomic_read(&pd->reorder_objects)) > > - padata_reorder(pd); > > + if (!(pd->pinst->flags & PADATA_INIT)) > > + return; > > > > - for_each_cpu(cpu, pd->cpumask.cbcpu) { > > - squeue = per_cpu_ptr(pd->squeue, cpu); > > - flush_work(&squeue->work); > > - } > > + if (atomic_dec_return(&pd->refcnt) == 0) > > + complete(&pd->flushing_done); > > > > - BUG_ON(atomic_read(&pd->refcnt) != 0); > > + wait_for_completion(&pd->flushing_done); > > + reinit_completion(&pd->flushing_done); > > + atomic_set(&pd->refcnt, 1); > > } > > I don't think waiting is an option. In a pathological case the > hardware may not return at all. We cannot and should not hold off > CPU hotplug for an arbitrary amount of time when the event we are > waiting for isn't even occuring on that CPU. Ok, I hadn't considered hardware not returning. > I don't think flushing is needed at all. All we need to do is > maintain consistency before and after the CPU hotplug event. I could imagine not flushing would work for replacing a pd. The old pd could be freed by whatever drops the last reference and the new pd could be installed, all without flushing. In the case of freeing an instance, though, padata needs to wait for all the jobs to complete so they don't use the instance's data after it's been freed. Holding the CPU hotplug lock isn't necessary for this, though, so I think we're ok to wait here.