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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 25 Apr 2020 19:41:48 -0700 From: Clay McClure <clay@...mons.net> To: Grygorii Strashko <grygorii.strashko@...com> Cc: Arnd Bergmann <arnd@...db.de>, Richard Cochran <richardcochran@...il.com>, "David S. Miller" <davem@...emloft.net>, Sekhar Nori <nsekhar@...com>, Networking <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] net: cpts: Condition WARN_ON on PTP_1588_CLOCK On Wed, Apr 22, 2020 at 02:16:11PM +0300, Grygorii Strashko wrote: > > On 21/04/2020 00:42, Arnd Bergmann wrote: > > > > On Mon, Apr 20, 2020 at 11:34 PM Richard Cochran > > > > > > To be clear, do you all see a need to change the stubbed version of > > > ptp_clock_register() or not? > > > > No, if the NULL return is only meant to mean "nothing wrong, keep going > > wihtout an object", that's fine with me. It does occasionally confuse driver > > writers (as seen here), so it's not a great interface, but there is no general > > solution to make it better. That's why in my first patch I condition the WARN_ON() on PTP_1588_CLOCK, since without that the null pointer here is not an error: void cpts_unregister(struct cpts *cpts) { if (WARN_ON(!cpts->clock)) return; Grygorii's question (paraphrasing: "why would you ever do that?") prompted my second patch, making the broken configuration obvious by emitting an error during `ifup`, instead of just a warning during `ifdown`. But I think Grygorii is on to something here: > 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). So, let's not allow it. In my view, commit d1cbfd771ce8 ("ptp_clock: Allow for it to be optional") went a bit too far, and converted even clearly PTP-specific modules from `select` to `imply` PTP_1588_CLOCK, which is what made this broken configuration possible. I suggest reverting that change, just for the PTP-specific modules under drivers/net/ethernet. I audited all drivers that call `ptp_clock_register()`; it looks like these should `select` (instead of merely `imply`) PTP_1588_CLOCK: NET_DSA_MV88E6XXX_PTP NET_DSA_SJA1105_PTP MACB_USE_HWSTAMP CAVIUM_PTP TI_CPTS_MOD PTP_1588_CLOCK_IXP46X Note how they all reference PTP or timestamping in their name, which is a clue that they depend on PTP_1588_CLOCK. I have a patch for this, but first, a procedural question: does mailing list etiquette dictate that I reply to this thread with the new patch, or does it begin a new thread? -- Clay
Powered by blists - more mailing lists