4: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