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.
Avoid having to rebuild conflicting master/soe_errors.c objects. Inside
the `tool` folder, the `soe_error_codes` array is used only by
SoeCommand, so this should not create further problems.
Esben Haabendal
Florian Pose
Bjarne von Horn
Bjarne von Horn
Shi Qiyao
Nicola Fontana