[RTEMS Project] #4677: incorrect handling of "inactive_per_block" from "Objects_Information" structure (cloned)

[RTEMS trac]

#4677: incorrect handling of "inactive_per_block" from "Objects_Information"
structure (cloned)
-------------------------+-------------------------------------------------
  Reporter:  Adrian      |      Owner:  Sebastian Huber
  Varlan                 |
      Type:  defect      |     Status:  assigned
  Priority:  normal      |  Milestone:  6.1
 Component:  score       |    Version:  6
  Severity:  normal      |   Keywords:  CONFIGURE_UNLIMITED_OBJECTS
                         |  inactive_per_block
Blocked By:              |   Blocking:
-------------------------+-------------------------------------------------
 Cloned from #4676:
 ----
 The inactive_per_block for block 1 is not handled correctly.
 For the first object in the second block, the inactive_per_block value is
 not decremented. As a consequence, the block might be deleted when the
 second to last object from block 1 is deleted.
 This is only valid when the application is configured with
 "CONFIGURE_UNLIMITED_OBJECTS".


 The reason is the following:

 in function "_Objects_Activate_unlimited" from "objectimpl.h"

 --------snip snip snip--------
   block = _Objects_Get_index( the_object->id ) - OBJECTS_INDEX_MINIMUM;

   if ( block > objects_per_block ) {
     block /= objects_per_block;

     information->inactive_per_block[ block ]--;
     information->inactive--;
   }
 --------snip snip snip--------

 in a block with 8 objects per block, when creating the 9th object,
 _Objects_Get_index( the_object->id ) returns 9. Therefore, "block" will be
 8 (9 - 1).
 The next "if" will not be taken (8 > 8 ? No) and the inactive_per_block
 will not be decremented to 7 and remains at 8.
 This means that block 1 is a candidate for "_Objects_Shrink_information"
 function although object id 9 is still valid.

 Steps to reproduce:
 -assuming 8 objects per allocation block
 -using semaphores as objects

 1. create 17 "RTEMS_SIMPLE_BINARY_SEMAPHORE" semaphore objects id's 1 ->
 17.
 2. delete semaphores 11, 12, 13, 14, 15, 16, 17 (order is important)
 3. lock semaphore 9
 4. delete semaphore 10 -> at this point, block 1 is freed although
 semaphore 9 is still active
 5. unlock semaphore 9  -> this can lead to errors. In my case due to the
 free the semaphore object was altered and changed from a
 "SEMAPHORE_VARIANT_SIMPLE_BINARY" to
 "SEMAPHORE_VARIANT_MUTEX_INHERIT_PRIORITY" resulting in a return value of
 "RTEMS_NOT_OWNER_OF_RESOURCE".


 Simple fix:
 the condition for the "if" should be ">=" instead of ">".

--
Ticket URL: <http://devel.rtems.org/ticket/4677>
RTEMS Project <http://www.rtems.org/>
RTEMS Project