rtems_filesystem_operations_table::lock_h/unlock_h questions

[Stella Laurenzo]

Following up on this question on behalf of Radu, I can infer the following
"rules" for locking:

   - External locking is applied only to operations which span individual
   calls into the file system and must remain consistent. This seems to be
   done in only a handful of cases (which make sense but I can't attest to
   whether they are the only ones that should have external locking applied).
   These are all results of calling rtems_filesystem_instance_lock():
      - path evaluation in libcsupport/src/sup_fs_eval_path.c. I have not
      audited the correctness of this code but it seems to (be trying
to) acquire
      locks as it traverses across each file system boundary.
      - fchdir() while performing an access check that spans two fs calls
      - fchown() for similar reasons
      - rtems_filesyste_location_free() when calling into the
      ops->freenod_h entry point.
   - The filesystem access lock can be acquired recursively.
   - Individual rtems_filesystem_operations_table entry points should guard
   their own internal state via locking as appropriate.

I inferred the last point from looking at other drivers and the libio entry
points, which make no effort to externally acquire the filesystem lock
unless if they need it for their own consistency requirements. I'm left to
conclude that the RFS implementation is just missing internal locking and
should have it.

Does anyone have context on this issue that would indicate otherwise?

On Wed, Dec 14, 2016 at 10:16 AM, Radu Margarint <raduma at google.com> wrote:

> Hello,
>
> I've a couple of questions about the lock/unlock handlers in  he fs ops
> table struct. Specifically, I can't find any documentation about when a
> file system driver should expect those locks to be taken.
>
> The RTEMS File System design guide @ https://docs.rtems.org/doc-
> current/share/rtems/pdf/filesystem.pdf doesn't even mention them once.
>
> The online docs @ https://docs.rtems.org/doxygen/cpukit/html/group__
> LibIOFSOps.html#gae6a0c55a60927170f228b90ede1032f9 just mention a simple
> 'they lock the file system' but w/o saying when that lock would be taken by
> the high level code.
>
> Looking in the code, I see it called from a few higher level entry points,
> like eval path logic, chown, chdir, a couple of other ones. But not all
> calls into the file systems take the lock.
>
> The root cause for me asking this question is that I traced a number of
> file system corruptions & dead locks to the fact that the RFS driver
> doesn't seem to take it's own internal lock in all entry points.
> Specifically, all the entry points in https://github.com/RTEMS/rtems/blob/
> 5eb769ca8b553b4378a773967f08de20847794db/cpukit/libfs/src/
> rfs/rtems-rfs-rtems.c don't take any locks, but they do internal inode
> load/unload operations which mutate internal state but w/o any barriers in
> place. rtems_rfs_rtems_fstat for example. If I add internal locking
> around the logic in these functions (such as the dosfs driver does, and is
> seems is required based on all the tracing I've done), the issues I can
> repro are resolved.
>
> However before I make those changes to our snapshot of the rtems tree, I'd
> like to make sure I understand what the expected/designed locking should
> actually be.
>
> Thanks
> --radu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20161219/858411bc/attachment-0002.html>