Re: check locking re-write

Harshit Mogalapalli <[email protected]> Fri, 18 Oct 2024 12:13:04 +0530
Newsgroups org.kernel.vger.smatch
Message-ID <[email protected]>
Hi Dan,


On 14/10/24 15:29, Dan Carpenter wrote:
> I've committed a re-write to check_locking.c.  I see as I was running the
> validation/ tests that there seems to be a problem with the irq handling in
> spin_trylock_irqsave().  I'll take a look at that.
> 
> It was getting to be complicated to try keep the two versions in sync and the
> new code is better than the old code so I've committed it.
> 
> Let me know any other issues you find.  The new code is much cleaner and easier
> to debug than the old code.  Since it's modular it should let me create a bunch
> of new locking checks.  With the old code, even the double locking check was
> disabled because it was such a mess but now I have a check for that which is
> pretty decent and I should be able to push it soon.
> 

drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwvid.c:175 
brcmf_fwvid_attach() warn: inconsistent returns '&fwvid_list_lock'.
   Locked on  : 168
   Unlocked on: 175

This is a false positive I think(mutex locking is properly handled in 
brcmf_fwvid_request_module()), not sure how much it is related to the 
new locking code, could you please take a look ?(I am running latest smatch)



Thanks,
Harshit

> regards,
> dan carpenter
> 
>