Running pynfs on macOS
Quick update on macOS progress. I just uploaded 4 patches to Gerrit which (along with other build hacks, shared previously [1]) allow macOS to run the pynfs 4.0 suite without crashing. I thought I may be done with crash bugs, but I hit another one while editing an FSAL_MEM-backed file in Vim, and the pynfs 4.1 suite has at least one crash failure too (related to lock misuse, similar to the last 4 patches). I will continue to send patches for non-macOS-specific correctness bugs. The pynfs 4.0 suite still has failures [2]. I may not address these at all, depending on the root cause, since I'm not really concerned with FSAL_MEM in particular, since I plan to be writing my own FSAL backend. [1] https://github.com/matvore/nfs-ganesha [2] WRT5a st_write.testMaximumData : FAILURE READ did not correspond to WRITE with large dataset -- SATT18 st_setattr.testMixed : FAILURE Changing size from 0 to 10 and owner to b'65534' using stateid=0 should return NFS4_OK, instead got NFS4ERR_PERM -- SEC7 st_secinfo.testRPCSEC_GSS : FAILURE SECINFO returned mechanism list without RPCSEC_GSS -- OPEN30 st_open.testReplay : FAILURE non-replayed open should fail should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK -- OPEN25 st_open.testDenyWrite1 : FAILURE OPEN with access==write on a write-denied file should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK -- OPEN21 st_open.testDenyRead1 : FAILURE OPEN with access==read on a read-denied file should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK -- WRT5a st_write.testMaximumData : FAILURE READ did not correspond to WRITE with large dataset -- SATT18 st_setattr.testMixed : FAILURE Changing size from 0 to 10 and owner to b'65534' using stateid=0 should return NFS4_OK, instead got NFS4ERR_PERM -- SEC7 st_secinfo.testRPCSEC_GSS : FAILURE SECINFO returned mechanism list without RPCSEC_GSS -- OPEN30 st_open.testReplay : FAILURE non-replayed open should fail should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK -- OPEN25 st_open.testDenyWrite1 : FAILURE OPEN with access==write on a write-denied file should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK -- OPEN21 st_open.testDenyRead1 : FAILURE OPEN with access==read on a read-denied file should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK
Here are the known failures in pynfs4.0: WRT18 st_write.testChangeGranularityWrite : FAILURE consecutive SETATTR(mode)'s don't all change change attribute SEC7 st_secinfo.testRPCSEC_GSS : FAILURE SECINFO returned mechanism list without RPCSEC_GSS OPEN30 st_open.testReplay : FAILURE non-replayed open should fail should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK OPEN25 st_open.testDenyWrite1 : FAILURE OPEN with access==write on a write-denied file should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK OPEN21 st_open.testDenyRead1 : FAILURE OPEN with access==read on a read-denied file should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK The 3 OPEN failures are due to: 61c83b - Do not downgrade on reopen. SEC7 fails if you don't have Kerberos setup and part of your export. WRT18 may or may not fail depending on the resolution of timestamps in the underlying file system. So the concerning failures for your test are WRT5a and SATT18. Frank
-----Original Message----- From: Matthew DeVore [mailto:matvore@comcast.net] Sent: Friday, October 30, 2020 6:57 AM To: devel@lists.nfs-ganesha.org Cc: bga@google.com; ankurag@google.com Subject: [NFS-Ganesha-Devel] Running pynfs on macOS
Quick update on macOS progress.
I just uploaded 4 patches to Gerrit which (along with other build hacks, shared previously [1]) allow macOS to run the pynfs 4.0 suite without crashing.
I thought I may be done with crash bugs, but I hit another one while editing an FSAL_MEM-backed file in Vim, and the pynfs 4.1 suite has at least one crash failure too (related to lock misuse, similar to the last 4 patches).
I will continue to send patches for non-macOS-specific correctness bugs.
The pynfs 4.0 suite still has failures [2]. I may not address these at all, depending on the root cause, since I'm not really concerned with FSAL_MEM in particular, since I plan to be writing my own FSAL backend.
[1] https://github.com/matvore/nfs-ganesha
[2] WRT5a st_write.testMaximumData : FAILURE READ did not correspond to WRITE with large dataset -- SATT18 st_setattr.testMixed : FAILURE Changing size from 0 to 10 and owner to b'65534' using stateid=0 should return NFS4_OK, instead got NFS4ERR_PERM -- SEC7 st_secinfo.testRPCSEC_GSS : FAILURE SECINFO returned mechanism list without RPCSEC_GSS -- OPEN30 st_open.testReplay : FAILURE non-replayed open should fail should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK -- OPEN25 st_open.testDenyWrite1 : FAILURE OPEN with access==write on a write-denied file should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK -- OPEN21 st_open.testDenyRead1 : FAILURE OPEN with access==read on a read-denied file should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK -- WRT5a st_write.testMaximumData : FAILURE READ did not correspond to WRITE with large dataset -- SATT18 st_setattr.testMixed : FAILURE Changing size from 0 to 10 and owner to b'65534' using stateid=0 should return NFS4_OK, instead got NFS4ERR_PERM -- SEC7 st_secinfo.testRPCSEC_GSS : FAILURE SECINFO returned mechanism list without RPCSEC_GSS -- OPEN30 st_open.testReplay : FAILURE non-replayed open should fail should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK -- OPEN25 st_open.testDenyWrite1 : FAILURE OPEN with access==write on a write-denied file should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK -- OPEN21 st_open.testDenyRead1 : FAILURE OPEN with access==read on a read-denied file should return NFS4ERR_SHARE_DENIED, instead got NFS4_OK _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
Good to know these failures are mostly already known. On Fri, Oct 30, 2020 at 07:15:33AM -0700, Frank Filz wrote:
So the concerning failures for your test are WRT5a and SATT18.
SATT18 fails with this message in the log: Access check returned Forbidden action (new OWNER was not user) That comes from fsal_helper.c. I put an extra log to confirm that attr->owner (what the request indicates the new owner should be) is 65534. I guess it is expected that the tests are usually ran as sudo. As for WRT5a, I set the inode size for the FSAL_MEM export to ~1MB (cargo-culted from a sample config file), and the file size for this FSAL appears to be capped at that. So any attempt to read bytes past the first inode worth of bytes returns 'a' bytes. See the line "isize += MEM.inode_size;" and the mem_read2 function in mem_handle.c. At the risk of overloading this thread, I noticed a more alarming bug. I added an assert in _mdcache_lru_unref to verify that the post-decremented refcount was non-negative. The assert failure can be triggered trivially (with FSAM_MEM, just mount the export and run "export foo > bar" in the root of the export). When the assert failed, the last two ref puts were at: 0 libganesha_nfsd.4.dylib 0x00000001069cd67b _mdcache_lru_unref + 443 1 libganesha_nfsd.4.dylib 0x00000001069bbbae mdcache_put_ref + 30 2 libganesha_nfsd.4.dylib 0x0000000106979867 compound_data_Free + 87 3 libganesha_nfsd.4.dylib 0x00000001069795bb nfs4_Compound + 1307 4 libganesha_nfsd.4.dylib 0x000000010690ff48 nfs_rpc_process_request + 4344 5 libganesha_nfsd.4.dylib 0x000000010690ed2c nfs_rpc_valid_NFS + 268 6 libntirpc.3.2.dylib 0x0000000106ae9b55 svc_vc_decode + 133 7 libntirpc.3.2.dylib 0x0000000106ae68e3 svc_request + 51 8 libntirpc.3.2.dylib 0x0000000106ae8d6f svc_vc_recv + 943 9 libntirpc.3.2.dylib 0x0000000106ae6805 svc_rqst_xprt_task_recv + 85 10 libntirpc.3.2.dylib 0x0000000106ae4ea1 svc_rqst_epoll_loop + 769 11 libntirpc.3.2.dylib 0x0000000106af0112 work_pool_thread + 402 12 libsystem_pthread.dylib 0x00007fff70cfc109 _pthread_start + 148 13 libsystem_pthread.dylib 0x00007fff70cf7b8b thread_start + 15 Which seems reasonable. The next one, which brought the refcount to -1, was: 0 libganesha_nfsd.4.dylib 0x00000001069cd67b _mdcache_lru_unref + 443 1 libganesha_nfsd.4.dylib 0x00000001069c3bba cih_remove_checked + 618 2 libganesha_nfsd.4.dylib 0x00000001069c37dd mdc_clean_entry + 1085 3 libganesha_nfsd.4.dylib 0x00000001069cfb67 mdcache_lru_clean + 919 4 libganesha_nfsd.4.dylib 0x00000001069cd8f9 _mdcache_lru_unref + 1081 5 libganesha_nfsd.4.dylib 0x00000001069bbbae mdcache_put_ref + 30 6 libganesha_nfsd.4.dylib 0x0000000106979867 compound_data_Free + 87 7 libganesha_nfsd.4.dylib 0x00000001069795bb nfs4_Compound + 1307 8 libganesha_nfsd.4.dylib 0x000000010690ff48 nfs_rpc_process_request + 4344 9 libganesha_nfsd.4.dylib 0x000000010690ed2c nfs_rpc_valid_NFS + 268 10 libntirpc.3.2.dylib 0x0000000106ae9b55 svc_vc_decode + 133 11 libntirpc.3.2.dylib 0x0000000106ae68e3 svc_request + 51 12 libntirpc.3.2.dylib 0x0000000106ae8d6f svc_vc_recv + 943 13 libntirpc.3.2.dylib 0x0000000106ae6805 svc_rqst_xprt_task_recv + 85 14 libntirpc.3.2.dylib 0x0000000106ae4ea1 svc_rqst_epoll_loop + 769 15 libntirpc.3.2.dylib 0x0000000106af0112 work_pool_thread + 402 16 libsystem_pthread.dylib 0x00007fff70cfc109 _pthread_start + 148 17 libsystem_pthread.dylib 0x00007fff70cf7b8b thread_start + 15 Of course, there is no guarantee that this is the "wrong" or extra ref put, but I can't see the ref get to correspond with this put. Any thoughts? - Matt
Good to know these failures are mostly already known.
On Fri, Oct 30, 2020 at 07:15:33AM -0700, Frank Filz wrote:
So the concerning failures for your test are WRT5a and SATT18.
SATT18 fails with this message in the log: Access check returned Forbidden action (new OWNER was not user)
That comes from fsal_helper.c. I put an extra log to confirm that attr->owner (what the request indicates the new owner should be) is 65534.
I guess it is expected that the tests are usually ran as sudo.
Ah, yes, that test won't do well if not root...
As for WRT5a, I set the inode size for the FSAL_MEM export to ~1MB (cargo- culted from a sample config file), and the file size for this FSAL appears to be capped at that. So any attempt to read bytes past the first inode worth of bytes returns 'a' bytes. See the line "isize += MEM.inode_size;" and the mem_read2 function in mem_handle.c.
Ok, that becomes an expected failure...
At the risk of overloading this thread, I noticed a more alarming bug. I added an assert in _mdcache_lru_unref to verify that the post-decremented refcount was non-negative. The assert failure can be triggered trivially (with FSAM_MEM, just mount the export and run "export foo > bar" in the root of the export). When the assert failed, the last two ref puts were at:
I'll defer to Daniel for looking at this one.
0 libganesha_nfsd.4.dylib 0x00000001069cd67b _mdcache_lru_unref + 443 1 libganesha_nfsd.4.dylib 0x00000001069bbbae mdcache_put_ref + 30 2 libganesha_nfsd.4.dylib 0x0000000106979867 compound_data_Free + 87 3 libganesha_nfsd.4.dylib 0x00000001069795bb nfs4_Compound + 1307 4 libganesha_nfsd.4.dylib 0x000000010690ff48 nfs_rpc_process_request + 4344 5 libganesha_nfsd.4.dylib 0x000000010690ed2c nfs_rpc_valid_NFS + 268 6 libntirpc.3.2.dylib 0x0000000106ae9b55 svc_vc_decode + 133 7 libntirpc.3.2.dylib 0x0000000106ae68e3 svc_request + 51 8 libntirpc.3.2.dylib 0x0000000106ae8d6f svc_vc_recv + 943 9 libntirpc.3.2.dylib 0x0000000106ae6805 svc_rqst_xprt_task_recv + 85 10 libntirpc.3.2.dylib 0x0000000106ae4ea1 svc_rqst_epoll_loop + 769 11 libntirpc.3.2.dylib 0x0000000106af0112 work_pool_thread + 402 12 libsystem_pthread.dylib 0x00007fff70cfc109 _pthread_start + 148 13 libsystem_pthread.dylib 0x00007fff70cf7b8b thread_start + 15
Which seems reasonable. The next one, which brought the refcount to -1, was:
0 libganesha_nfsd.4.dylib 0x00000001069cd67b _mdcache_lru_unref + 443 1 libganesha_nfsd.4.dylib 0x00000001069c3bba cih_remove_checked + 618 2 libganesha_nfsd.4.dylib 0x00000001069c37dd mdc_clean_entry + 1085 3 libganesha_nfsd.4.dylib 0x00000001069cfb67 mdcache_lru_clean + 919 4 libganesha_nfsd.4.dylib 0x00000001069cd8f9 _mdcache_lru_unref + 1081 5 libganesha_nfsd.4.dylib 0x00000001069bbbae mdcache_put_ref + 30 6 libganesha_nfsd.4.dylib 0x0000000106979867 compound_data_Free + 87 7 libganesha_nfsd.4.dylib 0x00000001069795bb nfs4_Compound + 1307 8 libganesha_nfsd.4.dylib 0x000000010690ff48 nfs_rpc_process_request + 4344 9 libganesha_nfsd.4.dylib 0x000000010690ed2c nfs_rpc_valid_NFS + 268 10 libntirpc.3.2.dylib 0x0000000106ae9b55 svc_vc_decode + 133 11 libntirpc.3.2.dylib 0x0000000106ae68e3 svc_request + 51 12 libntirpc.3.2.dylib 0x0000000106ae8d6f svc_vc_recv + 943 13 libntirpc.3.2.dylib 0x0000000106ae6805 svc_rqst_xprt_task_recv + 85 14 libntirpc.3.2.dylib 0x0000000106ae4ea1 svc_rqst_epoll_loop + 769 15 libntirpc.3.2.dylib 0x0000000106af0112 work_pool_thread + 402 16 libsystem_pthread.dylib 0x00007fff70cfc109 _pthread_start + 148 17 libsystem_pthread.dylib 0x00007fff70cf7b8b thread_start + 15
Of course, there is no guarantee that this is the "wrong" or extra ref put, but I can't see the ref get to correspond with this put. Any thoughts?
- Matt _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
I believe Inode_Size = 1114112; should be sufficient for pyNFS to pass. For iozone, I need Inode_Size = 33554432; But that's a *lot* of memory per inode. Daniel On 11/4/20 5:12 PM, Frank Filz wrote:
Good to know these failures are mostly already known.
On Fri, Oct 30, 2020 at 07:15:33AM -0700, Frank Filz wrote:
So the concerning failures for your test are WRT5a and SATT18.
SATT18 fails with this message in the log: Access check returned Forbidden action (new OWNER was not user)
That comes from fsal_helper.c. I put an extra log to confirm that attr->owner (what the request indicates the new owner should be) is 65534.
I guess it is expected that the tests are usually ran as sudo.
Ah, yes, that test won't do well if not root...
As for WRT5a, I set the inode size for the FSAL_MEM export to ~1MB (cargo- culted from a sample config file), and the file size for this FSAL appears to be capped at that. So any attempt to read bytes past the first inode worth of bytes returns 'a' bytes. See the line "isize += MEM.inode_size;" and the mem_read2 function in mem_handle.c.
Ok, that becomes an expected failure...
At the risk of overloading this thread, I noticed a more alarming bug. I added an assert in _mdcache_lru_unref to verify that the post-decremented refcount was non-negative. The assert failure can be triggered trivially (with FSAM_MEM, just mount the export and run "export foo > bar" in the root of the export). When the assert failed, the last two ref puts were at:
I'll defer to Daniel for looking at this one.
0 libganesha_nfsd.4.dylib 0x00000001069cd67b _mdcache_lru_unref + 443 1 libganesha_nfsd.4.dylib 0x00000001069bbbae mdcache_put_ref + 30 2 libganesha_nfsd.4.dylib 0x0000000106979867 compound_data_Free + 87 3 libganesha_nfsd.4.dylib 0x00000001069795bb nfs4_Compound + 1307 4 libganesha_nfsd.4.dylib 0x000000010690ff48 nfs_rpc_process_request + 4344 5 libganesha_nfsd.4.dylib 0x000000010690ed2c nfs_rpc_valid_NFS + 268 6 libntirpc.3.2.dylib 0x0000000106ae9b55 svc_vc_decode + 133 7 libntirpc.3.2.dylib 0x0000000106ae68e3 svc_request + 51 8 libntirpc.3.2.dylib 0x0000000106ae8d6f svc_vc_recv + 943 9 libntirpc.3.2.dylib 0x0000000106ae6805 svc_rqst_xprt_task_recv + 85 10 libntirpc.3.2.dylib 0x0000000106ae4ea1 svc_rqst_epoll_loop + 769 11 libntirpc.3.2.dylib 0x0000000106af0112 work_pool_thread + 402 12 libsystem_pthread.dylib 0x00007fff70cfc109 _pthread_start + 148 13 libsystem_pthread.dylib 0x00007fff70cf7b8b thread_start + 15
Which seems reasonable. The next one, which brought the refcount to -1, was:
0 libganesha_nfsd.4.dylib 0x00000001069cd67b _mdcache_lru_unref + 443 1 libganesha_nfsd.4.dylib 0x00000001069c3bba cih_remove_checked + 618 2 libganesha_nfsd.4.dylib 0x00000001069c37dd mdc_clean_entry + 1085 3 libganesha_nfsd.4.dylib 0x00000001069cfb67 mdcache_lru_clean + 919 4 libganesha_nfsd.4.dylib 0x00000001069cd8f9 _mdcache_lru_unref + 1081 5 libganesha_nfsd.4.dylib 0x00000001069bbbae mdcache_put_ref + 30 6 libganesha_nfsd.4.dylib 0x0000000106979867 compound_data_Free + 87 7 libganesha_nfsd.4.dylib 0x00000001069795bb nfs4_Compound + 1307 8 libganesha_nfsd.4.dylib 0x000000010690ff48 nfs_rpc_process_request + 4344 9 libganesha_nfsd.4.dylib 0x000000010690ed2c nfs_rpc_valid_NFS + 268 10 libntirpc.3.2.dylib 0x0000000106ae9b55 svc_vc_decode + 133 11 libntirpc.3.2.dylib 0x0000000106ae68e3 svc_request + 51 12 libntirpc.3.2.dylib 0x0000000106ae8d6f svc_vc_recv + 943 13 libntirpc.3.2.dylib 0x0000000106ae6805 svc_rqst_xprt_task_recv + 85 14 libntirpc.3.2.dylib 0x0000000106ae4ea1 svc_rqst_epoll_loop + 769 15 libntirpc.3.2.dylib 0x0000000106af0112 work_pool_thread + 402 16 libsystem_pthread.dylib 0x00007fff70cfc109 _pthread_start + 148 17 libsystem_pthread.dylib 0x00007fff70cf7b8b thread_start + 15
Of course, there is no guarantee that this is the "wrong" or extra ref put, but I can't see the ref get to correspond with this put. Any thoughts?
- Matt _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
On Thu, Nov 05, 2020 at 08:49:33AM -0500, Daniel Gryniewicz wrote:
I believe
Inode_Size = 1114112;
should be sufficient for pyNFS to pass. For iozone, I need
Inode_Size = 33554432;
But that's a *lot* of memory per inode.
I don't think this is try for FSAL_MEM, which only allows one inode per file, and any attempt to read past the first inode results in 'a' bytes. See the results of `grep -rw datasize src/FSAL/FSAL_MEM`. I am only able to run FSAL_MEM (not even FSAL_VFS) in my hacked-together macOS setup. Note however that this issue isn't blocking me and not particularly troublesome (I will be writing my own FSAL in the coming weeks). Did you have a chance to look at the reference counting problem explained below?
At the risk of overloading this thread, I noticed a more alarming bug. I added an assert in _mdcache_lru_unref to verify that the post-decremented refcount was non-negative. The assert failure can be triggered trivially (with FSAM_MEM, just mount the export and run "export foo > bar" in the root of the export). When
Sorry, I meant to say `echo foo > bar` And by non-negative, I mean >= 0. Attached patch for clarity.
the assert failed, the last two ref puts were at:
I'll defer to Daniel for looking at this one.
0 libganesha_nfsd.4.dylib 0x00000001069cd67b _mdcache_lru_unref + 443 1 libganesha_nfsd.4.dylib 0x00000001069bbbae mdcache_put_ref + 30 2 libganesha_nfsd.4.dylib 0x0000000106979867 compound_data_Free + 87 3 libganesha_nfsd.4.dylib 0x00000001069795bb nfs4_Compound + 1307 4 libganesha_nfsd.4.dylib 0x000000010690ff48 nfs_rpc_process_request + 4344 5 libganesha_nfsd.4.dylib 0x000000010690ed2c nfs_rpc_valid_NFS + 268 6 libntirpc.3.2.dylib 0x0000000106ae9b55 svc_vc_decode + 133 7 libntirpc.3.2.dylib 0x0000000106ae68e3 svc_request + 51 8 libntirpc.3.2.dylib 0x0000000106ae8d6f svc_vc_recv + 943 9 libntirpc.3.2.dylib 0x0000000106ae6805 svc_rqst_xprt_task_recv + 85 10 libntirpc.3.2.dylib 0x0000000106ae4ea1 svc_rqst_epoll_loop + 769 11 libntirpc.3.2.dylib 0x0000000106af0112 work_pool_thread + 402 12 libsystem_pthread.dylib 0x00007fff70cfc109 _pthread_start + 148 13 libsystem_pthread.dylib 0x00007fff70cf7b8b thread_start + 15
Which seems reasonable. The next one, which brought the refcount to -1, was:
0 libganesha_nfsd.4.dylib 0x00000001069cd67b _mdcache_lru_unref + 443 1 libganesha_nfsd.4.dylib 0x00000001069c3bba cih_remove_checked + 618 2 libganesha_nfsd.4.dylib 0x00000001069c37dd mdc_clean_entry + 1085 3 libganesha_nfsd.4.dylib 0x00000001069cfb67 mdcache_lru_clean + 919 4 libganesha_nfsd.4.dylib 0x00000001069cd8f9 _mdcache_lru_unref + 1081 5 libganesha_nfsd.4.dylib 0x00000001069bbbae mdcache_put_ref + 30 6 libganesha_nfsd.4.dylib 0x0000000106979867 compound_data_Free + 87 7 libganesha_nfsd.4.dylib 0x00000001069795bb nfs4_Compound + 1307 8 libganesha_nfsd.4.dylib 0x000000010690ff48 nfs_rpc_process_request + 4344 9 libganesha_nfsd.4.dylib 0x000000010690ed2c nfs_rpc_valid_NFS + 268 10 libntirpc.3.2.dylib 0x0000000106ae9b55 svc_vc_decode + 133 11 libntirpc.3.2.dylib 0x0000000106ae68e3 svc_request + 51 12 libntirpc.3.2.dylib 0x0000000106ae8d6f svc_vc_recv + 943 13 libntirpc.3.2.dylib 0x0000000106ae6805 svc_rqst_xprt_task_recv + 85 14 libntirpc.3.2.dylib 0x0000000106ae4ea1 svc_rqst_epoll_loop + 769 15 libntirpc.3.2.dylib 0x0000000106af0112 work_pool_thread + 402 16 libsystem_pthread.dylib 0x00007fff70cfc109 _pthread_start + 148 17 libsystem_pthread.dylib 0x00007fff70cf7b8b thread_start + 15
Of course, there is no guarantee that this is the "wrong" or extra ref put, but I can't see the ref get to correspond with this put. Any thoughts?
- Matt _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
On Thu, Nov 05, 2020 at 02:10:11PM -0800, Matthew DeVore wrote:
Did you have a chance to look at the reference counting problem explained below?
I'm attaching a patch which I suspect is the right thing to do, and solves the failed assertion for me. I'm not totally sure about it, though.
At the risk of overloading this thread, I noticed a more alarming bug. I added an assert in _mdcache_lru_unref to verify that the post-decremented refcount was non-negative. The assert failure can be triggered trivially (with FSAM_MEM, just mount the export and run "export foo > bar" in the root of the export). When
Sorry, I meant to say `echo foo > bar`
-----Original Message----- From: Matthew DeVore [mailto:matvore@comcast.net] Sent: Friday, November 6, 2020 4:41 PM To: Daniel Gryniewicz <dang@redhat.com> Cc: Frank Filz <ffilzlnx@mindspring.com>; devel@lists.nfs-ganesha.org; bga@google.com; ankurag@google.com Subject: [NFS-Ganesha-Devel] Re: Running pynfs on macOS
On Thu, Nov 05, 2020 at 02:10:11PM -0800, Matthew DeVore wrote:
Did you have a chance to look at the reference counting problem explained below?
I'm attaching a patch which I suspect is the right thing to do, and solves
Could you post that patch to Gerrithub? Frank the
failed assertion for me. I'm not totally sure about it, though.
At the risk of overloading this thread, I noticed a more alarming bug. I added an assert in _mdcache_lru_unref to verify that the post-decremented refcount was non-negative. The assert failure can be triggered trivially (with FSAM_MEM, just mount the export and run "export foo > bar" in the root of the export). When
Sorry, I meant to say `echo foo > bar`
On Fri, Nov 06, 2020 at 04:47:03PM -0800, Frank Filz wrote:
Could you post that patch to Gerrithub?
https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/505607 Thanks for taking a look.
participants (3)
-
Daniel Gryniewicz -
Frank Filz -
Matthew DeVore