Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp2959178rwn; Sat, 10 Sep 2022 02:16:08 -0700 (PDT) X-Google-Smtp-Source: AA6agR5d5AAfYWcxUgJeUQZ0xqs1X5M1/aEhh9vBXo0/LPae3NRB5Q4vncrILKmq/IDLB5TNppMm X-Received: by 2002:a50:fa99:0:b0:44e:9e71:4899 with SMTP id w25-20020a50fa99000000b0044e9e714899mr14545948edr.197.1662801367962; Sat, 10 Sep 2022 02:16:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662801367; cv=none; d=google.com; s=arc-20160816; b=cSfyCsZSTeKD40xei/hA9BRMHxYrOfrukUyxaNuajTp6fWuwXNM+B9GQgnx6rQHWin ewOOZOOriYAhmojK632kIgcahPQVEBc1RKS44wcxMHfZyFyHVlQZMug80+IeARx1i2ta L9IbK9rimHc94ey561T/JJz7gYkifAMRr/IvUOb5f0ODIORk7yZJdvJmhSod3hAJzPax gbKWfmEM+uY77xEWhyFxq0fBgG07de3Dp3kBYEromEzRQMqKmk6UQnQkwqPXSXIst6Rz uQp6FzZliP2cyw1/fPROaarjSS9p/FV7AjxJYe/zKGa4AmFXh2oS06iGkxqjshypqjjQ tL0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=mWMJic3+3eVweR7Hb3wJwKAsDypmbh3PTgAfppiGim0=; b=ZBQxolop/RjCsyQnz1TvjACvrN4tFa3PSo9viToaLwXnEVEK5o3lkyIzm12IKHfjN9 2GpMog2iwcimG8Wl71EHeUPvm6s3qjdb1sFupWbK9eFodw2lFWyNuUBHOgmi7baGpT55 kcV9/qZSyxa1VfHOpk49kE7qzqZTLrmZMS0I3iEx4aKYxj1ANOvTQAVx7S0IzlwNQRy9 91sbROKlMjveMixq7UyjMs1IOEs6ldYyw7z6re0uB+81r/1ogSMkNKDk8R29mSmzWdEh QVEl8bphfMhN1bpoKyu+fKUuDSnI6/4jOw3gqBxEDOr9AdyVjwss0Z0J2r3NL4TUz5Wr AlVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=XZ9bImxf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y8-20020a056402170800b00448852341e0si2052018edu.427.2022.09.10.02.15.43; Sat, 10 Sep 2022 02:16:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=XZ9bImxf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229647AbiIJJFd (ORCPT + 99 others); Sat, 10 Sep 2022 05:05:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57726 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229552AbiIJJFa (ORCPT ); Sat, 10 Sep 2022 05:05:30 -0400 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EDB0C5C950 for ; Sat, 10 Sep 2022 02:05:28 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id c11so6938700wrp.11 for ; Sat, 10 Sep 2022 02:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date; bh=mWMJic3+3eVweR7Hb3wJwKAsDypmbh3PTgAfppiGim0=; b=XZ9bImxf8XtKwz5O25eFDJyl1TKgS+4Hi4wWwjJENYHZOY29lP2VbpTwYOMWw++olk 4K1qpSSO4+87Hd6R+l2+0U0FqICl6zqzF0GSBh84YzSC4whAlP/MdFl21okuGN10B6Yh Sn8/q4/61ZcdlRKw4yjYBQnjgt0naNiZCApDprcpVXwF25huetUS/7ok5KdCu0Ty+J/Z cu6jV5yEoGommBEYZlut/agcSalGVwtlTwIp5k4KkI8gewIAZVYazi0bOSNUFSn0sWqx zaSSgaqEqKUC8EgGhwXOKIDrdGQSdyYn+ywLMVk5Ap0P19n4IkEEy0TnDVBdAaQxa9vd GQSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date; bh=mWMJic3+3eVweR7Hb3wJwKAsDypmbh3PTgAfppiGim0=; b=1iAB+ZfUWY0GU/31V105XQbLRw9kVkCl3CtWLFtaOX+fNNXKlVXqLeGP5/uVSVVw4H XY6xFO0KRGNfYgMFxbt25ASoBqRHn/U9tihRDjwWQ3HEpP/2rdkEppWJgxcJSBwAHUe5 LISOw4r6WqU+9Oed9QcA/FlUFUzdQhovVcm0v7gPz6gfOBgqUqFA6Oqrs7g2t34+Fnup S0wl2sHZW8Fj75hegJUhVxPJFvr6Kh5PPEww2/jfk0C2rskrcaBOakOCrt3IfqStHWc2 UYoOtFgmdlViCBQdpASbV6RRlnGduIUsf1CZwMPV1paKsrPkQ0cS7kK02R6rSUaVxyZ+ sptA== X-Gm-Message-State: ACgBeo2sJAj5o/EdaI3KGVkIw597D1/smYD3SogR5vayIsCZH965ST/g VHgpduEAVgpGNcICGg+x47ZW X-Received: by 2002:a05:6000:1245:b0:228:6aa7:dbb2 with SMTP id j5-20020a056000124500b002286aa7dbb2mr10485053wrx.77.1662800727504; Sat, 10 Sep 2022 02:05:27 -0700 (PDT) Received: from localhost.localdomain ([117.217.182.47]) by smtp.gmail.com with ESMTPSA id i81-20020a1c3b54000000b003a8418ee646sm3081677wma.12.2022.09.10.02.05.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 10 Sep 2022 02:05:27 -0700 (PDT) From: Manivannan Sadhasivam To: kishon@ti.com, lpieralisi@kernel.org, bhelgaas@google.com Cc: kw@linux.com, robh@kernel.org, vidyas@nvidia.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Manivannan Sadhasivam Subject: [PATCH v2 1/3] PCI: endpoint: Use a separate lock for protecting epc->pci_epf list Date: Sat, 10 Sep 2022 14:35:06 +0530 Message-Id: <20220910090508.61157-2-manivannan.sadhasivam@linaro.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220910090508.61157-1-manivannan.sadhasivam@linaro.org> References: <20220910090508.61157-1-manivannan.sadhasivam@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The EPC controller maintains a list of EPF drivers added to it. For protecting this list against the concurrent accesses, the epc->lock (used for protecting epc_ops) has been used so far. Since there were no users trying to use epc_ops and modify the pci_epf list simultaneously, this was not an issue. But with the addition of callback mechanism for passing the events, this will be a problem. Because the pci_epf list needs to be iterated first for getting hold of the EPF driver and then the relevant event specific callback needs to be called for the driver. If the same epc->lock is used, then it will result in a deadlock scenario. For instance, ... mutex_lock(&epc->lock); list_for_each_entry(epf, &epc->pci_epf, list) { epf->event_ops->core_init(epf); | |-> pci_epc_set_bar(); | |-> mutex_lock(&epc->lock) # DEADLOCK ... So to fix this issue, use a separate lock called "list_lock" for protecting the pci_epf list against the concurrent accesses. This lock will also be used by the callback mechanism. Signed-off-by: Manivannan Sadhasivam --- drivers/pci/endpoint/pci-epc-core.c | 9 +++++---- include/linux/pci-epc.h | 2 ++ 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c index 3bc9273d0a08..6cce430d431b 100644 --- a/drivers/pci/endpoint/pci-epc-core.c +++ b/drivers/pci/endpoint/pci-epc-core.c @@ -613,7 +613,7 @@ int pci_epc_add_epf(struct pci_epc *epc, struct pci_epf *epf, if (type == SECONDARY_INTERFACE && epf->sec_epc) return -EBUSY; - mutex_lock(&epc->lock); + mutex_lock(&epc->list_lock); func_no = find_first_zero_bit(&epc->function_num_map, BITS_PER_LONG); if (func_no >= BITS_PER_LONG) { @@ -640,7 +640,7 @@ int pci_epc_add_epf(struct pci_epc *epc, struct pci_epf *epf, list_add_tail(list, &epc->pci_epf); ret: - mutex_unlock(&epc->lock); + mutex_unlock(&epc->list_lock); return ret; } @@ -672,11 +672,11 @@ void pci_epc_remove_epf(struct pci_epc *epc, struct pci_epf *epf, list = &epf->sec_epc_list; } - mutex_lock(&epc->lock); + mutex_lock(&epc->list_lock); clear_bit(func_no, &epc->function_num_map); list_del(list); epf->epc = NULL; - mutex_unlock(&epc->lock); + mutex_unlock(&epc->list_lock); } EXPORT_SYMBOL_GPL(pci_epc_remove_epf); @@ -773,6 +773,7 @@ __pci_epc_create(struct device *dev, const struct pci_epc_ops *ops, } mutex_init(&epc->lock); + mutex_init(&epc->list_lock); INIT_LIST_HEAD(&epc->pci_epf); ATOMIC_INIT_NOTIFIER_HEAD(&epc->notifier); diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h index a48778e1a4ee..fe729dfe509b 100644 --- a/include/linux/pci-epc.h +++ b/include/linux/pci-epc.h @@ -122,6 +122,7 @@ struct pci_epc_mem { * struct pci_epc - represents the PCI EPC device * @dev: PCI EPC device * @pci_epf: list of endpoint functions present in this EPC device + * list_lock: Mutex for protecting pci_epf list * @ops: function pointers for performing endpoint operations * @windows: array of address space of the endpoint controller * @mem: first window of the endpoint controller, which corresponds to @@ -139,6 +140,7 @@ struct pci_epc_mem { struct pci_epc { struct device dev; struct list_head pci_epf; + struct mutex list_lock; const struct pci_epc_ops *ops; struct pci_epc_mem **windows; struct pci_epc_mem *mem; -- 2.25.1