From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj2-f4.google.com (mail-pj2-f4.google.com [74.125.227.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B520B176FB1 for ; Wed, 8 Jul 2026 01:31:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.227.132 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783474283; cv=none; b=lVj6qgtTgUr64PFTqAOyfQTtr0wRXx/kAaa+5KHOCj8uFAi+5hEW+S3b07o0frtPlVjiSYAjnCvavSTYhclZILJ0Gr4j+MygFmTpjlnyZPK2KXRJ7DC1yu92DGCaFcBSZE159W+JdALoXkvtQieoQ6w0Y5i7TmzUS5JBnZw4lJ8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783474283; c=relaxed/simple; bh=OVmXd4rCBHziySVsuXof+n5zHjriBavZp5Q1amysqzs=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=O5BVj9yX5wCzA2iBwBTTz4O1e7PZAjBBFd/7GwFk69fzYMH9j0L6MgGmiTJPhIRxbRIJ/9RELxWu92a4k/26fyMlILIuMdDPgHxzPqoViqI3xmKQ6beYLOq9a5XKyd4hrbpdNrVXo5Z3otRae/hbW5xJ2Xx619mdCcKQCu51s18= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=UEMhds4b; arc=none smtp.client-ip=74.125.227.132 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="UEMhds4b" Received: by mail-pj2-f4.google.com with SMTP id 98e67ed59e1d1-381a094c43fso100716a91.0 for ; Tue, 07 Jul 2026 18:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783474280; x=1784079080; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=D/LQLPuILxjB411/fYFouWHdkKkRbW9iZLAYWIeHak0=; b=UEMhds4bjx4790faMqpsOwLWxuVJICY9837C84RQGIj2v5l0p7sJZJJC/wQwt8F3f3 gnOc5vFOV1mYj6rLjXQSqMxSzkSiwwuOrkmLrFmbpkKxkKN9mctIaWcQEmG1+FFbguxX yYlg3l0sjxjZ3O5TsxeUwNg7eTd5xyYsJMlYyknGJ0Yg/twY5fRpgiVlffIkyXCCyOiS ejxu9xKVZ0zR5/yotqRo8GfsESylgpCGZG1vVCCTe24Ktn4gFA03n/XKMvrOCcOmXapC GOCuG4zyebUSc1Nty28Bhk/e4n2giMCNdsHzJbthPIzgIgyIptaimOtV2n1bifZ6jCeo vmfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783474280; x=1784079080; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=D/LQLPuILxjB411/fYFouWHdkKkRbW9iZLAYWIeHak0=; b=jTcdZzr99N0iUaYRLRP8L2nAIZ+BusXzpAdnJqGxr/vcNQk1FnFysmDaLsIhsIYgzA IYIjYT+gxI2LKZ2GndvbUNXZ9uxKoy8AY93npt1Ed33GF0wX0Q6fObe/wD6d+L1cP+L0 BrXt7tmD2aAVi1k/16IiPL8fMIKWGYcDlRwdztf+KdORo0SWSCb/9U29Q/FLx2dijYjG HmKWzpXaN+k0DnMhZrHGFmqoTAYRdLvrNKds59Xk3ZwJJoGhZ65fBSrPJvhGKrTmDCic fTnn9ZSoAKwVDvTz+5J00gsC0iPPgxbzuVCi13qqZFFce0ux7p+YnsFM+0DgxPkQXHIY U3iA== X-Forwarded-Encrypted: i=1; AHgh+RrPykZP8hwlruxs/Mo8TKlM9cuiQ8CRnB/ZGKK/Et0A4dY020UDfBO+e+B5Hi1dofhGGPLxze3FiEhFJ48=@vger.kernel.org X-Gm-Message-State: AOJu0Yz/4wkqxkILJQTAoAPn6JqLVtmornct9pvop5pDDhTcklc2AUha FFJUZF2gn4HWbuSlzrAqlHb/F6/gkJks7oLJrEWxpIXMSDOLzQ/5pftG X-Gm-Gg: AfdE7cn0zSmOSKCew8/PTkLDTz7CcwOjZpfqWrCiLhQKIrESqIpq2VMJLVb0zcl/VI5 z3iN5gCPAauAQM6tBzImJapkMMxCAHNQ2bxq/z2VhEezOo0LXSV5Q7H1fBNuIHzzeLmbMC9DNLG dLXu9MM5RSQYpaF+xlHNEXNkC+tNVq2yW9YPB58Kkk0YakHdsAs1F4TeLXjvcCw5HVZsRZXeo3C bUE2sxEuzX4uvPMXoUgeT4695B3KpVOVKx4Oi2NP9e91Dw6YycBx0vsn8whn6C4v0ma6v7eb5Kb GA3e3jfpkjK+8yrZT5Kvo42+7MuBcEeJY99H5AZ3pmzQNf6exDwJyTZ4UnN7UkkJH2tY7AVMWFn 6/MVTi2vsARcNVX3adeFRdGMaD/1R0YqHfzyyzaPEq66SJvzg960YdLaootPglwRiJ4flbTVFZL yK58O8KcYjnzFnSteeDBFH X-Received: by 2002:a05:6a21:62c6:b0:398:837a:7af0 with SMTP id adf61e73a8af0-3c0bd04207cmr152449637.30.1783474280029; Tue, 07 Jul 2026 18:31:20 -0700 (PDT) Received: from [10.125.112.20] ([210.184.73.204]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-ca5af7d58f3sm1656435a12.1.2026.07.07.18.31.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jul 2026 18:31:19 -0700 (PDT) Message-ID: Date: Wed, 8 Jul 2026 09:31:09 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/3] mm/compaction: skip isolate mlocked folios when compact_unevictable_allowed=0 From: Wandun To: Alexander Krabler , "Vlastimil Babka (SUSE)" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "linux-trace-kernel@vger.kernel.org" , "linux-rt-devel@lists.linux.dev" Cc: "akpm@linux-foundation.org" , "surenb@google.com" , "mhocko@suse.com" , "jackmanb@google.com" , "hannes@cmpxchg.org" , "ziy@nvidia.com" , "rostedt@goodmis.org" , "mhiramat@kernel.org" , "mathieu.desnoyers@efficios.com" , "david@kernel.org" , "ljs@kernel.org" , "liam@infradead.org" , "rppt@kernel.org" , "bigeasy@linutronix.de" , "clrkwllms@kernel.org" , Hugh Dickins References: <20260604023812.3700316-1-chenwandun1@gmail.com> <20260604023812.3700316-2-chenwandun1@gmail.com> <969cb14b-5b8b-48e6-add6-4dd13101dd89@kernel.org> <040788a9-e0d5-478e-bb48-3d22b8b41020@gmail.com> <05d7369e-341c-49f4-ae13-df3d0ad930d7@gmail.com> Content-Language: en-US In-Reply-To: <05d7369e-341c-49f4-ae13-df3d0ad930d7@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 6/29/26 17:07, Wandun wrote: > > > On 6/26/26 21:42, Alexander Krabler wrote: >> On 6/26/26 11:38, Wandun wrote: >>> On 6/26/26 16:45, Alexander Krabler wrote: >>>> However, we were not able to reproduce the actual race >>>> (mlockall() process waiting on a migration PTE), >>>> not in the past, not now. Might be hard to trigger that race. >>> >>> Not hard to trigger that case, I added a debug message, such as below, >>> lots of messages occur in a few second. >>> >>> diff --cc mm/memory.c >>> index ff338c2abe92,ff338c2abe92..6552b3b14f78 >>> --- a/mm/memory.c >>> +++ b/mm/memory.c >>> @@@ -4768,6 -4768,6 +4768,8 @@@ vm_fault_t do_swap_page(struct vm_faul >>> if (softleaf_is_migration(entry)) { >>> migration_entry_wait(vma->vm_mm, vmf->pmd, >>> vmf->address); >>> + if (!strcmp(current->comm, "repro")) >>> + pr_err("============== hit ================\n"); >>> } else if (softleaf_is_device_exclusive(entry)) { >>> vmf->page = softleaf_to_page(entry); >>> ret = remove_device_exclusive_entry(vmf); >> >> I have a kprobe on migration_entry_wait set and logged into a ftrace buffer >> (including kernel stacktrace). >> Yes, this function is hit, but only inside the mmap-syscall, which is okay, >> memory allocation is not realtime-safe. >> >> repro-2090 [002] d.... 811.129549: frt_migration_entry_wait: (migration_entry_wait+0x0/0x100) >> repro-2090 [002] d.... 811.129553: >> => migration_entry_wait >> => __handle_mm_fault >> => handle_mm_fault >> => __get_user_pages >> => populate_vma_page_range >> => __mm_populate >> => vm_mmap_pgoff >> => ksys_mmap_pgoff >> => __arm64_sys_mmap >> => el0_svc_common.constprop.0 >> => do_el0_svc >> => el0_svc >> => el0t_64_sync_handler >> => el0t_64_sync >> >> The original race was an instruction abort interrupt out of nothing due >> to the migration PTE set by kcompactd. >> And these kind of races I see quite often on non mlockall()-processes, >> but can't reproduce on memory locked processes. >> >> Example: >> podman-832 [000] d.... 812.447820: frt_migration_entry_wait: (migration_entry_wait+0x0/0x100) >> podman-832 [000] d.... 812.447823: >> => migration_entry_wait >> => __handle_mm_fault >> => handle_mm_fault >> => do_page_fault >> => do_translation_fault >> => do_mem_abort >> => el0_da >> => el0t_64_sync_handler >> => el0t_64_sync > > Hi, Alexander > > From the perspective of the root cause, there is no fundamental difference > between these two call stacks. I modified the reproduction program, and it > can still reproduce the situation of the second call stack > (although it doesn't occur as frequently). The complete reproduction program > is as follows: > > > #define _GNU_SOURCE > #include > #include > #include > #include > #include > #include > #include > > #define PAGE_SIZE 4096 > #define NR_PAGES 10000 > > static void *worker_fn(void *arg) > { > int fd = (long)arg; > size_t len = NR_PAGES * PAGE_SIZE; > > while (1) { > if (ftruncate(fd, 0) < 0) {} > if (ftruncate(fd, len) < 0) {} > > char *p = mmap(NULL, len, PROT_READ | PROT_WRITE, > MAP_SHARED, fd, 0); > if (p == MAP_FAILED) > continue; > > mlockall(MCL_ONFAULT | MCL_FUTURE); > > for (int i = 0; i < NR_PAGES; i++) { > for (int j = 0; j < PAGE_SIZE; j++) { > p[i * PAGE_SIZE + j] = 1; > } > } > > usleep(200); > munmap(p, len); > } > return NULL; > } > > static void *compact_fn(void *arg) > { > (void)arg; > int fd = open("/proc/sys/vm/compact_memory", O_WRONLY); > if (fd < 0) > return NULL; > > while (1) { > if (write(fd, "1", 1) < 0) {} > usleep(5000); > } > } > > int main(void) > { > int nproc = sysconf(_SC_NPROCESSORS_ONLN); > if (nproc < 1) > nproc = 1; > > int *fds = calloc((size_t)nproc, sizeof(int)); > if (!fds) > return 1; > > size_t len = NR_PAGES * PAGE_SIZE; > for (int i = 0; i < nproc; i++) { > char path[64]; > snprintf(path, sizeof(path), "./repro_%d.dat", i); > unlink(path); > fds[i] = open(path, O_RDWR | O_CREAT, 0600); > if (fds[i] < 0) > return 1; > if (ftruncate(fds[i], len) < 0) > return 1; > } > > printf("repro: %d workers, %d pages, Ctrl-C to stop\n", > nproc, NR_PAGES); > > pthread_t compact; > pthread_create(&compact, NULL, compact_fn, NULL); > > pthread_t *threads = calloc((size_t)nproc, sizeof(pthread_t)); > for (int i = 0; i < nproc; i++) > pthread_create(&threads[i], NULL, worker_fn, (void *)(long)fds[i]); > > pthread_join(compact, NULL); > return 0; > } I found there are false positives in this reproducer. I modified the program a little, the diff is as follows, the problem can still be reproduced diff --git a/repro.c b/repro.c index b1b34d5..59cb417 100644 --- a/repro.c +++ b/repro.c @@ -15,6 +15,7 @@ static void *worker_fn(void *arg) int fd = (long)arg; size_t len = NR_PAGES * PAGE_SIZE; + mlockall(MCL_ONFAULT | MCL_FUTURE | MCL_CURRENT); while (1) { if (ftruncate(fd, 0) < 0) {} if (ftruncate(fd, len) < 0) {} @@ -24,8 +25,6 @@ static void *worker_fn(void *arg) if (p == MAP_FAILED) continue; - mlockall(MCL_ONFAULT | MCL_FUTURE); - for (int i = 0; i < NR_PAGES; i++) { for (int j = 0; j < PAGE_SIZE; j++) { p[i * PAGE_SIZE + j] = 1; > > > > >> >> Thanks, >> Alexander >> >> -- >> >> KUKA Deutschland GmbH Board of Directors: Michael Jürgens (Chairman), Johan Naten, Hui Zhang Registered Office: Augsburg HRB 14914 >> >> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of contents of this e-mail is strictly forbidden. >> >> Please consider the environment before printing this e-mail. >