sebastian.huber at embedded-brains.de
Wed Dec 21 06:49:08 UTC 2016
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
> 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
> 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
> 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
> 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.
More information about the users