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: <05fd5be4-a969-2b7f-52e4-754d9651a280@ti.com>
Date:   Mon, 18 May 2020 21:13:54 +0300
From:   Grygorii Strashko <grygorii.strashko@...com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        <linux-kernel@...r.kernel.org>
CC:     <stable@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>,
        Richard Cochran <richardcochran@...il.com>,
        Nicolas Pitre <nico@...xnic.net>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Clay McClure <clay@...mons.net>,
        "David S. Miller" <davem@...emloft.net>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 5.6 019/194] net: Make PTP-specific drivers depend on
 PTP_1588_CLOCK

Hi Greg,

On 18/05/2020 20:35, Greg Kroah-Hartman wrote:
> From: Clay McClure <clay@...mons.net>
> 
> [ Upstream commit b6d49cab44b567b3e0a5544b3d61e516a7355fad ]
> 
> Commit d1cbfd771ce8 ("ptp_clock: Allow for it to be optional") changed
> all PTP-capable Ethernet drivers from `select PTP_1588_CLOCK` to `imply
> PTP_1588_CLOCK`, "in order to break the hard dependency between the PTP
> clock subsystem and ethernet drivers capable of being clock providers."
> As a result it is possible to build PTP-capable Ethernet drivers without
> the PTP subsystem by deselecting PTP_1588_CLOCK. Drivers are required to
> handle the missing dependency gracefully.
> 
> Some PTP-capable Ethernet drivers (e.g., TI_CPSW) factor their PTP code
> out into separate drivers (e.g., TI_CPTS_MOD). The above commit also
> changed these PTP-specific drivers to `imply PTP_1588_CLOCK`, making it
> possible to build them without the PTP subsystem. But as Grygorii
> Strashko noted in [1]:
> 
> On Wed, Apr 22, 2020 at 02:16:11PM +0300, Grygorii Strashko wrote:
> 
>> Another question is that CPTS completely nonfunctional in this case and
>> it was never expected that somebody will even try to use/run such
>> configuration (except for random build purposes).
> 
> In my view, enabling a PTP-specific driver without the PTP subsystem is
> a configuration error made possible by the above commit. Kconfig should
> not allow users to create a configuration with missing dependencies that
> results in "completely nonfunctional" drivers.
> 
> I audited all network drivers that call ptp_clock_register() but merely
> `imply PTP_1588_CLOCK` and found five PTP-specific drivers that are
> likely nonfunctional without PTP_1588_CLOCK:
> 
>      NET_DSA_MV88E6XXX_PTP
>      NET_DSA_SJA1105_PTP
>      MACB_USE_HWSTAMP
>      CAVIUM_PTP
>      TI_CPTS_MOD
> 
> Note how these symbols all reference PTP or timestamping in their name;
> this is a clue that they depend on PTP_1588_CLOCK.
> 
> Change them from `imply PTP_1588_CLOCK` [2] to `depends on PTP_1588_CLOCK`.
> I'm not using `select PTP_1588_CLOCK` here because PTP_1588_CLOCK has
> its own dependencies, which `select` would not transitively apply.
> 
> Additionally, remove the `select NET_PTP_CLASSIFY` from CPTS_TI_MOD;
> PTP_1588_CLOCK already selects that.
> 
> [1]: https://lore.kernel.org/lkml/c04458ed-29ee-1797-3a11-7f3f560553e6@ti.com/
> 
> [2]: NET_DSA_SJA1105_PTP had never declared any type of dependency on
> PTP_1588_CLOCK (`imply` or otherwise); adding a `depends on PTP_1588_CLOCK`
> here seems appropriate.
> 
> Cc: Arnd Bergmann <arnd@...db.de>
> Cc: Richard Cochran <richardcochran@...il.com>
> Cc: Nicolas Pitre <nico@...xnic.net>
> Cc: Grygorii Strashko <grygorii.strashko@...com>
> Cc: Geert Uytterhoeven <geert@...ux-m68k.org>
> Fixes: d1cbfd771ce8 ("ptp_clock: Allow for it to be optional")
> Signed-off-by: Clay McClure <clay@...mons.net>
> Signed-off-by: David S. Miller <davem@...emloft.net>
> Signed-off-by: Sasha Levin <sashal@...nel.org>
> ---

Could you drop this patch, pls?
it's not for stable and can cause build failures.

-- 
Best regards,
grygorii

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ