Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3980510imm; Mon, 30 Jul 2018 06:48:13 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfuUAAnwhBBuixSVGS59KZhV0BnOxU/jVz7RPm7yyiO7h4B+RG8ZrHlxsE5OYUxwK5PdSML X-Received: by 2002:a17:902:6ac3:: with SMTP id i3-v6mr16574969plt.252.1532958493337; Mon, 30 Jul 2018 06:48:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532958493; cv=none; d=google.com; s=arc-20160816; b=JvrjnYCXIbbj8XpteHR3en5jjOQ6MRkba8zt3kZA1OUK67Up7nHly+95lReDnSNTXH kbEI+d3I9nC0gXceo+/XKMw9YIfowywN75Qw8AEOSp2apuFXfHMgUTq5jcIMIi/bvScB ImGfxyAAlPtAwU2sia+u8fdoWWLHdUlOBpQxWONRDpzQNr0s3hgc3oXcDOOPYrihAIEq 35fm50Okaov5Qgt0I+AmKuOK8q5sEZUOPK8wwtHMnsA+QaRUo24C/5zhzK5oi8v1lLMB rwKQ8/hOtC/f110si7J8e9K0fbiRgxSYgIZRoeTooQomgiVnQ/QKc2qhd2DwCwsohjzx I2pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:references:in-reply-to:subject:cc:to:from :arc-authentication-results; bh=xKaKrxoaLcUoK4jfZTF7odfRNRYqqV9r4GU6G7pWGYM=; b=VvR13AbCdup9Cp+zI7DYW8gleLFP1pXbJX8Hc+sPJKbr56IDyvTXZlTeP1GHGzSdCZ OTlLW+rvrPmM9mzxehF0E68Mvmf9cy7QdhcwijMU4DSj3rfsZGLRMEMkNxxoakzez0rF Um8mHS+I+iwOb/fGsLfJ/6FvEOIple67KjAPbE4n6kn7pq2SKxBXOZW2HN9xCDypqv68 jeBKkYnKbVF6McCXuZ2wSmO4O+ne7ol/QmwSiA/n25A+bw9MnWPXdczyrD8o/sPAsFiw j/CTo5erVsZ4KVie/jR1IXPhL0UmSEd4StQwFVHIx69Aj6D1NRIRxPA2+6ldrhgoHnrE RmNQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 p10-v6si10453877pgm.265.2018.07.30.06.47.58; Mon, 30 Jul 2018 06:48:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727057AbeG3PWI convert rfc822-to-8bit (ORCPT + 99 others); Mon, 30 Jul 2018 11:22:08 -0400 Received: from ozlabs.org ([203.11.71.1]:34137 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726535AbeG3PWH (ORCPT ); Mon, 30 Jul 2018 11:22:07 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 41fLTd5D1Zz9rxx; Mon, 30 Jul 2018 23:47:01 +1000 (AEST) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Laurent Dufour , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Cc: aneesh.kumar@linux.ibm.com, benh@kernel.crashing.org, paulus@samba.org, npiggin@gmail.com Subject: Re: [PATCH 3/3] powerpc/pseries/mm: call H_BLOCK_REMOVE In-Reply-To: <1532699493-10883-4-git-send-email-ldufour@linux.vnet.ibm.com> References: <1532699493-10883-1-git-send-email-ldufour@linux.vnet.ibm.com> <1532699493-10883-4-git-send-email-ldufour@linux.vnet.ibm.com> Date: Mon, 30 Jul 2018 23:47:01 +1000 Message-ID: <877elcj0oa.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Laurent, Just one comment below. Laurent Dufour writes: > diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c > index 96b8cd8a802d..41ed03245eb4 100644 > --- a/arch/powerpc/platforms/pseries/lpar.c > +++ b/arch/powerpc/platforms/pseries/lpar.c > @@ -418,6 +418,73 @@ static void pSeries_lpar_hpte_invalidate(unsigned long slot, unsigned long vpn, > BUG_ON(lpar_rc != H_SUCCESS); > } > > + > +/* > + * As defined in the PAPR's section 14.5.4.1.8 > + * The control mask doesn't include the returned reference and change bit from > + * the processed PTE. > + */ > +#define HBLKR_AVPN 0x0100000000000000UL > +#define HBLKR_CTRL_MASK 0xf800000000000000UL > +#define HBLKR_CTRL_SUCCESS 0x8000000000000000UL > +#define HBLKR_CTRL_ERRNOTFOUND 0x8800000000000000UL > +#define HBLKR_CTRL_ERRBUSY 0xa000000000000000UL > + > +/** > + * H_BLOCK_REMOVE caller. > + * @idx should point to the latest @param entry set with a PTEX. > + * If PTE cannot be processed because another CPUs has already locked that > + * group, those entries are put back in @param starting at index 1. > + * If entries has to be retried and @retry_busy is set to true, these entries > + * are retried until success. If @retry_busy is set to false, the returned > + * is the number of entries yet to process. > + */ > +static unsigned long call_block_remove(unsigned long idx, unsigned long *param, > + bool retry_busy) > +{ > + unsigned long i, rc, new_idx; > + unsigned long retbuf[PLPAR_HCALL9_BUFSIZE]; > + > +again: > + new_idx = 0; > + BUG_ON((idx < 2) || (idx > PLPAR_HCALL9_BUFSIZE)); I count 1 .. > + if (idx < PLPAR_HCALL9_BUFSIZE) > + param[idx] = HBR_END; > + > + rc = plpar_hcall9(H_BLOCK_REMOVE, retbuf, > + param[0], /* AVA */ > + param[1], param[2], param[3], param[4], /* TS0-7 */ > + param[5], param[6], param[7], param[8]); > + if (rc == H_SUCCESS) > + return 0; > + > + BUG_ON(rc != H_PARTIAL); 2 ... > + /* Check that the unprocessed entries were 'not found' or 'busy' */ > + for (i = 0; i < idx-1; i++) { > + unsigned long ctrl = retbuf[i] & HBLKR_CTRL_MASK; > + > + if (ctrl == HBLKR_CTRL_ERRBUSY) { > + param[++new_idx] = param[i+1]; > + continue; > + } > + > + BUG_ON(ctrl != HBLKR_CTRL_SUCCESS > + && ctrl != HBLKR_CTRL_ERRNOTFOUND); 3 ... BUG_ON()s. I know the code in this file is already pretty liberal with the use of BUG_ON() but I'd prefer if we don't make it any worse. Given this is an optimisation it seems like we should be able to fall back to the existing implementation in the case of error (which will probably then BUG_ON() ????) If there's some reason we can't then I guess I can live with it. cheers