From: Xin Chen <xin.chen2@oss.qualcomm.com>
To: Greg KH <gregkh@linuxfoundation.org>
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
Subject: Re: [PATCH v1] tty: n_tty: use kvzalloc/kvfree for line discipline data
Date: Tue, 18 Aug 2026 11:31:14 +0800 [thread overview]
Message-ID: <d2aa3572-e3f3-44c1-816e-a95bbbc77abb@oss.qualcomm.com> (raw)
In-Reply-To: <2026081706-tricky-slicing-166f@gregkh>
On Mon, Aug 17, 2026, Greg KH wrote:
> So you run out of memory? That feels wrong.
Not a full OOM — just a transient exhaustion of order-0 pages caused
by repeated vzalloc() calls each draining the buddy order-0 free list.
The system recovers quickly, but the damage is already done by then.
> Why not just use a specific slab for this one structure if it is so
> important that it never run out?
kvzalloc() already achieves that: it tries kmalloc() first, which
serves the ~10 KB n_tty_data from the kmalloc-16384 slab (an order-2
compound page), leaving the order-0 free list intact. A dedicated slab
would add complexity without further benefit.
> Why was this using vzalloc() in the first place if it could fail?
Historically, ~10 KB was considered too large for kmalloc(), so
vzalloc() was used. kvzalloc() is the natural modern replacement: it
tries kmalloc() first and falls back to vmalloc() only on failure,
which is strictly better.
> And if it does fail, doesn't everything work properly, you just need
> to handle that failure in userspace correctly, right?
Even if the error were surfaced correctly to userspace, there is
nothing useful it can do. The actual failure here is that skb_clone()
in hci_send_cmd_sync() silently fails due to the depleted order-0
free list, leaving hdev->req_skb NULL. The firmware reply arrives and
is processed, but hci_req_cmd_complete() cannot find the completion
callback, so the waiter times out with -ETIMEDOUT. From userspace's
perspective this looks like a hardware or firmware timeout, not a
memory issue. Even if userspace retried BT enable, it would trigger
serdev_device_open() again, which calls n_tty_open() again, which
calls vzalloc() again — further draining the order-0 free list and
making recovery harder. The root fix is to stop consuming order-0
pages unnecessarily in the first place, which is exactly what
switching to kvzalloc() achieves.
Thanks,
Xin Chen
next prev parent reply other threads:[~2026-08-18 3:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 13:55 [PATCH v1] tty: n_tty: use kvzalloc/kvfree for line discipline data Xin Chen
2026-08-17 14:14 ` Greg KH
2026-08-18 3:09 ` Xin Chen
2026-08-18 6:05 ` Greg KH
2026-08-18 6:22 ` Xin Chen
2026-08-17 14:16 ` Greg KH
2026-08-17 14:49 ` Greg KH
2026-08-18 6:02 ` Xin Chen
2026-08-18 6:34 ` Greg KH
2026-08-18 6:58 ` Xin Chen
2026-08-18 7:34 ` Greg KH
2026-08-18 3:31 ` Xin Chen [this message]
2026-08-18 6:07 ` Greg KH
2026-08-18 6:39 ` Xin Chen
2026-08-18 7:03 ` [PATCH v2] " Xin Chen
2026-08-18 7:15 ` Jiri Slaby
2026-08-18 7:23 ` Xin Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d2aa3572-e3f3-44c1-816e-a95bbbc77abb@oss.qualcomm.com \
--to=xin.chen2@oss.qualcomm.com \
--cc=cheng.jiang@oss.qualcomm.com \
--cc=cxin@qti.qualcomm.com \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=liulzhao@qti.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.