rtems_filesystem_operations_table::lock_h/unlock_h questions

[Sebastian Huber]

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).

An updated filesystem handbook would be quite nice.

-- 
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.