On Fri, Dec 3, 2021 at 1:09 PM Marco Elver <elver@xxxxxxxxxx> wrote:
>
> On Tue, Nov 30, 2021 at 11:08PM +0100, andrey.konovalov@xxxxxxxxx wrote:
> [...]
> > enum kasan_arg_stacktrace {
> > KASAN_ARG_STACKTRACE_DEFAULT,
> > KASAN_ARG_STACKTRACE_OFF,
> > @@ -40,6 +46,7 @@ enum kasan_arg_stacktrace {
> >
> > static enum kasan_arg kasan_arg __ro_after_init;
> > static enum kasan_arg_mode kasan_arg_mode __ro_after_init;
> > +static enum kasan_arg_vmalloc kasan_arg_vmalloc __ro_after_init;
> > static enum kasan_arg_stacktrace kasan_arg_stacktrace __ro_after_init;
>
> It just occurred to me that all of these (except kasan_arg_mode) are
> only used by __init functions, so they could actually be marked
> __initdata instead of __ro_after_init to free up some bytes after init.
*Except kasan_arg_mode and kasan_arg. Both are accessed by
kasan_init_hw_tags_cpu(), which is not __init to support hot-plugged
CPUs.
However, kasan_arg_stacktrace and kasan_arg_vmalloc can indeed be
marked as __initdata, will do in v2.
> [...]
> > + switch (kasan_arg_vmalloc) {
> > + case KASAN_ARG_VMALLOC_DEFAULT:
> > + /* Default to enabling vmalloc tagging. */
> > + static_branch_enable(&kasan_flag_vmalloc);
> > + break;
> > + case KASAN_ARG_VMALLOC_OFF:
> > + /* Do nothing, kasan_flag_vmalloc keeps its default value. */
> > + break;
> > + case KASAN_ARG_VMALLOC_ON:
> > + static_branch_enable(&kasan_flag_vmalloc);
> > + break;
> > + }
>
> The KASAN_ARG_STACKTRACE_DEFAULT and KASAN_ARG_VMALLOC_ON cases can be
> combined.
Will do in v2.
Thanks!
