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

On Tue, Aug 18, 2026 at 02:02:43PM +0800, Xin Chen wrote:
> 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().

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.

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

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?

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

Again, that sounds like a bluetooth issue, and why can't you just
properly handle the skb out of memory issue?

This feels like papering over the real problem.

> > And no cc: stable or Fixes: tag?
> 
> Both will be added in v2:
> 
>   Fixes: ebec3f8f5271 ("n_tty: Access echo_* variables carefully.")

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.

thanks,

greg k-h