rtems_filesystem_operations_table::lock_h/unlock_h questions

[Sebastian Huber]

Hello Radu,

On 14/12/16 19:16, Radu Margarint wrote:
> Hello,
>
> 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.
>
> The RTEMS File System design guide @ 
> https://docs.rtems.org/doc-current/share/rtems/pdf/filesystem.pdf 
> doesn't even mention them once.

this document is out of date.

>
> The online docs @ 
> https://docs.rtems.org/doxygen/cpukit/html/group__LibIOFSOps.html#gae6a0c55a60927170f228b90ede1032f9 
> just mention a simple 'they lock the file system' but w/o saying when 
> that lock would be taken by the high level code.
>
> 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.

The RTEMS file system layer is quite primitive. It assumes a global lock 
for one file system instance.

>
> 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 
> https://github.com/RTEMS/rtems/blob/5eb769ca8b553b4378a773967f08de20847794db/cpukit/libfs/src/rfs/rtems-rfs-rtems.c 
> don't take any locks, but they do internal inode load/unload 
> operations which mutate internal state but w/o any barriers in place. 
> rtems_rfs_rtems_fstat 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.
>
> 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.

Is this related to:

https://devel.rtems.org/ticket/2792

RFS is currently the only filesystem supported by RTEMS which uses some 
sort of internal locking.

For new filesystems I would probably use FreeBSD code via libbsd.

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