From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.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 C683E32F770 for ; Tue, 18 Aug 2026 06:39:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787035184; cv=none; b=jdmTRptf1G7dpB26BosQKSyzU0d81VCkecUSeQIhLKrC5/AiUTkSyYYfy4YbsQXCgcrVOGCzxcg+sanuPnd3YEg66+Lf2s4qbL0MFEHF7VqfvtnFxoG4sI5yKwd2eLtHkQe+IZ2MuGTZ4RBeGqD/otvHy6kxz/yItSl++TQ3d+0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787035184; c=relaxed/simple; bh=s9l4mDPEH4t3IYZQoGYBXeULBj6e1vAAeVBjHlUHAzU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=q+wln4eMJI2aBO7ijZ9O+yYbQAH7eug9GvY4tcK10p+sW37Nmj7pDtXCmz5ixjEf7PMZOVN+y2b3fqgtlboJ9HPGX5fmbYshC3sH8afzEZXXFDu2mb1T0AmuerGM4mOlrxrlQqqERR/DzGxipidnX5P/1XueZfxceYqbVdVLhkI= 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=DxFhOxVk; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=e2Y9dfcX; arc=none smtp.client-ip=205.220.168.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="DxFhOxVk"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="e2Y9dfcX" Received: from pps.filterd (m0279864.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67I34Ddl3299176 for ; Tue, 18 Aug 2026 06:39:42 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= s9l4mDPEH4t3IYZQoGYBXeULBj6e1vAAeVBjHlUHAzU=; b=DxFhOxVk0YabJkVv pae1l89uibT1ZZLpJ++qCTjPRPnU7FzRxIjsZJ1h4VGHp4zibS+IQNdhOFKGJTHe vpHLyhjgqPrkDjVIpa/sqjXf8YmEsLlJTGrAI/i6yRMJdv5Q5qmAMh8pt1H0XRV0 rw0Vu5tv8CFpyJmOJrRbS0l+it2lvGcxPZsnOioA9d7E6LT8OGfX6vMk/fzge3jT h65gAlVlsWtOi20TV0U0ezhT/sCUY8YyU8qgUEy/q7SxmXNQ1BJcZa3GtpnfpULz 5tZ8JOFLOgd/72QkquE/HWvX+RqrG7NmP6A+X8TCiEgfntsejTifufUw2N082q1l FuU63w== Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4g4f5prue1-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 18 Aug 2026 06:39:41 +0000 (GMT) Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-2cc640dfde3so54183745ad.1 for ; Mon, 17 Aug 2026 23:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1787035181; x=1787639981; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=s9l4mDPEH4t3IYZQoGYBXeULBj6e1vAAeVBjHlUHAzU=; b=e2Y9dfcXvAiqosMwGvvfbf4lqzZl4ZHR0tSaAUE5XiHSQocHVoux/zIBrHn7pdSnLR 3S6vPvXjhR3FJCm+pCXarGJtCZfeEBBp3RUGEbNq0GuL5xkVxtJdlO9Ws9GQ+4El8VG8 8n7yyjNv3/H8+uwVhigorkI3QQy2DUU6IUgxplSpuINhF1aB+b8cBcKUcLGvytmbEmLg e7gsERki4yW76hqLZFmOH2wDzg9NtfukcArKuw1xXoE0dQ23gpHd5EwEvVMpXrJrmhH7 nllnYeJWwLRu7eViqN9h3KKassYpAwGoPPb+iYLwaCz8Pu1FdDyOrHvNz/b0D6vo2mms waiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787035181; x=1787639981; h=content-transfer-encoding:content-type:in-reply-to:from: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 :content-type; bh=s9l4mDPEH4t3IYZQoGYBXeULBj6e1vAAeVBjHlUHAzU=; b=N9Q4oQ7JiZ72w2vPJO9oNjUlJOb3Jp7TtmWOEqR33uj+z77XvR5lrSYZyo+LHt8S1F ucHms5S50f0Wdf5QupDa4VQ2dRGN+bW+GHWgY34ADqICYDxWskE/II1L6tSUmTkuTshQ CnE70yBff7DNSkcxYzi3cQFpRo3etv6b+s/8TrI/s5ZEJvgtWWpRzbi+gtzZXLNbLQ0U 8AFsWAcVVOrRHN0ia9V3cuYDjg5QWNuAQtSr3lOsFBjk/aUnhyfE7zFtxhtlVJqQR/Hf 4HcJWBdC4excKStmiT3SVp9yXC9mphQBDn9jy4KbaHE2EIeGvWq7u9j/qMT9PeF0tkJR NeTA== X-Forwarded-Encrypted: i=1; AHgh+RpztYULIwrPEktYR/YDRvBXyszlDXOQxM54IuUj/YP21tGZ8Hg1cUJZ9mE0NergmJSNuE3LU7L/6F90O/k=@vger.kernel.org X-Gm-Message-State: AOJu0Yyaxz0rjscJJn+Nqf26e8COswjwrxRe9wnjJcdFky7dD1oSWPp8 KlfDIhU8iue/HYxvl13DNennawV4g5UbQADLyJC7opA0sw2hGSqv26oLnNxSGrBg1awVds6Yb7G S25CRrMGwaeJg9bgvh734Cbw8fs4Nin3w71naEAim0DxTq0qwnrsbkC6Bjw5id9MHKcc= X-Gm-Gg: AR+sD12IzwUeh5ojR7axoKepfAGIVrcRoGbsmnq2pCHTzABovhs25eZiHMJgHEOON6N LxuY94CM+35Tl3sdw5vkvGQiUHedJj88TrxSD306xMGwgVjLmS0qLMbczpVC+pU0kpJDn/L64fN afImvo07oeipwd1TSty8Fd69vp7szVdjwdZEOqcH6MAE16vtzlp05rf9SKwZG6upEfDOUcnWRyi c/c4KaXbXZ26cnDplCiV8RzBXpQXqHJ6k6QPGrHqIjoou418T08HjvFCBqAc0QMkMhCSUrqbyka AXgk+7a/5qqZHFcknJjYFdWvbAQH6oCg2ZTIZ5uXpCDQulyHh2peU+B+c9OcmWMUyqfQV89h/Vg xwSklUR3/2iFdEOQgWfWIL5I= X-Received: by 2002:a17:90b:3147:b0:38f:1a2e:6e56 with SMTP id 98e67ed59e1d1-3933b8825fdmr28351623a91.9.1787035181183; Mon, 17 Aug 2026 23:39:41 -0700 (PDT) X-Received: by 2002:a17:90b:3147:b0:38f:1a2e:6e56 with SMTP id 98e67ed59e1d1-3933b8825fdmr28351580a91.9.1787035180701; Mon, 17 Aug 2026 23:39:40 -0700 (PDT) Received: from [10.239.97.207] ([114.94.8.21]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d5c1e8dc12sm10649375ad.56.2026.08.17.23.39.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Aug 2026 23:39:40 -0700 (PDT) Message-ID: Date: Tue, 18 Aug 2026 14:39:36 +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 v1] tty: n_tty: use kvzalloc/kvfree for line discipline data To: Greg KH Cc: jirislaby@kernel.org, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, liulzhao@qti.qualcomm.com, cheng.jiang@oss.qualcomm.com, cxin@qti.qualcomm.com References: <20260817135526.386863-1-xin.chen2@oss.qualcomm.com> <2026081706-tricky-slicing-166f@gregkh> <2026081841-relation-barn-304e@gregkh> From: Xin Chen In-Reply-To: <2026081841-relation-barn-304e@gregkh> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=S+/pBosP c=1 sm=1 tr=0 ts=6a83fe2d cx=c_pps a=cmESyDAEBpBGqyK7t0alAg==:117 a=Uz3yg00KUFJ2y2WijEJ4bw==:17 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=DJpcGTmdVt4CTyJn9g5Z:22 a=IRcymfdx-6Cw2LxaQ3QA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=1OuFwYUASf3TG4hYMiVC:22 X-Proofpoint-GUID: JHz3Z1SMWvgIF4CKqcBT_aMNqMhPwbyF X-Proofpoint-ORIG-GUID: JHz3Z1SMWvgIF4CKqcBT_aMNqMhPwbyF X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODE4MDA0OCBTYWx0ZWRfX04iI1WYUgTq7 QkorEkEF8YE5XYlNVAcRRTAhCiEGuLfQLFtaIV6bH1cEFPeTTf5VCZr6Kh9M4jAANosvrJpAF9g 67TLR6lZPXm1pokddhVhPFYLIwmBstLrM0Xuq0v8FYfWn1NYOoMdV0zhdeNN4RwMYwWDI8kOE7H XFXY+W0CEAzUTFhaI+BVMka5tYDfAY5FwZn5hFcqyVxEQbI5qyzxIfTT0rljb9zb7xmLnDAejdz xSwpCPltgR8oFXPywrBJQsWNwxkimTMulLKYmp0Tb5OvbZQbHrVrUrrXfwd+03At5xfUel9XHKV Vx6FnjfO5y67rXh97JK4sNqHuKROgnuSvUvAF7zJznP0bZxajN9s0dSJlOw3u7kpxY5dM2VFmCo 4lCrGwr5mIfPZAyLE5mvhMyDEp9QEJS+C4GeFxwGkpfCu5NkpakeR8HuaxpZwSlIyZK8R/QYOrq bd8cIRPZ/frB2EgCCqA== X-Proofpoint-Spam-Info: AW1haW4tMjYwODE4MDA0OCBTYWx0ZWRfXwSdH52jk9PDN 30sdSTlb4wj0rnkszgWaxo2uyCn8272+yTaZL/4+IK3F+u399Bobc6L6h/wV4JLrT+HgQWMhYYp iOeoOvMyRFLfq9RV5tLjv2gZpuuytVQ= X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-17_04,2026-08-12_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 malwarescore=0 spamscore=0 lowpriorityscore=0 clxscore=1015 bulkscore=0 impostorscore=0 adultscore=0 priorityscore=1501 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608180048 On Mon, Aug 18, 2026, Greg KH wrote: > What specific "damage"? The specific damage is that hci_send_cmd_sync() calls skb_clone(hdev->sent_cmd, GFP_KERNEL) to set hdev->req_skb. If that clone fails, hdev->req_skb stays NULL.  When the firmware reply arrives, hci_req_cmd_complete() checks hdev->req_skb to find the registered completion callback; finding NULL, it never calls hci_cmd_sync_complete(), req_status stays HCI_REQ_PEND, and the waiter in __hci_cmd_sync_sk() times out with -ETIMEDOUT.  The command was sent and the firmware replied successfully — the damage is purely that the completion path is broken. > But it's not consuming them "unnecessarily" as the memory is needed. > Why not fix the root problem here of having this be called so many > times that you are running out of memory? The repeated calls are a normal consequence of the serdev open/close retry logic in the BT transport layer; constraining that would require changes in a different subsystem and would not address the underlying fragility.  The real question is why skb_clone(GFP_KERNEL) fails at all when the system is not truly OOM. > And why isn't memory being reclaimed properly if we do not have any > left in that free list?  The allocation can sleep, so it should be > always succeeding if the system isn't truly out of memory, as you > imply it is not. This is the crux of the issue.  vzalloc() allocates order-0 pages through vm_area_alloc_pages(), which takes the bulk allocation path (alloc_pages_bulk_noprof) for order-0.  The bulk allocator uses ALLOC_WMARK_LOW and does not perform direct reclaim — it is intentionally a fast, non-sleeping path.  When the low watermark check fails it falls through to goto failed, and vm_area_alloc_pages() falls back to single-page alloc_pages() calls which can reclaim. So vzalloc() itself can succeed even under pressure, but only after consuming whatever order-0 pages were available via the bulk path first. The problem is that skb_clone(GFP_KERNEL) in hci_send_cmd_sync() is a single kmalloc-backed allocation.  It does not retry on failure and has no reclaim loop of its own; if the zone is below the low watermark at the moment it runs, it fails and returns NULL.  The window is narrow but real: the bulk path in vzalloc() drains the PCP/buddy order-0 lists below the low watermark; skb_clone() runs before kswapd has had a chance to refill them; it fails silently. Switching to kvzalloc_obj() serves the ~10 KB n_tty_data from the kmalloc-16384 slab (an order-2 compound page), which does not touch the order-0 free list at all, eliminating the pressure window entirely. Thanks, Xin Chen