This will not completely resolve RHEL-60906, because there will be
always race condition if the rename event happens before the instance
is fully initialized, but it should significantly improve the situation.
Drawback is that it can report in the logs device names that shouldn't
be matched by the plugin_net instance, i.e. it matches devices according
to their original names but accesses them with their new names. This
can be confusing. Also in the runtime API (e.g. for removal of the
device from the instance), the original device names have to be used.
For insertion of the device to the instance, new names have to be used.
This can be even more confusing.
Unfortunately, there probably isn't better alternative now, because
for correct operation we would have to handle rename by removal and
addition events. This would require rollback and retune steps which would
lead to very negative performance consequences. Also we would have to
cope with partially tuned devices if the rename event happens during
profile application. It's doable, but it would require big
architectural changes.
The PR also extends internal API, now the plugin instances receive
'instance' as a method parameter.
Also fixed some existing CodeQL warnings.
Resolves: RHEL-60906
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
- improved conditionals for better readability
- fixed tuned-ppd not to run install twice
- used macro for profiles path
- consolidated names of related variables
- updated Makefile to update the current profile paths during
installation
- fixed tests to use correct profile directory on RHEL/CentOS
- consolidated whitespaces and variable names in fixed tests
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Currently instance priorities are only used at startup to sort the
instance classes. To enable dynamic creation of instances, we need
to store the priorities, so new instances can be sorted accordingly.
Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
It requires slight internal plugin API change, thus 3rd party plugins
needs updating.
Namely the 'command_set' methods for devices were extended by the
'remove' boolean parameter which is set to 'True' on the hotplug remove
event. Then the method should silent the ENOENT errors where
appropriate, because the device interface may be removed (by
kernel/udev) before the method finishes.
Resolves: RHEL-11342
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The original idea behind this patch is credited to
Jiří Mencák <jmencak@redhat.com>.
Resolves: rhbz#1825882
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Switch from the deprecated execution method.
Fix for the bz1798183-RFE-support-post-loaded-profile beakerlib test.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The 'D' is now capital to clarify pronunciation.
DBus service name is kept as '/Tuned' not to break
backward compatibility.
This will also need update of downstream tests
which rely on the specific output strings containing
the name.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
This is a minimal viable implementation of a post-loaded profile
feature. It was implemented to satisfy the needs of the
kernel_settings Ansible role.
https://github.com/linux-system-roles/kernel_settings
This feature allows us to apply a profile in a way that is
somewhat separate from the way profiles from the active_profile file
are applied. Namely, the post-loaded profile is always applied after
all the profiles from the active_profile (or more precisely, the
post-loaded profile is always put to the tail of the profile chain
when merging). Also, the post-loaded profile setting is not affected
by running 'tuned-adm profile <some profile>' - the post-loaded
profile remains applied.
The name of the post-loaded profile is stored in
/etc/tuned/post_loaded_profile.
The lack of support for multiple post-loaded profiles was more or less
an arbitrary decision. There are no problems with it, as far as I can
see. However, there is currently no use case for multiple post-loaded
profiles, so I decided to make things easier for our future selves -
it's one less thing to worry about if we need to make changes to the
profile loading logic. We can add support for multiple post-loaded
profiles anytime.
A number of other design decisions went into the
implementation. They are listed here:
https://github.com/redhat-performance/tuned/pull/272
Resolves: rhbz#1798183
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
This patch fixes (at least) the following race conditions:
1. If a device is attached while iterating assigned devices, the
MonitorObserver thread can attempt to insert the newly attached
device to the assigned_devices set while the set is being iterated,
which results in the following exception:
RuntimeError: Set changed size during iteration
2. Some devices can be missed when applying a tuning - devices are enumerated
(i.e., Plugin._init_devices() gets called) before udev device monitoring is
started (hotplug.Plugin._hardware_events_init() gets called), so devices
that appear between these two actions are not tuned.
3. Device monitoring is stopped too late, which can result in some tunings
not being unapplied after stopping a profile. This can happen for devices
that get added during profile rollback after unit_manager.stop_tuning()
gets called, but before unit_manager.destroy_all() gets called.
4. It can happen that tuning is applied twice for a device if it is added
during profile activation, e.g. after unit_manager.create() is called in
Daemon._thread_code(), but before unit_manager.start_tuning() is called.
Apart from unnecessarily applying the tuning twice, it can result in
overwriting saved original settings for the device and hence our inability
to properly roll back our changes to the settings.
5. The observer thread can attempt to use load_monitor before it's created
in Plugin._instance_init(), which can result in AttributeError.
Hopefully it doesn't introduce new race conditions :).
The fix is to:
1. rearrange the sequence of certain actions,
2. separate Instance.devices to two separate sets: processed_devices
and assigned_devices.
processed_devices are never iterated when the MonitorObserver thread
is running (*), so the first problem described above cannot happen.
The set is used to store devices, which have already been tuned.
The assigned_devices set is now the set of devices that are going
to be tuned. The set can only be accessed by the main thread.
(*) Except when verifying tuning - this is fixed in a follow-up patch
I tried to separate the changes into more digestable patches, but I
couldn't figure out how.
Resolves: rhbz#1592743
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Since python3.3, Mapping has been moved to collections.abc and starting
with python3.8, it will no longer be available as collections.Mapping.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
- we should use pyudev.Device class property 'properties'
for accesing device properties
- but we still need to keep try catch workaround
because of old pyudev package which is present in centos
