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

[Yeoreum Yun]

On Thu, Nov 05, 2026 at 01:51:44PM +0000, Yeoreum Yun wrote:
> > 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.

JFYI, When I check again without KASAN HW_TAG and clang-23:

  ctlv_schema_check_indexed_nest() -> 240 bytes
  ctlv_schema_check_attr() -> 176 bytes

This is no difference with KASAN HW_TAG.

Anyway, limit depth to 8 seems valid for me.

Thanks!

-- 
Sincerely,
Yeoreum Yun