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
| ||
|
Date: Thu, 12 Nov 2020 22:21:21 +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 Thu, Nov 12, 2020 at 7:19 PM Richard Cochran <richardcochran@...il.com> wrote: > > On Thu, Nov 12, 2020 at 09:25:12AM +0100, Arnd Bergmann wrote: > > This is not really getting any better. If Richard is worried about > > Kconfig getting changed here, I would suggest handling the > > case of PTP being disabled by returning an error early on in the > > function, like > > > > struct am65_cpts *am65_cpts_create(struct device *dev, void __iomem *regs, > > struct device_node *node) > > { > > struct am65_cpts *cpts; > > int ret, i; > > > > if (!IS_ENABLED(CONFIG_PTP_1588_CLOCK)) > > return -ENODEV; > > No, please, no. That only adds confusion. The NULL return value > already signals that the compile time support was missing. That was > the entire point of this... > > * ptp_clock_register() - register a PTP hardware clock driver > * > * @info: Structure describing the new clock. > * @parent: Pointer to the parent device of the new clock. > * > * Returns a valid pointer on success or PTR_ERR on failure. If PHC > * support is missing at the configuration level, this function > * returns NULL, and drivers are expected to gracefully handle that > * case separately. The problem is that the caller doesn't handle that case gracefully, but it instead wants to return an error after all. I don't see a good solution either; as far as I'm concerned we should never be building code that fails if PTP_1588_CLOCK is disabled when it cannot do anything sensible in that configuration. 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. It would be possible to have a ptp_clock_register_optional() interface in addition to ptp_clock_register(), which could then be changed to return an error. Some other subsystems follow this pattern, but it's not any less confusing either. Arnd
Powered by blists - more mailing lists