On Mon, Oct 9, 2023 at 12:10 PM Alexander Potapenko <glider@xxxxxxxxxx> wrote:
>
> On Wed, Sep 13, 2023 at 7:17 PM <andrey.konovalov@xxxxxxxxx> wrote:
> >
> > From: Andrey Konovalov <andreyknvl@xxxxxxxxxx>
> >
> > Change the bool can_alloc argument of __stack_depot_save to a
> > u32 argument that accepts a set of flags.
> >
> > The following patch will add another flag to stack_depot_save_flags
> > besides the existing STACK_DEPOT_FLAG_CAN_ALLOC.
> >
> > Also rename the function to stack_depot_save_flags, as __stack_depot_save
> > is a cryptic name,
> >
> > Signed-off-by: Andrey Konovalov <andreyknvl@xxxxxxxxxx>
> Reviewed-by: Alexander Potapenko <glider@xxxxxxxxxx>
> (assuming you'll address Marco's comment)
>
> ...
>
> > void kasan_record_aux_stack_noalloc(void *addr)
> > {
> > - return __kasan_record_aux_stack(addr, false);
> > + return __kasan_record_aux_stack(addr, 0);
>
> Maybe make the intent to not allocate more explicit by declaring some
> STACK_DEPOT_FLAG_CAN_NOT_ALLOC = 0?
> (Leaving this up to you)
The next patch adds another flag, so STACK_DEPOT_FLAG_CAN_NOT_ALLOC is
probably not the best name. I could add something like
STACK_DEPOT_FLAG_NONE, but I think this might create an impression
that there's some kind of NONE flag that affects the behavior of
stack_depot_save_flags in a special way.
I think we can just keep the value as 0, as it seems what the kernel
does in similar cases. E.g. for slab_flags_t, the kernel passes 0 to
kmem_cache_create when there are no special flags required.
Thanks!
