[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <64c98e79-2de5-419a-9565-2523635bd3dc@kili.mountain>
Date: Thu, 15 Jun 2023 17:02:03 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Jamal Hadi Salim <jhs@...atatu.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Jiri Pirko <jiri@...nulli.us>,
Vinicius Costa Gomes <vinicius.gomes@...el.com>,
linux-kernel@...r.kernel.org, intel-wired-lan@...ts.osuosl.org,
Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@...el.com>,
Peilin Ye <yepeilin.cs@...il.com>,
Pedro Tammela <pctammela@...atatu.com>,
Richard Cochran <richardcochran@...il.com>,
Zhengchao Shao <shaozhengchao@...wei.com>,
Maxim Georgiev <glipus@...il.com>
Subject: Re: [PATCH v2 net-next 6/9] net: netdevsim: create a mock-up PTP
Hardware Clock driver
On Wed, Jun 14, 2023 at 12:54:37AM +0300, Vladimir Oltean wrote:
> +
> + spin_lock_init(&phc->lock);
> + timecounter_init(&phc->tc, &phc->cc, 0);
> +
> + phc->clock = ptp_clock_register(&phc->info, dev);
> + if (IS_ERR_OR_NULL(phc->clock)) {
> + err = PTR_ERR_OR_ZERO(phc->clock);
> + goto out_free_phc;
> + }
> +
> + ptp_schedule_worker(phc->clock, MOCK_PHC_REFRESH_INTERVAL);
> +
> + return phc;
> +
> +out_free_phc:
> + kfree(phc);
> +out:
> + return ERR_PTR(err);
> +}
Simon added me to the CC list because this code generates a Smatch
warning about passing zero to ERR_PTR() which is NULL. I have written
a blog about this kind of warning.
https://staticthinking.wordpress.com/2022/08/01/mixing-error-pointers-and-null/
Returning NULL can be perfectly fine, but in this code here it will lead
to a crash. The caller checks for error pointers but after that it
assumes that "phc" is a non-NULL pointer.
The IS_ERR_OR_NULL() check is not correct. It should just be if
if (IS_ERR()).
However, the question is can this driver work without a phc->clock?
Depending on the answer you have to do one of two things.
If yes, then the correct thing is to add NULL checks throughout the
driver to prevent a NULL dereference.
If no, then the correct thing is to ensure that CONFIG_PTP_1588_CLOCK is
enabled using Kconfig. We should never have a driver where we compile
it and then it can't probe.
regards,
dan carpenter
Powered by blists - more mailing lists