Was up-call with MDC tested?
It looks like it is trying to use op_ctx which is NULL.
Marc.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fe867fff700 (LWP 18907)]
0x0000000000532b76 in mdc_cur_export () at
/nas/ganesha/new-ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_int.h:376
376 return mdc_export(op_ctx->fsal_export);
(gdb) where
#0 0x0000000000532b76 in mdc_cur_export () at
/nas/ganesha/new-ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_int.h:376
#1 0x00000000005342a1 in mdc_check_mapping (entry=0x7fe870001530) at
/nas/ganesha/new-ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:210
#2 0x000000000053584c in mdcache_find_keyed (key=0x7fe867ffe470,
entry=0x7fe867ffe468) at
/nas/ganesha/new-ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:636
#3 0x00000000005358c1 in mdcache_locate_keyed (key=0x7fe867ffe470,
export=0x12d8f40, entry=0x7fe867ffe468, attrs_out=0x0)
at
/nas/ganesha/new-ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:670
#4 0x000000000052feac in mdcache_create_handle (exp_hdl=0x12d8f40,
hdl_desc=0x7fe880001088, handle=0x7fe867ffe4e8, attrs_out=0x0)
at
/nas/ganesha/new-ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:1629
#5 0x0000000000433f36 in lock_avail (export=0x12d8f40,
file=0x7fe880001088, owner=0x7fe87c302dc0, lock_param=0x7fe8800010a0) at
/nas/ganesha/new-ganesha/src/FSAL_UP/fsal_up_top.c:172
#6 0x0000000000438142 in queue_lock_avail (ctx=0x7fe880001100) at
/nas/ganesha/new-ganesha/src/FSAL_UP/fsal_up_async.c:243
#7 0x000000000050156f in fridgethr_start_routine (arg=0x7fe880001100) at
/nas/ganesha/new-ganesha/src/support/fridgethr.c:550
#8 0x00007fea288a0df3 in start_thread (arg=0x7fe867fff700) at
pthread_create.c:308
#9 0x00007fea27f603dd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:113
(gdb) up
#1 0x00000000005342a1 in mdc_check_mapping (entry=0x7fe870001530) at
/nas/ganesha/new-ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:210
210 struct mdcache_fsal_export *export = mdc_cur_export();
(gdb) p op_ctx
$1 = (struct req_op_context *) 0x0
From: Marc Eshel/Almaden/IBM@IBMUS
To: "Frank Filz" <ffilz...@mindspring.com>
Cc: nfs-ganesha-devel@lists.sourceforge.net
Date: 08/18/2016 09:21 AM
Subject: Re: [Nfs-ganesha-devel] multi fd support
Using NFSv4 I get read lock on the same file from two different NFS
clients. The server get the two locks using the two different owners
(state), when I unlock the lock on one client that results in closing the
file I get fsal_close() with no owner id so I am forced to release all
locks which is wrong.
Marc.
From: "Frank Filz" <ffilz...@mindspring.com>
To: Marc Eshel/Almaden/IBM@IBMUS
Cc: <nfs-ganesha-devel@lists.sourceforge.net>
Date: 08/17/2016 10:04 PM
Subject: RE: multi fd support
> Hi Frank,
> Don't we need fsal_close() to call close2() ?
> We need the owner so we can release only the locks for this fd before
> closing it.
> Marc.
With support_ex enabled, fsal_close is only called when the
fsal_obj_handle
is being disposed of or when the LRU thread is closing open file
descriptors
(which will now only be those open file descriptors not associated with
state), and it's purpose is only to close the global/anonymous file
descriptor. There should be no locks associated with the global file
descriptor.
A few notes for you:
1. Not having a delegation aware FSAL to work on, I did not explore all
the
implications of delegations with support_ex. A delegation probably should
inherit the file descriptor from the initial open state, but maybe it
needs
it's own.
2. For NFS v4 locks, the support_ex API SHOULD allow you to just have an
open file descriptor associated with the open state and not have to have
one
per lock state (per lock owner) since your locks already have owners
associated without having to have separate file descriptors. For NFS v3
locks of course there is no way (currently) to tie to an open state (even
if
there is an NLM_SHARE from the same process). I would like to eventually
look for ties and create them if possible. Of course if it benefits you to
have an open fd per lock owner, that's fine too. And actually, you can
even
fall back to using the global file descriptor (and note that now the FSAL
actually gets to control when that's opened or closed).
3. I'm not sure you caught that you need to protect the global file
descriptor with the fsal_obj_handle->lock since the content_lock is no
more...
I'm on vacation the rest of the week so I may not be able to respond until
next week.
Frank
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
------------------------------------------------------------------------------
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
------------------------------------------------------------------------------
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
