Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NFS Ganesha global stats are now written into shm to be displayed at runtime #11

Open
wants to merge 1 commit into
base: V2.3-mapr
Choose a base branch
from

Conversation

srirampatil
Copy link

Allocating a shared memory in nfs_main to store the global stats. These
global stats are written by Ganesha and can be read by a client program
display_stats.
display_stats binary is created at path support/display_stats. It does not
take any arguments as of now. It displays the Ganesha global stats as they
happen every second.

Change-Id: Idf318d7d6a5c1e660e0a97f8106a69c0b83a3197
Signed-off-by: Sriram Patil [email protected]

…runtime

Allocating a shared memory in nfs_main to store the global stats. These
global stats are written by Ganesha and can be read by a client program
display_stats.
display_stats binary is created at path support/display_stats. It does not
take any arguments as of now. It displays the Ganesha global stats as they
happen every second.

Change-Id: Idf318d7d6a5c1e660e0a97f8106a69c0b83a3197
Signed-off-by: Sriram Patil <[email protected]>
@srirampatil
Copy link
Author

Example output (The formatting will be messed up in the comment)

ACCESS CLOSE COMMIT CREATE GETATTR LINK LOCK LOOKUP LOOKUPP OPEN READDIR READLINK REMOVE RENAME SETATTR READ WRITE
0 0 1 0 546 0 0 0 0 0 0 0 0 0 0 338 42 549 68
0 0 0 0 660 0 0 0 0 0 0 0 0 0 0 216 27 663 82
0 0 3 0 518 0 0 0 0 0 0 0 0 0 0 314 39 522 65
0 0 0 0 256 0 0 0 0 0 0 0 0 0 0 175 21 262 32
0 0 0 0 596 0 0 0 0 0 0 0 0 0 0 209 26 595 74
0 0 0 0 435 0 0 0 0 0 0 0 0 0 0 205 25 436 54
0 0 0 0 624 0 0 0 0 0 0 0 0 0 0 320 40 630 78
0 0 0 0 532 0 0 0 0 0 0 0 0 0 0 221 27 533 66
0 0 0 0 629 0 0 0 0 0 0 0 0 0 0 348 43 636 79
0 0 0 0 382 0 0 0 0 0 0 0 0 0 0 178 22 380 47

svorobiev pushed a commit that referenced this pull request Jul 29, 2020
The caller of state_lock() is expected to take the lock on its own.
This should fix the sporadical failure seen in this patchset:
https://review.gerrithub.io/#/c/385433/

==3884==ERROR: AddressSanitizer: heap-use-after-free on address 0x6110003fbf68 at pc 0x00000077cd18 bp 0x7fffc9cbf150 sp 0x7fffc9cbf148
READ of size 8 at 0x6110003fbf68 thread T34
Detaching after fork from child process 3944.
    #0 0x77cd17 in copy_conflict /export/nfs-ganesha/src/SAL/state_lock.c:2239:26
    #1 0x77fa9c in state_lock /export/nfs-ganesha/src/SAL/state_lock.c:2444:5
    #2 0x733404 in _9p_lock /export/nfs-ganesha/src/Protocols/9P/9p_lock.c:168:18
    #3 0x71c904 in _9p_process_buffer /export/nfs-ganesha/src/Protocols/9P/9p_interpreter.c:180:7
    #4 0x5fb386 in _9p_rdma_process_request /export/nfs-ganesha/src/MainNFSD/9p_rdma_callbacks.c:158:8
    #5 0x5c928f in _9p_execute /export/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1509:3
    #6 0x5aa899 in worker_run /export/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1604:4
    #7 0x88c1c4 in fridgethr_start_routine /export/nfs-ganesha/src/support/fridgethr.c:550:3
    #8 0x7ffff79b16c9 in start_thread (/lib64/libpthread.so.0+0x76c9)
    #9 0x7ffff4ed7f7e in __GI___clone (/lib64/libc.so.6+0x107f7e)

0x6110003fbf68 is located 104 bytes inside of 200-byte region [0x6110003fbf00,0x6110003fbfc8)
freed by thread T26 here:
    #0 0x4e2ae0 in __interceptor_cfree.localalias.1 (/export/nfs-ganesha/build/MainNFSD/ganesha.nfsd+0x4e2ae0)
    #1 0x7731e4 in gsh_free /export/nfs-ganesha/src/include/abstract_mem.h:271:2
    #2 0x7731b6 in lock_entry_dec_ref /export/nfs-ganesha/src/SAL/state_lock.c:714:3
    #3 0x77b06a in remove_from_locklist /export/nfs-ganesha/src/SAL/state_lock.c:774:2
    #4 0x78d39a in free_list /export/nfs-ganesha/src/SAL/state_lock.c:967:3
    #5 0x7848c4 in subtract_lock_from_list /export/nfs-ganesha/src/SAL/state_lock.c:1140:3
    #6 0x7833ac in state_unlock /export/nfs-ganesha/src/SAL/state_lock.c:2716:11
    #7 0x7334fe in _9p_lock /export/nfs-ganesha/src/Protocols/9P/9p_lock.c:187:7
    #8 0x71c904 in _9p_process_buffer /export/nfs-ganesha/src/Protocols/9P/9p_interpreter.c:180:7
    #9 0x5fb386 in _9p_rdma_process_request /export/nfs-ganesha/src/MainNFSD/9p_rdma_callbacks.c:158:8
    #10 0x5c928f in _9p_execute /export/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1509:3
    #11 0x5aa899 in worker_run /export/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1604:4
    #12 0x88c1c4 in fridgethr_start_routine /export/nfs-ganesha/src/support/fridgethr.c:550:3
    #13 0x7ffff79b16c9 in start_thread (/lib64/libpthread.so.0+0x76c9)

previously allocated by thread T16 here:
    #0 0x4e2c98 in __interceptor_malloc (/export/nfs-ganesha/build/MainNFSD/ganesha.nfsd+0x4e2c98)
    #1 0x77443f in gsh_malloc__ /export/nfs-ganesha/src/include/abstract_mem.h:78:12
    #2 0x780f13 in create_state_lock_entry /export/nfs-ganesha/src/SAL/state_lock.c:579:14
    #3 0x77ffcf in state_lock /export/nfs-ganesha/src/SAL/state_lock.c:2562:16
    #4 0x733404 in _9p_lock /export/nfs-ganesha/src/Protocols/9P/9p_lock.c:168:18
    #5 0x71c904 in _9p_process_buffer /export/nfs-ganesha/src/Protocols/9P/9p_interpreter.c:180:7
    #6 0x5fb386 in _9p_rdma_process_request /export/nfs-ganesha/src/MainNFSD/9p_rdma_callbacks.c:158:8
    #7 0x5c928f in _9p_execute /export/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1509:3
    #8 0x5aa899 in worker_run /export/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1604:4
    #9 0x88c1c4 in fridgethr_start_routine /export/nfs-ganesha/src/support/fridgethr.c:550:3
    #10 0x7ffff79b16c9 in start_thread (/lib64/libpthread.so.0+0x76c9)

Thanks goes to Malahal for the analysis of the problem

Change-Id: Ie82eb4a5ecf5da3fd3a8d1cd9dbdb99b54842745
Signed-off-by: Dominique Martinet <[email protected]>
svorobiev pushed a commit that referenced this pull request Jul 29, 2020
csa_sec_parms_val was declared in its own scope but was used much
later, we need to declare it outside of the helper and pass the
address there.

==7480==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffea684340 at pc 0x7fffecec1e9c bp 0x7fffea683510 sp 0x7fffea683500
READ of size 4 at 0x7fffea684340 thread T5

    #0 0x7fffecec1e9b in xdr_uint32_t /src/nfs-ganesha/src/libntirpc/ntirpc/rpc/xdr_inline.h:221
    #1 0x7fffecec1ef7 in xdr_u_int32_t /src/nfs-ganesha/src/libntirpc/ntirpc/rpc/xdr_inline.h:236
    #2 0x7fffecec9d88 in xdr_callback_sec_parms4 /src/nfs-ganesha/src/include/nfsv41.h:6750
    #3 0x7fffecec3c3c in xdr_array_encode /src/nfs-ganesha/src/libntirpc/ntirpc/rpc/xdr_inline.h:848
    #4 0x7fffecec3ef3 in xdr_array /src/nfs-ganesha/src/libntirpc/ntirpc/rpc/xdr_inline.h:891
    #5 0x7fffececaa56 in xdr_CREATE_SESSION4args /src/nfs-ganesha/src/include/nfsv41.h:7049
    #6 0x7fffecece544 in xdr_nfs_argop4 /src/nfs-ganesha/src/include/nfsv41.h:8233
    #7 0x7fffecec3c3c in xdr_array_encode /src/nfs-ganesha/src/libntirpc/ntirpc/rpc/xdr_inline.h:848
    #8 0x7fffecec3ef3 in xdr_array /src/nfs-ganesha/src/libntirpc/ntirpc/rpc/xdr_inline.h:891
    #9 0x7fffececfef4 in xdr_COMPOUND4args /src/nfs-ganesha/src/include/nfsv41.h:8732
    #10 0x7fffeced6f8c in pxy_compoundv4_call /src/nfs-ganesha/src/FSAL/FSAL_PROXY/handle.c:764
    #11 0x7fffeced834a in pxy_compoundv4_execute /src/nfs-ganesha/src/FSAL/FSAL_PROXY/handle.c:857
    #12 0x7fffeceda878 in pxy_setsessionid /src/nfs-ganesha/src/FSAL/FSAL_PROXY/handle.c:966
    #13 0x7fffecedc7eb in pxy_clientid_renewer /src/nfs-ganesha/src/FSAL/FSAL_PROXY/handle.c:1147
    #14 0x7ffff5572593 in start_thread /usr/src/debug/glibc-2.27-78-g2b47bb9cba/nptl/pthread_create.c:463
    #15 0x7ffff4e84e6e in clone (/lib64/libc.so.6+0xf9e6e)

Address 0x7fffea684340 is located in stack of thread T5 at offset 288 in frame
    #0 0x7fffeced9cbc in pxy_setsessionid /src/nfs-ganesha/src/FSAL/FSAL_PROXY/handle.c:936

  This frame has 7 object(s):
    [32, 36) 'seqid'
    [96, 100) 'fore_ca_rdma_ird_val_sink'
    [160, 164) 'back_ca_rdma_ird_val_sink'
    [224, 232) 'cid'
    [288, 336) 'csa_sec_parms_val' <== Memory access at offset 288 is inside this variable
    [384, 960) 'arg'
    [992, 1632) 'res'

Change-Id: I597abb06747898418c907e33b57b1f0ac1f904f7
Signed-off-by: Dominique Martinet <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant