From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 96EA8431E5C; Wed, 1 Jul 2026 20:09:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782936542; cv=none; b=j4TDkqrJlh3Er72ZS3GsRM9MOGnvB0uc5wz0LXYfbE2Obd/x30//h3vylLTHic9Bdonb5Q8fDlFUPE8xNc4KOlVpAWWWPwK9DnXEZdjnPYjbTKPGOtFkdzxtB2XTV80pnX/N/6XfWODarEtb7EWJLX9TJAGsvI7n/mMorQsgkG8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782936542; c=relaxed/simple; bh=AcLjc22Sw/64qloW5ZNpc4LBEJYDNuRdHzkPWuS4lEg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VybbH30SuxrZ3jnB2J5QN2XKN3nmRUwIYMGdlC3As5LPhv2Q+QKxbFS7zqpvAjwqsX4lesto6eL/s5eD/y7Sh+d2muXwX4JzcD0d4ZJ05UoXzt7MRoCBEu3oWYN+J2vhZwzea3k24JmtRAA5C6FBjxNMRBgY+EbGMfVI8VrJ/TM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EXBCJmcb; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EXBCJmcb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC83F1F000E9; Wed, 1 Jul 2026 20:08:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782936541; bh=96jvHTeDCxR7+XirD0BwNbewxZDFsoQe83dAJZ5Y+5s=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=EXBCJmcbAvYPFqFcBHQO2r6ZqZwgwUddvkI9gPT7NLVOsImpXL3HDd6PrstGD6Lq6 cfeIDkj7dEFVZZULAW1dTbFQgzx4rZ6/4XVBr2FGMh/+FXIJJK5eGDawPCpu9s4Igq xs/iIq1X3Kr0xmjXsu0VyJTzyoMYM82kK8fG3PEZY+u5s9depmm8O3qbqysSt+ocJJ TTqq456rc5j7FcKAE/rky5u4fYHgdJxR8KfO0YiJFiqoOufCKaqvfwNyku7A9KJyVu /JxdFoi85x2DKjjGOO4Az4XTjjI36aglvg+YymUKsPxDtSMaNdhSvAByUIAGf+fRON Gu9WbdAhClKXA== Message-ID: Date: Wed, 1 Jul 2026 21:08:58 +0100 Precedence: bulk X-Mailing-List: linux-arm-msm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] misc: fastrpc: release pending invoke refs on rpmsg removal To: Yousef Alhouseen , Konrad Dybcio , Srinivas Kandagatla , Amol Maheshwari Cc: Arnd Bergmann , Greg Kroah-Hartman , linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20260624192700.5388-1-alhouseenyousef@gmail.com> Content-Language: en-US From: Srinivas Kandagatla In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/25/26 10:07 AM, Yousef Alhouseen wrote: > Hi Konrad, > > You're right. These touch related FastRPC lifetime and bounds paths, > and several of them depend on the same state cleanup. I grouped the > follow-up fixes I still think are valid into a small series, and I'll > keep any further FastRPC changes batched instead of sending more > standalone threads. I also like to understand how are these patches tested? --srini > > Thanks, > Yousef > > On Thu, 25 Jun 2026 09:40:53 +0200, Konrad Dybcio > wrote: >> On 6/24/26 9:27 PM, Yousef Alhouseen wrote: >>> fastrpc_rpmsg_remove() wakes pending invoke waiters when the rpmsg device >>> is removed, but it does not release the send references taken before each >>> request was submitted. Those references normally disappear only when a DSP >>> reply arrives, which cannot be relied on after endpoint removal. >>> >>> Walk the channel IDR during removal, mark in-flight contexts completed, >>> and schedule the send-reference put while waking waiters with -EPIPE. This >>> prevents disconnected channels from pinning invoke contexts indefinitely. >>> >>> Signed-off-by: Yousef Alhouseen >>> --- >> >> You sent ~10 patches to fastrpc as separate threads, do they have >> any sort of co-dependence? Can they be applied in random order? >> >> Generally if your changes are even vaguely related, it's best to >> send them in a single series, if only to reduce the possibility of >> a merge conflict >> >> Konrad