Re: [bvanassche:ufs-lrbp-as-priv-data 27/28] drivers/ufs/core/ufshcd.c:7594 ufshcd_advanced_rpmb_req_handler() warn: inconsistent returns '&hba->clk_scaling_lock'.

[Dan Carpenter <dan.carpenter@linaro.org>]

On Fri, Oct 31, 2025 at 11:23:39AM -0700, Bart Van Assche wrote:
> On 10/31/25 11:01 AM, Dan Carpenter wrote:
> > These are from the zero day bot so how they are generated is mysterious.
> > The zero day bot thought the patch was 3 days old.  I think someone did
> > a merge or something.
> > 
> > I re-ran it on that branch and there were three warnings.  The "literal
> > zero" is a style issue thing so I haven't published that check.
> > 
> > drivers/ufs/core/ufshcd.c:2955 __ufshcd_setup_cmd() warn: variable dereferenced before check 'cmd' (see line 2950)
> > 
> > drivers/ufs/core/ufshcd.c:6849 ufshcd_err_handler() warn: inconsistent returns '&hba->host_sem'.
> >    Locked on  : 6696
> >    Unlocked on: 6688,6849
> > 
> > drivers/ufs/core/ufshcd.c:9035 ufshcd_device_init() info: returning a literal zero is cleaner
> 
> Hi Dan,
> 
> The inconsistent returns issue for hba->host_sem has been fixed on Martin
> Petersen's fixes branch but unfortunately that fix is not yet
> present on his for-next branch.
> 
> I plan to include a fix for the "variable dereferenced before check
> 'cmd'" complaint.
> 
> Is it expected that I don't see the above reports if I run smatch
> myself? This is what I see if I run smatch (commit 2fb2b9093c5d
> ("sleep_info: The synchronize_srcu() sleeps")):
> 

Yes.  The dereference happens inside a function so you need to have built
the cross function database to see that one.

It's not hard, but it takes a while.  smatch_scripts/build_kernel_data.sh
You might need to rebuild it twice to see the warning...

https://staticthinking.wordpress.com/2023/05/02/the-cross-function-db/

> $ make drivers/ufs/ C=2 CHECK="smatch -p=__kernel__"
>   CHECK   scripts/mod/empty.c
>   CALL    scripts/checksyscalls.sh
>   CHECK   drivers/ufs/core/ufshcd.c
> drivers/ufs/core/ufshcd.c:1536 ufshcd_clk_scaling_suspend_work() warn:
> ignoring unreachable code.

This isn't supposed to show up.  It's seems to not be parsing scoped
guard correctly...  I can't reproduce it.  I think I'm on the same kernel
and Smatch release that you are on but I still can't reproduce it.  It's
not something I have seen from the kbuild-bot either.

regards,
dan carpenter