[RTEMS Project] #3741: libdl load of ELF objects on NFS file system lock up

[RTEMS trac]

#3741: libdl load of ELF objects on NFS file system lock up
-----------------------------------+--------------------------
 Reporter:  dufault                |       Owner:  Chris Johns
     Type:  defect                 |      Status:  accepted
 Priority:  normal                 |   Milestone:  5.1
Component:  lib/dl                 |     Version:  5
 Severity:  normal                 |  Resolution:
 Keywords:  run-time-loader libdl  |  Blocked By:
 Blocking:                         |
-----------------------------------+--------------------------

Comment (by Chris Johns):

 The default RTL allocator (heap) uses the file system while holding the
 heap allocator lock and if the file system uses the heap we end up in a
 deadlock. LibBSD's NFS implementation uses the heap.

 The allocator lock/unlock logic was added when the trampoline changes were
 added. Trampolines provide large memory support and is documented in the
 User Manual (https://docs.rtems.org/branches/master/user/exe/loader.html
 #large-memory). The trampoline table needs to be close to the code using
 it or it may be out of range. If something allocates a large piece of
 memory between allocating the text memory and the trampoline table the
 relocation to the trampoline will be out of range.

 There are two unknowns until the memory is allocated and code is loaded.
 The first is the location in memory and the second is the instruction the
 relocation record is pointing too. The location lets us determine the
 distance from the instruction to the target address and if it is in range
 and the instruction lets the arch back-end know determine the range the
 instruction has.

 The ELF loader can be split into a finer set of stages to do as much
 processing before allocating memory however as stated above the two
 unknowns need to be resolved.

 The most robust solution is to add code to build a table of relocation
 records that could require trampolines. While the allocator lock is being
 held:

 a. Lock the allocator
 a. Allocate the sections
 a. Locate the symbols
 a. Determine the number of trampolines using the cached relocation records
 a. Allocate the trampoline table
 a. Unlock the allocator

 The number of trampolines can be determined using the relocation table
 data held in memory. The relocation table could be implemented in a
 similar way the unresolved externals is done with a common pool of blocks
 that grows and shrinks based on demand. A block allocation should aid the
 heap with fragmentation.

--
Ticket URL: <http://devel.rtems.org/ticket/3741#comment:2>
RTEMS Project <http://www.rtems.org/>
RTEMS Project