November 2018 - Devel - NFS Ganesha List Archives

lseek gets bad offset from nfs client with ganesha/gluster which supports SEEK
by Kinglong Mee 14 Sep '20

14 Sep '20

The latest ganesha/gluster supports seek according to, https://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-41#section-15.11 From the given sa_offset, find the next data_content4 of type sa_what in the file. If the server can not find a corresponding sa_what, then the status will still be NFS4_OK, but sr_eof would be TRUE. If the server can find the sa_what, then the sr_offset is the start of that content. If the sa_offset is beyond the end of the file, then SEEK MUST return NFS4ERR_NXIO. For a file's filemap as, Part 1: HOLE 0x0000000000000000 ---> 0x0000000000600000 Part 2: DATA 0x0000000000600000 ---> 0x0000000000700000 Part 3: HOLE 0x0000000000700000 ---> 0x0000000001000000 SEEK(0x700000, SEEK_DATA) gets result (sr_eof:1, sr_offset:0x70000) from ganesha/gluster; SEEK(0x700000, SEEK_HOLE) gets result (sr_eof:0, sr_offset:0x70000) from ganesha/gluster. If an application depends the lseek result for data searching, it may enter infinite loop. while (1) { next_pos = lseek(fd, cur_pos, seek_type); if (seek_type == SEEK_DATA) { seek_type = SEEK_HOLE; } else { seek_type = SEEK_DATA; } if (next_pos == -1) { return ; cur_pos = next_pos; } The lseek syscall always gets 0x70000 from nfs client for those two cases, but, if underlying filesystem is ext4/f2fs, or the nfs server is knfsd, the lseek(0x700000, SEEK_DATA) gets ENXIO. I wanna to know, should I fix the ganesha/gluster as knfsd return ENXIO for the first case? or should I fix the nfs client to return ENXIO for the first case? thanks, Kinglong Mee

4 8

Access check issue for RO client.
by gaurav gangalwar 07 Dec '18

07 Dec '18

Hi, For client with ReadOnly access and user with ReadWrite access, Ganesha returns READ/MODIFY/APPEND allowed on ACCESS call. Linux kernel NFS returns just READ allowed for same. I think we need to fix Ganesha’s behaviour, we should return access rights based on client access check also. Please check the patch attached to fix the behaviour. Regards, Gaurav

2 3

making liburcu and lttng coexist in a LGPL'ed program
by Jeff Layton 03 Dec '18

03 Dec '18

The nfs-ganesha project has used lttng for quite some time to handle tracing. Recently though, we decided to start building liburcu in as a mandatory component, with an eye toward using it in certain areas. Before this change, the code linked in liburcu-bp directly, but now we just use liburcu. Unfortunately, when we enable tracepoints in the build now, we get errors like this at link time: --------------------8<---------------- [ 96%] Linking C executable ganesha.nfsd /usr/bin/ld: libMainServices.a(nfs_worker_thread.c.o): undefined reference to symbol 'rcu_gp_bp' /usr/bin/ld: //usr/lib64/liburcu-bp.so.6: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[2]: *** [MainNFSD/CMakeFiles/ganesha.nfsd.dir/build.make:308: MainNFSD/ganesha.nfsd] Error 1 make[1]: *** [CMakeFiles/Makefile2:2740: MainNFSD/CMakeFiles/ganesha.nfsd.dir/all] Error 2 make: *** [Makefile:152: all] Error 2 --------------------8<---------------- nfs-ganesha defines _LGPL_SOURCE, and that makes lttng use the redefinitions in tracepoint-rcu.h. If I disable _LGPL_SOURCE, it all builds as expected. I found a similar bug here: https://bugs.lttng.org/issues/1156 Any thoughts on the right fix for this? We'd like to eat our cake and have it too, so that we can have _LGPL_SOURCE defined, lttng enabled, and the urcu flavor be determined at runtime. Many thanks, -- Jeff Layton <jlayton(a)redhat.com>

2 6

Windows client and NLM_FREE_ALL
by Suhrud Patankar 02 Dec '18

02 Dec '18

Hello All, Windows client can take multiple NLM shares with the same owner. In case of FREE_ALL from the client (which is same as client reboot sm-notify in the linux world), we must release ALL shares for that owner. Please see the patch for the same. https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/435605 Any Comments/suggestions? Thanks & Regards, Suhrud

1 1

Ganesha crashe in dec_nlm_state_ref.
by Suhrud Patankar 02 Dec '18

02 Dec '18

Hello All, Ganesha: V2.5.0.4 Windows client: Windows 10 Pro Testing NFSv3 access from windows client. Sometimes Ganesha crashes in dec_nlm_state_ref. My understanding of the issue is - state is maintained in multiple lists but a single ref is taken for all entries. state mutex is not held while adding/removing it from different lists. this can cause incorrect ref on the state object. Attached patch appears to fix this. However I still need to test more. Any comments on the issue and patch will be highly appreciated. Thanks & Regards, Suhrud

3 3

Ganesha coredump in mdcache_get_chunk()
by Malahal Naineni 30 Nov '18

30 Nov '18

The prev_chunk's dirent list is empty although it has num_entries as 112. Crashes at the following line as the dirents list is empty. chunk->reload_ck = glist_last_entry(&prev_chunk->dirents, mdcache_dir_entry_t, chunk_list)->ck; #0 0x00007fae938dc4ab in raise () from /lib64/libpthread.so.0 #1 0x000000000045549e in crash_handler (signo=11, info=0x7fae25f48eb0, ctx=0x7fae25f48d80) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/MainNFSD/nfs_init.c:225 #2 <signal handler called> #3 mdcache_get_chunk (parent=0x7faa1001a290, prev_chunk=0x7fade0206350, whence=2147483647) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c:909 #4 0x000000000054fbe9 in mdcache_populate_dir_chunk (directory=0x7faa1001a290, whence=2147483647, dirent=0x7fae25f49680, prev_chunk=0x7fade0206350, eod_met=0x7fae25f4967f) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:2659 #5 0x0000000000551767 in mdcache_readdir_chunked (directory=0x7faa1001a290, whence=2147483647, dir_state=0x7fae25f49990, cb=0x43310f <populate_dirent>, attrmask=0, eod_met=0x7fae25f49e8b) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:3053 #6 0x000000000053f39f in mdcache_readdir (dir_hdl=0x7faa1001a2c8, whence=0x7fae25f49970, dir_state=0x7fae25f49990, cb=0x43310f <populate_dirent>, attrmask=0, eod_met=0x7fae25f49e8b) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:639 #7 0x00000000004339f3 in fsal_readdir (directory=0x7faa1001a2c8, cookie=2147483647, nbfound=0x7fae25f49e8c, eod_met=0x7fae25f49e8b, attrmask=0, cb=0x495d70 <nfs3_readdir_callback>, opaque=0x7fae25f49e40) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/FSAL/fsal_helper.c:1502 #8 0x0000000000495b57 in nfs3_readdir (arg=0x7fa8b4f75e80, req=0x7fa8b4f75678, res=0x7faad82c8c70) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/Protocols/NFS/nfs3_readdir.c:289 #9 0x000000000044ccde in nfs_rpc_execute (reqdata=0x7fa8b4f75650) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/MainNFSD/nfs_worker_thread.c:1290 #10 0x000000000044d4e8 in worker_run (ctx=0x4926600) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/MainNFSD/nfs_worker_thread.c:1562 #11 0x000000000050c57f in fridgethr_start_routine (arg=0x4926600) at /usr/src/debug/nfs-ganesha-2.5.3-ibm031.00-0.1.1-Source/support/fridgethr.c:550 (gdb) frame 3 (gdb) p *prev_chunk $9 = {chunks = {next = 0x7faad808a570, prev = 0x7fade00000d8}, dirents = {next = 0x7fade0206360, prev = 0x7fade0206360}, parent = 0x0, chunk_lru = {q = {next = 0x0, prev = 0x0}, qid = LRU_ENTRY_L1, refcnt = 0, flags = 0, lane = 534, cf = 0}, reload_ck = 1453366958, next_ck = 0, num_entries = 112} Regards, Malahal. PS: code frome here: https://github.com/malahal/nfs-ganesha/commits/ibm2.5 for matching crash line numbers!

2 1

Back port suggestions to v2.6
by Sriram Patil 30 Nov '18

30 Nov '18

Hi, As discussed with Daniel on one of the issues on github, here are some candidates for back porting to v2.6 for the final 2.6 release. Explicitly revert the following changes on V2.6-stable: 57908cc GLUSTER: Use telldir result from previous dirent as cookie e52b213 VFS: Use d_off from previous dirent as cookie Back port following changes to V2.6-stable: 660f330 FSAL_MDCACHE: avoid assertion due to wrong check fb5f604 Fix leaks related to CIDR clients 10e4b26 AUTH - Return correct result 1b65dbb Free group name string properly in proc_export() faa9745 Allow exports to be referral points in FSAL_VFS fab810d Remove unexported export on DBUS unexport. I have tried to pick independent changes so that we do not have to back port a chain of commits. Please let me know if the list of commits is good. Thanks, Sriram

2 2

Change in ffilz/nfs-ganesha[next]: Handle NLM share FREE_ALL for windows clients
by Suhrud Patankar (GerritHub) 30 Nov '18

30 Nov '18

Suhrud Patankar has uploaded this change for review. ( https://review.gerrithub.io/435605 Change subject: Handle NLM share FREE_ALL for windows clients ...................................................................... Handle NLM share FREE_ALL for windows clients Windows client can take multiple share reservations with the same owner. When handling FREE_ALL, we need to release all shares from that client. Change-Id: I6c763462cbf63498e8bf1579b1d1ef152e427e0d Signed-off-by: Suhrud Patankar <suhrudpatankar(a)gmail.com> --- M src/SAL/state_lock.c M src/SAL/state_share.c M src/include/nfsv41.h 3 files changed, 18 insertions(+), 8 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/05/435605/1 -- To view, visit https://review.gerrithub.io/435605 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I6c763462cbf63498e8bf1579b1d1ef152e427e0d Gerrit-Change-Number: 435605 Gerrit-PatchSet: 1 Gerrit-Owner: Suhrud Patankar <suhrudpatankar(a)gmail.com>

1 0

Change in ffilz/nfs-ganesha[next]: cmake: work around lttng/urcu/_LGPL_SOURCE incompatibility
by Jeff Layton (GerritHub) 28 Nov '18

28 Nov '18

Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/435301 Change subject: cmake: work around lttng/urcu/_LGPL_SOURCE incompatibility ...................................................................... cmake: work around lttng/urcu/_LGPL_SOURCE incompatibility When _LGPL_SOURCE is defined, the lttng and urcu code will turn some library functions into macros or static inlines. Unfortunately, when lttng does this, it always selects the "bulletproof" (bp) flavor of urcu. With the new usage of urcu in ganesha this is problematic as we may not have liburcu-bp linked in. Undefine _LGPL_SOURCE for now until we have a proper fix. Change-Id: I59c900a7af39920261b12f04e0ec3c2fafd3a8da Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- M src/include/config-h.in.cmake 1 file changed, 5 insertions(+), 2 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/01/435301/1 -- To view, visit https://review.gerrithub.io/435301 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I59c900a7af39920261b12f04e0ec3c2fafd3a8da Gerrit-Change-Number: 435301 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>

1 0

Git clone on Ganesha export from windows client fails
by Suhrud Patankar 28 Nov '18

28 Nov '18

Hello All, Ganesha: V2.5.0.4 Windows client: Windows 10 Pro I am testing NFSv3 access from windows client. The git clone operation from windows client fails with permission denied error. The windows client creates a file with mode as 555 and then tries to take read+write share reservation on it. This fails to reopen the file for write. The happens as the 'owner_skip' flag for test_access does not get set for this code path. The attached patch fixes this. Please suggest if this is correct way to handle this issue. Thanks & Regards, Suhrud

2 2