From a46a1ad097419aeea7350987dd95230f50d90392 Mon Sep 17 00:00:00 2001
From: hc <hc@nodka.com>
Date: Fri, 15 Nov 2024 08:53:41 +0000
Subject: [PATCH] 固定GMAC1 网卡名为 eth3
---
kernel/mm/memory.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/kernel/mm/memory.c b/kernel/mm/memory.c
index 834078a..51ec122 100644
--- a/kernel/mm/memory.c
+++ b/kernel/mm/memory.c
@@ -845,6 +845,14 @@
return 1;
/*
+ * If the source mm belongs to a Dovetail-enabled process, we
+ * don't want to impose the COW-induced latency on it: make
+ * sure the child gets its own copy of the page.
+ */
+ if (dovetailing() && test_bit(MMF_DOVETAILED, &src_mm->flags))
+ goto do_copy;
+
+ /*
* What we want to do is to check whether this page may
* have been pinned by the parent process. If so,
* instead of wrprotect the pte on both sides, we copy
@@ -862,6 +870,7 @@
if (likely(!page_maybe_dma_pinned(page)))
return 1;
+do_copy:
/*
* The vma->anon_vma of the child process may be NULL
* because the entire vma does not contain anonymous pages.
@@ -5696,6 +5705,15 @@
void __might_fault(const char *file, int line)
{
/*
+ * When running over the oob stage (e.g. some co-kernel's own
+ * thread), we should only make sure to run with hw IRQs
+ * enabled before accessing the memory.
+ */
+ if (running_oob()) {
+ WARN_ON_ONCE(hard_irqs_disabled());
+ return;
+ }
+ /*
* Some code (nfs/sunrpc) uses socket ops on kernel memory while
* holding the mmap_lock, this is safe because kernel memory doesn't
* get paged out, therefore we'll never actually fault, and the
--
Gitblit v1.6.2