[LTTNG] Compilation broken
by Sriram Patil
Hi,
It looks like lttng linking is broken in both top of the tree and 2.7-stable branch. I am seeing following errors when trying to compile ganesha by setting USE_LTTNG,
On top of tree,
/usr/bin/ld: ganesha.nfsd: hidden symbol `tracepoint_dlopen' in CMakeFiles/ganesha.nfsd.dir/MainNFSD/nfs_main.c.o is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
CMakeFiles/ganesha.nfsd.dir/build.make:107: recipe for target 'ganesha.nfsd' failed
make[2]: *** [ganesha.nfsd] Error 1
CMakeFiles/Makefile2:201: recipe for target 'CMakeFiles/ganesha.nfsd.dir/all' failed
make[1]: *** [CMakeFiles/ganesha.nfsd.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2
On V2.7-stable branch,
/usr/bin/ld: rpcping: hidden symbol `tracepoint_dlopen' in ../src/lttng/libntirpc_lttng.a(main.c.o) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
libntirpc/tests/CMakeFiles/rpcping.dir/build.make:109: recipe for target 'libntirpc/tests/rpcping' failed
make[2]: *** [libntirpc/tests/rpcping] Error 1
CMakeFiles/Makefile2:450: recipe for target 'libntirpc/tests/CMakeFiles/rpcping.dir/all' failed
make[1]: *** [libntirpc/tests/CMakeFiles/rpcping.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2
- Sriram
5 years, 8 months
Change in ...nfs-ganesha[next]: build: use a version script for libganesha_nfsd.so
by Name of user not set (GerritHub)
kaleb(a)redhat.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451937
Change subject: build: use a version script for libganesha_nfsd.so
......................................................................
build: use a version script for libganesha_nfsd.so
Only expose symbols needed by applications, e.g. ganesha.nfsd and
the FSALs.
Add link flag the FSALs and the applications to not allow undefined
symbols as an aid to developers. If a new API is added and it is used
in an app or FSAL they will discover it immediately if they forget to
add it to the version script.
Tested (superficially) with FSAL_VFS and FSAL_GLUSTER.
Note that Fedora tried, circa f28 or so, to require "-z defs" (a.k.a.
--no-undefined). It will probably come back at some point, so we
will be ahead of the curve here.
Signed-off-by: Kaleb S. KEITHLEY <kkeithle(a)redhat.com>
Change-Id: I970d4735c9842a9a1c86081299297f7c471260a9
---
M src/CMakeLists.txt
M src/FSAL/FSAL_CEPH/CMakeLists.txt
M src/FSAL/FSAL_GLUSTER/CMakeLists.txt
M src/FSAL/FSAL_GPFS/CMakeLists.txt
M src/FSAL/FSAL_MEM/CMakeLists.txt
M src/FSAL/FSAL_PROXY/CMakeLists.txt
M src/FSAL/FSAL_RGW/CMakeLists.txt
M src/FSAL/FSAL_VFS/panfs/CMakeLists.txt
M src/FSAL/FSAL_VFS/vfs/CMakeLists.txt
M src/FSAL/FSAL_VFS/xfs/CMakeLists.txt
M src/FSAL/Stackable_FSALs/FSAL_NULL/CMakeLists.txt
M src/MainNFSD/CMakeLists.txt
A src/MainNFSD/libganesha_nfsd.ver
13 files changed, 233 insertions(+), 29 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/37/451937/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451937
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: I970d4735c9842a9a1c86081299297f7c471260a9
Gerrit-Change-Number: 451937
Gerrit-PatchSet: 1
Gerrit-Owner: kaleb(a)redhat.com
Gerrit-MessageType: newchange
5 years, 8 months
Announce Push of V2.8-dev.27
by Frank Filz
Branch next
Tag:V2.8-dev.27
Release Highlights
* revert accidental idmapper.c change
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
5a1cdae Frank S. Filz V2.8-dev.27
3cd5d76 Frank S. Filz Revert idmapper changes that accidentally got included
in a patch
5 years, 8 months
Question about recovery on Ceph FSAL
by fanzi2009＠hotmail.com
Hi Layton ,Dan and other experts,
When a client connect Server A, and Sever A crush. So the client try to connect Server B. If Server A reboot very slowly so that Server B don't know it should enter cluster grace period .If so, this client have no opportunity to reclaim previous resource. Is it right?
Marvin
5 years, 8 months
Change in ...nfs-ganesha[next]: Free NLM lock holder memory after sending the response
by Malahal (GerritHub)
Malahal has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451701
Change subject: Free NLM lock holder memory after sending the response
......................................................................
Free NLM lock holder memory after sending the response
Make nlm4_Lock_Free() to free the memory allocated in
fill_netobj() while processing a lock conflict.
Change-Id: Ib26c40b0b1ccc7933803d553c55dd1853397363f
Signed-off-by: Malahal Naineni <malahal(a)us.ibm.com>
---
M src/Protocols/NLM/nlm_Lock.c
1 file changed, 4 insertions(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/01/451701/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451701
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: Ib26c40b0b1ccc7933803d553c55dd1853397363f
Gerrit-Change-Number: 451701
Gerrit-PatchSet: 1
Gerrit-Owner: Malahal <malahal(a)gmail.com>
Gerrit-MessageType: newchange
5 years, 8 months
Change in ...nfs-ganesha[next]: MDCACHE: Don't deref the mdcache_entry pointer once the ref is dropped.
by Ashish Sangwan (GerritHub)
Ashish Sangwan has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451679
Change subject: MDCACHE: Don't deref the mdcache_entry pointer once the ref is dropped.
......................................................................
MDCACHE: Don't deref the mdcache_entry pointer once the ref is dropped.
The read callback drops the ref taken earlier on the mdcache entry.
ASAN has reported use after free error while accessing the entry
pointer once the callback is finished.
Signed-off-by: Ashish Sangwan <ashishsangwan2(a)gmail.com>
Change-Id: I5b1ff9595af2d878de428e3977613bf1e7c541e5
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_file.c
1 file changed, 4 insertions(+), 3 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/79/451679/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451679
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: I5b1ff9595af2d878de428e3977613bf1e7c541e5
Gerrit-Change-Number: 451679
Gerrit-PatchSet: 1
Gerrit-Owner: Ashish Sangwan <ashishsangwan2(a)gmail.com>
Gerrit-MessageType: newchange
5 years, 8 months
Change in ...nfs-ganesha[next]: MDCACHE - Fix race between lru functions for the chunk and the parent...
by Ashish Sangwan (GerritHub)
Ashish Sangwan has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451673
Change subject: MDCACHE - Fix race between lru functions for the chunk and the parent of the chunk getting freed and reused.
......................................................................
MDCACHE - Fix race between lru functions for the chunk and the parent
of the chunk getting freed and reused.
The LRU functions which acts on the chunk, chunk_lru_run_lane and
lru_reap_chunk_impl both of them takes ref on the chunk and dropa
the qlane lock before calling mdcache_lru_unref_chunk to drop
the ref taken earlier. The extra ref prevents the chunk from getting
freed but it can't stop the chunk's parent from getting freed and reused.
We are hitting a hang when trying to acquire content lock on
the freed parent.
These LRU functions doesn't actually need ref and holding the qlane
lock is enough to prevent the chunk from being freed.
Signed-off-by: Ashish Sangwan <ashishsangwan2(a)gmail.com>
Change-Id: I3cb5f09fa4894c121545a47182116e77d94f0643
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_avl.c
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.h
4 files changed, 25 insertions(+), 56 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/73/451673/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451673
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: I3cb5f09fa4894c121545a47182116e77d94f0643
Gerrit-Change-Number: 451673
Gerrit-PatchSet: 1
Gerrit-Owner: Ashish Sangwan <ashishsangwan2(a)gmail.com>
Gerrit-MessageType: newchange
5 years, 8 months
Race between reusing MDCACHE entry of the parent and chunk_lru_run()
by Pradeep
Hello,
I'm hitting hang where rmv_detached_dirent() is stuck at the spinlock for
ever.
#0 0x00007feb01a9a4e5 in pthread_spin_lock () from /lib64/libpthread.so.0
#1 0x00000000005519e7 in rmv_detached_dirent (parent=0x7feaeb8dd600,
dirent=0x7fea9fbd8700)
at
/usr/src/debug/nfs-ganesha-2.7.1/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_int.h:420
#2 0x00000000005522e8 in mdcache_avl_remove (parent=0x7feaeb8dd600,
dirent=0x7fea9fbd8700)
at
/usr/src/debug/nfs-ganesha-2.7.1/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_avl.c:256
#3 0x0000000000547752 in mdcache_clean_dirent_chunk (chunk=0x7fea9f86f970)
at
/usr/src/debug/nfs-ganesha-2.7.1/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:454
#4 0x00000000005386a2 in lru_clean_chunk (chunk=0x7fea9f86f970)
at
/usr/src/debug/nfs-ganesha-2.7.1/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c:2078
#5 0x000000000053881b in mdcache_lru_unref_chunk (chunk=0x7fea9f86f970)
at
/usr/src/debug/nfs-ganesha-2.7.1/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c:2097
#6 0x000000000053698c in chunk_lru_run_lane (lane=14)
at
/usr/src/debug/nfs-ganesha-2.7.1/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c:1509
#7 0x0000000000536d26 in chunk_lru_run (ctx=0x7feafe00f580)
at
/usr/src/debug/nfs-ganesha-2.7.1/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c:1563
#8 0x0000000000508ad9 in fridgethr_start_routine (arg=0x7feafe00f580)
at /usr/src/debug/nfs-ganesha-2.7.1/support/fridgethr.c:550
#9 0x00007feb01a95e25 in start_thread () from /lib64/libpthread.so.0
#10 0x00007feb0139dbad in clone () from /lib64/libc.so.6
420 pthread_spin_lock(&parent->fsobj.fsdir.spin);
(gdb) print parent->fsobj.fsdir.spin
$1 = -1
(gdb) print parent->obj_handle.type
$2 = REGULAR_FILE
Looks like when the thread is in this path, the parent got reused for a
different object in the filesystem. From looking at code, this seems
possible:
Lets say thread1 goes through the reuse path:
- mdcache_lru_get() ->
- mdcache_lru_clean() ->
- mdc_clean_entry() ->
- mdcache_dirent_invalidate_all()
- mdcache_lru_unref_chunk()
- This will call lru_clean_chunk() only if refcnt is zero.
Lets say another thread (thread2 below) incremented it
from the background
thread. So thread1 will return back and the entry now
gets reused.
Now the background thread (thread2) comes up to clean chunks and increments
refcnt:
- chunk_lru_run()
- chunk_lru_run_lane()
- mdcache_lru_unref_chunk()
- Here we unlock qlane lock and then decrement refcnt. When this
thread unlocks, thread1 will grab qlane lock and skip the
chunk because
refcnt is > 0. By the time we reach
mdcache_lru_unref_chunk(), the parent
would have been reused by thread1 for a different object. Now
mdcache_lru_unref_chunk() make progress as refcnt became
zero; but parent
is invalid. So it gets stuck in rmv_detached_dirent().
I think we should hold the qlock in chunk_lru_run_lane() till the refcnt is
decremented to make sure that reaping of parent is not possible. Since
mdcache_lru_unref_chunk() already holds the lock later, we could probably
pass a flag to indicate if the qlane lock is already held or nor (similar
to content_lock). Please let me know if there is a better approach to
refactor this.
Thanks,
Pradeep
5 years, 8 months
