summaryrefslogtreecommitdiffstats
path: root/debian/patches-rt/net_disable_NET_RX_BUSY_POLL.patch
diff options
context:
space:
mode:
Diffstat (limited to 'debian/patches-rt/net_disable_NET_RX_BUSY_POLL.patch')
-rw-r--r--debian/patches-rt/net_disable_NET_RX_BUSY_POLL.patch31
1 files changed, 20 insertions, 11 deletions
diff --git a/debian/patches-rt/net_disable_NET_RX_BUSY_POLL.patch b/debian/patches-rt/net_disable_NET_RX_BUSY_POLL.patch
index f59cd5be4..650b6c7e8 100644
--- a/debian/patches-rt/net_disable_NET_RX_BUSY_POLL.patch
+++ b/debian/patches-rt/net_disable_NET_RX_BUSY_POLL.patch
@@ -1,15 +1,24 @@
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Sat, 27 May 2017 19:02:06 +0200
-Subject: net/core: disable NET_RX_BUSY_POLL
-Origin: https://www.kernel.org/pub/linux/kernel/projects/rt/5.2/older/patches-5.2.17-rt9.tar.xz
+Subject: net/core: disable NET_RX_BUSY_POLL on RT
+Origin: https://www.kernel.org/pub/linux/kernel/projects/rt/5.4/older/patches-5.4.3-rt1.tar.xz
-sk_busy_loop() does preempt_disable() followed by a few operations which can
-take sleeping locks and may get long.
-I _think_ that we could use preempt_disable_nort() (in sk_busy_loop()) instead
-but after a successfull cmpxchg(&napi->state, …) we would gain the ressource
-and could be scheduled out. At this point nobody knows who (which context) owns
-it and so it could take a while until the state is realeased and napi_poll()
-could be invoked again.
+napi_busy_loop() disables preemption and performs a NAPI poll. We can't acquire
+sleeping locks with disabled preemption so we would have to work around this
+and add explicit locking for synchronisation against ksoftirqd.
+Without explicit synchronisation a low priority process would "own" the NAPI
+state (by setting NAPIF_STATE_SCHED) and could be scheduled out (no
+preempt_disable() and BH is preemptible on RT).
+In case a network packages arrives then the interrupt handler would set
+NAPIF_STATE_MISSED and the system would wait until the task owning the NAPI
+would be scheduled in again.
+Should a task with RT priority busy poll then it would consume the CPU instead
+allowing tasks with lower priority to run.
+
+The NET_RX_BUSY_POLL is disabled by default (the system wide sysctls for
+poll/read are set to zero) so disable NET_RX_BUSY_POLL on RT to avoid wrong
+locking context on RT. Should this feature be considered useful on RT systems
+then it could be enabled again with proper locking and synchronisation.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
@@ -18,12 +27,12 @@ Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
--- a/net/Kconfig
+++ b/net/Kconfig
-@@ -280,7 +280,7 @@ config CGROUP_NET_CLASSID
+@@ -278,7 +278,7 @@ config CGROUP_NET_CLASSID
config NET_RX_BUSY_POLL
bool
- default y
-+ default y if !PREEMPT_RT_FULL
++ default y if !PREEMPT_RT
config BQL
bool