Hi, > > > On Thu, 22 Apr 2021 at 11:17, Maninder Singh <maninder1.s@xxxxxxxxxxx> wrote: > > > > > > when KASAN multishot is ON and some buggy code hits same code path > > > of KASAN issue repetetively, it can flood logs on console. > > > > > > Check for allocaton, free and backtrace path at time of KASAN error, > > > if these are same then it is duplicate error and avoid these prints > > > from KASAN. > > > > On a more fundamental level, I think this sort of filtering is the > > wrong solution to your problem. One reason why it's good that > > multishot is off by default is, because _every_ KASAN report is > > critical and can destabilize the system. Therefore, any report after > > the first one might be completely bogus, because the system is in a > > potentially bad state and its behaviour might be completely random. Yes it's valid point , But in Some scenarios testing in production take time and waiting for one issue fix takes time as there are multiple stakeholders in modules. So we thought it was better to catch multiple issues in one long run. > > The correct solution is to not leave the system running, fix the first > > bug found, continue; rinse and repeat. Therefore, this patch adds a > > lot of code for little benefit. > > I agree with Marco here. > > It doesn't make sense to have this deduplication code in the kernel > anyway. If you want unique reports, write a userspace script that > parses dmesg and groups the reports. > Yes agree, but issue is when multishot is ON, same KASAN error reports multiple time and can flood the serial logs. which can be avoided with patch [1/2] Thanks, Maninder Singh
