Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - vector_add changes: (2 Items)
   
vector_add changes  
I am looking at the change made to function vector_add() as a fix to PR 24407. I don't have access to exact diffs, but 
looks like realloc function is replaced with separate steps to allocate, copy, update the vector pointer and freeing the
 memory. And this is done to prevent timer_fire() from accessing the freed memory.

Isn't it possible for timer_fire() to still access the freed memory if there is an interrupt on CPU executing 
timer_fire() after this function gets the address of vector array, but before it indexes into the array. Or, am I 
missing something obvious?

If that is true, do you see any problem in replacing the 'tid' field with thread pointer in timer_entry structure?

Thanks in advance for your input,
Prasad Lingutla
Re: vector_add changes  
On Thu, Aug 14, 2008 at 05:42:28PM -0400, Varaprasad Lingutla wrote:
> I am looking at the change made to function vector_add() as a fix to PR 24407. I don't have access to exact diffs, but
 looks like realloc function is replaced with separate steps to allocate, copy, update the vector pointer and freeing 
the memory. And this is done to prevent timer_fire() from accessing the freed memory.
> 
> Isn't it possible for timer_fire() to still access the freed memory if 
> there is an interrupt on CPU executing timer_fire() after this function 
> gets the address of vector array, but before it indexes into the array. 
> Or, am I missing something obvious?

No, you're right. The fix is good for uniprocessor, but on SMP we can
still have a problem (unlikely in practice because of the amount of time
it takes to do the indirection in the interrupt vs how long it would take
before the contents of the vector are modified in the _sfree()). But still...

> If that is true, do you see any problem in replacing the 'tid' field with 
> thread pointer in timer_entry structure?

It would cause the structure to grow and some systems have tens of thousands
of the suckers. I think we can keep the tid and close the hole another way.
I've created PR 60353 for the change. Good catch!

-- 
Brian Stecher (bstecher@qnx.com)        QNX Software Systems
phone: +1 (613) 591-0931 (voice)        175 Terence Matthews Cr.
       +1 (613) 591-3579 (fax)          Kanata, Ontario, Canada K2M 1W8