Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp2074055imw; Tue, 5 Jul 2022 22:40:23 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vHwotcO22Jhau8IuUzrZv2hCL2dVbcEL+xm3iSFmINHvf49IPti2ronKy93KeCNO7gPbmG X-Received: by 2002:a05:6a00:10c3:b0:525:40fe:6e8d with SMTP id d3-20020a056a0010c300b0052540fe6e8dmr45200461pfu.38.1657086022912; Tue, 05 Jul 2022 22:40:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657086022; cv=none; d=google.com; s=arc-20160816; b=ibh01vU0iXKzEjR/128bEscN75/UJxt+kS0NXcrBoy5uUzQGNw/WVqZplL4L420t9P nZj7cQ/g4QsSaBE8rRsIvur9wfQFIAHLZWrdt/52By3wnaUlmVpUXQJdMww2KpoZ2XNE VMy2hn1Cvbls5FwaDZSToDVDPvBTGboE2aFkcp1xvPutE26tobasu5XNVKcX/DRjSY7P vFq9cbxviMWBpz2/aXBa8Xu3lv3/SKdMFUioIa53aKj4AHLG0xQiD7wCDYril4VlbjxC YE+uHmxqnS1xHwcNx2EgUkzYEibBa8UVniVOJk/7RqxgBsemLmof4NH7YbWpz3BvOHUU aHwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=WXjdQsds+XZxZZX7SRcqQV+eu4pHZKuRykJohRSEZyc=; b=UgYe9fkK3Y9twYcviVYkhINQQ77hUczcwiKLK7ePOSEAasow8M8N497Fb7B35R3YZy O8QSoPHJC6zjjjCzneWJmuqYpG3YluZlxMQNZp1bkCpdpWXo/M7DMsbRKZZMdPjplZx4 h2sobaz80yDkgiuriun7y7mH9e+4fHHUqMHNcE85cNOmXWryGkDyZdUwtRyckzs/iT83 lxAasIa/PiaJP4ugqrYlK01umS+WqQXdT0GcDZFLLQZwhvGoyGQ7uLgidVSb4Fbe5SS1 r29Qc9w0Vh/ub74qnpeeet5LU8a63B+BO9d6hPJmIXnQHNBACw3QKXo0Jy3u8zhXRaVV T16w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=uVd9oFok; 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=quicinc.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f19-20020a056a001ad300b0051beb7365b5si46800865pfv.355.2022.07.05.22.40.10; Tue, 05 Jul 2022 22:40:22 -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=@quicinc.com header.s=qcdkim header.b=uVd9oFok; 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=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230126AbiGFE6k (ORCPT + 99 others); Wed, 6 Jul 2022 00:58:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230080AbiGFE6h (ORCPT ); Wed, 6 Jul 2022 00:58:37 -0400 Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 227391571D; Tue, 5 Jul 2022 21:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1657083516; x=1688619516; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=WXjdQsds+XZxZZX7SRcqQV+eu4pHZKuRykJohRSEZyc=; b=uVd9oFokqqfnlikGBJHDfJWPra9NR9Cp7I3hz8ug144eRRSptSZ4dius voA2sbdfR2sYWU5vUzepStVM74X21JmX2fty8Dhcq+rgImsrLeQpXDyWh J3Rr/Ze84XkEf83IEiuWFhGE0uTLE46fWJPiLMT66+LrvuH5XfU4k1E1x o=; Received: from unknown (HELO ironmsg05-sd.qualcomm.com) ([10.53.140.145]) by alexa-out-sd-01.qualcomm.com with ESMTP; 05 Jul 2022 21:58:35 -0700 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg05-sd.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jul 2022 21:58:35 -0700 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Tue, 5 Jul 2022 21:58:35 -0700 Received: from [192.168.142.6] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Tue, 5 Jul 2022 21:58:34 -0700 Subject: Re: [PATCH 1/2] remoteproc: core: Introduce rproc_del_carveout To: Arnaud POULIQUEN , , CC: , , References: <1654888985-3846-1-git-send-email-quic_clew@quicinc.com> <1654888985-3846-2-git-send-email-quic_clew@quicinc.com> <7881ee36-89f6-3ba9-f4ac-7c4e614728dd@foss.st.com> From: Chris Lew Message-ID: <42e27ed9-1e31-9943-4e82-84c3b3090383@quicinc.com> Date: Tue, 5 Jul 2022 21:57:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <7881ee36-89f6-3ba9-f4ac-7c4e614728dd@foss.st.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 On 6/30/2022 9:36 AM, Arnaud POULIQUEN wrote: > Hi, > > On 6/10/22 21:23, Chris Lew wrote: >> To mirror the exported rproc_add_carveout(), add a rproc_del_carveout() >> so memory carveout resources added by devices outside of remoteproc can >> manage the resource lifetime more accurately. >> >> Signed-off-by: Chris Lew >> --- >> drivers/remoteproc/remoteproc_core.c | 20 ++++++++++++++++++++ >> include/linux/remoteproc.h | 1 + >> 2 files changed, 21 insertions(+) >> >> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c >> index 02a04ab34a23..ee71fccae970 100644 >> --- a/drivers/remoteproc/remoteproc_core.c >> +++ b/drivers/remoteproc/remoteproc_core.c >> @@ -1001,6 +1001,26 @@ void rproc_add_carveout(struct rproc *rproc, struct rproc_mem_entry *mem) >> EXPORT_SYMBOL(rproc_add_carveout); >> >> /** >> + * rproc_del_carveout() - remove an allocated carveout region >> + * @rproc: rproc handle >> + * @mem: memory entry to register >> + * >> + * This function removes specified memory entry in @rproc carveouts list. >> + */ >> +void rproc_del_carveout(struct rproc *rproc, struct rproc_mem_entry *mem) >> +{ >> + struct rproc_mem_entry *entry, *tmp; >> + >> + list_for_each_entry_safe(entry, tmp, &rproc->carveouts, node) { >> + if (entry == mem) { >> + list_del(&mem->node); >> + return; >> + } >> + } >> +} >> +EXPORT_SYMBOL(rproc_del_carveout); > > This API seems to me quite dangerous because it can be called while carveouts are in use. > At least some checks should be added... > > What about using rproc_resource_cleanup instead? > > Regards, > Arnaud > The intended users of this API would be devices who negotiate with the device and know when the carveouts it has added are in use or can be reclaimed. I had looked at rproc_resource_cleanup() and that seemed more like a blanket cleanup rather than being able to cleanup a specific carveout. I agree the API seems dangerous, but I wasn't quite sure what kind of checks could be put here since remoteproc itself doesn't have any mechanisms to monitor the carveout state itself. We're relying on the fact that the device who added the carveout shouldn't make any mistakes which is fairly fragile. Thanks! Chris >> + >> +/** >> * rproc_mem_entry_init() - allocate and initialize rproc_mem_entry struct >> * @dev: pointer on device struct >> * @va: virtual address >> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h >> index 7c943f0a2fc4..43112aa78ffe 100644 >> --- a/include/linux/remoteproc.h >> +++ b/include/linux/remoteproc.h >> @@ -658,6 +658,7 @@ struct rproc *devm_rproc_alloc(struct device *dev, const char *name, >> int devm_rproc_add(struct device *dev, struct rproc *rproc); >> >> void rproc_add_carveout(struct rproc *rproc, struct rproc_mem_entry *mem); >> +void rproc_del_carveout(struct rproc *rproc, struct rproc_mem_entry *mem); >> >> struct rproc_mem_entry * >> rproc_mem_entry_init(struct device *dev,