rtems_filesystem_operations_table::lock_h/unlock_h questions

[Stella Laurenzo]

On Mon, Dec 19, 2016 at 10:21 PM, Sebastian Huber <
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.


>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20161220/75e0c035/attachment.html>