<div dir="ltr"><span style="font-size:12.8px">Following up on this question on behalf of Radu, I can infer the following "rules" for locking:</span><div style="font-size:12.8px"><ul><li style="margin-left:15px">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_<wbr>instance_lock():</li><ul><li style="margin-left:15px">path evaluation in libcsupport/src/sup_fs_eval_<wbr>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.</li><li style="margin-left:15px">fchdir() while performing an access check that spans two fs calls</li><li style="margin-left:15px">fchown() for similar reasons</li><li style="margin-left:15px">rtems_filesyste_location_free(<wbr>) when calling into the ops->freenod_h entry point.</li></ul><li style="margin-left:15px">The filesystem access lock can be acquired recursively.</li><li style="margin-left:15px">Individual rtems_filesystem_<wbr>operations_table entry points should guard their own internal state via locking as appropriate.</li></ul><div>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.</div></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Does anyone have context on this issue that would indicate otherwise?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 14, 2016 at 10:16 AM, Radu Margarint <span dir="ltr"><<a href="mailto:raduma@google.com" target="_blank">raduma@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello,</div><div><br></div><div>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.</div><div><br></div><div>The RTEMS File System design guide @ <a href="https://docs.rtems.org/doc-current/share/rtems/pdf/filesystem.pdf" target="_blank">https://docs.rtems.org/doc-<wbr>current/share/rtems/pdf/<wbr>filesystem.pdf</a> doesn't even mention them once.</div><div><br></div><div>The online docs @ <a href="https://docs.rtems.org/doxygen/cpukit/html/group__LibIOFSOps.html#gae6a0c55a60927170f228b90ede1032f9" target="_blank">https://docs.rtems.org/<wbr>doxygen/cpukit/html/group__<wbr>LibIOFSOps.html#<wbr>gae6a0c55a60927170f228b90ede10<wbr>32f9</a> just mention a simple 'they lock the file system' but w/o saying when that lock would be taken by the high level code.</div><br><div>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.</div><div><br></div><div>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 <a href="https://github.com/RTEMS/rtems/blob/5eb769ca8b553b4378a773967f08de20847794db/cpukit/libfs/src/rfs/rtems-rfs-rtems.c" target="_blank">https://github.com/RTEMS/<wbr>rtems/blob/<wbr>5eb769ca8b553b4378a773967f08de<wbr>20847794db/cpukit/libfs/src/<wbr>rfs/rtems-rfs-rtems.c</a> don't take any locks, but they do internal inode load/unload operations which mutate internal state but w/o any barriers in place. <span style="color:rgb(121,93,163);font-family:consolas,"liberation mono",menlo,courier,monospace;font-size:12px;white-space:pre-wrap">rtems_rfs_rtems_fstat </span>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks</div><span class="HOEnZb"><font color="#888888"><div>--radu </div></font></span></div>
</blockquote></div><br></div>