linux-kernel - Re: [PATCH -next] lib: TEST_REF_TRACKER should depend on REF

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CANn89iJ2HjNqOM=yF0yCi5K8id7XY=nG-yoo-sJsv=ykaSNDnw@mail.gmail.com>
Date:   Wed, 15 Dec 2021 02:55:09 -0800
From:   Eric Dumazet <edumazet@...gle.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        netdev <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -next] lib: TEST_REF_TRACKER should depend on REF_TRACKER
 instead of selecting it

On Wed, Dec 15, 2021 at 2:41 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Eric,
>
> On Wed, Dec 15, 2021 at 11:24 AM Eric Dumazet <edumazet@...gle.com> wrote:
> > On Wed, Dec 15, 2021 at 2:10 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > > On Wed, Dec 15, 2021 at 10:51 AM Eric Dumazet <edumazet@...gle.com> wrote:
> > > > On Wed, Dec 15, 2021 at 1:36 AM Geert Uytterhoeven
> > > > <geert+renesas@...der.be> wrote:
> > > > > TEST_REF_TRACKER selects REF_TRACKER, thus enabling an optional feature
> > > > > the user may not want to have enabled.  Fix this by making the test
> > > > > depend on REF_TRACKER instead.
> > > >
> > > > I do not understand this.
> > >
> > > The issue is that merely enabling tests should not enable optional
> > > features, to prevent unwanted features sneaking into a product.
> >
> > if you do not want the feature, just say no ?
> >
> > # CONFIG_TEST_REF_TRACKER is not set
> > # CONFIG_NET_DEV_REFCNT_TRACKER is not set
> > # CONFIG_NET_NS_REFCNT_TRACKER is not set
> >
> > > If tests depend on features, all tests for features that are enabled can
> > > still be enabled (e.g. made modular, so they can be loaded when needed).
> > >
> > > > How can I test this infra alone, without any ref_tracker being selected ?
> > > >
> > > > I have in my configs
> > > >
> > > > CONFIG_TEST_REF_TRACKER=m
> > > > # CONFIG_NET_DEV_REFCNT_TRACKER is not set
> > > > # CONFIG_NET_NS_REFCNT_TRACKER is not set
> > > >
> > > > This should work.
> > >
> > > So you want to test the reference tracker, without having any actual
> > > users of the reference tracker enabled?
> >
> > Yes, I fail to see the problem you have with this.
> >
> > lib/ref_tracker.c is not adding intrusive features like KASAN.
>
> How can I be sure of that? ;-)
>
> > > Perhaps REF_TRACKER should become visible, cfr. CRC32 and
> > > the related CRC32_SELFTEST?
> >
> > I can not speak for CRC32.
> >
> > My point is that I sent a series, I wanted this series to be bisectable.
> >
> > When the test was added, I wanted to be able to use it right away.
> > (like compile it, and run it)
>
> Then you indeed need a way to force-enable the feature. For other
> library-like features, that is done by making the feature visible,
> cfr. CRC32.
>
> My point is that a user should be able to easily enable all available
> tests for all features he has wilfully enabled in his kernel config,
> without running into the risk of accidentally enabling more features.
> Hence a test should depend on the feature under test, not blindly
> enable the feature.

So you say that STACKDEPOT should be user selectable,
even if no layer is using it ?

I based my work on STACKDEPOT, not on EXT4