[RTEMS Project] #4212: libio leaks location clones

[RTEMS trac]

#4212: libio leaks location clones
--------------------------+--------------------
  Reporter:  Chris Johns  |      Owner:  (none)
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  6.1
 Component:  fs           |    Version:  6
  Severity:  normal       |   Keywords:
Blocked By:               |   Blocking:
--------------------------+--------------------
 `rtems_filesystem_location_copy` overwrites a location that may have been
 cloned  via the ops handler leaking the destination node. If a file system
 has allocated resources in a location node when cloned it will leak. I
 assume there is a free for every clone?

 An example of a leak is to mount of file system under IMFS and then open a
 file under the mounted file system. The path eval restart in the IMFS will
 clone a node and then open will:

 {{{
   rtems_filesystem_eval_path_extract_currentloc( &ctx, &iop->pathinfo );
   rtems_filesystem_eval_path_cleanup( &ctx );
 }}}

 The `ctx` contains a cloned location.

 Allocating resources to a location may be required because of the limited
 available file system fields and the opaque nature of the fields or a file
 system may have data it locks or reference counts and that needs to be
 managed.

 I do not fully understand the semantics around the location object and
 while I could guess at a fix there are a number functions related to
 locations and a large number of use cases that I would not know if my fix
 is OK. For example should the copy function free the destination location
 and then clone the source location or should it just free the destination
 location or should all the places a copy is done be updated to manage the
 free and cloning based on the context? Or is the issue in the `open` call
 and the lines pasted here be swapped?

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