list_entry() will never return a NULL pointer, thus remove the
check.

Signed-off-by: Yuesong Li <liyuesong@vivo.com>
---
 drivers/staging/vme_user/vme.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/staging/vme_user/vme.c b/drivers/staging/vme_user/vme.c
index 218b19db6dac..42304c9f83a2 100644
--- a/drivers/staging/vme_user/vme.c
+++ b/drivers/staging/vme_user/vme.c
@@ -416,10 +416,6 @@ void vme_slave_free(struct vme_resource *resource)
 
 	slave_image = list_entry(resource->entry, struct vme_slave_resource,
 				 list);
-	if (!slave_image) {
-		dev_err(bridge->parent, "Can't find slave resource\n");
-		return;
-	}
 
 	/* Unlock image */
 	mutex_lock(&slave_image->mtx);
@@ -794,10 +790,6 @@ void vme_master_free(struct vme_resource *resource)
 
 	master_image = list_entry(resource->entry, struct vme_master_resource,
 				  list);
-	if (!master_image) {
-		dev_err(bridge->parent, "Can't find master resource\n");
-		return;
-	}
 
 	/* Unlock image */
 	spin_lock(&master_image->lock);
-- 
2.34.1

I think Greg may have already merged your commit, which I'm okay with
because so far as I can see it's fine.  But there should normally be
some additional analysis for this type of patch.

On Thu, Aug 22, 2024 at 10:57:36AM +0800, Yuesong Li wrote:
> list_entry() will never return a NULL pointer, thus remove the
> check.
> 

This is true.  But the other possibility here is that it could be that
list_entry_or_null() was intended.

In other words, sure, this patch doesn't introduce new crashing bugs, but it
might going against the work that static checker developers do to find risky
code.

The first thing I would do would be to see which commit introduced this.
git log -p --follow drivers/staging/vme_user/vme.c
This issue was introduced in 2009.  Probably if the code has been this way for
15 years and no one has complained then it's fine to remove the NULL check.

To be honest, that's probably all the analysis you need.  :P  I did a little bit
more analysis using Smatch.  These are the places where Smatch says that
->entry is set.  You'd have to build the cross function database using
~/smatch/smatch_scripts/build_kernel_data.sh and then run
`smatch/smatch_data/db/smdb.py where vme_resource entry`.

drivers/staging/vme_user/vme_user.c | vme_user_probe                 | (struct vme_resource)->entry | min-max
drivers/staging/vme_user/vme_user.c | vme_user_remove                | (struct vme_resource)->entry | min-max
drivers/staging/vme_user/vme.c | vme_slave_request              | (struct vme_resource)->entry | 0-u64max
drivers/staging/vme_user/vme.c | vme_slave_free                 | (struct vme_resource)->entry | min-max
drivers/staging/vme_user/vme.c | vme_master_request             | (struct vme_resource)->entry | 0-u64max
drivers/staging/vme_user/vme.c | vme_master_free                | (struct vme_resource)->entry | min-max
drivers/staging/vme_user/vme.c | vme_dma_request                | (struct vme_resource)->entry | 0-u64max
drivers/staging/vme_user/vme.c | vme_dma_free                   | (struct vme_resource)->entry | min-max
drivers/staging/vme_user/vme.c | vme_lm_request                 | (struct vme_resource)->entry | 0-u64max
drivers/staging/vme_user/vme.c | vme_lm_free                    | (struct vme_resource)->entry | min-max

When you look at the code, ->entry gets pointed to an entry in the list in the
request function and never modified again.

Which is slightly weird.  In other words, struct vme_resource)->entry is not
used as a list at all so far as I can see.  It's unclear to me what's going on
with vme, but I suspect we're going to remove it.  See 35ba63b8f6d0 ("vme: move
back to staging").  Otherwise the temptation would be to ask that we set a
pointer directly to slave_image and master_image instead of saving a pointer to
entry.

regards,
dan carpenter

On Thu, Aug 22, 2024 at 10:57:36AM +0800, Yuesong Li wrote:
> list_entry() will never return a NULL pointer, thus remove the
> check.

Oh, nice catch!  I bet there are lots of other places this happens in
the tree as well.