From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (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 8F1F71DA23 for ; Tue, 14 Apr 2026 03:41:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776138108; cv=none; b=l5i656P7mQ096OhGzeKYMl5yVow8CSeuFx2PWbYbMYDJy43uNMNSo9d5JUpZ4qHBy7i1ukzs1Mzy3fSvR1mhFupVfvjD6aKRcYIiAt3UuiBS5NKxt0K+TyZH0zm9ue6pb7sghFLpd64qHIY8dn8aHHyUGZzcseqKF75KSv2tt2c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776138108; c=relaxed/simple; bh=Vrwsn0Qynugf+3jZEDc29x0q/HrfW395D70BhgcJIv8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=RRMxFvLMVOrFdk4Wb+2oJkr9LM6nbIpq/F4fqlIfO8BLa/R3BFve5TgrKa7sp6rQlVl0Dq5CajGg3bQKyQrb0Mn9BLaoofMxHbt6JpHTGJvjA8ON3tej3TdQ7Cni6+z0FH16/7Le5MXPEvb5+efRHXmsgwqcjUg0QOMgaaS/9Bg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=as6qMz2S; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=RC9AyHkZ; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="as6qMz2S"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="RC9AyHkZ" Received: from pps.filterd (m0279870.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 63DLD88q395289 for ; Tue, 14 Apr 2026 03:41:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= i/N1Ui71tI64FxlggBSULn1X9I+bgN0VJv4GfXg0nGc=; b=as6qMz2SrxsX2XXU KCvPXySPoiWbHpWcC+4ycXnOIw1tbgDHRM80pzF6e/Z7mvkhzAA7011/1Lkyrf86 g4qfBwPrmpdN+p2v6DRitSQDGz4kh3afzreacNjk4egosIoJcMvcloOCm00H+4tv kO5XUxf1mAIKgxvYaGE35OpvuXMYET1FJ8cKgUBn19kQrczIiYGA0+a26Eg65Oul Rsy5UHsoTFZZ17zZfiTHre7Lvhh8y/a7QOqGcyjzBSvuncmeROH/k4FJ4EHcRQIZ EmoL6z53rQxS88Xf6gJ8JnZAZCwMQOq3PxP3jGVHZ0Z/SOrXU+CHhYaQVN1s6E+2 USVpEA== Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4dh870rvbx-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 14 Apr 2026 03:41:45 +0000 (GMT) Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-35fbb5779e8so1543646a91.3 for ; Mon, 13 Apr 2026 20:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1776138104; x=1776742904; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=i/N1Ui71tI64FxlggBSULn1X9I+bgN0VJv4GfXg0nGc=; b=RC9AyHkZc4Ur3cJxgJpYWHRifBSh8hl8W2OdTfZUy5hwAzPIw87AOUZmlRADbu543g IWxpBu9R/zppKaCv9QRMp9qEqhv/oCOcpNoASrJOpXPBbq3Ab++ib3hWADb7i50KpiRq WIk8THgEXv6MXGTyr437qOAnkVdE4wB2PTgEhxkwLrpnrokEf6oAF+gUVNLJs7CwXbif bZ3r5zT0uT6XgdS2w0w+sR7JIzCvb/SgThp9/lzfQvulRfX/6Y6TBoiQxPh9/+6vWwbU 1y0w7QFsXkf0meI7HEc6ZKyAc6Dh0WnSvsEDSFPT5B4SzNi9mqkEqIOMDnttGvYYLZz+ 9RGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776138104; x=1776742904; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i/N1Ui71tI64FxlggBSULn1X9I+bgN0VJv4GfXg0nGc=; b=bp8KAG2HSE6dEmnejhs0veecYdFZspzEYUiFuFFom9mf6spHIOIzeW6jpyid1ver06 d/ZPydKMTHP1mDksSd+V++e4C7p8VK+cCeZGVa894/jiO/GyF/93+w+Nxj9vX45PZGsa 8JVfTlTgaeBa6UB2uAu3S8k2IeHeG6kDm8Jj9FVTdm00lGLotMmKRmPYlzltQoLa7zAu SZIA4kGB5R6ezNx7bYEEpzPtMDZTwcGwFG/7Y5yRBlrHhMj8MvSvyrtm7JclotLsFZDg xRXDR/rqvw0FYAkpsMafDwumT0Bvn5IEhj2XMjyE3ZPx3376Hmw1w0R9I/atq+1Pn0pJ 3vFw== X-Forwarded-Encrypted: i=1; AFNElJ/rNowJHOJLbZI9SZjA8AI/fMM89wNgO/RfjIop8gZBjLvc6BUg+iQp6ON6pNTmC427UywIcUwb7ODlwGY=@vger.kernel.org X-Gm-Message-State: AOJu0Yx8qp3a4yC/87314o6IovWiosF0STTnJPAIgJWuHwSjnwu5yfHJ +U1hzTv/a74HVpwEedpQVipF3lXvhqG5+/Zgzh8b2dUFaIDVZDw2AdRfHT/giKYCjfGbPLBtRnT AP2XTaNRVvAJPS7NqH/zzWe+z5XvmDSeTOCo3wR+/G+TWLLK1r6kKfyM5hQ1TV9lFOCw= X-Gm-Gg: AeBDiev24lpkjP9H2Nwp9aNYFf+fcGMFup3Jyjc+5V0UAqoDiSV82kih6vmJMH2Lud9 3DrbH+Ty7xwDLqqTm0CeaJ2yORiq/W+V2ZkdTtTGIvLl8FwFVSe+7hukwb5LiEU8PpSYfz89akn 2KaasbrPKPviPIOjcwkWN/AtQlewlhItKOVZQ9E3mb/+jA0O2QED/ePftJQxLLDLQxxbM9PSsAU l0RoNKV54oyNr+J4mh512E5fsaHXNSrlcp1vb9otIydkltqr/ywzYb2X4r6wPUr6Kgm0FO3rHVm VAEQ6JA0DJY7pBKXIiEwtzDi/Ua95Y5KwKP9W66w7BJxBs9AoT+ZJxOlrfcMoOlyS8XWSRQsb4r Nu4bvLWuanGKeMR4C83PA4SyOcCZsWKdCF/QdRMhkaJLtAiFJZuipM5nXivu94betbqqMVlNo0p bjj8tGpbhso00zQzg= X-Received: by 2002:a17:90b:3f0b:b0:35f:c22d:bddc with SMTP id 98e67ed59e1d1-35fc22dbfd7mr2462602a91.0.1776138104289; Mon, 13 Apr 2026 20:41:44 -0700 (PDT) X-Received: by 2002:a17:90b:3f0b:b0:35f:c22d:bddc with SMTP id 98e67ed59e1d1-35fc22dbfd7mr2462577a91.0.1776138103784; Mon, 13 Apr 2026 20:41:43 -0700 (PDT) Received: from [10.133.33.94] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b2d4f25d32sm135577435ad.57.2026.04.13.20.41.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Apr 2026 20:41:43 -0700 (PDT) Message-ID: <846cf4bb-43da-4d2a-a128-bdaf1371e19b@oss.qualcomm.com> Date: Tue, 14 Apr 2026 11:41:39 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] remoteproc: core: Attach rproc asynchronously in rproc_add() path To: Stephan Gerhold Cc: Bjorn Andersson , Mathieu Poirier , aiqun.yu@oss.qualcomm.com, tingwei.zhang@oss.qualcomm.com, trilok.soni@oss.qualcomm.com, yijie.yang@oss.qualcomm.com, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Bartosz Golaszewski , Dmitry Baryshkov References: <20260409-rproc-attach-issue-v1-0-088a1c348e7a@oss.qualcomm.com> <20260409-rproc-attach-issue-v1-1-088a1c348e7a@oss.qualcomm.com> Content-Language: en-US From: Jingyi Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-ORIG-GUID: CcD-gYyi7BkxitrJaJZCPzcLVuG0rjPe X-Proofpoint-GUID: CcD-gYyi7BkxitrJaJZCPzcLVuG0rjPe X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNDE0MDAzMiBTYWx0ZWRfXxlqcfStvsYKD kLmlSZmyka+hBt1s4lcEP0Dwap3z3RKW6JCNtZjve2OmZv7Z1EC850k2Lcoph2KixrwVtnMHBKY fGAmpeN61KFitDTkUvP8/9f18WAs00aBiBT+RNiEIYAk7G9D2QA0Fpj2DMt6yvrH7U2DOjlt3V7 mD7CG3zbG6mEOTJfQJlDxxucn+gUsjOBMWzbOTOBnkocZmr4sXI8tHjtMqKRiW3jRXSkFu/MzYW UeIVIFUPCW8LviIg3jSF4984Lim9tHiJYBNxjKjTyN7hcmll+EEnnJ6fXc8AnNfknrVkKxVmsgE JlKzaSxSpMJiVpFecjWMYPW47W3ZI2C82pwM2rMMDi2/zZUoprN7RVmcmOdQ0C8br/2pVOIoFrF RAS2jQc/R9zPCAMJ5ZdnhZNg1XpJx/DOc/+tJec0Rz4+b4zW+ZjDKtXV9/zim3kNObXGz1H8g9Q UNjME99qFL7eYWxkG4Q== X-Authority-Analysis: v=2.4 cv=MK9QXsZl c=1 sm=1 tr=0 ts=69ddb779 cx=c_pps a=UNFcQwm+pnOIJct1K4W+Mw==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=gowsoOTTUOVcmtlkKump:22 a=VwQbUJbxAAAA:8 a=EUspDBNiAAAA:8 a=sqA1CSfs5v188lrnezMA:9 a=QEXdDO2ut3YA:10 a=uKXjsCUrEbL0IQVhDsJ9:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-04-13_03,2026-04-13_04,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 lowpriorityscore=0 priorityscore=1501 adultscore=0 clxscore=1015 suspectscore=0 spamscore=0 bulkscore=0 malwarescore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2604070000 definitions=main-2604140032 On 4/10/2026 10:28 PM, Stephan Gerhold wrote: > +Cc Bartosz, Dmitry > > On Thu, Apr 09, 2026 at 01:46:21AM -0700, Jingyi Wang wrote: >> For rproc with state RPROC_DETACHED and auto_boot enabled, the attach >> callback will be called in the rproc_add()->rproc_trigger_auto_boot()-> >> rproc_boot() path, the failure in this path will cause the rproc_add() >> fail and the resource release, which will cause issue like rproc recovery >> or falling back to firmware load fail. Add attach_work for rproc and call >> it asynchronously in rproc_add() path like what rproc_start() do. >> >> Signed-off-by: Jingyi Wang >> --- >> drivers/remoteproc/remoteproc_core.c | 20 ++++++++++++-------- >> include/linux/remoteproc.h | 1 + >> 2 files changed, 13 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c >> index b087ed21858a..f02db1113fae 100644 >> --- a/drivers/remoteproc/remoteproc_core.c >> +++ b/drivers/remoteproc/remoteproc_core.c >> @@ -1673,18 +1673,21 @@ static void rproc_auto_boot_callback(const struct firmware *fw, void *context) >> release_firmware(fw); >> } >> >> +static void rproc_attach_work(struct work_struct *work) >> +{ >> + struct rproc *rproc = container_of(work, struct rproc, attach_work); >> + >> + rproc_boot(rproc); >> +} >> + >> static int rproc_trigger_auto_boot(struct rproc *rproc) >> { >> int ret; >> >> - /* >> - * Since the remote processor is in a detached state, it has already >> - * been booted by another entity. As such there is no point in waiting >> - * for a firmware image to be loaded, we can simply initiate the process >> - * of attaching to it immediately. >> - */ >> - if (rproc->state == RPROC_DETACHED) >> - return rproc_boot(rproc); >> + if (rproc->state == RPROC_DETACHED) { >> + schedule_work(&rproc->attach_work); >> + return 0; >> + } > > I think the change itself is reasonable to make "auto-attach" behavior > consistent with "auto-boot". The commit message is a bit misleading > though: > > - You're really doing two separate functional changes here: > > (1) Ignore the return value of rproc_boot() during auto-boot attach, > to keep the remoteproc registered and available in sysfs even if > attaching fails. > (2) Run the rproc_boot() in the background using schedule_work(). > [To improve boot performance? To work around some locking issues?] > > - The actual issue you are seeing sounds like a use-after-free in the > remoteproc core error cleanup path. I think this one is still > present, we should really have a call to > cancel_work_sync(&rproc->crash_handler) as Dmitry wrote in the > previous discussion [1]. > > Thanks, > Stephan > > [1]: https://lore.kernel.org/all/ce24a2sgg4b6wymoxwgl2ve6np2nxn2wuxfqxfpmvqqrpvgouf@xihd6ziqwu4m/ Hi Stephan, Exactly as you say, what this change do is allowing rproc_attach return false. It should be okay to keep this change and describe it more clear in commit msg in next version? And the use-after-free issue is what we want to resolve in the patch2 in this series, I think cancel_work_sync() is a reasonable change but it cannot resolve this issue as the worker could be executing when we call this(and this is what it behaves when I did local test) and the use-after-free issue still exists. Shall we send a separate patch for this cancel_work_sync? Thanks, Jingyi