[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <13937d22-46ac-480a-8956-f89a0fd295ac@stanley.mountain>
Date: Tue, 29 Oct 2024 11:07:07 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Philip Li <philip.li@...el.com>
Cc: Matthew Sakai <msakai@...hat.com>, oe-kbuild@...ts.linux.dev,
Mike Snitzer <snitzer@...nel.org>, lkp@...el.com,
oe-kbuild-all@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: drivers/md/dm-vdo/data-vio.c:976 vdo_launch_bio() warn:
inconsistent returns '&pool->lock'.
On Tue, Oct 29, 2024 at 03:15:47PM +0800, Philip Li wrote:
> On Tue, Oct 29, 2024 at 11:03:07AM +0800, Philip Li wrote:
> > On Mon, Oct 28, 2024 at 07:00:40PM -0400, Matthew Sakai wrote:
> > > This should be addressed upstream by commit
> > > 872564c501b72ae0c84af51084753e8652e4a84b ("dm vdo data-vio: silence sparse
> > > warnings about locking context imbalances")
> > >
> > > That commit is from February. Would it be possible for these checks to use a
> > > more up-to-date version of the code before warning us about things that have
> > > already been addressed?
> >
> > Sorry about this Matt, the bot side will check why this happens and fix
> > the issue asap to avoid meaningless report.
>
> Hi Matt and Dan, would you mind do a further check of this, per the re-test,
> smatch warns as below on v6.12-rc3
>
> drivers/md/dm-vdo/data-vio.c:982 vdo_launch_bio() warn: inconsistent returns '&pool->lock'.
> Locked on : 972,977
> Unlocked on: 982
>
> The corresponding code of drivers/md/dm-vdo/data-vio.c is below
>
Ah. Right.
The cross function DB doesn't scale well enough for the zero day bot to use so
it didn't detect the fix. If we had the cross function DB then that silences
the warning.
1) I re-wrote the locking check so it detected this bug where before it didn't.
2) The kbuild bot was using the new check on old code because Matthew Sakai
did a branch based on 8 month old code.
3) The kbuild bot detected the bug, but unfortunately the cross function DB
doesn't scale well enough for the kbuild bot to use so it didn't detect the
fix.
4) I reviewed the code based on the information in the email and determined that
it was buggy.
All those steps had to happen for the warning to be sent out. In a normal
situation, I would have sent the warning out at the time when the code was
written and you wouldn't be getting warning emails eight months later. The
kbuild-bot generally avoids sending duplicate warnings.
Sometimes the kbuild bot does send duplicate warnings, but I normally delete
those. Perhaps some people might argue that if you do a branch from 8 month old
code, maybe you would want the warnings, but I think you should look at the
Fixes tags instead. Not everyone gets the Fixes tags right, of course... But
I trust kernel developers to Fix their bugs and generally they do so duplicates
are normally false positives which have been deliberately ignored.
regards,
dan carpenter
Powered by blists - more mailing lists