linux-kernel - Re: [RFC 0/6] Regressions for "imply" behavior change

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: <CAK8P3a3Wx5_bUOKnN3_hG5nLOqv3WCUtMSq6vOkJzWZgsmAz+A@mail.gmail.com>
Date:   Thu, 16 Apr 2020 09:20:40 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Saeed Mahameed <saeedm@...lanox.com>
Cc:     "narmstrong@...libre.com" <narmstrong@...libre.com>,
        "masahiroy@...nel.org" <masahiroy@...nel.org>,
        "Laurent.pinchart@...asonboard.com" 
        <Laurent.pinchart@...asonboard.com>,
        "leon@...nel.org" <leon@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "nico@...xnic.net" <nico@...xnic.net>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "kieran.bingham+renesas@...asonboard.com" 
        <kieran.bingham+renesas@...asonboard.com>,
        "jani.nikula@...ux.intel.com" <jani.nikula@...ux.intel.com>,
        "a.hajda@...sung.com" <a.hajda@...sung.com>,
        "jonas@...boo.se" <jonas@...boo.se>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "airlied@...ux.ie" <airlied@...ux.ie>,
        "jgg@...pe.ca" <jgg@...pe.ca>,
        "jernej.skrabec@...l.net" <jernej.skrabec@...l.net>
Subject: Re: [RFC 0/6] Regressions for "imply" behavior change

On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed <saeedm@...lanox.com> wrote:
>
> On Tue, 2020-04-14 at 20:47 +0200, Arnd Bergmann wrote:
> > On Tue, Apr 14, 2020 at 7:49 PM Saeed Mahameed <saeedm@...lanox.com>
> > wrote:
> > > On Tue, 2020-04-14 at 17:25 +0200, Arnd Bergmann wrote:
> > > > On Tue, Apr 14, 2020 at 5:23 PM Jason Gunthorpe <jgg@...pe.ca>
> > > > wrote:
> > > > Correct.
> > > >
> > >
> > > Great !
> > >
> > > Then bottom line we will change mlx5/Kconfig: to
> > >
> > > depends on VXLAN || !VXLAN
> >
> > Ok
> >
>
> BTW how about adding a new Kconfig option to hide the details of
> ( BAR || !BAR) ? as Jason already explained and suggested, this will
> make it easier for the users and developers to understand the actual
> meaning behind this tristate weird condition.
>
> e.g have a new keyword:
>      reach VXLAN
> which will be equivalent to:
>      depends on VXLAN && !VXLAN

I'd love to see that, but I'm not sure what keyword is best. For your
suggestion of "reach", that would probably do the job, but I'm not
sure if this ends up being more or less confusing than what we have
today.

> > > This will force MLX5_CORE to m when necessary to make vxlan
> > > reachable
> > > to mlx5_core.  So no need for explicit use of IS_REACHABLE().
> > > in mlx5 there are 4 of these:
> > >
> > >         imply PTP_1588_CLOCK
> > >         imply VXLAN
> > >         imply MLXFW
> > >         imply PCI_HYPERV_INTERFACE
> >
> > As mentioned earlier, we do need to replace the 'imply
> > PTP_1588_CLOCK'
> > with the same
> >
> >          depends on PTP_1588_CLOCK || !PTP_1588_CLOCK
> >
> > So far I have not seen problems for the other two options, so I
> > assume they
> > are fine for now -- it seems to build just fine without
> > PCI_HYPERV_INTERFACE,
> > and MLXFW has no other dependencies, meaning that 'imply' is the
> > same as 'select' here. Using 'select MLXFW' would make it clearer
> > perhaps.
>
> No, I would like to avoid select and allow building mlx5 without MLXFW,
> MLXFW already has a stub protected with IS_REACHABLE(), this is why we
> don't have an issue with it.

So the 'imply MLXFW' should be dropped then?

        Arnd