ubc_msync have a bug

App & System Services Core OS
chenhuaiyu OP
Created Jan ’21
Replies 4
Boosts 0
Views 462
Participants 2
the conflict between ubcmsync of kext and msync of application, my company has implemented a file system similar to NFS, which is implemented by kext. Now we use the rwtest03 case in the modified LTP program to test the consistency of the file system. We find that the data inconsistency is caused by msync function call in the application layer and UBCmsync in kext call conflict, suspected VFS layer processing problem. The test scenario is as follows: 20 processes open the same file, the file size is 12.8 million bytes, MMAP maps the whole file, lock random file range, lock range before memcopy, msync whole file, umap file, read file and write content comparison, close file. The above procedure is called circularly. During the calling process, in the kext file system call occasionally ubcmsync with flag of pull all sync invalidate is the call to the entire file in vnopgetattr, which we must use. It is found that the pageout caused by mmap of application layer is input to our file system. Occasionally, a page of data is old data or bad data, such as all zeros. Occasionally, it can cause double fault in the pageout. We strongly doubt the ubcmsync of Mac OS X and application layer call msync system call caused by the problem, whether there is an expert to answer. thank you.mac os x 10.14.0
Replies  4
Boosts  0
Views  462
Participants  2
chenhuaiyu OP
Jan ’21
Who knows about UBC_ Msync calls invalid cache. Can it be called randomly in the kernel file system. Is there a bug in Mac
0
DTS Engineer OP
Apple
Jan ’21
It’s certainly possible that UBC might have a bug. It’s also possible that your VFS plug-in might have a bug. VFS plug-ins are super complex and the KPI is quite poorly documented )-:

Anyway, let’s start with some regression info:

  • You’re testing on 10.14, which is quite old. Does the problem reproduce on macOS 11? If not, wind back through 10.15.7, 10.15, and 10.14 to see where things changed.

  • Does the same test cause problems when against the primary built-in file systems (APFS and HFS Plus)?

Finally, you wrote:

Who knows about UBC

Be aware that DevForums is an informal support channel, so responses may vary depending on who just happens to see your question and how much time they have available to respond. If you want formal support you should open a DTS tech support incident.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
0
chenhuaiyu OP
Jan ’21
I have realized the function of sharing files in a distributed file system of kext. It is possible to modify the same shared files on multiple MAC machines. Therefore, the vnopgetattr op int the file system is realized, when the mtime attribute of vnode changes, the data cache on vnode is invalid, so ubcmsync interface is called invalid data cache in getattr of my file system kext. I see NFS called Vinvalbuf2 function in getattr, which will call ubcmsync flushes back and invalid cache at the last. I call ubcmsync with reference to this interface as nfs. But in the test case, I used LTP's multiprocess MMAP read-write operation, and found that in the process of MMAP read-write, if getattr called UBC msync, Sometimes a page will be invalid or stale data in vnoppageout. It seems that a page is fault . somtimes the data error seen in vnoppageout is error, sometimes causes double fault in vnoppageout, because I will write data to disk in vnoppageout and cause double fault in iscsi driver. It seems that a page has been released or deleted in block layer. MMAP of application layer and msync after memcopy will cause vnoppageout to call our file system. Can you come to any conclusion, thank you!
0
chenhuaiyu OP
Feb ’21
(lldb) image lookup -a 0xffffff801a5ac283
Address: kernel[0xffffff80003ac283] (kernel.TEXT.text + 344707)
Summary: kernelpanic + 99 at debug.c (lldb) image lookup -a 0xffffff801a6d91ea Address: kernel[0xffffff80004d91ea] (kernel.TEXT.text + 1577450) Summary: kernelpanic64 + 218 at trapnative.c:152
(lldb) image lookup -a 0xffffff801a55a51f
Address: kernel[0xffffff800035a51f] (kernel.TEXT.text + 9503)
Summary: kernelhndl_double_fault + 15 (lldb) image lookup -a 0xffffff801a6cd95f Address: kernel[0xffffff80004cd95f] (kernel.TEXT.text + 1530207) Summary: kernelusimplelock + 47 at machineroutines.c
(lldb) image lookup -a 0xffffff801a5c95ad
Address: kernel[0xffffff80003c95ad] (kernel.TEXT.text + 464301)
Summary: kernelthread_dispatch + 445 at sched_prim.c:2768 (lldb) image lookup -a 0xffffff801a5c906e Address: kernel[0xffffff80003c906e] (kernel.TEXT.text + 462958) Summary: kernelthreadinvoke + 1710 at schedprim.c:2559
(lldb) image lookup -a 0xffffff801a5c7d0f
Address: kernel[0xffffff80003c7d0f] (kernel.TEXT.text + 457999)
Summary: kernelthread_block_reason + 175 at sched_prim.c:3088 (lldb) image lookup -a 0xffffff801a559f64 Address: kernel[0xffffff8000359f64] (kernel.TEXT.text + 8036) Summary: kernelreturntoiret + 276
(lldb) image lookup -a 0xffffff801a9518f5
Address: kernel[0xffffff80007518f5] (kernel.TEXT.text + 4167925)
Summary: kernelfq_alloc + 37 [inlined] mcache_alloc + 12 at classq_fq_codel.c:84 kernelfqalloc + 25 at classqfq_codel.c:84
(lldb) image lookup -a 0xffffff801a959881
Address: kernel[0xffffff8000759881] (kernel.TEXT.text + 4200577)
Summary: kernelfq_if_hash_pkt + 433 at pktsched_fq_codel.c:981 (lldb) image lookup -a 0xffffff801a951d67 Address: kernel[0xffffff8000751d67] (kernel.TEXT.text + 4169063) Summary: kernelfqaddq + 311 at classqfq_codel.c:189
(lldb) image lookup -a 0xffffff801a95860b
Address: kernel[0xffffff800075860b] (kernel.TEXT.text + 4195851)
Summary: kernelfq_if_enqueue_classq + 795 at pktsched_fq_codel.c:382 (lldb) image lookup -a 0xffffff801a868c4c Address: kernel[0xffffff8000668c4c] (kernel.TEXT.text + 3214412) Summary: kernelifnetenqueuecommon + 892 [inlined] ifclassq_enqueue + 41
kernelifnet_enqueue_common + 851 at dlil.c (lldb) image lookup -a 0xffffff801a868806 Address: kernel[0xffffff8000668806] (kernel.TEXT.text + 3213318) Summary: kernelifnet_enqueue + 22 at dlil.c:4252
(lldb) image lookup -a 0xffffff801a86a4ca
Address: kernel[0xffffff800066a4ca] (kernel.TEXT.text + 3220682)
Summary: kerneldlil_output + 4026 at dlil.c:5573 (lldb) image lookup -a 0xffffff801a98f688 Address: kernel[0xffffff800078f688] (kernel.TEXT.text + 4421256) Summary: kernelipoutputlist + 10968 at ip_output.c
(lldb) image lookup -a 0xffffff801a9a4fe9
Address: kernel[0xffffff80007a4fe9] (kernel.TEXT.text + 4509673)
Summary: kerneltcp_ip_output + 857 at tcp_output.c:2852 (lldb) image lookup -a 0xffffff801a9a44a0 Address: kernel[0xffffff80007a44a0] (kernel.TEXT.text + 4506784) Summary: kerneltcpoutput + 13392 at tcpoutput.c:2534
(lldb) image lookup -a 0xffffff801a9b1f00
Address: kernel[0xffffff80007b1f00] (kernel.TEXT.text + 4562688)
Summary: kerneltcp_usr_send + 1296 at tcp_usrreq.c:1087 (lldb) image lookup -a 0xffffff801ab2108c Address: kernel[0xffffff800092108c] (kernel.TEXT.text + 6066316) Summary: kernelsosend + 2908 at uipc_socket.c:2453
(lldb) image lookup -a 0xffffff801ab4830d
Address: kernel[0xffffff800094830d] (kernel.TEXT.text + 6226701)
Summary: kernelsock_send_internal + 589 at kpi_socket.c:867 (lldb) image lookup -a 0xffffff801a82edc2 Address: kernel[0xffffff800062edc2] (kernel.TEXT.text + 2977218) Summary: kernelVNOPSTRATEGY + 66 at kpivfs.c:5722
(lldb) image lookup -a 0xffffff801a83785f
Address: kernel[0xffffff800063785f] (kernel.TEXT.text + 3012703)
Summary: kernelspec_strategy + 943 at spec_vnops.c:2408 (lldb) image lookup -a 0xffffff801ab54409 Address: kernel[0xffffff8000954409] (kernel.TEXT.text + 6276105) Summary: kernelvnodepageout + 2297 [inlined] VNOPPAGEOUT + 93 at vnode_pager.c:522
kernelvnode_pageout + 2204 at vnode_pager.c:522 (lldb) image lookup -a 0xffffff801a622dbf Address: kernel[0xffffff8000422dbf] (kernel.TEXT.text + 830911) Summary: kernelvnodepagerclusterwrite + 271 at bsdvm.c:790
(lldb) image lookup -a 0xffffff801a622c0f
Address: kernel[0xffffff8000422c0f] (kernel.TEXT.text + 830479)
Summary: kernelvnode_pager_data_return + 15 at bsd_vm.c:454 (lldb) image lookup -a 0xffffff801a63070b Address: kernel[0xffffff800043070b] (kernel.TEXT.text + 886539) Summary: kernelvmobjectupdate + 3291 [inlined] memoryobjectdatareturn + 46 at memoryobject.c:580
kernelvm_object_update + 3245 [inlined] vm_object_update_extent + 811 at memory_object.c:1031 kernelvmobjectupdate + 2434 at memory_object.c:1031
(lldb) image lookup -a 0xffffff801a62f974
Address: kernel[0xffffff800042f974] (kernel.TEXT.text + 883060)
Summary: kernelmemory_object_lock_request + 308 at memory_object.c:341 (lldb) image lookup -a 0xffffff801ab03158 Address: kernel[0xffffff8000903158] (kernel.TEXT.text + 5943640) Summary: kernelubcmsync + 232 [inlined] ubcmsyncinternal + 189 at ubcsubr.c:1646
kernelubc_msync + 43 at ubc_subr.c:1646 (lldb) image lookup -a 0xffffff801a8293f4 Address: kernel[0xffffff80006293f4] (kernel.TEXT.text + 2954228) Summary: kernelvnodegetattr + 164 [inlined] VNOPGETATTR + 48 at kpi_vfs.c:2374
kernelvnode_getattr + 116 at kpi_vfs.c:2374 (lldb) image lookup -a 0xffffff801acd2a9b Address: kernel[0xffffff8000ad2a9b] (kernel.TEXT.text + 7842459) Summary: kernelmacvnodecheckgetattrlist + 123 at macvfs.c:1010
(lldb) image lookup -a 0xffffff801a7d2ea8
Address: kernel[0xffffff80005d2ea8] (kernel.TEXT.text + 2600616)
Summary: kernelgetattrlist_internal + 424 at vfs_attrlist.c:2832 (lldb) image lookup -a 0xffffff801a7d5cff Address: kernel[0xffffff80005d5cff] (kernel.TEXT.text + 2612479) Summary: kernelgetattrlistatinternal + 287 at vfsattrlist.c:3071
(lldb) image lookup -a 0xffffff801a7d5bd0
Address: kernel[0xffffff80005d5bd0] (kernel.TEXT.text + 2612176)
Summary: kernelgetattrlist + 112 at vfs_attrlist.c:3096 (lldb) image lookup -a 0xffffff801abb5b7b Address: kernel[0xffffff80009b5b7b] (kernel.TEXT.text + 6675323) Summary: kernelunixsyscall64 + 619 at systemcalls.c:381
(lldb) image lookup -a 0xffffff801a55a466
Address: kernel[0xffffff800035a466] (kernel.TEXT.text + 9318)
Summary: kernel`hndlunix_scall64 + 22
0
ubc_msync have a bug
First post date Last post date
 
 
Q