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 > >