sebastian.huber at embedded-brains.de
Thu Dec 15 07:14:47 UTC 2016
On 14/12/16 19:16, Radu Margarint wrote:
> 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 @
> doesn't even mention them once.
this document is out of date.
> The online docs @
> 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
> 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:
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.
More information about the users