Re: [PATCH v1] tty: n_tty: use kvzalloc/kvfree for line discipline data

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