|
Bugzilla – Full Text Bug Listing |
| Summary: | LTP: openQA test fails in msync04 on ntfs | ||
|---|---|---|---|
| Product: | [openSUSE] PUBLIC SUSE Linux Enterprise Server 15 SP6 | Reporter: | WEI GAO <wegao> |
| Component: | Kernel | Assignee: | Kernel Bugs <kernel-bugs> |
| Status: | NEW --- | QA Contact: | |
| Severity: | Normal | ||
| Priority: | P3 - Medium | CC: | avinesh.kumar, hector.oron, jack, pcervinka, petr.vorel |
| Version: | unspecified | Flags: | wegao:
needinfo?
|
| Target Milestone: | --- | ||
| Hardware: | PowerPC-64 | ||
| OS: | Other | ||
| URL: | https://openqa.suse.de/tests/14296698/modules/msync04/steps/7 | ||
| Whiteboard: | |||
| Found By: | openQA | Services Priority: | |
| Business Priority: | Blocker: | Yes | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
failed strace log
pass strace log failed ftrace on powerVM env |
||
|
Description
WEI GAO
2024-05-14 07:55:30 UTC
Another failed case which also triggered by ntfs check (which enabled on PowerVM on 89.1) https://openqa.suse.de/tests/14296699#step/fallocate06/6 @wei could you please check similar fail on aarch64 baremetal https://openqa.suse.de/tests/14280426#step/msync04/8 ? (In reply to Petr Cervinka from comment #2) > @wei could you please check similar fail on aarch64 baremetal > https://openqa.suse.de/tests/14280426#step/msync04/8 ? sure, will check it. It seems issue failed on different setup, such as arm qemu will pass but baremetal arm will fail, same for power, power qemu env is pass but powerVM env is fail. arm qemu is pass https://openqa.suse.de/tests/14288381#step/msync04/6 arm baremetal is failed https://openqa.suse.de/tests/14280426#step/msync04/7 ppc64le-virtio qemu is pass https://openqa.suse.de/tests/14305717#step/msync04/7 powerVM is failed https://openqa.suse.de/tests/14296698#step/msync04/1 Created attachment 874892 [details]
failed strace log
Created attachment 874893 [details]
pass strace log
When i try to manual reproduce in openqa powerVM env, i found this issue not 100% reproduce, i suspect test case encounter some latency when update the dirty bit. Further investigation needed. also happen on 390kvm https://openqa.suse.de/tests/14305377#step/msync04/7 memcontrol02 test also failed on ntfs. https://openqa.suse.de/tests/14305637#step/memcontrol02/7 (In reply to WEI GAO from comment #8) > memcontrol02 test also failed on ntfs. > https://openqa.suse.de/tests/14305637#step/memcontrol02/7 I wonder if this is related. Although NTFS on s390x is likely not much used combination. Also, it fails on Tumbleweed on x86_64 when run with debug_pagealloc=on (but not on SLE 15-SP6). https://openqa.opensuse.org/tests/4187995#step/msync04/8 Both tests format NTFS on loop device, underlying is Btrfs. Jan, could you please have a look? BTW you commented 3 years old issue on (but on XFS and on x86_64). dmesg does not mention anything NTFS related, but I can add logs if you want to see it. https://lore.kernel.org/ltp/20220125121746.wrs4254pfs2mwexb@quack3.lan/ In powerVM env if you add extra sync() before write mmaped area in test case, then you can reproduce this issue 100%.
diff --git a/testcases/kernel/syscalls/msync/msync04.c b/testcases/kernel/syscalls/msync/msync04.c
index 72ddc27a4..26b966505 100644
--- a/testcases/kernel/syscalls/msync/msync04.c
+++ b/testcases/kernel/syscalls/msync/msync04.c
@@ -53,6 +53,7 @@ static void test_msync(void)
mmaped_area = SAFE_MMAP(NULL, pagesize, PROT_READ | PROT_WRITE,
MAP_SHARED, test_fd, 0);
SAFE_CLOSE(test_fd);
+sync();
mmaped_area[8] = 'B';
dirty = get_dirty_bit(mmaped_area);
if (!dirty) {
Also attach the ftrace for following line, i find balance_dirty_pages(i suppose this is the reason why dirty flag cleared before we start check it) called within handle_mm_fault, i suppose there some potential issue here(normally balance_dirty_pages should not be called here), all dirty page should already cleared by sync() before.
mmaped_area[8] = 'B'; <<<<<
Created attachment 874950 [details]
failed ftrace on powerVM env
Also happens on some x86_64 baremetal machines https://openqa.suse.de/tests/14339973#step/msync04/7 isn't it related to higher amount of ram? Well, as already explained in the email communication referenced from comment 9, msync04 test is inherently racy and I don't see that anything has changed to address that. Nothing guarantees that the page is not written out before get_dirty_page() manages to read the page state. Hence the test should be reworked to verify the page contents is on disk when it finds dirty bit isn't set anymore... (In reply to Jan Kara from comment #13) > Well, as already explained in the email communication referenced from > comment 9, msync04 test is inherently racy and I don't see that anything has > changed to address that. Nothing guarantees that the page is not written out > before get_dirty_page() manages to read the page state. Hence the test > should be reworked to verify the page contents is on disk when it finds > dirty bit isn't set anymore... Thanks for pointing it out, I'm sorry to overlook the actual info you put there already. Although it might be useful to add msync support to framework in fstests, let's first try rewrite LTP msync04 test. I created a ticket for it: https://github.com/linux-test-project/ltp/issues/1157. (In reply to Petr Vorel from comment #14) > (In reply to Jan Kara from comment #13) > > Well, as already explained in the email communication referenced from > > comment 9, msync04 test is inherently racy and I don't see that anything has > > changed to address that. Nothing guarantees that the page is not written out > > before get_dirty_page() manages to read the page state. Hence the test > > should be reworked to verify the page contents is on disk when it finds > > dirty bit isn't set anymore... > > Thanks for pointing it out, I'm sorry to overlook the actual info you put > there already. Although it might be useful to add msync support to framework > in fstests, let's first try rewrite LTP msync04 test. I created a ticket for > it: https://github.com/linux-test-project/ltp/issues/1157. Thanks both Petr and Jan, i will try to fix https://github.com/linux-test-project/ltp/issues/1157. |