public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Schspa Shi <schspa@gmail.com>
Cc: longman@redhat.com, swboyd@chromium.org, linux@roeck-us.net,
	wuchi.zero@gmail.com, linux-kernel@vger.kernel.org,
	syzbot+5093ba19745994288b53@syzkaller.appspotmail.com
Subject: Re: [PATCH 1/2] debugobject: fix concurrency issues with is_static_object
Date: Wed, 22 Mar 2023 18:46:29 +0100	[thread overview]
Message-ID: <87sfdw8yru.ffs@tglx> (raw)
In-Reply-To: <m2ttycd8kx.fsf@gmail.com>

On Wed, Mar 22 2023 at 23:40, Schspa Shi wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
>>> +	} else {
>>> +		/*
>>> +		 * The debug object is inited, and we should check this again
>>> +		 */
>>> +		if (obj->is_static) {
>>> +			raw_spin_unlock_irqrestore(&db->lock, flags);
>>> +			return;
>>
>> This is broken. If the object is static and already hashed and in active
>> state then this returns and fails to detect the re-initialization of an
>> active object.
>>
>
> Yes, it's right, this can be fixed by pass a skip_ifstatic parameters
> from debug_object_activate. then re-initialization of an active object
> can be detected.

>>> -static __initdata struct self_test obj = { .static_init = 0 };
>>> +static struct self_test obj __initdata = { .static_init = 0 };
>>> +static struct self_test sobj __initdata = { .static_init = 1 };
>>
>> ...
>>
>>> -	obj.static_init = 1;
>>
>> Plus the s/obj/sobj/ which should be equivalent, unless I'm missing
>> something here.
>>
>
> We have saved the is_static state when it is used at the first time, so
> the is_static_object function won't be called in this environment.

There is zero requirement for saving that state.

>>  lib/debugobjects.c |  127 +++++++++++++++++++++++++++--------------------------
>>  1 file changed, 67 insertions(+), 60 deletions(-)
>>
>> --- a/lib/debugobjects.c
>> +++ b/lib/debugobjects.c
>> @@ -216,10 +216,6 @@ static struct debug_obj *__alloc_object(
>>  	return obj;
>>  }
>>  
>> -/*
>> - * Allocate a new object. If the pool is empty, switch off the debugger.
>> - * Must be called with interrupts disabled.
>> - */
>>  static struct debug_obj *
>>  alloc_object(void *addr, struct debug_bucket *b, const struct debug_obj_descr *descr)
>>  {
>> @@ -273,7 +269,7 @@ alloc_object(void *addr, struct debug_bu
>>  	if (obj) {
>>  		obj->object = addr;
>>  		obj->descr  = descr;
>> -		obj->state  = ODEBUG_STATE_NONE;
>> +		obj->state  = ODEBUG_STATE_INIT;
>
> This actually droped the ODEBUG_STATE_NONE state. If we active a
> uninitialized object, there will be no error report.

Indeed.

> This should be
>
> if (descr->is_static_object && descr->is_static_object(addr))
> 	obj->state  = ODEBUG_STATE_INIT;
> else
> 	obj->state  = ODEBUG_STATE_NONE;

Kinda.

> But this can't resolve the initial state requirement from the
> is_static_object() call.

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.

> I think we can report an error when calling debug_object_free() from a
> static object. If don't do so, there is no way to determine it's a
> static object.

The memory allocator will tell you loudly when you try to free a static
object. So no point in having another check.

> When its initialization state changes, the is_static_object() call
> will return the wrong value.

That call is only relevant on the first invocation when there is no
tracking object yet. So what's the problem you are trying to solve?

> Please see the fellowing test case:
>
> 	obj.static_init = 1;

This is pointless, really. Once the object is tracked it does not matter
at all whether it was statically or dynamically allocated.

>
> I test this patch, with my above change, and it seems to work well, but
> we still need to add extra flags to store its static state. And
> debug_object_free() should report an error for the static object.

No, we don't.

> I think we should introduce lookup_object_or_alloc and is_static at the
> same time.

What for?

Thanks,

        tglx

  reply	other threads:[~2023-03-22 17:46 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-03 16:19 [PATCH 1/2] debugobject: fix concurrency issues with is_static_object Schspa Shi
2023-03-03 16:19 ` [PATCH 2/2] debugobject: add unit test for static debug object Schspa Shi
2023-03-23  3:16   ` Schspa Shi
2023-03-23  7:53     ` Thomas Gleixner
2023-03-23  8:44       ` Schspa Shi
2023-04-13 22:39         ` Thomas Gleixner
2023-03-03 17:00 ` [PATCH 1/2] debugobject: fix concurrency issues with is_static_object Waiman Long
2023-03-03 17:53   ` Schspa Shi
2023-03-04  0:14     ` Thomas Gleixner
2023-03-03 23:47 ` Thomas Gleixner
2023-03-22 15:40   ` Schspa Shi
2023-03-22 17:46     ` Thomas Gleixner [this message]
2023-03-22 17:55       ` Schspa Shi
2023-03-22 21:17         ` Thomas Gleixner
2023-03-23  3:10           ` Schspa Shi
2023-03-22 18:05       ` Thomas Gleixner
2023-03-22 18:18         ` Schspa Shi
2023-04-12  7:54         ` [PATCH] debugobject: Prevent init race with static objects Thomas Gleixner
2023-04-13  0:17           ` Stephen Boyd
2023-04-13 12:14             ` Thomas Gleixner
2023-05-01 13:40           ` Ido Schimmel
2023-05-01 15:42             ` Thomas Gleixner
2023-05-02  5:53               ` Ido Schimmel
2023-05-02  8:12               ` [tip: core/debugobjects] debugobject: Ensure pool refill (again) tip-bot2 for Thomas Gleixner
2023-04-15 21:20 ` [tip: core/debugobjects] debugobject: Prevent init race with static objects tip-bot2 for Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sfdw8yru.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=longman@redhat.com \
    --cc=schspa@gmail.com \
    --cc=swboyd@chromium.org \
    --cc=syzbot+5093ba19745994288b53@syzkaller.appspotmail.com \
    --cc=wuchi.zero@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox