[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: WIP: Fix nlm client refcount going up from zero

2017-02-15 Thread GerritHub 
>From Malahal :

Malahal has uploaded a new change for review. ( 
https://review.gerrithub.io/348993


Change subject: WIP: Fix nlm client refcount going up from zero
..

WIP: Fix nlm client refcount going up from zero

Once a refcount goes to zero, we should not be using it any more and let
the thread that made it zero free up the entry. If zero refcount entry
is found in the hash table, don't use it, remove it from the hash table
and insert a new nlm client using get_nlm_client.

Change-Id: Icda341d943cbd18bff4439e961748f6fda7f1092
Signed-off-by: Malahal Naineni 
---
M src/SAL/nlm_owner.c
1 file changed, 38 insertions(+), 29 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/93/348993/1
-- 
To view, visit https://review.gerrithub.io/348993
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Icda341d943cbd18bff4439e961748f6fda7f1092
Gerrit-Change-Number: 348993
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Malahal 
--
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 state_test calling LogLock when there is no conflict

2017-02-15 Thread GerritHub 
>From Malahal :

Malahal has uploaded a new change for review. ( 
https://review.gerrithub.io/348994


Change subject: Fix state_test calling LogLock when there is no conflict
..

Fix state_test calling LogLock when there is no conflict

holder is expected to be set only when there is a lock conflict.
holder would be unintialized when there is no lock conflict and this
leads to crash in LogLock.

Change-Id: I081f3a3a670809a5a89ec934a4d84352d1a80f3f
Signed-off-by: Malahal Naineni 
---
M src/SAL/state_lock.c
1 file changed, 12 insertions(+), 8 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/94/348994/1
-- 
To view, visit https://review.gerrithub.io/348994
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I081f3a3a670809a5a89ec934a4d84352d1a80f3f
Gerrit-Change-Number: 348994
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Malahal 
--
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] Dirent invalidation on up call

2017-02-15 Thread Frank Filz 
> er, oh noes...

The problem I think I see is that the directory never gets cleaned out in this 
case...

I get that we may not want to dispose of the dirents on the upcall thread, but 
we should dispose of them the next time we do a lookup or readdir...

Everything else that invalidates a directory cleans out the dirents inline.

Frank

> > I'm looking at when dirents are invalidated, and it looks like
> > MDCACHE_DIR_POPULATED is cleared on up call, but nothing actually
> > cleans out the dirents...
> >
> > Is this an omission?
> >
> > 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


---
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

Re: [Nfs-ganesha-devel] Dirent invalidation on up call

2017-02-15 Thread Matt Benjamin 
er, oh noes...

Matt

- Original Message -
> From: "Frank Filz" 
> To: nfs-ganesha-devel@lists.sourceforge.net
> Sent: Wednesday, February 15, 2017 7:43:40 PM
> Subject: [Nfs-ganesha-devel] Dirent invalidation on up call
> 
> I'm looking at when dirents are invalidated, and it looks like
> MDCACHE_DIR_POPULATED is cleared on up call, but nothing actually cleans out
> the dirents...
> 
> Is this an omission?
> 
> 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

[Nfs-ganesha-devel] Dirent invalidation on up call

2017-02-15 Thread Frank Filz 
I'm looking at when dirents are invalidated, and it looks like
MDCACHE_DIR_POPULATED is cleared on up call, but nothing actually cleans out
the dirents...

Is this an omission?

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] Change in ffilz/nfs-ganesha[next]: Fix SSE4_2 compile path.

2017-02-15 Thread GerritHub 
>From Dylan Reid :

Dylan Reid has uploaded a new change for review. ( 
https://review.gerrithub.io/348971


Change subject: Fix SSE4_2 compile path.
..

Fix SSE4_2 compile path.

A semicolon has been missing from the "CHUNK" macro since it was
reformatted.

Change-Id: Ieb7d3b8166fda68bc8e15aec4a281c0af1019438
Signed-off-by: Dylan Reid 
---
M src/support/city.c
1 file changed, 1 insertion(+), 1 deletion(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/71/348971/1
-- 
To view, visit https://review.gerrithub.io/348971
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ieb7d3b8166fda68bc8e15aec4a281c0af1019438
Gerrit-Change-Number: 348971
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Dylan Reid 
--
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] reg. FSAL_ACE_PERM_WRITE_DATA check in fsal_check_setattr_perms

2017-02-15 Thread Frank Filz 
 
> Frank,
> 
> I have subscribed to the list. Apologies for any inconvenience caused.
> 
> > This wouldn't actually help since the call to test_access just winds
> > up in fsal_test_access which isn't going to know about your special super
> user.
> > All Ganesha is doing here is not making a test_access call that turns
> > into an fsal_test_access call that would always fail the permission
> > check - or actually, I think it might always pass the permission check
> > for files that don't have an NFS v4 ACL... We would have to change the
> > test_access API to add permissions to check for in mode tests that are
> > outside the mode permission checking...
> 
> > The alternative as a general mechanism is to increase the number of
> > calls to the underlying filesystem Ganesha makes which is likely to
> > have a negative impact on other FSAL's performance.
> 
> Our filesystem doesn't support NFSv4 ACLs. Sorry to prolong this further but
> just to be clear, we have implemented our own test_access call. In our
> test_access implementation we have a way to figure out if the user is super
> user or not. Agree that removing the check would result in a lot of
> fsal_test_access calls.

What version of Ganesha do you use? 2.4 and later will not ever call your 
FSAL's test_access because FSAL_MDCACHE always calls fsal_test_access and never 
calls the underlying FSAL's own test_access.

Maybe what we need is a way for places that are checking for super user to call 
an FSAL is_super_user(creds) method, which of could would default to returning 
true only for uid == 0.

Your implementation of course could do whatever you need to do.

Then we just have to get out of the habit of checking for uid == 0 and instead 
invoke is_super_user(creds)...

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] Change in ffilz/nfs-ganesha[next]: Pull up ntirpc #39

2017-02-15 Thread GerritHub 
>From :

william.allen.simp...@gmail.com has uploaded a new change for review. ( 
https://review.gerrithub.io/348814


Change subject: Pull up ntirpc #39
..

Pull up ntirpc #39

Change-Id: I41c54962e6dc2df803610b1aed70378433d57421
Signed-off-by: William Allen Simpson 
---
M src/libntirpc
1 file changed, 1 insertion(+), 1 deletion(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/14/348814/1
-- 
To view, visit https://review.gerrithub.io/348814
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I41c54962e6dc2df803610b1aed70378433d57421
Gerrit-Change-Number: 348814
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: william.allen.simp...@gmail.com
--
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_PROXY (support_ex without state) : pxy_status2

2017-02-15 Thread GerritHub 
>From Patrice LUCAS :

Patrice LUCAS has uploaded a new change for review. ( 
https://review.gerrithub.io/348901


Change subject: FSAL_PROXY (support_ex without state) : pxy_status2
..

FSAL_PROXY (support_ex without state) : pxy_status2

Change-Id: I9411ae1a1939dad543b2fc9e4628d81f77a0b94a
Signed-off-by: Patrice LUCAS 
---
M src/FSAL/FSAL_PROXY/handle.c
1 file changed, 10 insertions(+), 0 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/01/348901/1
-- 
To view, visit https://review.gerrithub.io/348901
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I9411ae1a1939dad543b2fc9e4628d81f77a0b94a
Gerrit-Change-Number: 348901
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Patrice LUCAS 
--
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] reg. FSAL_ACE_PERM_WRITE_DATA check in fsal_check_setattr_perms

2017-02-15 Thread Satya Prakash GS 
Frank,

I have subscribed to the list. Apologies for any inconvenience caused.

> This wouldn't actually help since the call to test_access just winds up in
> fsal_test_access which isn't going to know about your special super user.
> All Ganesha is doing here is not making a test_access call that turns into
> an fsal_test_access call that would always fail the permission check - or
> actually, I think it might always pass the permission check for files that
> don't have an NFS v4 ACL... We would have to change the test_access API to
> add permissions to check for in mode tests that are outside the mode
> permission checking...

> The alternative as a general mechanism is to increase the number of calls to
> the underlying filesystem Ganesha makes which is likely to have a negative
> impact on other FSAL's performance.

Our filesystem doesn't support NFSv4 ACLs. Sorry to prolong this
further but just to be clear, we have implemented our own test_access
call. In our test_access implementation we have a way to figure out if
the user is super user or not. Agree that removing the check would
result in a lot of fsal_test_access calls.

On Wed, Feb 15, 2017 at 3:57 AM, Frank Filz  wrote:
> One thing,
>
> I suggest you subscribe to the nfs-ganesha-devel mailing list. I have made
> it so your responses should go through without being a member, but you risk
> missing a response if someone doesn't reply-all (or worse, we risk missing a
> response that is just sent to you).
>
>> -Original Message-
>> From: Satya Prakash GS [mailto:g.satyaprak...@gmail.com]
>> Sent: Tuesday, February 14, 2017 2:07 PM
>> To: nfs-ganesha-devel@lists.sourceforge.net
>> Subject: Re: [Nfs-ganesha-devel] reg. FSAL_ACE_PERM_WRITE_DATA check
>> in fsal_check_setattr_perms
>>
>> >On 02/14/2017 06:48 AM, Satya Prakash GS wrote:
>> >> I was referring to this check --->
>> >>
>> >> if (access_check !=
>> FSAL_ACE4_MASK_SET(FSAL_ACE_PERM_WRITE_DATA)) {
>> >>   status = CACHE_INODE_FSAL_EPERM;
>> >>   note = "(no ACL to check)";
>> >>   goto out;
>> >> }
>>
>> > Sorry, I assumed an ACL existed on the file.  What this check is
>> > saying is that, if there's no ACL, the finest granularity check we can
>> > do is unix permission bits, which is just Read Write Execute (and
>> > Write is the only relevant one here), so only continue if we're looking
> for
>> Write access.
>>
>> Can Ganesha avoid doing this check and call test_access always with the
>> constructed access_mask. I see nothing should be broken because of this.
>
> This wouldn't actually help since the call to test_access just winds up in
> fsal_test_access which isn't going to know about your special super user.
> All Ganesha is doing here is not making a test_access call that turns into
> an fsal_test_access call that would always fail the permission check - or
> actually, I think it might always pass the permission check for files that
> don't have an NFS v4 ACL... We would have to change the test_access API to
> add permissions to check for in mode tests that are outside the mode
> permission checking...
>
> The alternative as a general mechanism is to increase the number of calls to
> the underlying filesystem Ganesha makes which is likely to have a negative
> impact on other FSAL's performance.
>
>> >> which is done if the user is not owner of the file.
>> >>
>> >> As per the code,  user can do chown if he is owner or if there is an
>> >> acl on the file. Can Ganesha just pass the credentials (uid, gid) on
>> >> to the server for it to decide if chown is allowed on that file by a
>> >> particular user (irrespective of acls set on that file). That way,
>> >> certain users can be treated specially by the server and grant them
>> >> access.
>> >>
>>  Looking at the code, we don't check WRITE_DATA for owner checks,
>>  only for size or time changes.  For owner/group changes, we check
>>  FSAL_ACE_PERM_WRITE_OWNER, which is the correct ACL to check.
>> 
>>  Presumably, you could just add an ACL to all files allowing all
>>  access to
>> >> your
>>  "root" user.  This should allow access, correct?
>> >>
>> >>> This would be a solution.
>> >>
>> >> I am trying to see if we can avoid any on-disk changes. Since NFS is
>> >> one of the ways to access filesystem it would be better if we can
>> >> avoid handling it differently.
>>
>> > You don't have to do this in the filesystem; you can have the
>> > getattrs() in your FSAL just always add an ACL to the beginning that
>> > allows all access to your superuser.
>>
>> This could mean interpreting an existing acl and building a new acl if an
> acl
>> exists on that file.
>
> Does your FSAL/filesystem support NFS v4 ACLs? That would add complexity,
> however, if you have additional super users that aren't represented in the
> ACL, that may cause additional issues anywhere Ganesha has special rules for
> the super user.
>
> Frank
>
>
> ---
> This email has been checked for viruses by Avast

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: [nlm_Test] Reference mioght be used un-initialized.

2017-02-15 Thread GerritHub 
>From Swen Schillig :

Swen Schillig has uploaded a new change for review. ( 
https://review.gerrithub.io/348794


Change subject: [nlm_Test] Reference mioght be used un-initialized.
..

[nlm_Test] Reference mioght be used un-initialized.

In function nlm4_Test, the state_owner_t variable "holder"
might be dereferenced without being set.
It must be initialized(NULL) first to detect that it isn't set.

Change-Id: Ib76d8a2562f97c4cbf3ed4652b9c2e9a2449ec3d
Signed-off-by: Swen Schillig 
---
M src/Protocols/NLM/nlm_Test.c
1 file changed, 2 insertions(+), 1 deletion(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/94/348794/1
-- 
To view, visit https://review.gerrithub.io/348794
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ib76d8a2562f97c4cbf3ed4652b9c2e9a2449ec3d
Gerrit-Change-Number: 348794
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Swen Schillig 
--
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]: Fixing a deadlock between reaper thread and setclientid

2017-02-15 Thread GerritHub 
>From Sriram Patil :

Sriram Patil has uploaded a new change for review. ( 
https://review.gerrithub.io/348712


Change subject: Fixing a deadlock between reaper thread and setclientid
..

Fixing a deadlock between reaper thread and setclientid

The setclientid op takes the lock on client_record->cr_mutex first, then it
goes ahead and takes a read-write lock on the hash table partition as part
of nfs_get_client_id  or remove_unconfirmed_client_id. However, this order
of taking locks is not maintained in reap_hash_table, called by reaper_run,
which was causing the deadlock.

Change-Id: Ibf66fac471cfea32c9af768a1ea6eb7f1c4847dc
Signed-off-by: Sriram Patil 
---
M src/MainNFSD/nfs_reaper_thread.c
1 file changed, 3 insertions(+), 1 deletion(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/12/348712/1
-- 
To view, visit https://review.gerrithub.io/348712
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ibf66fac471cfea32c9af768a1ea6eb7f1c4847dc
Gerrit-Change-Number: 348712
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Sriram Patil 
--
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_PROXY (support_ex without state) : pxy_setattr2

2017-02-15 Thread GerritHub 
>From Patrice LUCAS :

Patrice LUCAS has uploaded a new change for review. ( 
https://review.gerrithub.io/348756


Change subject: FSAL_PROXY (support_ex without state) : pxy_setattr2
..

FSAL_PROXY (support_ex without state) : pxy_setattr2

Change-Id: I13b0a1799e42d605eeb5fe42404013c4449f93ae
Signed-off-by: Patrice LUCAS 
---
M src/FSAL/FSAL_PROXY/handle.c
1 file changed, 55 insertions(+), 0 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/56/348756/1
-- 
To view, visit https://review.gerrithub.io/348756
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I13b0a1799e42d605eeb5fe42404013c4449f93ae
Gerrit-Change-Number: 348756
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Patrice LUCAS 
--
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