linux-kernel - Re: [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAG_fn=V8e8y1fbOaYUD5SfDSQ9+Tc3r7w6ZSoJ-ZNFJvvq-Aeg@mail.gmail.com>
Date:   Wed, 16 Dec 2020 14:34:36 +0100
From:   Alexander Potapenko <glider@...gle.com>
To:     Vijayanand Jitta <vjitta@...eaurora.org>
Cc:     Minchan Kim <minchan@...nel.org>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        dan.j.williams@...el.com, broonie@...nel.org,
        Masami Hiramatsu <mhiramat@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andrey Konovalov <andreyknvl@...gle.com>, qcai@...hat.com,
        ylal@...eaurora.org, vinmenon@...eaurora.org
Subject: Re: [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE

> > To reiterate, I think you don't need a tunable stack_hash_order
> > parameter if the only use case is to disable the stack depot.
> > Maybe it is enough to just add a boolean flag?
>
> There are multiple users of stackdepot they might still want to use
> stack depot but with a lower memory footprint instead of MAX_SIZE
> so, a configurable size might help here ?

Can you provide an example of a use case in which the user wants to
use the stack depot of a smaller size without disabling it completely,
and that size cannot be configured statically?
As far as I understand, for the page owner example you gave it's
sufficient to provide a switch that can disable the stack depot if
page_owner=off.

> > Or even go further and disable the stack depot in the same place that
> > disables page owner, as the user probably doesn't want to set two
> > flags instead of one?
> >
>
> Since, page owner is not the only user of stack depot we can't take that
> decision of disabling stack depot if page owner is disabled.

Agreed, but if multiple subsystems want to use stackdepot together, it
is even harder to estimate the total memory consumption.
How likely is it that none of them will need MAX_SIZE?

> >> Minchan,
> >> This should be fine right ? Do you see any issue with disabling
> >> stack depot completely ?
> >>
> >> Thanks,
> >> Vijay
> >>
> >>>> Thanks,
> >>>> Vijay
> >>>>
> >>>>>>> Thanks,
> >>>>>>> Vijay
> >>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Vijay
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> >>>>>>>>> member of Code Aurora Forum, hosted by The Linux Foundation
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> >>>>>>> member of Code Aurora Forum, hosted by The Linux Foundation
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> >>>> member of Code Aurora Forum, hosted by The Linux Foundation
> >>>
> >>>
> >>>
> >>
> >> --
> >> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> >> member of Code Aurora Forum, hosted by The Linux Foundation
> >
> >
> >
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member of Code Aurora Forum, hosted by The Linux Foundation



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg