On Sat, 7 May 2016, changbin...@intel.com wrote:
Can you please fix your mail client. Every mail you send has:
Cc: .....
"Du, Changbin" <changbin...@intel.com>,
Du
And that stray 'Du' is just broken.
> At last, I have a concern about the fixups that can it change the
> object which is in incorrect state on fixup? Because the 'addr' may
> not point to any valid object if a non-static object is not tracked.
> Then Change such object can overwrite someone's memory and cause
> unexpected behaviour. For example, the timer_fixup_activate bind
> timer to function stub_timer.
Well, you have the choice of:
1) Leave the object uninitialized and watch the resulting explosion
2) Assume that the pointer is a valid object and initialize it
The latter has been chosen as the lesser of two evils.
> raw_spin_unlock_irqrestore(&db->lock, flags);
> /*
> - * Maybe the object is static. Let the type specific
> + * Maybe the object is static. Let the type specific
> * code decide what to do.
Instead of doing white space changes you really want to explain the logic
here.
> */
> - if (debug_object_fixup(descr->fixup_assert_init, addr,
> - ODEBUG_STATE_NOTAVAILABLE))
> + if (descr->is_static_object && descr->is_static_object(addr)) {
> + /* Make sure that it is tracked in the object tracker */
> + debug_object_init(addr, descr);
> + } else {
> debug_print_object(&o, "assert_init");
> + debug_object_fixup(descr->fixup_assert_init, addr,
> + ODEBUG_STATE_NOTAVAILABLE);
> + }
> return;
> }
Other than the missing comment this looks good.
Thanks,
tglx
