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 16D5036E466 for ; Tue, 18 Aug 2026 06:58:50 +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=1787036336; cv=none; b=TZCODvIbOavry3ExoZ38ckRBuT0TwJmtxklrMPi8kacO6agInVB7nrMg0SEjEsr1xBWoP0pxQbkER73IC8yGUXxx9YFm1cRQw4Cz5djfNuM+QXwOahjdKu48TCqCeiO9rSq9wGtJ5ZqDDs+mz571ptKEnIh5KnSf82W0dfaNF4c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787036336; c=relaxed/simple; bh=sCppY9oplS9I77Rlb4PwXNSC0fTQ9KiH7dzOsgxLOPM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gxunOUwSuPmyRgML3tOO7SpDQsbXcvXRAWdT8e3aNRhhgG/UB1bDthxECnwQpwJiRdOEXyrwiKr+LwGBLVUzoj3vRZHu4TLcY6jM9Iw5TD0+IVcTu2La+jcYmgBGQkpbNwtScQvDF4OaIGijl3Z4DoC6970/lZMVevgp5iCRTYM= 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=PB8GkTnk; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=SjDJkm+I; 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="PB8GkTnk"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="SjDJkm+I" Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67I28S4A2884748 for ; Tue, 18 Aug 2026 06:58:47 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= sCppY9oplS9I77Rlb4PwXNSC0fTQ9KiH7dzOsgxLOPM=; b=PB8GkTnkBCB6yCrt RC7YyWQhkE0lgkdWvNodkm3CkK1wgAmW1ZbNrZg4ffu7O1/rJLj3ljfKfv+8ZirO WAEl5zokfsxcpwxslafE44CQdToTlcVGBhhANiC2JbFs+liE82GgTcxMixAp44gE 1Ux5O4to8TSszY6DtBpDjeSSkI2nh/ssp2iX2uLOOdZ21dHMVwFD4Te/xkzvLSyX 1xC/iL2y8rohgTqFAX3jjByFsZVWBC09Ea15F0DLkvfhGw2tFcxx9OCYAdA1aZVD TcsLs2vfgmyjivkkkDIFL4hYQJ7Mc1tjeXTbSiP6yWK2KTGFSiIjmFnUwPuoAEhs G/LJVg== Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4g4ebps4s8-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 18 Aug 2026 06:58:47 +0000 (GMT) Received: by mail-pg1-f197.google.com with SMTP id 41be03b00d2f7-ca124bf0189so565538a12.0 for ; Mon, 17 Aug 2026 23:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1787036326; x=1787641126; 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=sCppY9oplS9I77Rlb4PwXNSC0fTQ9KiH7dzOsgxLOPM=; b=SjDJkm+IMM0JgI8LrdKh3kB7Fbdx7aXPFCBNItrx5/UtOeIfNKN790jZB2WKA+hQoz 8ntAEOHK5QPSSt2fyYrsuO+v3xVLWnKpYR/XHyQjlBGT6KaM/47FbiQw0+hrsDO3qyFa cGxUrJGycUfpRjTCq2fab9BOOKe1U0vs1wRlE2rvq8b+kJtNuw+Ib7NEJR4jwzAHVr2y snm77sPZOII/PrTPn6LwOMWZJVQa6NSbLZuSOFSfsikMN6q7QoqDSTHdu9eZEcNV9h0Q BG4W+MUq4PcvHFE/Ggjz4TWjbao0SkhDdX/2dHCxozjGviHPlCZCqqT3q24K2yFfqVxm /xNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787036326; x=1787641126; 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=sCppY9oplS9I77Rlb4PwXNSC0fTQ9KiH7dzOsgxLOPM=; b=hRDWk+7p21EwSAvNGs9W6cst9Xhhzgswgiayk8cozqRmTmjCddohh7DGEfC8Pp0tEI ICrZEr32pW5xupwIVCgBkA5BOfUQOBZBDn+/7QctxpdeWFEwuqr7OXcvjn6GI90yzn90 gmJjy/+J6wWHUXFHMbWUymHwos4//g+NUrU0B/HEHdndFpWFAbO9xAw00oBDGvJmNtuZ MYXtKbqkUxw86KcqZyOduNm+S5Am+HflvLpBp86KeGppitPDfT9Z6KpwIqCOtqyDlbrp S3tKJUT4PIm//A6ELBTJjsk9vBLqxKAmNl0EIUWk4YHGHz9lSG0R+R9g3hQhEgzd0lGr 1DjQ== X-Forwarded-Encrypted: i=1; AHgh+RoDeqxh8Imu9amxPqQMvZDjx+Zepu9jyQ+5WIIf1BVFUxi7qu6qYeFg3V2SAfEh6CjsMzuFDoGPgRTisKk=@vger.kernel.org X-Gm-Message-State: AOJu0YwVecnHOl2J5/c0wvh0wZMBeH7wVZf7QHCCh1U/AqQvPgtnXk3a DwZ8/xcM8sGs2eIv3/aEjfaL8QTRAQ2wj5tX1/hZirHC7XWudnkBsO4cscNmwBwvwpqaJ0fcYBD NifPb3zxg0mHAcxiw2MXwSnIptyKAqKo7vUigcx4EHDNIiczjm70MqNdXYAOpELjjSe0= X-Gm-Gg: AR+sD137iFwLPh0dxbVaor/CmWHKjZPi2U1iedkVvfDkJsy8Z3cRauiGKs6Akr+p+6r BmpPKoe9GoUzlb58qd9/p+uTZqdGCyf5IbChSvTSWSMjmx8SFKUiLG5sookluSxno6f4Du4F+Cu 87R4X9xTKomwF6YNXFAk/EGEMwlAv477jiGe8ITUdkLbMC0TeJvvJUn9/JwSJh+9YwOYPJ6FDu1 dOvOrXmhEaUwtpay3WlAaAN3hb3cCTkPWEW6yynMyPvOBuRJpEN1RqLQFjfNSAoj+Uwfwk8nUZs UWoUWaBnFxItlOFpoxf/fLTV4Fmx1Vk/LatAe1supf2FzB8c/WyFq9eIAWgos7THGUx5Jm6GtrW mZz2XmntYIWlaevl35NAxO3g= X-Received: by 2002:a17:90a:c88c:b0:38e:c232:9d2c with SMTP id 98e67ed59e1d1-39563856439mr2906842a91.2.1787036326271; Mon, 17 Aug 2026 23:58:46 -0700 (PDT) X-Received: by 2002:a17:90a:c88c:b0:38e:c232:9d2c with SMTP id 98e67ed59e1d1-39563856439mr2906803a91.2.1787036325718; Mon, 17 Aug 2026 23:58:45 -0700 (PDT) Received: from [10.239.97.207] ([114.94.8.21]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-394f818030asm5591927a91.3.2026.08.17.23.58.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Aug 2026 23:58:45 -0700 (PDT) Message-ID: <5c0fdf81-950c-427f-8327-a8b4b1ad922f@oss.qualcomm.com> Date: Tue, 18 Aug 2026 14:58:41 +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> <2026081747-secret-partly-158a@gregkh> <066081a1-e644-4b01-86c5-e5ab908a7754@oss.qualcomm.com> <2026081814-sash-sandbag-6e11@gregkh> From: Xin Chen In-Reply-To: <2026081814-sash-sandbag-6e11@gregkh> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: qA97TBf0UdAKJv0bZ3cnVtCgJIK_yyZW X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODE4MDA1MCBTYWx0ZWRfX2QqyYIZRgERx wS6O9gtXE5yWkRc9MQpciaAFOVFaUD4jTOtgQTwouT8w2QGZNMMZphkT+xJAQOLAHOfGMyVnm6s YdiSAnJDN8Sor/+Id9mXCV80yWKlcP3t9+w8Vej37CAMmi94pwEg/PFhg4sOKoWLIIychExS5tt f7CmG4k1RCBdQD6lJen2QmWuTGa/5VRwo3egpUTWdoQcO3bjgldpYnszB0X04nPcyfDeivkWENB fUyIRc1FBeX3qTenzG8RXCBnlV9kZLvJjgeuuhbX4kc2IwuEzd5a9k4EDrDkOV5H6aQIb+m8jwd tOCZ+yr+DhhJrE2iyUVRRJ/bhplQ9yUiW1BJhk2ULgL3L6nxy2GGtnD93QQ1VvsTdQPvrkHFegh WZYOzV1cGYdF+6Ef4bKdR4oH1M0lpUzz22sNZHvc2IUF3rw7rfwoRn0hYjt7elfIBs+VvDKliAH PC5MVHXIQc87fizHpIQ== X-Proofpoint-Spam-Info: AW1haW4tMjYwODE4MDA1MCBTYWx0ZWRfX3UkedeMM1SJ3 bcgx8GdiwixoFz3Su3YJVInHtFGfN2fVmViwZIcwjPbWbJGiEVyLQar4hZ2O43IXSTeB3O+DDhh 0/pnNETaLTITZek2LxmW6B2yzj6eyG8= X-Authority-Analysis: v=2.4 cv=FsU1OWrq c=1 sm=1 tr=0 ts=6a8402a7 cx=c_pps a=rz3CxIlbcmazkYymdCej/Q==:117 a=Uz3yg00KUFJ2y2WijEJ4bw==:17 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_glEPmIy2e8OvE2BGh3C:22 a=ji0Z8l6HprpF4QN2JWYA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=bFCP_H2QrGi7Okbo017w:22 X-Proofpoint-ORIG-GUID: qA97TBf0UdAKJv0bZ3cnVtCgJIK_yyZW 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 impostorscore=0 spamscore=0 phishscore=0 clxscore=1015 malwarescore=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 adultscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608180050 On Tue, Aug 18, 2026, Greg KH wrote: > But that's not a problem with the tty layer, if something else happens > to "drain" the pool again you can not create a skb.  You are not > solving the root problem here. You are right that this does not prevent every possible order-0 exhaustion. However, the specific and reproducible trigger is n_tty_open() consuming order-0 pages via vzalloc() immediately before skb_clone() runs. Eliminating that unnecessary pressure removes the failure in practice, even if it does not make skb_clone() immune to all possible memory pressure. > But that's not really a change, when was vmalloc() first used? > As nothing has changed here, then why is this suddenly showing up now? ldata was originally allocated with kzalloc() (introduced in commit 70ece7a73159, "TTY: n_tty, add ldisc data to n_tty", 2012).  Commit ebec3f8f5271 switched it to vmalloc()/vzalloc() in 2018 as a side effect of fixing an echo buffer race — the allocation change was incidental, not intentional.  The issue surfaces now because the BT enable-disable sanity test exercises a back-to-back open pattern that was not common before serdev-based UART transports became widespread. > Again, that sounds like a bluetooth issue, and why can't you just > properly handle the skb out of memory issue? The skb_clone() failure is silent — it returns NULL and the code continues without error, leaving hdev->req_skb NULL.  By the time the BT layer observes the problem (a -ETIMEDOUT 10 seconds later), it is several layers removed from the skb_clone() failure: the firmware has already replied successfully, hci_req_cmd_complete() has already run and found req_skb NULL, and the completion callback was never invoked.  At that point the BT layer has no way to distinguish a memory failure from a genuine firmware timeout, let alone recover from it.  And even if the NULL req_skb were detected and surfaced as an error immediately, there is nothing the BT layer could do to recover — it cannot reclaim memory or retry the allocation itself.  The only option would be to wait for the memory to be reclaimed and retry the entire BT enable sequence from userspace, which is exactly the kind of fragile error handling we want to avoid.  The tty change is simpler and correct: ldata was originally a kzalloc() allocation and there is no reason for it to use vmalloc-backed pages that interfere with unrelated allocations. > No, that did not change the behavior of the tty call here to use a > different pool, all it did was change the zeroing out of the buffer > allocated. You are correct, I apologize for the wrong Fixes: tag.  The switch from kzalloc() to vmalloc() was introduced by commit 20bafb3d23d1 ("n_tty: Move buffers into n_tty_data", 2013), which merged the read_buf and echo_buf (each 4 KB) into n_tty_data, making the structure too large for kmalloc() at the time.  That is the correct Fixes: tag.  I will update it in v2:   Fixes: 20bafb3d23d1 ("n_tty: Move buffers into n_tty_data") Thanks, Xin