Introduce a new lock for synchronization of the master->domains list, and use
that instead of the big master_sem lock, improving real-time performance of
fx. ecrt_domain_process() when EoE thread is being shut down (or other
use-cases where master_sem is held for extended periods).
The following locking order is used:
* master->master_sem
* master->domains_lock
* master->io_sem
* domain->datagram_pairs_lock
Meaning that it is allowed to take domains_lock while holding master_sem, and
it is allowed to hold domains_lock while locking io_sem and
datagram_pairs_lock.
[RV: For now, the lockdep_assert_held() annotations are commented out,
since they don't compile with CONFIG_PROVE_LOCKING and (the default)
--disable-rtmutex.]
While domain->datagram_pairs was previously partly protected by the
master->master_sem lock (it was not done consistently though), the fix
to protection of master->datagram_queue made it even worse.
This change adds protection of domain->datagram_pairs using a new lock
dedicated to this. The domain->datagram_pairs_lock is acquired in the actual
functions accessing the domain->datagram_pairs, and this currently means that
it is acquired both in situations where master->master_sem is held and in
situations where master->io_sem is held.
With this, we should have in place so that master->io_sem is always held when
accessing master->datagram_queue.
Note, the use of master->master_sem in ec_ioctl_send() and
ec_ioctl_receive() were wrong (introduced in commit cef602586c). The
only thing needing to be synchronized there is the access to
master->datagram_queue, which is protected by master->io_sem.
This corresponds roughly to the fixes for stable-1.5 that are seen in
https://gitlab.com/etherlab.org/ethercat/-/merge_requests/36 .
In order to ensure proper use of locking, the purpose of each mutex/semaphore
must be clear and documented.
This is my best guess. The master->io_sem has a simple purpose, synchronizing
access to the master->datagram_queue list structure.
When converting to the ec_lock_t abstraction, these were missed,
making building with --enable-rtmutex broken.
Fixes: 9955855f7e (Applied 0016-If-enable-rtmutex-use-rtmutexes-instead-of-semaphore.patch)
- The unmodified upstream iproute2 package installs the ip utility in
/sbin. That is also where it thus ends up with for example Yocto
builds.
- Debian/Ubuntu installs it in /bin (and I assume that's how this came
to be), but their packaging logic provides a symlink /sbin/ip ->
/bin/ip .
- ArchLinux seems to install it in both places (as hardlinks).
- CentOS only has /sbin/ip.
- Fedora only has /sbin/ip.
So /sbin/ip should work everywhere, whereas /bin/ip does not.
This flag specifies that the file descriptor should be closed when an
exec function is invoked. When a file descriptor is allocated (as with
open or dup), O_CLOEXEC bit is initially cleared on the new file
descriptor, meaning that descriptor will survive into the new program
after exec. Setting O_CLOEXEC avoid this survival of the desciptor in
the new program. And setting it at open() time is the only race-free
way to avoid accidentally leaking the fd via other threads that
concurrently do fork()+exec() (or similar, e.g. posix_spawn).
alloc_tty_driver was deprecated by tty_alloc_driver in commit 7f0bc6a68ed9
(TTY: pass flags to alloc_tty_driver) in 2012 but first in kernel
v5.15 it has been dropped (56ec5880a28e). Switch to tty_alloc_driver
when using kernels >= v5.15
As of v5.15, the put_tty_driver alias has been dropped in favor of
directly calling tty_driver_kref_put (9f90a4ddef4e). Switch to
tty_driver_kref_put when using kernels >= v5.15
As from v5.14 the write_room (03b3b1a2405c) and
chars_in_buffer (fff4ef17a940) methods' return type changed from int
to unsigned int in struct tty_operations. This has impact on
ec_tty_write_room() and ec_tty_chars_in_buffer().
init.d support has been updated but the TeX files still reference some
old contents.
Fix all the `../script` folder references, avoid pointing to generated
files (that, depending on the configure options, may or may not exist)
and, while at it, refresh a bit the systemd/init.d documentations.