rtems_filesystem_operations_table::lock_h/unlock_h questions

Radu Margarint raduma at google.com
Wed Dec 14 18:16:43 UTC 2016


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 @
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
don't take any locks, but they do internal inode load/unload operations
which mutate internal state but w/o any barriers in place.
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20161214/d20b93cd/attachment.html>

More information about the users mailing list