<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 19, 2016 at 10:21 PM, Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 19/12/16 22:37, Stella Laurenzo wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Following up on this question on behalf of Radu, I can infer the following "rules" for locking:<br>
<br></span>
  * External locking is applied only to operations which span<span class=""><br>
    individual calls into the file system and must remain consistent.<br>
    This seems to be done in only a handful of cases (which make sense<br>
    but I can't attest to whether they are the only ones that should<br>
    have external locking applied). These are all results of<br>
    calling rtems_filesystem_instance_lock<wbr>():<br></span>
      o path evaluation in libcsupport/src/sup_fs_eval_pa<wbr>th.c. I have<span class=""><br>
        not audited the correctness of this code but it seems to (be<br>
        trying to) acquire locks as it traverses across each file<br>
        system boundary.<br></span>
      o fchdir() while performing an access check that spans two fs calls<br>
      o fchown() for similar reasons<br>
      o rtems_filesyste_location_free(<wbr>) when calling into the<br>
        ops->freenod_h entry point.<br>
  * The filesystem access lock can be acquired recursively.<br>
  * Individual rtems_filesystem_operations_ta<wbr>ble entry points should<span class=""><br>
    guard their own internal state via locking as appropriate.<br>
<br>
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.<br>
<br>
Does anyone have context on this issue that would indicate otherwise?<br>
<br>
</span></blockquote>
<br>
The filesystem operations (rtems_filesystem_operations_t<wbr>able) should use the file system instance lock and locking is done by the filesystem layer via the lock_h/unlock_h operations. The filesystem node operations (rtems_filesystem_file_handler<wbr>s_r) are not automatically locked by the filesystem layer, see for example msdos_file_write() which obtains/releases the fs_info->vol_sema (= one and only lock for a FAT filesystem instance in RTEMS).<br></blockquote><div><br></div><div>Thanks, this is helpful. We have patched the filesystem operations themselves to internally lock because there seems to be cases this is not happening at the callsites and was crashing us in the field. We now have a test that can duplicate the crash and can back that local patch out and try to find the missing lock at the filesystem layer and propose a fix. I do believe that there are cases of a missing lock_h/unlock_h call somewhere in the path traversal code, but we haven't isolated it yet.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
An updated filesystem handbook would be quite nice.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116" target="_blank">+49 89 189 47 41-16</a><br>
Fax     : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109" target="_blank">+49 89 189 47 41-09</a><br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brain<wbr>s.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</font></span></blockquote></div><br></div></div>