Powered by Linux
Re: check locking re-write — Semantic Matching Tool

Re: check locking re-write

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 18, 2024 at 12:13:04PM +0530, Harshit Mogalapalli wrote:
> 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)

The problem was that fwvid_list_lock is a file scope lock and the param/key
stuff says "I can't tie this lock to a parameter" so it returns the parameter
as -2.

I've changed this so that global locks like this are called
"global &fwvid_list_lock" and then it works.  You'll need to reload the --info
for that file.

kchecker --info drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwvid.c | tee out
~/smatch/smatch_data/db/reload_partial.sh out

Then test again:

kchecker drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwvid.c

In the old code, this used to work because there was a "best match" thing where
if the function did an unlock and we couldn't tie it to a lock then we'd look
at the locks we were holding and try to match it as best we can.  This is better
because it matches correctly without guessing.

regards,
dan carpenter





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux