On Thu, Jun 12, 2025 at 09:28:42AM +0100, Mike Leach wrote:
On Thu, 12 Jun 2025 at 06:19, Anshuman Khandual anshuman.khandual@arm.com wrote:
On 11/06/25 8:14 PM, Leo Yan wrote:
container_of() cannot return NULL, so the checks for NULL pointers are unnecessary and can be safely removed.
As a result, this commit silences the following smatch warnings:
coresight-stm.c:345 stm_generic_link() warn: can 'drvdata' even be NULL? coresight-stm.c:356 stm_generic_unlink() warn: can 'drvdata' even be NULL? coresight-stm.c:387 stm_generic_set_options() warn: can 'drvdata' even be NULL? coresight-stm.c:422 stm_generic_packet() warn: can 'drvdata' even be NULL?
Signed-off-by: Leo Yan leo.yan@arm.com
drivers/hwtracing/coresight/coresight-stm.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c index e45c6c7204b4491e0f879bc7d5d445aa1d3118be..464b0c85c3f7d3519169d62a51e9f8c6281b5358 100644 --- a/drivers/hwtracing/coresight/coresight-stm.c +++ b/drivers/hwtracing/coresight/coresight-stm.c @@ -342,7 +342,7 @@ static int stm_generic_link(struct stm_data *stm_data, { struct stm_drvdata *drvdata = container_of(stm_data, struct stm_drvdata, stm);
if (!drvdata || !drvdata->csdev)
if (!drvdata->csdev) return -EINVAL;
I'd agree that the container_of() cannot return NULL, but what happens if stm_data is NULL? Perhaps the NULL check was on the wrong parameter?
The pointer "stm_data" should be safe. The data structure is allocated in probe and released in the remove, the structure "stm_data" is safely accessed during runtime.
If stm_data really has NULL pointer issue, we should already receive alarms for kernel oops :)
Thanks, Leo