这个问题我之前调试USB驱动时也踩过类似的坑，核心原因和内核栈的特性以及usb_bulk_msg的工作机制脱不了干系，具体可以拆解成这几个关键点：

1. 内核栈的大小限制与隐性溢出风险 #

内核态的栈空间远比用户态小，通常是4KB或8KB（取决于架构和内核配置）。你在usb_write里定义的char wbuf[512]看起来占空间不大，但要注意：内核函数调用本身会占用栈空间——比如函数参数、返回地址、寄存器备份、其他局部变量，要是你的驱动还有嵌套调用，或者当前栈已经被其他操作占用了一部分，512字节的数组很容易触发隐性栈溢出。

当数据长度在8字节以内时，栈的总使用量还没突破临界值，传输能正常完成；但数据超过8字节后，栈的占用量触发了溢出，破坏了usb_bulk_msg内部的栈帧数据，导致传输逻辑出错，最终表现为超时。而kzalloc分配的堆空间属于系统堆，没有栈的大小限制，自然能处理更大的数据包。

2. 缓冲区的生命周期与跨上下文访问问题 #

usb_bulk_msg是同步传输函数，内部会提交URB（USB请求块）并等待其完成。这里有个容易忽略的点：栈上的缓冲区仅在当前函数栈帧有效，如果URB的处理涉及中断上下文（大部分USB控制器都是中断驱动的），当中断触发时，当前的函数栈帧可能已经被修改，栈缓冲区的内容也可能被覆盖。

而堆分配的缓冲区是全局有效的（直到你调用kfree释放），不会因为函数栈帧的变化而失效，所以能稳定支持跨上下文的URB操作，不会出现传输超时的问题。

3. 内存对齐要求的隐性触发 #

部分USB控制器对传输缓冲区的内存对齐有严格要求（比如需要对齐到8字节、16字节甚至更大的边界）。栈上的数组虽然是连续的，但内核栈的起始地址和数组的对齐方式可能刚好不符合控制器的要求：短数据时，对齐问题没影响硬件读取；但数据变长后，对齐错误导致硬件无法正确解析缓冲区内容，最终触发传输超时。

kzalloc默认会按照内核的内存对齐规则分配内存，通常能满足USB控制器的对齐要求，所以堆缓冲区不会遇到这个问题。

验证建议 #

你可以试试这两个方法来确认原因：

• 把栈上的wbuf改小（比如char wbuf[64]），测试超过8字节但小于64字节的数据包是否能正常发送；
• 给栈数组加上对齐属性：char wbuf[512] __aligned(16);，如果传输恢复正常，说明是对齐问题导致的。

总结 #

内核栈虽然使用方便，但在驱动开发中，只要涉及到较大的缓冲区、需要跨上下文使用的缓冲区，一定要用堆分配（kzalloc/kmalloc），避免栈溢出、生命周期失效或对齐问题带来的隐性bug。

内容的提问来源于stack exchange，提问作者Jiawei liu