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

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Aug 18, 2026 at 11:31:14AM +0800, Xin Chen wrote:
> 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.

What specific "damage"?

> > 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.

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?

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 truely out of memory, as you imply it is
not.

thanks,

greg k-h