rtems_filesystem_operations_table::lock_h/unlock_h questions

[Sebastian Huber]

On 20/12/16 19:45, Stella Laurenzo wrote:
>
>
> On Mon, Dec 19, 2016 at 10:21 PM, Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>     On 19/12/16 22:37, Stella Laurenzo wrote:
>
>         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():
>               o 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.
>               o fchdir() while performing an access check that spans
>         two fs calls
>               o fchown() for similar reasons
>               o 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?
>
>
>     The filesystem operations (rtems_filesystem_operations_table)
>     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_handlers_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).
>
>
> 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.

A missing lock_h/unlock_h in the filesystem layer would be a major bug. 
It would be nice if you can clarify this issue.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.