From: Xin Chen <xin.chen2@oss.qualcomm.com>
To: Jiri Slaby <jirislaby@kernel.org>, gregkh@linuxfoundation.org
Cc: linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
stable@vger.kernel.org, liulzhao@qti.qualcomm.com,
cheng.jiang@oss.qualcomm.com, cxin@qti.qualcomm.com
Subject: Re: [PATCH v2] tty: n_tty: use kvzalloc/kvfree for line discipline data
Date: Tue, 18 Aug 2026 15:23:20 +0800 [thread overview]
Message-ID: <53126b4a-09a9-443b-bfb5-e7285494aa7a@oss.qualcomm.com> (raw)
In-Reply-To: <2e072c67-9d42-409a-8c24-82e88dd01418@kernel.org>
On Tue, Aug 18, 2026, Jiri Slaby wrote:
> Switching from order-0 to order-2? If you ran out of vmspace on some
> 32bit platform, perhaps. But you apparently did not. So all this
> feels odd.
To clarify: the concern is not vmalloc address space exhaustion.
The issue is that vzalloc() allocates order-0 pages from the buddy
allocator via the bulk allocation path (alloc_pages_bulk_noprof),
which uses ALLOC_WMARK_LOW and does not perform direct reclaim.
When two back-to-back vzalloc() calls drain enough order-0 pages
to push the zone below the low watermark, a subsequent
skb_clone(GFP_KERNEL) in hci_send_cmd_sync() fails silently,
leaving hdev->req_skb NULL and causing BT enable to time out with
-ETIMEDOUT.
kvzalloc_obj() serves the ~10 KB n_tty_data from the kmalloc-16384
slab, which is backed by order-2 compound pages — a separate pool
that does not deplete the order-0 free list that skb_clone() depends
on. The commit message could have been clearer on this point; I will
improve it in the next version.
Thanks,
Xin Chen
next prev parent reply other threads:[~2026-08-18 7:23 UTC|newest]
Thread overview: 20+ 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-21 8:06 ` Xin Chen
2026-08-18 3:31 ` Xin Chen
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 [this message]
2026-08-21 6:48 ` kernel test robot
2026-08-21 8:35 ` kernel test robot
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=53126b4a-09a9-443b-bfb5-e7285494aa7a@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 \
--cc=stable@vger.kernel.org \
/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.