rtems_filesystem_operations_table::lock_h/unlock_h questions

[Radu Margarint]

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/20161214/d20b93cd/attachment.html>