Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp107578imm; Wed, 3 Oct 2018 12:44:55 -0700 (PDT) X-Google-Smtp-Source: ACcGV600yIhXDupLzhXKyPWDkVj+n3x2xZF6sOMSXXg7gSe/JVrS99P+VXEFuPOJ7/uQieP33GqT X-Received: by 2002:a17:902:9b89:: with SMTP id y9-v6mr3132277plp.239.1538595895263; Wed, 03 Oct 2018 12:44:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538595895; cv=none; d=google.com; s=arc-20160816; b=X+06aqbHuzkH3F5QegpF1ZWNja0ZAw0kzRzKSJoNyTPBZuiBVHEpbAO8TdAPAkYQKC vN1ggE82Ksp6iALrn3APpZbZ8ECNuDIhJiHsZ5MG6u0oWk+R4aOxKVWxZOyrpbewnGHv n/sAbwqeKfgI7pHzRxzVFmQcXxO/0GEs5qbcC+QaWZ81qRdWu84r24YODuT7pPwd1Nph 5t/KgZzoe6HFuvXG5MGJEH0anIa2vtkL45TKrz/n1pp/QtPy9F4ELVee5W/Rj5IutDrH 89/wy4FOCbe7JmEqSCH0Dw0GhfLrjBPB4npZy1nKK7x8mL5qvVMVJ3UN3S6Nmz+seKK8 sRqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=FiRhWKtCIWOPdlD8ynF6vii9PAGkGSBg/JZTaFckhvY=; b=Xd8lESgQjIERvrN1gVIQqcmfe2HvszrLK9EeNNBQ02zkH0jhtmVzt1PFcDaL8JsKuL 7bJGctn/coLAX+6fL7zq7dcQ4iGFN41xxa+2SpVExlGLYGFsRRjd8Dm8mJTNy1yd/eGJ X8U1N7IEiwhzZqi0fRSRPED5y5QQUeuKaYaDtthxc8wmvAyRpXmuCAZSmUXSQ/xK6jw2 DVS5zCdHIcfYiaQSM7M7Xl29j/PEGt67aCtBIi4xoMrN1sTUkSbyO3qYT/JmcByU6dXz TONaW/6KWfXsequ/Jp9/5kGIw3zsN8oCNKct0ony0KOkLD+Amja5zccNthnoGvaUoNB1 bwsw== 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 f8-v6si2231512pgu.370.2018.10.03.12.44.39; Wed, 03 Oct 2018 12:44:55 -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 S1727417AbeJDCdm (ORCPT + 99 others); Wed, 3 Oct 2018 22:33:42 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:34627 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727283AbeJDCdm (ORCPT ); Wed, 3 Oct 2018 22:33:42 -0400 Received: from tmo-108-185.customers.d1-online.com ([80.187.108.185] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1g7n3h-00047x-2w; Wed, 03 Oct 2018 21:43:45 +0200 Date: Wed, 3 Oct 2018 21:43:39 +0200 (CEST) From: Thomas Gleixner To: Reinette Chatre cc: fenghua.yu@intel.com, tony.luck@intel.com, jithu.joseph@intel.com, gavin.hindman@intel.com, dave.hansen@intel.com, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] x86/intel_rdt: CBM overlap should also check for overlap with CDP peer In-Reply-To: <6fc60e52-8f93-6135-78c0-254676c0c375@intel.com> Message-ID: References: <262e12b66c238517c4766190dd493d937825f563.1537987801.git.reinette.chatre@intel.com> <6fc60e52-8f93-6135-78c0-254676c0c375@intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Reinette, On Wed, 3 Oct 2018, Reinette Chatre wrote: > On 10/3/2018 12:02 AM, Thomas Gleixner wrote: > >> +{ > >> + struct rdt_resource *r_cdp; > >> + struct rdt_domain *d_cdp; > >> + bool ret; > >> + > >> + ret = _rdtgroup_cbm_overlaps(r, d, _cbm, closid, exclusive); > >> + if (ret) > >> + return ret; > > > > if (__rdtgroup_cbm_overlaps(r, d, _cbm, closid, exclusive)) > > return true; > > > >> + > >> + if (rdt_cdp_peer_get(r, d, &r_cdp, &d_cdp) == 0) > >> + return _rdtgroup_cbm_overlaps(r_cdp, d_cdp, _cbm, > >> + closid, exclusive); > > > > if (rdt_cdp_peer_get(r, d, &r_cdp, &d_cdp) < 0) > > return false; > > > > return __rdtgroup_cbm_overlaps(r_cpd, d_cdp, _cbm, closid, exclusive); > > > > Makes the whole thing more obvious. > > I think a different change is needed to support the request from your > review of the first patch to propagate that unthinkable error where only > one of the CDP peers could have an rdt_domain associated with it. > > In the above that error in question from rdt_cdp_peer_get() will be lost. > > I could do the following in support of propagating that error (note that > in support of the code below __rdtgroup_cbm_overlaps() also changes to > return int instead of bool): > > int rdtgroup_cbm_overlaps(struct rdt_resource *r, struct rdt_domain *d, > u32 cbm, int closid, bool exclusive) > { > struct rdt_resource *r_cdp; > struct rdt_domain *d_cdp; > int ret; > > if (__rdtgroup_cbm_overlaps(r, d, cbm, closid, exclusive)) > return 1; > > ret = rdt_cdp_peer_get(r, d, &r_cdp, &d_cdp); > if (ret == -ENOENT) { > return 0; > } else if (ret == -EINVAL) { > rdt_last_cmd_puts("Error finding CDP peer\n"); > return ret; > } else { > return __rdtgroup_cbm_overlaps(r_cdp, d_cdp, cbm, > closid, exclusive); > } > > return -EINVAL; > } > > With the above change in rdtgroup_cbm_overlaps() the call sites then > change to for example: > > ret = rdtgroup_cbm_overlaps(r, d, cbm_val, rdtgrp->closid, true); > if (ret < 0) { > /* last_cmd_status already populated with error */ > return -EINVAL; > } else if (ret == 1) { > rdt_last_cmd_puts("overlaps with exclusive group\n"); > return -EINVAL; > } > /* fall through when no overlap detected */ > > Would this be acceptable? We really have to think about that whether it's worth it. Looking at the resulting code I doubt it. Then I'd rather prefer the warnon and the simpler code. But either way works for me. Thanks, tglx