[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Cleanup export refcounts, especially in DBUS show_exports

2017-12-08 Thread GerritHub 
>From Frank Filz :

Frank Filz has uploaded this change for review. ( 
https://review.gerrithub.io/391022


Change subject: Cleanup export refcounts, especially in DBUS show_exports
..

Cleanup export refcounts, especially in DBUS show_exports

Change-Id: I82116d8bc600fc7116338323407888b03b305486
Signed-off-by: Frank S. Filz 
---
M src/FSAL/fsal_helper.c
M src/Protocols/RQUOTA/rquota_common.c
M src/Protocols/RQUOTA/rquota_getquota.c
M src/Protocols/RQUOTA/rquota_setquota.c
M src/support/export_mgr.c
5 files changed, 15 insertions(+), 1 deletion(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/22/391022/1
-- 
To view, visit https://review.gerrithub.io/391022
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I82116d8bc600fc7116338323407888b03b305486
Gerrit-Change-Number: 391022
Gerrit-PatchSet: 1
Gerrit-Owner: Frank Filz 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Add export refcount debugging

2017-12-08 Thread GerritHub 
>From Frank Filz :

Frank Filz has uploaded this change for review. ( 
https://review.gerrithub.io/391016


Change subject: Add export refcount debugging
..

Add export refcount debugging

Change-Id: Iefcde64e10119bec1f644894a57f19ea0a480e4b
Signed-off-by: Frank S. Filz 
---
M src/include/export_mgr.h
M src/support/export_mgr.c
2 files changed, 28 insertions(+), 4 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/16/391016/1
-- 
To view, visit https://review.gerrithub.io/391016
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Iefcde64e10119bec1f644894a57f19ea0a480e4b
Gerrit-Change-Number: 391016
Gerrit-PatchSet: 1
Gerrit-Owner: Frank Filz 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Fix release of host_prefix in client_match

2017-12-08 Thread GerritHub 
>From Frank Filz :

Frank Filz has uploaded this change for review. ( 
https://review.gerrithub.io/391009


Change subject: Fix release of host_prefix in client_match
..

Fix release of host_prefix in client_match

It was getting used after free if a match with a NETWORK_CLIENT
failed.

Change-Id: I6ed692ade41b9984ad7b3e643aabd67704d5021f
Signed-off-by: Frank S. Filz 
---
M src/support/exports.c
1 file changed, 14 insertions(+), 10 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/09/391009/1
-- 
To view, visit https://review.gerrithub.io/391009
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I6ed692ade41b9984ad7b3e643aabd67704d5021f
Gerrit-Change-Number: 391009
Gerrit-PatchSet: 1
Gerrit-Owner: Frank Filz 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Stacked FSALs and fsal_export parameters and op_ctx

2017-12-08 Thread Daniel Gryniewicz 

fsal_export should probably be set anywhere gsh_export is set.

Daniel

On 12/07/2017 07:54 PM, Frank Filz wrote:

Stacked FSALs often depend on op_ctx->fsal_export being set.

We also have lots of FSAL methods that take the fsal_export as a parameter.

I wonder if we would be better off removing the fsal_export parameters in
almost all cases, and instead expecting op_ctx->fsal_export to be set?

One danger is that if an FSAL method is called for a different export than
op_ctx->fsal_export, the subcall macros will end up changing
op_ctx->fsal_export and break the caller... It would be better that the
caller assure that op_ctx is properly set up (and save the current
op_ctx->fsal_export if necessary).

In any case, we probably need to audit anywhere op_ctx->fsal_export is not
set. I see that RQUOTA does not set it...

One advantage of making sure op_ctx->fsal_export is always set in the upper
layers is that it should ALSO set op_ctx->ctx_export.

We should also check for any place where op_ctx is NULL. We have
subcall_shutdown_raw that assumes op_ctx might not be set, and the only
place it is used is in calling sub_export release, with the result that that
was not actually working right in the DBUS unexport case where there wasn't
a proper op_ctx (though I wonder if that's also why shutdown reports an
extra ref to FSAL_PSEUDO, is there some point in shutdown where we don't
have an op_ctx?).

Frank


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Stacked FSALs and fsal_export parameters and op_ctx

2017-12-08 Thread Daniel Gryniewicz 
I'm on the opposite end.  I'm not in favor of passing op_ctx needlessly 
to every function in Ganesha.


Any useful threading system must have some form of TLS.

Daniel

On 12/08/2017 10:13 AM, Matt Benjamin wrote:

I'd like to see this use of TLS as a "hidden parameter" replaced
regardless.  It has been a source of bugs, and locks us into a
pthreads execution model I think needlessly.

Matt

On Fri, Dec 8, 2017 at 10:07 AM, Frank Filz  wrote:

On 12/7/17 7:54 PM, Frank Filz wrote:

Stacked FSALs often depend on op_ctx->fsal_export being set.

We also have lots of FSAL methods that take the fsal_export as a

parameter.



The latter sounds better.

Now that we know every single thread local storage access involves a hidden
lock/unlock sequence in glibc "magically" invoked by the linker, it would be
better to remove as many TLS references as possible!

After all, too many lock/unlock are a real performance issue.

Perhaps we should pass op_ctx as the parameter instead.


I thought the lock was only to create the TLS variable, and not on every 
reference.

Frank


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel







--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Stacked FSALs and fsal_export parameters and op_ctx

2017-12-08 Thread Matt Benjamin 
I'd like to see this use of TLS as a "hidden parameter" replaced
regardless.  It has been a source of bugs, and locks us into a
pthreads execution model I think needlessly.

Matt

On Fri, Dec 8, 2017 at 10:07 AM, Frank Filz  wrote:
>> On 12/7/17 7:54 PM, Frank Filz wrote:
>> > Stacked FSALs often depend on op_ctx->fsal_export being set.
>> >
>> > We also have lots of FSAL methods that take the fsal_export as a
>> parameter.
>> >
>> The latter sounds better.
>>
>> Now that we know every single thread local storage access involves a hidden
>> lock/unlock sequence in glibc "magically" invoked by the linker, it would be
>> better to remove as many TLS references as possible!
>>
>> After all, too many lock/unlock are a real performance issue.
>>
>> Perhaps we should pass op_ctx as the parameter instead.
>
> I thought the lock was only to create the TLS variable, and not on every 
> reference.
>
> Frank
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel



-- 

Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-821-5101
fax.  734-769-8938
cel.  734-216-5309

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Stacked FSALs and fsal_export parameters and op_ctx

2017-12-08 Thread Frank Filz 
> On 12/7/17 7:54 PM, Frank Filz wrote:
> > Stacked FSALs often depend on op_ctx->fsal_export being set.
> >
> > We also have lots of FSAL methods that take the fsal_export as a
> parameter.
> >
> The latter sounds better.
> 
> Now that we know every single thread local storage access involves a hidden
> lock/unlock sequence in glibc "magically" invoked by the linker, it would be
> better to remove as many TLS references as possible!
> 
> After all, too many lock/unlock are a real performance issue.
> 
> Perhaps we should pass op_ctx as the parameter instead.

I thought the lock was only to create the TLS variable, and not on every 
reference.

Frank


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] test over FSAl_NULL

2017-12-08 Thread LUCAS Patrice 

Hi,


Does anyone recently test the FSAL_NULL stackable FSAL ?


Before using it as example of coding a stackable FSAL, I simply tried to 
use FSAL_NULL over FSAL_VFS and I got the following segmentation fault 
when running cthon04 basic test7 ('link and rename').


Best regards,

Patrice


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x72daf700 (LWP 22397)]
0x0041c23e in posix2fsal_attributes (buffstat=0x72dad590, 
fsalattr=0x72dad780) at /opt/nfs-ganesha/src/FSAL/fsal_convert.c:432
432 fsalattr->supported = 
op_ctx->fsal_export->exp_ops.fs_supported_attrs(
Missing separate debuginfos, use: debuginfo-install 
glibc-2.17-157.el7_3.5.x86_64 gssproxy-0.4.1-13.el7.x86_64 
keyutils-libs-1.5.8-3.el7.x86_64 kr
b5-libs-1.14.1-27.ocean1.el7.centos.x86_64 
libcom_err-1.42.13.wc6-8.ocean1.el7.centos.x86_64 
libselinux-2.5-6.el7.x86_64 pcre-8.32-15.el7_2.1.x86_

64
(gdb) where
#0  0x0041c23e in posix2fsal_attributes 
(buffstat=0x72dad590, fsalattr=0x72dad780)

    at /opt/nfs-ganesha/src/FSAL/fsal_convert.c:432
#1  0x0041c21c in posix2fsal_attributes_all 
(buffstat=0x72dad590, fsalattr=0x72dad780)

    at /opt/nfs-ganesha/src/FSAL/fsal_convert.c:422
#2  0x73f155dc in fetch_attrs (myself=0x7fffd801baf0, my_fd=35, 
attrs=0x72dad780) at /opt/nfs-ganesha/src/FSAL/FSAL_VFS/file.c:325
#3  0x73f1927a in vfs_getattr2 (obj_hdl=0x7fffd801baf0, 
attrs=0x72dad780) at /opt/nfs-ganesha/src/FSAL/FSAL_VFS/file.c:1595
#4  0x741255d3 in getattrs (obj_hdl=0x7fffd800fdd0, 
attrib_get=0x72dad780)

    at /opt/nfs-ganesha/src/FSAL/Stackable_FSALs/FSAL_NULL/handle.c:503
#5  0x00531459 in mdcache_refresh_attrs (entry=0x7fffd80175e0, 
need_acl=false, invalidate=false)
    at 
/opt/nfs-ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:1048
#6  0x0052d4a1 in mdcache_refresh_attrs_no_invalidate 
(entry=0x7fffd80175e0)
    at 
/opt/nfs-ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_int.h:445
#7  0x005310be in mdcache_rename (obj_hdl=0x7fffe4037888, 
olddir_hdl=0x7fffd8017618, old_name=0x7fffd8002b80 "file.0",

    newdir_hdl=0x7fffd8017618, new_name=0x7fffd800f730 "newfile.0")
    at 
/opt/nfs-ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:991
#8  0x00431b26 in fsal_rename (dir_src=0x7fffd8017618, 
oldname=0x7fffd8002b80 "file.0", dir_dest=0x7fffd8017618,
    newname=0x7fffd800f730 "newfile.0") at 
/opt/nfs-ganesha/src/FSAL/fsal_helper.c:1412
#9  0x00475947 in nfs4_op_rename (op=0x7fffd80153f0, 
data=0x72dadae0, resp=0x7fffd8018220)

    at /opt/nfs-ganesha/src/Protocols/NFS/nfs4_op_rename.c:122
#10 0x00459b84 in nfs4_Compound (arg=0x7fffd800c538, 
req=0x7fffd800be30, res=0x7fffd800a950)

    at /opt/nfs-ganesha/src/Protocols/NFS/nfs4_Compound.c:752
#11 0x0044ab75 in nfs_rpc_process_request 
(reqdata=0x7fffd800be30) at 
/opt/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1338
#12 0x0044b77a in nfs_rpc_valid_NFS (req=0x7fffd800be30) at 
/opt/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1736
#13 0x76c28546 in svc_vc_decode (req=0x7fffd800be30) at 
/opt/nfs-ganesha/src/libntirpc/src/svc_vc.c:812
#14 0x0044fb64 in nfs_rpc_decode_request (xprt=0x7fffe4000bc0, 
xdrs=0x7fffd8017be0)

    at /opt/nfs-ganesha/src/MainNFSD/nfs_rpc_dispatcher_thread.c:1625
#15 0x76c28458 in svc_vc_recv (xprt=0x7fffe4000bc0) at 
/opt/nfs-ganesha/src/libntirpc/src/svc_vc.c:785
#16 0x76c24bce in svc_rqst_xprt_task (wpe=0x7fffe4000dd8) at 
/opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:753
#17 0x76c25048 in svc_rqst_epoll_events (sr_rec=0x7ef210, 
n_events=1) at /opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:925
#18 0x76c252ea in svc_rqst_epoll_loop (sr_rec=0x7ef210) at 
/opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:998
#19 0x76c2539d in svc_rqst_run_task (wpe=0x7ef210) at 
/opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:1034
#20 0x76c2e9f1 in work_pool_thread (arg=0x7fffe8c0) at 
/opt/nfs-ganesha/src/libntirpc/src/work_pool.c:176

#21 0x77058dc5 in start_thread () from /lib64/libpthread.so.0
#22 0x7671a76d in clone () from /lib64/libc.so.6
(gdb)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: FSAL_GLUSTER: close fd without setting credentials at handle...

2017-12-08 Thread GerritHub 
>From Kinglong Mee :

Kinglong Mee has uploaded this change for review. ( 
https://review.gerrithub.io/390939


Change subject: FSAL_GLUSTER: close fd without setting credentials at 
handle_release()
..

FSAL_GLUSTER: close fd without setting credentials at handle_release()

When ganesha.nfsd shutdown, a crash happens for op_ctx is NULL,

admin_thread ->do_shutdown ->destroy_fsals ->shutdown_handles
 ->handle_release ->glusterfs_close_my_fd

Change-Id: I95aa5269ecbd4883b1c9a9ea6d1f471b58a3e41a
Signed-off-by: Kinglong Mee 
---
M src/FSAL/FSAL_GLUSTER/handle.c
1 file changed, 10 insertions(+), 5 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/39/390939/1
-- 
To view, visit https://review.gerrithub.io/390939
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I95aa5269ecbd4883b1c9a9ea6d1f471b58a3e41a
Gerrit-Change-Number: 390939
Gerrit-PatchSet: 1
Gerrit-Owner: Kinglong Mee 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Stacked FSALs and fsal_export parameters and op_ctx

2017-12-08 Thread William Allen Simpson 

On 12/7/17 7:54 PM, Frank Filz wrote:

Stacked FSALs often depend on op_ctx->fsal_export being set.

We also have lots of FSAL methods that take the fsal_export as a parameter.


The latter sounds better.

Now that we know every single thread local storage access involves a
hidden lock/unlock sequence in glibc "magically" invoked by the linker,
it would be better to remove as many TLS references as possible!

After all, too many lock/unlock are a real performance issue.

Perhaps we should pass op_ctx as the parameter instead.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel