6:57 a.m.
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
7:15 a.m.
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(a)lists.nfs-ganesha.org
Cc: bga(a)google.com; ankurag(a)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(a)lists.nfs-ganesha.org To unsubscribe send an email to
devel-leave(a)lists.nfs-ganesha.org
1:30 p.m.
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
2:12 p.m.
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(a)lists.nfs-ganesha.org To unsubscribe send an email to
devel-leave(a)lists.nfs-ganesha.org
5:49 a.m.
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(a)lists.nfs-ganesha.org To unsubscribe send an email to
> devel-leave(a)lists.nfs-ganesha.org
2:10 p.m.
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(a)lists.nfs-ganesha.org To unsubscribe send an email
to
> > devel-leave(a)lists.nfs-ganesha.org
>
4:41 p.m.
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`
4:47 p.m.
Could you post that patch to Gerrithub?
Frank
-----Original Message-----
From: Matthew DeVore [mailto:matvore@comcast.net]
Sent: Friday, November 6, 2020 4:41 PM
To: Daniel Gryniewicz <dang(a)redhat.com>
Cc: Frank Filz <ffilzlnx(a)mindspring.com>; devel(a)lists.nfs-ganesha.org;
bga(a)google.com; ankurag(a)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
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`
5:16 p.m.
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.
1266
days inactive
1274
days old
8 comments
3 participants
participants (3)
-
Daniel Gryniewicz -
Frank Filz -
Matthew DeVore