- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 0/5] Transition from CPU Type to MIDR Register for Virtualization Feature Detection
by liqiqi 25 Mar '26

25 Mar '26

Currently, there are two methods for determining whether a chip supports specific virtualization features: 1. Reading the chip's CPU type from BIOS 2. Reading the value of the MIDR register The issue with the first method is that each time a new chip is introduced, the new CPU type must be defined, which leads to poor code portability and maintainability. Therefore, the second method has been adopted to replace the first. This approach eliminates the dependency on CPU type by using the MIDR register and removes the need for defining CPU types and their related interfaces. liqiqi (5): kvm: arm64: use MIDR_HISI_TSV110 to determine whether NCSNP is supported kvm: arm64: Add HIP10, HIP10C MIDR definitions kvm: arm64: Use MIDR to determine whether DVMBM is supported kvm: arm64: Use MIDR to determine whether IPIv is supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cputype.h | 4 + arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 111 +++------------------------ arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- 4 files changed, 15 insertions(+), 113 deletions(-) -- 2.43.0

2 6

[PATCH OLK-6.6] perf: Fix __perf_event_overflow() vs perf_remove_from_context() race
by Luo Gengkun 25 Mar '26

25 Mar '26

From: Peter Zijlstra <peterz(a)infradead.org> mainline inclusion from mainline-v7.0-rc2 commit c9bc1753b3cc41d0e01fbca7f035258b5f4db0ae category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13907 CVE: CVE-2026-23271 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- Make sure that __perf_event_overflow() runs with IRQs disabled for all possible callchains. Specifically the software events can end up running it with only preemption disabled. This opens up a race vs perf_event_exit_event() and friends that will go and free various things the overflow path expects to be present, like the BPF program. Fixes: 592903cdcbf6 ("perf_counter: add an event_list") Reported-by: Simond Hu <cmdhh1767(a)gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Tested-by: Simond Hu <cmdhh1767(a)gmail.com> Link: https://patch.msgid.link/20260224122909.GV1395416@noisy.programming.kicks-a… Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/events/core.c | 42 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 41 insertions(+), 1 deletion(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index e5c2105625a2..1d3f8eed6d0d 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -9708,6 +9708,13 @@ int perf_event_overflow(struct perf_event *event, struct perf_sample_data *data, struct pt_regs *regs) { + /* + * Entry point from hardware PMI, interrupts should be disabled here. + * This serializes us against perf_event_remove_from_context() in + * things like perf_event_release_kernel(). + */ + lockdep_assert_irqs_disabled(); + return __perf_event_overflow(event, 1, data, regs); } @@ -9788,6 +9795,19 @@ static void perf_swevent_event(struct perf_event *event, u64 nr, { struct hw_perf_event *hwc = &event->hw; + /* + * This is: + * - software preempt + * - tracepoint preempt + * - tp_target_task irq (ctx->lock) + * - uprobes preempt/irq + * - kprobes preempt/irq + * - hw_breakpoint irq + * + * Any of these are sufficient to hold off RCU and thus ensure @event + * exists. + */ + lockdep_assert_preemption_disabled(); local64_add(nr, &event->count); if (!regs) @@ -9796,6 +9816,16 @@ static void perf_swevent_event(struct perf_event *event, u64 nr, if (!is_sampling_event(event)) return; + /* + * Serialize against event_function_call() IPIs like normal overflow + * event handling. Specifically, must not allow + * perf_event_release_kernel() -> perf_remove_from_context() to make + * progress and 'release' the event from under us. + */ + guard(irqsave)(); + if (event->state != PERF_EVENT_STATE_ACTIVE) + return; + if ((event->attr.sample_type & PERF_SAMPLE_PERIOD) && !event->attr.freq) { data->period = nr; return perf_swevent_overflow(event, 1, data, regs); @@ -10299,6 +10329,11 @@ void perf_tp_event(u16 event_type, u64 count, void *record, int entry_size, struct perf_sample_data data; struct perf_event *event; + /* + * Per being a tracepoint, this runs with preemption disabled. + */ + lockdep_assert_preemption_disabled(); + struct perf_raw_record raw = { .frag = { .size = entry_size, @@ -10712,6 +10747,11 @@ void perf_bp_event(struct perf_event *bp, void *data) struct perf_sample_data sample; struct pt_regs *regs = data; + /* + * Exception context, will have interrupts disabled. + */ + lockdep_assert_irqs_disabled(); + perf_sample_data_init(&sample, bp->attr.bp_addr, 0); if (!bp->hw.state && !perf_exclude_event(bp, regs)) @@ -11164,7 +11204,7 @@ static enum hrtimer_restart perf_swevent_hrtimer(struct hrtimer *hrtimer) if (regs && !perf_exclude_event(event, regs)) { if (!(event->attr.exclude_idle && is_idle_task(current))) - if (__perf_event_overflow(event, 1, &data, regs)) + if (perf_event_overflow(event, &data, regs)) ret = HRTIMER_NORESTART; } -- 2.34.1

2 1

[PATCH 0/5] Transition from CPU Type to MIDR Register for Virtualization Feature Detection
by liqiqi 25 Mar '26

25 Mar '26

Currently, there are two methods for determining whether a chip supports specific virtualization features: 1. Reading the chip's CPU type from BIOS 2. Reading the value of the MIDR register The issue with the first method is that each time a new chip is introduced, the new CPU type must be defined, which leads to poor code portability and maintainability. Therefore, the second method has been adopted to replace the first. This approach eliminates the dependency on CPU type by using the MIDR register and removes the need for defining CPU types and their related interfaces. liqiqi (5): kvm: arm64: use MIDR_HISI_TSV110 to determine whether NCSNP is supported kvm: arm64: Add HIP10, HIP10C MIDR definitions kvm: arm64: Use MIDR to determine whether DVMBM is supported kvm: arm64: Use MIDR to determine whether IPIv is supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cputype.h | 4 + arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 111 +++------------------------ arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- 4 files changed, 15 insertions(+), 113 deletions(-) -- 2.43.0

1 5

[PATCH OLK-6.6] media: dvb-core: fix wrong reinitialization of ringbuffer on reopen
by Chen Jinghuang 25 Mar '26

25 Mar '26

From: Jens Axboe <axboe(a)kernel.dk> mainline inclusion from mainline-v7.0-rc2 commit bfbc0b5b32a8f28ce284add619bf226716a59bc0 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13873 CVE: CVE-2026-23253 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock. Cc: stable(a)vger.kernel.org Fixes: 34731df288a5 ("V4L/DVB (3501): Dmxdev: use dvb_ringbuffer") Reported-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ab12f0c08dd7ab8d057c Tested-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/698a26d3.050a0220.3b3015.007d.GAE@google.com/ Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: drivers/media/dvb-core/dmxdev.c [context conflict] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- drivers/media/dvb-core/dmxdev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c index 9ce5f010de3f..4ce3ae3954c5 100644 --- a/drivers/media/dvb-core/dmxdev.c +++ b/drivers/media/dvb-core/dmxdev.c @@ -168,7 +168,9 @@ static int dvb_dvr_open(struct inode *inode, struct file *file) mutex_unlock(&dmxdev->mutex); return -ENOMEM; } - dvb_ringbuffer_init(&dmxdev->dvr_buffer, mem, DVR_BUFFER_SIZE); + dmxdev->dvr_buffer.data = mem; + dmxdev->dvr_buffer.size = DVR_BUFFER_SIZE; + dvb_ringbuffer_reset(&dmxdev->dvr_buffer); if (dmxdev->may_do_mmap) dvb_vb2_init(&dmxdev->dvr_vb2_ctx, "dvr", file->f_flags & O_NONBLOCK); -- 2.34.1

2 1

[PATCH 0/5] Transition from CPU Type to MIDR Register for Virtualization Feature Detection
by liqiqi 25 Mar '26

25 Mar '26

Currently, there are two methods for determining whether a chip supports specific virtualization features: 1. Reading the chip's CPU type from BIOS 2. Reading the value of the MIDR register The issue with the first method is that each time a new chip is introduced, the new CPU type must be defined, which leads to poor code portability and maintainability. Therefore, the second method has been adopted to replace the first. This approach eliminates the dependency on CPU type by using the MIDR register and removes the need for defining CPU types and their related interfaces. liqiqi (5): kvm: arm64: use MIDR_HISI_TSV110 to determine whether NCSNP is supported kvm: arm64: Add HIP10, HIP10C MIDR definitions kvm: arm64: Use MIDR to determine whether DVMBM is supported kvm: arm64: Use MIDR to determine whether IPIv is supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cputype.h | 4 + arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 111 +++------------------------ arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- 4 files changed, 15 insertions(+), 113 deletions(-) -- 2.43.0

1 5

[PATCH OLK-6.6] arm64: fix compile error if CONFIG_ARCH_HAS_COPY_MC not enabled
by Wupeng Ma 24 Mar '26

24 Mar '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8386 ------------------------------------------ If CONFIG_ARCH_HAS_COPY_MC is not enabled, kernel can not be compiled with the following error: aarch64-linux-gnu-ld: arch/arm64/mm/flush.o: in function `copy_mc_to_user_page': arch/arm64/mm/flush.c:56:(.text+0x3a4): undefined reference to `memcpy_mc' aarch64-linux-gnu-ld: mm/memory.o: in function `__access_remote_vm': mm/memory.c:6674:(.text+0xe138): undefined reference to `memcpy_mc' aarch64-linux-gnu-ld: mm/kasan/shadow.o: in function `memcpy_mc': mm/kasan/shadow.c:90:(.text+0xa94): undefined reference to `__memcpy_mc' Fix this by add stub function of memcpy_mc which just call memcpy. Fixes: d51d1b114c86 ("arm64: mm: support recovery from copy_{from/to}_user_page()") Fixes: b991780c836c ("arm64: introduce copy_mc_to_kernel() implementation") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- arch/arm64/include/asm/string.h | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/include/asm/string.h b/arch/arm64/include/asm/string.h index 23eca4fb24fa6..97844a8e3ed3a 100644 --- a/arch/arm64/include/asm/string.h +++ b/arch/arm64/include/asm/string.h @@ -36,8 +36,13 @@ extern void *memcpy(void *, const void *, __kernel_size_t); extern void *__memcpy(void *, const void *, __kernel_size_t); #define __HAVE_ARCH_MEMCPY_MC +#ifdef CONFIG_ARCH_HAS_COPY_MC extern int memcpy_mc(void *, const void *, __kernel_size_t); extern int __memcpy_mc(void *, const void *, __kernel_size_t); +#else +#define memcpy_mc(dst, src, len) __memcpy(dst, src, len) +#define __memcpy_mc(dst, src, len) __memcpy(dst, src, len) +#endif #define __HAVE_ARCH_MEMMOVE extern void *memmove(void *, const void *, __kernel_size_t); @@ -61,7 +66,9 @@ void memcpy_flushcache(void *dst, const void *src, size_t cnt); */ #define memcpy(dst, src, len) __memcpy(dst, src, len) +#ifndef memcpy_mc #define memcpy_mc(dst, src, len) __memcpy_mc(dst, src, len) +#endif #define memmove(dst, src, len) __memmove(dst, src, len) #define memset(s, c, n) __memset(s, c, n) -- 2.43.0

2 1

[PATCH OLK-6.6] media: dvb-core: fix wrong reinitialization of ringbuffer on reopen
by Chen Jinghuang 24 Mar '26

24 Mar '26

From: Jens Axboe <axboe(a)kernel.dk> mainline inclusion from mainline-v7.0-rc2 commit bfbc0b5b32a8f28ce284add619bf226716a59bc0 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13873 CVE: CVE-2026-23253 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock. Cc: stable(a)vger.kernel.org Fixes: 34731df288a5f ("V4L/DVB (3501): Dmxdev: use dvb_ringbuffer") Reported-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Tested-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/698a26d3.050a0220.3b3015.007d.GAE@google.com/ Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: drivers/media/dvb-core/dmxdev.c [context conflict] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- drivers/media/dvb-core/dmxdev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c index 9ce5f010de3f..4ce3ae3954c5 100644 --- a/drivers/media/dvb-core/dmxdev.c +++ b/drivers/media/dvb-core/dmxdev.c @@ -168,7 +168,9 @@ static int dvb_dvr_open(struct inode *inode, struct file *file) mutex_unlock(&dmxdev->mutex); return -ENOMEM; } - dvb_ringbuffer_init(&dmxdev->dvr_buffer, mem, DVR_BUFFER_SIZE); + dmxdev->dvr_buffer.data = mem; + dmxdev->dvr_buffer.size = DVR_BUFFER_SIZE; + dvb_ringbuffer_reset(&dmxdev->dvr_buffer); if (dmxdev->may_do_mmap) dvb_vb2_init(&dmxdev->dvr_vb2_ctx, "dvr", file->f_flags & O_NONBLOCK); -- 2.34.1

2 1

[PATCH OLK-6.6] media: dvb-core: fix wrong reinitialization of ringbuffer on reopen
by Chen Jinghuang 24 Mar '26

24 Mar '26

From: Jens Axboe <axboe(a)kernel.dk> mainline inclusion from mainline-v7.0-rc2 commit bfbc0b5b32a8f28ce284add619bf226716a59bc0 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13873 CVE: CVE-2026-23253 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock. Cc: stable(a)vger.kernel.org Fixes: 34731df288a5f ("V4L/DVB (3501): Dmxdev: use dvb_ringbuffer") Reported-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Tested-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/698a26d3.050a0220.3b3015.007d.GAE@google.com/ Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: drivers/media/dvb-core/dmxdev.c [context conflict] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- drivers/media/dvb-core/dmxdev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c index 9ce5f010de3f..4ce3ae3954c5 100644 --- a/drivers/media/dvb-core/dmxdev.c +++ b/drivers/media/dvb-core/dmxdev.c @@ -168,7 +168,9 @@ static int dvb_dvr_open(struct inode *inode, struct file *file) mutex_unlock(&dmxdev->mutex); return -ENOMEM; } - dvb_ringbuffer_init(&dmxdev->dvr_buffer, mem, DVR_BUFFER_SIZE); + dmxdev->dvr_buffer.data = mem; + dmxdev->dvr_buffer.size = DVR_BUFFER_SIZE; + dvb_ringbuffer_reset(&dmxdev->dvr_buffer); if (dmxdev->may_do_mmap) dvb_vb2_init(&dmxdev->dvr_vb2_ctx, "dvr", file->f_flags & O_NONBLOCK); -- 2.34.1

2 1

[PATCH 0/5] Transition from CPU Type to MIDR Register for
by liqiqi 24 Mar '26

24 Mar '26

Currently, there are two methods for determining whether a chip supports specific virtualization features: 1. Reading the chip's CPU type from BIOS 2. Reading the value of the MIDR register The issue with the first method is that each time a new chip is introduced, the new CPU type must be defined, which leads to poor code portability and maintainability. Therefore, the second method has been adopted to replace the first. This approach eliminates the dependency on CPU type by using the MIDR register and removes the need for defining CPU types and their related interfaces. liqiqi (5): kvm: arm64: use MIDR_HISI_TSV110 to determine whether NCSNP is supported kvm: arm64: Add HIP10, HIP10C MIDR definitions kvm: arm64: Use MIDR to determine whether DVMBM is supported kvm: arm64: Use MIDR to determine whether IPIv is supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cputype.h | 4 + arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 111 +++------------------------ arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- 4 files changed, 15 insertions(+), 113 deletions(-) -- 2.43.0

1 5

[openEuler-25.03, 0/1] mm: arm64: Add user replication feature with control policies.
by Gadeev Dmitry 24 Mar '26

24 Mar '26

This patchset implements support of userspace translation tables and private read-only data replication for AArch64 and is going to improve latency and memory bandwidth by reducing cross-NUMA memory accesses. openEuler 25.03 is used as a baseline. Current implementation supports next functionality: 1. Per-NUMA node replication of userspace translation tables and private read-only data. We replicate only __private read-only__ data to avoid dealing with replicas coherence and consistency support. Translation tables, in turn, are able to replicate for any kind of underlying data. 2. Ability to enable userspace replication for a certain process via procfs or for a group of processes via memory cgroup. 3. 4K and 64K pages are supported. 4. Several table replication policies supported: 0 - table replication disabled; 1 - table replication enabled only for data might be replicated, e.g. private read-only data; 2 - table replication enabled for any data; Tables are getting replicated during page faults. Several data replication policies supported as well: 0 - data replication disabled; 1 - appropriate data getting replicated on NUMA faults via NUMA balancer; 2 - appropriate data that has been already faulted in are getting replicated immediately, further data will be replicated on NUMA faults. That is no difference between 1 and 2 policies if it is enabled at the start of a process. 3 - appropriate data (with related page tables) are getting replicated immediately after populating either on page faults or somehow else. Data replication might be enabled (!= 0) only with table replication enabled (!= 0). 5. Replicated data pages can't be a ksm, migration or swap/reclaim candidates by design. But for other pages these work as well with replicated translation tables support. Known problems: 1. Current implementation doesn't support huge pages, so you have to build the kernel with huge pages disabled for user replication to work. Huge pages support will be added in the nearest future. 2. mremap syscall doesn't work with replicated memory yet. 3. page_idle, uprobes and userfaultfd support replicated translation tables, but not replicated data. Be responsible using these features with userspace replication enabled. 4. When replicating translation tables during page faults, there should be enough space on __each__ NUMA node for table allocations. Otherwise it will cause OOM-killer. Despite the problems above, they are mostly not related to workloads assumed to benefit from user replication feature, and such workloads will work properly with the feature enabled. Gadeev Dmitry (1): mm: Support NUMA-aware replication of read-only data and translation tables of user space applications with different policies arch/arm64/include/asm/numa_replication.h | 3 + arch/arm64/mm/init.c | 2 +- arch/arm64/mm/pgd.c | 13 +- fs/exec.c | 7 + fs/proc/base.c | 149 ++ fs/proc/task_mmu.c | 112 +- include/asm-generic/pgalloc.h | 19 +- include/asm-generic/tlb.h | 22 + include/linux/cgroup.h | 1 + include/linux/gfp_types.h | 12 +- include/linux/memcontrol.h | 4 + include/linux/mm.h | 77 +- include/linux/mm_inline.h | 5 + include/linux/mm_types.h | 70 +- include/linux/numa_kernel_replication.h | 237 ++- include/linux/numa_user_replication.h | 827 ++++++++ include/linux/page-flags.h | 18 +- include/trace/events/mmflags.h | 10 +- include/uapi/asm-generic/mman-common.h | 3 + kernel/cgroup/cgroup.c | 2 +- kernel/events/uprobes.c | 5 +- kernel/fork.c | 18 + kernel/sched/fair.c | 8 +- mm/Kconfig | 13 + mm/Makefile | 1 + mm/gup.c | 15 +- mm/ksm.c | 15 +- mm/madvise.c | 19 +- mm/memcontrol.c | 181 +- mm/memory.c | 566 +++++- mm/mempolicy.c | 5 + mm/migrate.c | 11 +- mm/migrate_device.c | 17 +- mm/mlock.c | 22 + mm/mmap.c | 26 + mm/mmu_gather.c | 55 +- mm/mprotect.c | 424 ++-- mm/mremap.c | 97 +- mm/numa_kernel_replication.c | 5 +- mm/numa_user_replication.c | 2242 +++++++++++++++++++++ mm/page_alloc.c | 8 +- mm/page_idle.c | 3 +- mm/page_vma_mapped.c | 3 +- mm/rmap.c | 41 +- mm/swap.c | 7 +- mm/swapfile.c | 3 +- mm/userfaultfd.c | 7 +- mm/userswap.c | 11 +- 48 files changed, 4979 insertions(+), 442 deletions(-) create mode 100644 include/linux/numa_user_replication.h create mode 100644 mm/numa_user_replication.c -- 2.53.0

2 3