Crash in mdcache_readdir_chunked
by Malahal Naineni
We are getting this crash from a couple of customers (using ganesha2.5
based code with some backports!). Looks like commit
3aa8575880190d7a20946a38ae3bc70b278d1099 (see the last paragraph of
the commit message) may fix this. Did anyone see this backtrace
before, if so what fixed it?
(gdb) bt
#0 0x00007fd511af64ab in raise () from /lib64/libpthread.so.0
#1 0x0000000000455447 in crash_handler (signo=11,
info=0x7fd47bef47f0, ctx=0x7fd47bef46c0)
at /usr/src/debug/nfs-ganesha-2.5.3-ibm028.00-0.1.1-Source/MainNFSD/nfs_init.c:225
#2 <signal handler called>
#3 0x000000000054fecf in mdcache_readdir_chunked
(directory=0x7fd1697a6c80, whence=0,
dir_state=0x7fd47bef57c0, cb=0x4330f3 <populate_dirent>,
attrmask=122830, eod_met=0x7fd47bef5e9b)
at /usr/src/debug/nfs-ganesha-2.5.3-ibm028.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:2971
#4 0x000000000053f44c in mdcache_readdir (dir_hdl=0x7fd1697a6cb8,
whence=0x7fd47bef57a0,
dir_state=0x7fd47bef57c0, cb=0x4330f3 <populate_dirent>,
attrmask=122830, eod_met=0x7fd47bef5e9b)
at /usr/src/debug/nfs-ganesha-2.5.3-ibm028.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:639
#5 0x00000000004339aa in fsal_readdir (directory=0x7fd1697a6cb8,
cookie=0, nbfound=0x7fd47bef5e9c,
eod_met=0x7fd47bef5e9b, attrmask=122830, cb=0x496a1a
<nfs3_readdirplus_callback>, opaque=0x7fd47bef5e50)
at /usr/src/debug/nfs-ganesha-2.5.3-ibm028.00-0.1.1-Source/FSAL/fsal_helper.c:1497
#6 0x000000000049680d in nfs3_readdirplus (arg=0x7fd1ed2071d0,
req=0x7fd1ed2069c8, res=0x7fd1589bd3d0)
at /usr/src/debug/nfs-ganesha-2.5.3-ibm028.00-0.1.1-Source/Protocols/NFS/nfs3_readdirplus.c:309
#7 0x000000000044cc86 in nfs_rpc_execute (reqdata=0x7fd1ed2069a0)
at /usr/src/debug/nfs-ganesha-2.5.3-ibm028.00-0.1.1-Source/MainNFSD/nfs_worker_thread.c:1290
#8 0x000000000044d490 in worker_run (ctx=0x4029b20)
at /usr/src/debug/nfs-ganesha-2.5.3-ibm028.00-0.1.1-Source/MainNFSD/nfs_worker_thread.c:1562
#9 0x000000000050c4b0 in fridgethr_start_routine (arg=0x4029b20)
at /usr/src/debug/nfs-ganesha-2.5.3-ibm028.00-0.1.1-Source/support/fridgethr.c:550
#10 0x00007fd511aeee25 in start_thread () from /lib64/libpthread.so.0
#11 0x00007fd5111af34d in clone () from /lib64/libc.so.6
(gdb) frame 3
#3 0x000000000054fecf in mdcache_readdir_chunked
(directory=0x7fd1697a6c80, whence=0,
dir_state=0x7fd47bef57c0, cb=0x4330f3 <populate_dirent>,
attrmask=122830, eod_met=0x7fd47bef5e9b)
at /usr/src/debug/nfs-ganesha-2.5.3-ibm028.00-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:2971
2971 if (dirent->ck == whence) {
(gdb) p dirent
$1 = (mdcache_dir_entry_t *) 0x1e58408900000000
(gdb) p dirent->ck
Cannot access memory at address 0x1e58408900000060
(gdb) l
2966 fsal_status_t status;
2967 enum fsal_dir_result cb_result;
2968 mdcache_entry_t *entry = NULL;
2969 struct attrlist attrs;
2970
2971 if (dirent->ck == whence) {
2972 /* When called with whence, the caller always wants the
2973 * next entry, skip this entry.
2974 */
2975 continue;
6 years, 1 month
Announce Push of V2.8-dev.5
by Frank Filz
Branch next
Tag:V2.8-dev.5
Release Highlights
* Fix incorrect parent file handle update on rename.
* Restore op_ctx->ctx_export and fsal_export in nfs4_op_readdir
* 2 delegations fixes
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
4939231 Frank S. Filz V2.8-dev.5
30a5d14 Jiffin Tony Thottan MDCACHE : check conflicts in delegations for
rename if destination exists
79a714e Jiffin Tony Thottan SAL : check conflicts for delegation
63fcaf8 Malahal Naineni Restore op_ctx->ctx_export and fsal_export in
nfs4_op_readdir
cf509a7 Malahal Naineni Fix incorrect parent file handle update on rename.
6 years, 1 month
Change in ffilz/nfs-ganesha[next]: MDCACHE: fix invalid assert in mdcache_avl_lookup_ck()
by Kinglong Mee (GerritHub)
Kinglong Mee has uploaded this change for review. ( https://review.gerrithub.io/432517
Change subject: MDCACHE: fix invalid assert in mdcache_avl_lookup_ck()
......................................................................
MDCACHE: fix invalid assert in mdcache_avl_lookup_ck()
Change-Id: If6e3cae6737e233c089e66315624e17bd229afa6
Signed-off-by: Kinglong Mee <kinglongmee(a)gmail.com>
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_avl.c
1 file changed, 6 insertions(+), 9 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/17/432517/1
--
To view, visit https://review.gerrithub.io/432517
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: If6e3cae6737e233c089e66315624e17bd229afa6
Gerrit-Change-Number: 432517
Gerrit-PatchSet: 1
Gerrit-Owner: Kinglong Mee <kinglongmee(a)gmail.com>
6 years, 1 month
Change in ffilz/nfs-ganesha[next]: Delegations : Handle OPEN4_SHARE_DENY_WRITE for read delegation
by Jiffin Tony Thottan (GerritHub)
Jiffin Tony Thottan has uploaded this change for review. ( https://review.gerrithub.io/432426
Change subject: Delegations : Handle OPEN4_SHARE_DENY_WRITE for read delegation
......................................................................
Delegations : Handle OPEN4_SHARE_DENY_WRITE for read delegation
If read delegation granted for open call with OPEN4_SHARE_DENY_WRITE,
then do not send recall incase of writes.
Change-Id: I78eafad574940549ff83b85d44e6af2a0e3a8ecd
Signed-off-by: Jiffin Tony Thottan <jthottan(a)redhat.com>
---
M src/Protocols/NFS/nfs4_op_open.c
M src/SAL/state_deleg.c
M src/include/sal_data.h
3 files changed, 7 insertions(+), 1 deletion(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/26/432426/1
--
To view, visit https://review.gerrithub.io/432426
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: I78eafad574940549ff83b85d44e6af2a0e3a8ecd
Gerrit-Change-Number: 432426
Gerrit-PatchSet: 1
Gerrit-Owner: Jiffin Tony Thottan <jthottan(a)redhat.com>
6 years, 1 month
Change in ffilz/nfs-ganesha[next]: rados_recov: convert rados_recov_old_oid to be rcu-managed refstr
by Jeff Layton (GerritHub)
Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/432327
Change subject: rados_recov: convert rados_recov_old_oid to be rcu-managed refstr
......................................................................
rados_recov: convert rados_recov_old_oid to be rcu-managed refstr
Change-Id: I5ede0b89175879fb24cb145946ce6f4cb5e9dc6b
Signed-off-by: Jeff Layton <jlayton(a)redhat.com>
---
M src/SAL/recovery/recovery_rados.h
M src/SAL/recovery/recovery_rados_cluster.c
M src/SAL/recovery/recovery_rados_kv.c
3 files changed, 54 insertions(+), 27 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/27/432327/1
--
To view, visit https://review.gerrithub.io/432327
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: I5ede0b89175879fb24cb145946ce6f4cb5e9dc6b
Gerrit-Change-Number: 432327
Gerrit-PatchSet: 1
Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
6 years, 1 month
Change in ffilz/nfs-ganesha[next]: rados_recov: convert rados_recov_oid to be RCU-managed gsh_refstr
by Jeff Layton (GerritHub)
Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/432326
Change subject: rados_recov: convert rados_recov_oid to be RCU-managed gsh_refstr
......................................................................
rados_recov: convert rados_recov_oid to be RCU-managed gsh_refstr
In the big scheme of things, the rados_recov_oid changes very
infrequently, and only in response to a different server requesting a
grace period.
Change the rados_recov_oid to be managed with an atomic refcount and
RCU. The general pattern is to take the rcu_read_lock and atomically
bump the refcount and then release it. Once we are finished with the
string we drop the refcount.
When we need to change the string, we swap the old object with the new
with an xchg operation, and then call synchronize_rcu to wait for any
users of the old pointer to complete.
This allows us to fetch and update the thing locklessly but safely.
Change-Id: I6df9ce3f0f562b8d760d4c02311528bbe635d17b
Signed-off-by: Jeff Layton <jlayton(a)redhat.com>
---
M src/SAL/recovery/recovery_rados.h
M src/SAL/recovery/recovery_rados_cluster.c
M src/SAL/recovery/recovery_rados_kv.c
M src/SAL/recovery/recovery_rados_ng.c
4 files changed, 126 insertions(+), 31 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/26/432326/1
--
To view, visit https://review.gerrithub.io/432326
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: I6df9ce3f0f562b8d760d4c02311528bbe635d17b
Gerrit-Change-Number: 432326
Gerrit-PatchSet: 1
Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
6 years, 1 month
Change in ffilz/nfs-ganesha[next]: support: add a gsh_refstr type and functions
by Jeff Layton (GerritHub)
Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/432325
Change subject: support: add a gsh_refstr type and functions
......................................................................
support: add a gsh_refstr type and functions
Create a new structure that consists of an atomic refcount value and a
flexarray that is intended to hold a string. When the refcount reaches
zero, then the object will be freed.
Unfortunately, the liburcu version currently in epel7 doesn't have
urcu_ref_get_unless_zero, so we check for that and provide a
copypasta'ed version if it isn't present.
Change-Id: I742e1fff3e47646e64fec235fad461b206924458
Signed-off-by: Jeff Layton <jlayton(a)redhat.com>
---
M src/CMakeLists.txt
M src/include/config-h.in.cmake
A src/include/gsh_refstr.h
M src/support/CMakeLists.txt
A src/support/refstr.c
5 files changed, 88 insertions(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/25/432325/1
--
To view, visit https://review.gerrithub.io/432325
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: I742e1fff3e47646e64fec235fad461b206924458
Gerrit-Change-Number: 432325
Gerrit-PatchSet: 1
Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
6 years, 1 month
Change in ffilz/nfs-ganesha[next]: Have threads register and unregister with RCU
by Jeff Layton (GerritHub)
Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/432324
Change subject: Have threads register and unregister with RCU
......................................................................
Have threads register and unregister with RCU
If you want to use rcu-critical sections, then you must register your
threads with RCU on creation. Since it's often difficult to predict
which threads may end up running a particular callback, ensure that we
register all threads that ganesha creates with RCU.
Change-Id: Ie9b027cfe12e5ec6e95b13c1b3090ca6be5047e2
Signed-off-by: Jeff Layton <jlayton(a)redhat.com>
---
M src/FSAL/FSAL_GLUSTER/fsal_up.c
M src/FSAL/FSAL_GPFS/fsal_up.c
M src/FSAL/FSAL_PROXY/handle.c
M src/FSAL/FSAL_VFS/panfs/mds.c
M src/MainNFSD/9p_dispatcher.c
M src/MainNFSD/9p_rdma_dispatcher.c
M src/MainNFSD/nfs_admin_thread.c
M src/MainNFSD/nfs_init.c
M src/dbus/dbus_server.c
M src/support/delayed_exec.c
M src/support/fridgethr.c
11 files changed, 61 insertions(+), 20 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/24/432324/1
--
To view, visit https://review.gerrithub.io/432324
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: Ie9b027cfe12e5ec6e95b13c1b3090ca6be5047e2
Gerrit-Change-Number: 432324
Gerrit-PatchSet: 1
Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
6 years, 1 month
Change in ffilz/nfs-ganesha[next]: cmake: always build in liburcu
by Jeff Layton (GerritHub)
Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/432323
Change subject: cmake: always build in liburcu
......................................................................
cmake: always build in liburcu
There is some infrastructure in liburcu for handling things locklessly
that could be of great use to ganesha. That library is available on
both Linux and FreeBSD, so there should be no reason we can't use it
with ganesha.
Change cmake to always search for liburcu and fail to configure if it
isn't present.
Change-Id: I7404115a762dc4d4bb8547f0fe7dcde2d9f3720e
Signed-off-by: Jeff Layton <jlayton(a)redhat.com>
---
M src/CMakeLists.txt
M src/cmake/modules/FindLTTng.cmake
M src/nfs-ganesha.spec-in.cmake
3 files changed, 5 insertions(+), 3 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/23/432323/1
--
To view, visit https://review.gerrithub.io/432323
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: I7404115a762dc4d4bb8547f0fe7dcde2d9f3720e
Gerrit-Change-Number: 432323
Gerrit-PatchSet: 1
Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
6 years, 1 month
Blocked Lock Not found when calling up_async_lock_grant
by ntvietvn＠gmail.com
Hello,
When reading the code, I wonder if the blocking lock can work with GPFS.
When the FSAL upcalls the SAL with up_async_lock_grant, it passes handle info in gsh_buffdesc so that in lock_grant we can rebuild the handle later (using create_handle) to look for the existing blocked lock in the queue. The issue is create_handle of GPFS always creates a new pointer to obj_hdl and in the lookup fct find_blocked_lock_upcall, ganesha compares the pointer of obj_hdl and not the value of this handle, thus it will never find the existing blocked lock.
Should we use a fct like handle_compare instead or did I misunderstand something?
Thank you
Viet
6 years, 1 month
