linux-kernel - Re: Re: [PATCH V4 net-bugfixs] net/ethernet: Update ret when ptp

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: <CAK8P3a3V98x3s7DvHtutiz97Q=5QjfS6Xn4kH2r2iamY3dzwkw@mail.gmail.com>
Date:   Fri, 13 Nov 2020 17:21:43 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     王擎 <wangqing@...o.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Grygorii Strashko <grygorii.strashko@...com>,
        "David S. Miller" <davem@...emloft.net>,
        Samuel Zou <zou_wei@...wei.com>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Ivan Khoronzhuk <ivan.khoronzhuk@...aro.org>,
        Networking <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Re: [PATCH V4 net-bugfixs] net/ethernet: Update ret when
 ptp_clock is ERROR

On Fri, Nov 13, 2020 at 12:27 AM Richard Cochran
<richardcochran@...il.com> wrote:
>
> On Thu, Nov 12, 2020 at 10:21:21PM +0100, Arnd Bergmann wrote:
> > I agree that the 'imply' keyword in Kconfig is what made this a
> > lot worse, and it would be best to replace that with normal
> > dependencies.
>
> IIRC, this all started with tinification and wanting dynamic posix
> clocks to be optional at compile time.
>
> I would like to simplify this whole mess:
>
> - restore dynamic posix clocks to be always included
>
> - make PHC always included when the MAC has that feature (by saying
>   "select" in the MAC Kconfig) -- I think this is what davem had
>   wanted back in the day ...
>
> I'm not against tinification in principle, but I believe it is a lost
> cause.

My preference would be to avoid both 'select' and 'imply' here,
both of them cause their own set of problems. The main downside
of 'select' is that you can't mix it with 'depends on' without risking
running into circular dependencies and impossible configurations,
while the main problem with 'imply' is that the behavior is close to
unpredictable. The original definition still made some sense to me,
but the new definition of 'imply' seems completely meaningless.

I've prototyped a patch that I think makes this more sensible
again: https://pastebin.com/AQ5nWS9e

This needs testing, but if you think the approach makes sense,
I can give it a few randconfig builds and submit for wider review.

       Arnd