----- Am 19. Sep 2017 um 16:40 schrieb Gedare Bloom ged...@rtems.org:
> On Tue, Sep 19, 2017 at 10:09 AM, Joel Sherrill <j...@rtems.org> wrote: >> >> >> On Tue, Sep 19, 2017 at 8:16 AM, Sebastian Huber >> <sebastian.hu...@embedded-brains.de> wrote: >>> >>> Hello, >>> >>> we have to make some trade-offs in the implementation with respect to the >>> error checking. The operations get a pointer to the synchronization object, >>> e.g. >>> >>> int sem_post(sem_t *sem); >>> >>> int pthread_mutex_lock(pthread_mutex_t *mutex); >>> >>> Do we want to check for NULL pointers? >> >> >> Is newlib consistently using the non-NULL declaration on the argument? No, I didn't add this yet. The GCC non-NULL attribute seems to enable dangerous optimizations. So, it was disabled on FreeBSD. https://github.com/freebsd/freebsd/commit/7cf8787338d19546498331daa53d0d0a50a56178#diff-be62a312cb99ea95d7cdebd37c77b35d >> >> Newlib/Cygwin folks have been pretty insistent that they do not want to >> check for NULL on the shared methods. >> >> Personally I hate to delete NULL argument pointer checks. Would a >> long-term compromise be to move them to argument checking macros >> that are enabled with --enable-rtems-debug? >> >>> >>> >>> Do we want to check for other obviously invalid pointer values, e.g. >>> SEM_FAILED? >> >> >> IMO Yes With the move to self-contain objects the storage space management moves from the system to the user. This makes it hard for the system to validate things. I am not sure if we should check for error conditions that shouldn't be present in production code. So, making these checks RTEMS_DEBUG dependent is something worth considering. Maybe we need a RTEMS_ROBUST option focusing on user introduced errors. RTEMS_DEBUG enables a lot of internal consistency checks. >> >>> >>> Do we want to check if the object has been initialized? >> >> >> Yes. We want to have predictable behavior. >> >>> >>> >>> >>> >>> glibc uses no checks at all. >> >> >> Performance over correctness? That doesn't seem like a good trade. >> > It's actually performance assuming correctness. Yes, its not about correctness. Its about different implementations of undefined behaviour. Correct applications suffer from these error checks. > In modern multicore > software the lock acquire is a serious critical path. I don't know > that RTEMS is quite to the point it matters so much, but eventually > even some targets will prefer the optimized fast path of lock acquire. > It's up to the caller to check that previous calls to create/init the > object succeeded, and the main complication then is if the > synchronization object is used after it is destroyed. > > If possible we should provide control over the trade-off, e.g., with a > debug flag for some checks. > >>> >>> >>> FreeBSD checks that the object has been initialized. For this purpose it >>> embeds a magic value field in the object structure. The drawback is that if >>> we also do this, the objects are not zero-initialized and thus cannot reside >>> in the BSS section. >> >> >> This is an impossible trade. Some systems have big Flash and small RAM. >> Others are the opposite. >> >> I would rather follow the FreeBSD model and know the object is initialized. >> > zero-initialized should also be check-able? The RAM size doesn't matter. Its about the ROM size. For a magic value check, we could use some magic auto-initialization, e.g. if (obj->magic != ok) check if completely zero, then set magic and ok, otherwise error > >>> >>> >>> Destruction of synchronization objects in use is undefined behaviour >>> according to POSIX. Do we want to flush waiting threads during destruction? >>> This is a complex operation. >> >> >> We have over 20 years of defined behavior in this case. I think >> we flush and return the same error we always did. Otherwise, >> we get a deadlock. >> > Is this true for all current synchronization objects we have? Where in > the code does this happen? > > If the destroyed object is easily identifiable, then waiting threads > can be denied the acquire without having to flush at time of object > destruction. (What about threads in the critical section of non-mutex > locks, e.g., counting semaphores?) Applications with objects that are in use during destruction are bound to have use after free problems. The flush doesn't really help here. It should be a fatal error or assert. The object life-time safety provided by uni-processor RTEMS with system managed objects can no longer guaranteed with self-contained objects or on SMP. You need a global lock for this. > >>> >>> >>> What you think? >>> >>> >>> -- >>> 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.hu...@embedded-brains.de >>> PGP : Public key available on request. >>> >>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >>> >>> _______________________________________________ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >> >> >> >> _______________________________________________ >> devel mailing list >> devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
