Re: [PATCH RFC 02/20] ctlv: Add the UAPI wire format and family API

[Yeoreum Yun]

> Tue, Oct 27, 2026 at 04:17:29PM +0100, jgg@xxxxxxxx wrote:
> >On Tue, Oct 27, 2026 at 02:48:19PM +0000, Yeoreum Yun wrote:
> >> > On Tue, Oct 27, 2026 at 09:02:14AM +0100, Jiri Pirko wrote:
> >> > > Mon, Oct 26, 2026 at 07:55:12PM +0100, yeoreum.yun@xxxxxxx wrote:
> >> > > >[    3.856919]  ctlv_schema_check_attr+0x3dc/0x538
> >> > > >[    3.857105]  ctlv_schema_check_indexed_nest+0x788/0x958
> >> > > >[    3.857301]  ctlv_schema_validate+0x88/0x180
> >> > > >[    3.857482]  ctlv_msg_test_as_deep_as_the_core_allows+0x11c/0x1e8
> >> > > >[    3.857698]  kunit_try_run_case+0x64/0x188
> >> > > >[    3.857878]  kunit_generic_run_threadfn_adapter+0x30/0x68
> >> > > >[    3.858086]  kthread+0x10c/0x140
> >> > > >[    3.858245]  ret_from_fork+0x10/0x20
> >> > > >[    3.858398] SMP: stopping secondary CPUs
> >> > > >[    3.858630] Kernel Offset: disabled
> >> > > >[    3.858720] CPU features: 0x0,00000000,00b0802e,9f190bc3,2affe72f
> >> > > >[    3.858872] Memory Limit: none
> >> > > >[    3.858976] ---[ end Kernel panic - not syncing: kernel stack overflow ]---
> >> > > >
> >> > > >[...]
> >> > > >
> >> > > >I think it might be good to configurable according to architecture
> >> > > >unless it's not good to reduce the CTLV_MAX_NEST_DEPTH number
> >> > > >otherwise, increasing stack size when CTLV is enabled seems unresonable...
> >> > > 
> >> > > Agreed, will lower it down. I think we should be okay with 8 for start.
> >> > 
> >> > I'm surprised this ran out of stack though with even as few as
> >> > 32 levels.. Is there accidently something large on the stack?
> >> >
> >> 
> >> Nope.
> >> 
> >> When I see the each functions stack allocation:
> >> - ctlv_schema_check_indexed_nest():
> >> 	sub	sp, sp, #0xf0 // 240 bytes
> >> 
> >> - ctlv_schema_check_attr():
> >> 	sub	sp, sp, #0xb0 // 176 bytes
> >> 
> >> Roughly (240 + 176) * CTLV_MAX_NEST_DEPTH = 13,952 (around 14KB)
> >> consumed.
> >
> >400 bytes per nest seems pretty big to me...
> >
> >Do you have debug options enabled or something that increases stack usage?
> 
> KASAN is such an option. On arm64 with GCC 15, the stack protector and
> zero-initialized stack variables, ctlv_schema_check_indexed_nest() takes
> 208 bytes and ctlv_schema_check_attr() 144 without KASAN. With generic
> KASAN, which instruments the stack with GCC, they take 432 and 304: the
> redzones around every local whose address is taken more than double both
> frames. Your numbers are in between, I guess a different compiler or
> KASAN mode.
> 
> Otherwise there is nothing large on the stack. 96 of the 208 bytes hold
> the callee-saved registers, the rest are small locals and spills. It is
> just two frames per nesting level.
> With the limit lowered to 8, validation at the maximum depth takes about
> 3KB, about 6KB with generic KASAN.

TBH, I'm bit of surprised since I'm not using GENERIC option but with HW
(MTE). Do you mean this with KASAN HW_TAG?
might the GENERIC and SW_TAG would be, but I don't expected with HW_TAG.


-- 
Sincerely,
Yeoreum Yun