From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CD3E5C369CB for ; Wed, 23 Apr 2025 09:18:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:CC:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=qZ4dAc3zEs2+CWBeqQ9MAC8977LAguWV8px1Fpbg/Q0=; b=HL3vL32mHJoPs3/hLTRwvSihsC lqSocGyrJPUsmBc6mL7RE6Ve80a9c/ys+50Zuyk/c+jMDfICtNmydk/RAJFVk3zJNWhGB/GDAyHzA dGYHCXX0CqTJpteS8fH5uTyWgZCYiIYzLNHFZmkCE+WdDJWiQC21TWA7bLIX3vKIiJ/8s5oosg/5J 2qwNqbLufWoJnWkjIBt262Xl/zcTLt7jN011sVsDJ8ZgkNg7joFxD+5A/pN/yl42TOMNPE33DmncT PYF4oHoMO60zoY6K77tpu8LyUQtAtA2Dgwzy06LQtyLUUIIanSPnrFIJJzVEZGfLjqLG9Xa/J74NH 3jkoIB4A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1u7WF7-00000009v0h-0Dj7; Wed, 23 Apr 2025 09:18:09 +0000 Received: from mx0a-0031df01.pphosted.com ([205.220.168.131]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1u7VGM-00000009fbI-1wfr for ath11k@lists.infradead.org; Wed, 23 Apr 2025 08:15:24 +0000 Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 53N0i8p4011273; Wed, 23 Apr 2025 08:15:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= qZ4dAc3zEs2+CWBeqQ9MAC8977LAguWV8px1Fpbg/Q0=; b=dGfYKXuGiw0LeGG8 +BInR+ecNMN0xDN8Ak7nUrTLlvUYtEeWFFgmGnsHmMpNBM+EBIaN1MIpVON5cOme pjnSwY6WvGwyQFXwOR2rWYy9OMXyOZJrxZkKSu2qhBgZ6Pkc7TIH7GUYaz0oXXhB YT2eV0REtGAI+sBVTTNw7zj8HzQJfN7jLyH/tVvlPBktfDIm5CvLzd3Y/v9GqzHf 2q+ZPT0EwByjYED4BADB9D9QuD+e7lDN8Wo0DtPuAPRly+buoHtM8leFHHgCT9+h K8U2uT1QUEbrLtC9+gT8a4p9U9U/HIxCtjZ5uvtNwKlC2kyscE5JOntQ1wgnA69O Q5mD6Q== Received: from nalasppmta03.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 466jh1hd3t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Apr 2025 08:15:15 +0000 (GMT) Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA03.qualcomm.com (8.18.1.2/8.18.1.2) with ESMTPS id 53N8FFtA006573 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Apr 2025 08:15:15 GMT Received: from [10.231.195.67] (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.1544.9; Wed, 23 Apr 2025 01:15:12 -0700 Message-ID: Date: Wed, 23 Apr 2025 16:15:10 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] wifi: ath11k: Fix memory reuse logic To: Muhammad Usama Anjum , Jeff Johnson , Kalle Valo , Anilkumar Kolli CC: , , , References: <20250423065931.4017574-1-usama.anjum@collabora.com> Content-Language: en-US From: Baochen Qiang In-Reply-To: <20250423065931.4017574-1-usama.anjum@collabora.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: 0rT3HxEE1QY2ANCXM7tXp71xeZqJvl4D X-Proofpoint-ORIG-GUID: 0rT3HxEE1QY2ANCXM7tXp71xeZqJvl4D X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNDIzMDA1NCBTYWx0ZWRfXzbTBBl7K5xjw LdVxx8ZDjUqMuKiq5Q+JPJYBn7YHJcjzZeW97QvJVde994MA6RIlqABITgdyO/1G6WxU0RVPE+F clXy05Wv7ycKz3P3UUrTIKC6s1QiL5GNIAojYfLngoueQUDw5E9ymOLgz2zpI+BxO5sYJdqmhVP G1dl5D4+5UHlGVzd8bHHceLNYp05uQNOMAAeniQP/gv5XyfWXPhpVojGE4JXXOaxsTMr/ScUtsL SOBf3rDJL29YqNT4fLQXtgOeNeGd0JrQUmguvpONs9JdDYYLSvwzdZ/PAJKxxCk84YZDKVu//kr NyRKhBkNm30fpbV7FbAETyElf3u3PRBLFpQSjN1j0hAn4yutzZeQL5c0P+KuXBMm3QCMdK1f2Sj cMXegOeb56iBEAHEztvyBvUB2i7YQwL6VeJiYFKQ4JcCJnnyhYtKnlfOUIJg3yBotNRdJeQy X-Authority-Analysis: v=2.4 cv=ZpjtK87G c=1 sm=1 tr=0 ts=6808a193 cx=c_pps a=ouPCqIW2jiPt+lZRy3xVPw==:117 a=ouPCqIW2jiPt+lZRy3xVPw==:17 a=GEpy-HfZoHoA:10 a=IkcTkHD0fZMA:10 a=XR8D0OoHHMoA:10 a=VwQbUJbxAAAA:8 a=QX4gbG5DAAAA:8 a=jXdBDdtSTMXgVRb5xNEA:9 a=QEXdDO2ut3YA:10 a=AbAUZ8qAyYyZVLSsDulk:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-04-23_06,2025-04-22_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 malwarescore=0 lowpriorityscore=0 priorityscore=1501 phishscore=0 clxscore=1015 bulkscore=0 suspectscore=0 mlxlogscore=999 spamscore=0 impostorscore=0 mlxscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2504070000 definitions=main-2504230054 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250423_011522_533974_D99C6C32 X-CRM114-Status: GOOD ( 38.05 ) X-BeenThere: ath11k@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "ath11k" Errors-To: ath11k-bounces+ath11k=archiver.kernel.org@lists.infradead.org On 4/23/2025 2:59 PM, Muhammad Usama Anjum wrote: > Firmware requests 2 segments at first. The first segment is of 6799360 > whose allocation fails due to dma remapping not available. The success > is returned to firmware. Then firmware asks for 22 smaller segments > instead of 2 big ones. Those get allocated successfully. At suspend/ > hibernation time, these segments aren't freed as they will be reused > by firmware after resuming. > > After resume the firmware asks for 2 segments again with first segment > of 6799360 and vaddr is not NULL. We compare the type and size with suggest to rephrase as: After resume the firmware asks for 2 segments again with first segment of 6799360. Since chunk->vaddr is not NULL, we compare the type and size with > previous type and size to know if it can be reused or not. > Unfortunately, we detect that it cannot be reuses and this first smaller s/reuses/reused/ > segment is freed. Then we continue to allocate 6799360 size memory from > dma which fails and we call ath11k_qmi_free_target_mem_chunk() which it is odd with 'from dma' ... I think just say 'allocate 6799360 size memory' is good enough. > frees the second smaller segment as well. Later success is returned to > firmware which asks for 22 smaller segments again. But as we had freed 2 > segments already, we'll allocate the first 2 new smaller segments again > and reuse the remaining 20. Hence we aren't reusing the all 22 small > segments, but only 20. > > This patch is correcting the skip logic when vaddr is set, but size/type > don't match. In this case, we should use the same skip and success logic > as used when dma_alloc_coherent fails without freeing the memory area. > > We had got reports that memory allocation in this function failed at > resume [1] which made us debug why the reuse logic is wrong. Those The link is just v1 of this patch, it is not the report. If there is no public report, just don't mention it. > failures weren't because of the bigger chunk allocation failure as they > are skipped. Rather these failures were because of smaller chunk > allocation failures. This issue is in the kernel side as because of > memory pressure or fragmentation, the dma memory allocation fails. This > patch fixes freeing and allocation of 2 smaller chunks. I know you are describing why you start to debug this issue. But I don't think it is needed in the commit message. No matter kernel allocation fails or succeeds, the issue is there, and the description above is sufficient to make the issue clear. > > Tested-on: WCN6855 WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.6 blank line needed. > [1] https://lore.kernel.org/all/b30bc7f6-845d-4f9d-967e-c04a2b5f13f5@collabora.com > > Signed-off-by: Muhammad Usama Anjum > --- > Changes since v1: > - Update description > > Fixes: 5962f370ce41 ("ath11k: Reuse the available memory after firmware reload") > I think we should keep fixes tag as ^ claimed that its adding reuse > support. But it left a bug in reuse which we are fixing. > > Feel free to add it or leave it as it is. Jeff, what do you think? > --- > drivers/net/wireless/ath/ath11k/qmi.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/ath/ath11k/qmi.c b/drivers/net/wireless/ath/ath11k/qmi.c > index 47b9d4126d3a9..3c26f4dcf5d29 100644 > --- a/drivers/net/wireless/ath/ath11k/qmi.c > +++ b/drivers/net/wireless/ath/ath11k/qmi.c > @@ -1990,8 +1990,16 @@ static int ath11k_qmi_alloc_target_mem_chunk(struct ath11k_base *ab) > */ > if (chunk->vaddr) { > if (chunk->prev_type == chunk->type && > - chunk->prev_size == chunk->size) > + chunk->prev_size == chunk->size) { > continue; > + } else if (ab->qmi.mem_seg_count <= ATH11K_QMI_FW_MEM_REQ_SEGMENT_CNT) { > + ath11k_dbg(ab, ATH11K_DBG_QMI, > + "size/type mismatch (current %d %u) (prev %d %u), try later with small size\n", > + chunk->size, chunk->type, > + chunk->prev_size, chunk->prev_type); > + ab->qmi.target_mem_delayed = true; > + return 0; > + } > > /* cannot reuse the existing chunk */ > dma_free_coherent(ab->dev, chunk->prev_size,