[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m2zg84nomr.fsf@gmail.com>
Date: Thu, 23 Mar 2023 11:10:29 +0800
From: Schspa Shi <schspa@...il.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: longman@...hat.com, swboyd@...omium.org, linux@...ck-us.net,
wuchi.zero@...il.com, linux-kernel@...r.kernel.org,
syzbot+5093ba19745994288b53@...kaller.appspotmail.com
Subject: Re: [PATCH 1/2] debugobject: fix concurrency issues with
is_static_object
Thomas Gleixner <tglx@...utronix.de> writes:
> On Thu, Mar 23 2023 at 01:55, Schspa Shi wrote:
>> Thomas Gleixner <tglx@...utronix.de> writes:
>>> Which requirement? The is_static_object() call takes the address of the
>>> actual object and has nothing to do with the tracking object at all.
>>>
>>
>> This is for the fellowing test case, actually we calls
>> debug_object_free() from a static object in our selftest, if we don't
>> report any thing when call debug_object_free from a static object, we
>> there is no such issues.
>
> That's an artifical and completely pointless test case. As I told you
> before the memory subsystem will warn when it's tried to free a static
> object. debug_objects_free() is invoked from the memory subsystem *free*
> functions.
>
> What is the value of another warning?
>
> Nothing at all.
>
> So why would we add extra code just to keep track of something
> completely redundant?
>
OK, there is really no need to do this extra check. And should I
submit a new patch version with your change 😃?
> Thanks,
>
> tglx
--
BRs
Schspa Shi
Powered by blists - more mailing lists