This reverts commit e6e9d6e290028b0a6b83b563fad9fafa7f1d515e.

It was a 4.19.31 backport of commit 6ea183d60c46 ("mm: handle
lru_add_drain_all for UP properly").  In summary, what that did
was to fix a possible harmless WARN_ON on non-SMP, introduced at
commit 4d43d395fed1 ("workqueue: Try to catch flush_work() without
INIT_WORK().") by adding non-SMP variants of lru functions.

The combination of that, with the -rt commit 473f14a9f234 ("mm:
perform lru_add_drain_all() remotely") at the merge of the two
results in the following build failure:

  mm/swap.c:736:2: error: #endif without #if

since the -rt change wants RT specific lru and the stable backport
wants non-SMP specific lru, and a chunk of the backport with
an #ifdef CONFIG_SMP is missing.

However, before we add a four way cluster of ifdeffery to handle all
cases, we note 4d43d395fed1 was added to the v5.1 release, and it
was not (currently) backported to any 4.19.x stable release - so it is
unclear to me why this commit was ever backported to 4.19.31 at all.

Further, we note this change was to mm/swap.c -- and by definition,
any preempt-rt deployment that uses swap for anything other than a
failure contingency mitigation is broken by design.

Given all that, I decided that the best path forward was to revert
the two of the three chunks of the backport that remain in the -rt
branch, and return us to the pre-4.19.31 merge behaviour for -rt.

Signed-off-by: Paul Gortmaker <paul.gortma...@windriver.com>

diff --git a/mm/swap.c b/mm/swap.c
index 7e0bcaf450a5..9217027671c8 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -325,6 +325,11 @@ static inline void activate_page_drain(int cpu)
 {
 }
 
+static bool need_activate_page_drain(int cpu)
+{
+       return false;
+}
+
 void activate_page(struct page *page)
 {
        struct zone *zone = page_zone(page);
@@ -728,12 +733,6 @@ void lru_add_drain_all(void)
 
        mutex_unlock(&lock);
 }
-#else
-void lru_add_drain_all(void)
-{
-       lru_add_drain();
-}
-#endif
 
 /**
  * release_pages - batched put_page()
-- 
2.7.4

-- 
_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Reply via email to