Hi, On Wed, Nov 01, 2023 at 12:08:00PM +0300, Dan Carpenter wrote: > Let me add Richard to the CC list. See lore for more details. > https://lore.kernel.org/all/CA+G9fYuA643RHHpPnz9Ww7rr3zV5a0y=7_uFcybBSL=QP_sQvQ@xxxxxxxxxxxxxx/ > > On Tue, Oct 31, 2023 at 09:57:48PM +0530, Naresh Kamboju wrote: > > On Mon, 30 Oct 2023 at 14:33, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > > > > > > We have started printing more and more intentional stack traces. Whether > > > it's testing KASAN is able to detect use after frees or it's part of a > > > kunit test. > > > > > > These stack traces can be problematic. They suddenly show up as a new > > > failure. Now the test team has to contact the developers. A bunch of > > > people have to investigate the bug. We finally decide that it's > > > intentional so now the test team has to update their filter scripts to > > > mark it as intentional. These filters are ad-hoc because there is no > > > standard format for warnings. > > > > > > A better way would be to mark it as intentional from the start. > > > > > > Here, I have marked the beginning and the end of the trace. It's more > > > tricky for things like lkdtm_FORTIFY_MEM_MEMBER() where the flow doesn't > > > reach the end of the function. I guess I would print a different > > > warning for stack traces that can't have a > > > "Intentional warning finished\n" message at the end. > > > > > > I haven't actually tested this patch... Daniel, do you have a > > > list of intentional stack traces we could annotate? > > > > [My two cents] > > > > I have been noticing following kernel warnings / BUGs > > Some are intentional and some are not. I had a similar thing happen to > me last week where I had too many Smatch false positives in my devel > code so I accidentally sent a patch with a stupid bug. I've since > updated my QC process to run both the devel and released versions of > Smatch. > > But a similar thing is happening here where we have so many bogus > warnings that we missed a real bug. IIRC, there was a similar discussion for lockdep issues. IMO, any (unintended) warning should trigger a test failure. I guess that would require adding some intrumentation to __WARN somehow, and also allowing tests to check whether a warning had been generated during their execution for tests that want to trigger one. Maxime
Attachment:
signature.asc
Description: PGP signature
