lseek gets bad offset from nfs client with ganesha/gluster which supports SEEK
by Kinglong Mee
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 years, 3 months
Access check issue for RO client.
by gaurav gangalwar
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
6 years
making liburcu and lttng coexist in a LGPL'ed program
by Jeff Layton
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>
6 years
Ganesha crashe in dec_nlm_state_ref.
by Suhrud Patankar
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
6 years
Ganesha coredump in mdcache_get_chunk()
by Malahal Naineni
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!
6 years
Back port suggestions to v2.6
by Sriram Patil
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
6 years
Change in ffilz/nfs-ganesha[next]: Handle NLM share FREE_ALL for windows clients
by Suhrud Patankar (GerritHub)
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>
6 years
Change in ffilz/nfs-ganesha[next]: cmake: work around lttng/urcu/_LGPL_SOURCE incompatibility
by Jeff Layton (GerritHub)
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>
6 years
Git clone on Ganesha export from windows client fails
by Suhrud Patankar
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
6 years
