kexec-tools/98-kexec.rules

SUBSYSTEM=="cpu", ACTION=="add", GOTO="kdump_reload"
SUBSYSTEM=="cpu", ACTION=="remove", GOTO="kdump_reload"
SUBSYSTEM=="memory", ACTION=="online", GOTO="kdump_reload"
SUBSYSTEM=="memory", ACTION=="offline", GOTO="kdump_reload"

GOTO="kdump_reload_end"

LABEL="kdump_reload"

RUN+="/usr/bin/systemd-run --no-block /usr/lib/udev/kdump-udev-throttler"

LABEL="kdump_reload_end"
Rewrite kdump's udev rules According to udev's man page, PROGRAM is either used to determine device's name or whether the device matches the rule. So we should use RUN insteand. Meanwhile, both RUN / PROGRAM only accepts very short-running foreground tasks, but kdump restart may take a long time if there are any device changes that will lead to image rebuild, which may lead to buggy behavior. On the other hand, memory / CPU hot plug should never trigger a initramfs rebuild. To solve this problem, we will use new introduced "kdumpctl reload" instead, and use systemd-run to create a transient service unit for the reload and run it in no-block mode, so udev won't be blocked by anything. We need to make systemd-run execute in non-blocking mode, and do not synchronously wait for the operation to finish, because udev expect the command line in RUN to be finished immediately, however, kdumpctl reload may take 0.5-1s for an ordinary reload, or even slower on some machines. So we give systemd-run an explicit --no-block option to run in non-blocking mode. Without --no-blocking, systemd-run will verify, enqueue and wait for the operation to finish. By using the --no-block option, systemd-run will only verify and enqueue the unit then return. In this way, we make sure the command is executed asynchronously, and the status will be monitored and logged by systemd, which is reliable and non-blocking. Another thing to mention is that --no-block is only needed after systemd-v220, before v220 systemd-run uses non-blocking mode by default and --no-block option is not available on earlier systemd versions. Also reformat the udev rules to a more maintanceable format. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> 2018-10-24 08:58:51 +00:00			`SUBSYSTEM=="cpu", ACTION=="add", GOTO="kdump_reload"`
			`SUBSYSTEM=="cpu", ACTION=="remove", GOTO="kdump_reload"`
			`SUBSYSTEM=="memory", ACTION=="online", GOTO="kdump_reload"`
			`SUBSYSTEM=="memory", ACTION=="offline", GOTO="kdump_reload"`

			`GOTO="kdump_reload_end"`

			`LABEL="kdump_reload"`

Throttle kdump reload request triggered by udev event Previously, kdump will restart / reload for many times on hotplug event, especially memory hotplug events. Hotplugged memory may generate many udev event as memory are managed and hotplugged in small chunks by the kernel. This results in unnecessary system workload and an actually longer delay of kdump reload and the hotplug event, as udev will either get blocked or kdumpctl will be waiting for other triggered operation. To fix this, introduce a kdump-udev-throttler as an agent which will be called by udev and merge concurrent kdump restart requests. Tested with a Hyper-V VM which is failing due to udev timeout previously, no new issues found. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> 2018-10-30 10:35:34 +00:00			`RUN+="/usr/bin/systemd-run --no-block /usr/lib/udev/kdump-udev-throttler"`
Rewrite kdump's udev rules According to udev's man page, PROGRAM is either used to determine device's name or whether the device matches the rule. So we should use RUN insteand. Meanwhile, both RUN / PROGRAM only accepts very short-running foreground tasks, but kdump restart may take a long time if there are any device changes that will lead to image rebuild, which may lead to buggy behavior. On the other hand, memory / CPU hot plug should never trigger a initramfs rebuild. To solve this problem, we will use new introduced "kdumpctl reload" instead, and use systemd-run to create a transient service unit for the reload and run it in no-block mode, so udev won't be blocked by anything. We need to make systemd-run execute in non-blocking mode, and do not synchronously wait for the operation to finish, because udev expect the command line in RUN to be finished immediately, however, kdumpctl reload may take 0.5-1s for an ordinary reload, or even slower on some machines. So we give systemd-run an explicit --no-block option to run in non-blocking mode. Without --no-blocking, systemd-run will verify, enqueue and wait for the operation to finish. By using the --no-block option, systemd-run will only verify and enqueue the unit then return. In this way, we make sure the command is executed asynchronously, and the status will be monitored and logged by systemd, which is reliable and non-blocking. Another thing to mention is that --no-block is only needed after systemd-v220, before v220 systemd-run uses non-blocking mode by default and --no-block option is not available on earlier systemd versions. Also reformat the udev rules to a more maintanceable format. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> 2018-10-24 08:58:51 +00:00
			`LABEL="kdump_reload_end"`