[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VI1P193MB0752C500BCA9E3193366E7D699D6A@VI1P193MB0752.EURP193.PROD.OUTLOOK.COM>
Date: Wed, 18 Oct 2023 04:19:21 +0800
From: Juntong Deng <juntong.deng@...look.com>
To: "Ricardo B. Marliere" <ricardo@...liere.net>
Cc: ryabinin.a.a@...il.com, glider@...gle.com, andreyknvl@...il.com,
dvyukov@...gle.com, vincenzo.frascino@....com,
akpm@...ux-foundation.org, linux-mm@...ck.org,
"linux-kernel-mentees@...ts.linuxfoundation.org"
<linux-kernel-mentees@...ts.linuxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
kasan-dev@...glegroups.com
Subject: Re: [RFC] mm/kasan: Add Allocation, Free, Error timestamps to KASAN
report
On 2023/10/18 4:10, Ricardo B. Marliere wrote:
> On 23/10/18 03:39AM, Juntong Deng wrote:
>> If the free time is slightly before the error time, then there is a
>> high probability that this is an error caused by race condition.
>>
>> If the free time is long before the error time, then this is obviously
>> not caused by race condition, but by something else.
>
> That sounds a bit arbitrary to me. How do you set the threshold for each
> case? I mean, the fact remains: an invalid read after the object being
> freed. Does it matter what it was caused by? It should be fixed
> regardless.
There is no threshold, and the timestamps are there to make it easier
for us to guess the cause of the error.
More information (timestamps) can help us find the real cause of the
error faster.
We can only fix the error if we find the real cause of the error.
Powered by blists - more mailing lists