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

[Xin Chen]

On Mon, Aug 17, 2026, Greg KH wrote:
> Also, you are papering over the real problem here.  If this one
> allocation is failing, what keeps the next one from failing and then
> the skb will not be able to be allocated?

The key difference is allocation size and allocator behavior.
vzalloc() always allocates page-by-page from the buddy order-0 free
list, so two back-to-back vzalloc() calls for ~10 KB each consume
~5 order-0 pages each, transiently depleting the order-0 free list.
kvzalloc() serves the same ~10 KB from the kmalloc-16384 slab, which
is backed by order-2 compound pages — a completely separate pool from
the order-0 pages that skb_clone(GFP_KERNEL) needs. So switching to
kvzalloc() eliminates the interference between n_tty_open() and
skb_clone().

> Why is the system so out of memory in this slab that this is
> happening?  What changed in the tty layer to cause this?  Or did it
> happen elsewhere?

Nothing changed recently in the tty layer. vzalloc() has been used
here since commit ebec3f8f5271 ("n_tty: Access echo_* variables
carefully.", 2018), which replaced vmalloc() with vzalloc(). The
issue surfaces only when serdev_device_open() is called multiple times
in quick succession (as happens during BT UART transport init),
triggering multiple n_tty_open() calls back-to-back. Each vzalloc()
drains order-0 pages, and the window where skb_clone() fails is
narrow but reproducible under this specific pattern. It was found
during a BT enable-disable sanity test that repeatedly cycles BT on
and off, which consistently triggers the back-to-back n_tty_open()
calls that expose the issue.

> And no cc: stable or Fixes: tag?

Both will be added in v2:

  Fixes: ebec3f8f5271 ("n_tty: Access echo_* variables carefully.")
  Cc: stable@xxxxxxxxxxxxxxx

Thanks,
Xin Chen