Re: Depleting fds security issue
by gaurav gangalwar
Looks like my previous message was not delivered due to long length,
summarising it again,
I tried with this fix, as suggested added SVC_DESTROY in UMNT call, added
some logs for debugging,
https://paste.fedoraproject.org/paste/MmpBT2vTwF8DMBvaLTu5rQ
Issue remains same.
*10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
ganesha.nfsd-78524[svc_2] mnt_Umnt :NFS3 :DEBUG :REQUEST PROCESSING:
Calling MNT_UMNT path /export*
*10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
ganesha.nfsd-78524[svc_2] nfs_rpc_process_request :DISP :DEBUG :After
svc_sendreply for umount before SVC_DESTROY0x7fff38024450 1045 4*
*10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
ganesha.nfsd-78524[svc_2] nfs_rpc_process_request :DISP :DEBUG :After
svc_sendreply for umount after SVC_DESTROY0x7fff38024450 1045 3*
*10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
ganesha.nfsd-78524[svc_2] nfs_rpc_decode_request :DISP :DEBUG :SVC_DECODE
on 0x7fff38024450 fd 1045 (::ffff:10.5.192.59:911
<http://10.5.192.59:911/>) xid=1123634942 returned XPRT_DESTROYED*
*10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
ganesha.nfsd-78524[svc_2] free_nfs_request :DISP :DEBUG
:free_nfs_request: 0x7fff38024450 fd 1045 xp_refcnt 3 rq_refcnt 0*
*10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
ganesha.nfsd-78524[svc_2] rpc :TIRPC :DEBUG :svc_rqst_xprt_task before
SVC_RELEASE 0x7fff38024450 1045 2*
*10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
ganesha.nfsd-78524[svc_2] rpc :TIRPC :DEBUG :svc_rqst_xprt_task after
SVC_RELEASE 0x7fff38024450 1045 1*
*10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
ganesha.nfsd-78524[svc_4] rpc :TIRPC :DEBUG :Event on already destroyed
xprt 0x7fff38024450 1045 1*
As we can see in the log highlighted we are still left with one ref even
after SVC_DESTROY in UMNT and all SVC_RELEASE.
I tried with SVC_RELEASE instead of SVC_DESTROY in same patch, it worked at
least for connection on which UMNT came, we are releasing the xprt for it.
*10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_2] mnt_Umnt :NFS3 :DEBUG :REQUEST PROCESSING:
Calling MNT_UMNT path /export*
*10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_2] nfs_rpc_process_request :DISP :DEBUG :After
svc_sendreply for umount before SVC_RELEASE 0x7fffd000b600 487 4*
*10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_2] nfs_rpc_process_request :DISP :DEBUG :After
svc_sendreply for umount after SVC_RELEASE 0x7fffd000b600 487 3*
*10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_2] nfs_rpc_decode_request :DISP :DEBUG :SVC_DECODE
on 0x7fffd000b600 fd 487 (::ffff:10.5.192.59:774 <http://10.5.192.59:774/>)
xid=457315812 returned XPRT_IDLE*
*10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_2] free_nfs_request :DISP :DEBUG
:free_nfs_request: 0x7fffd000b600 fd 487 xp_refcnt 3 rq_refcnt 0*
*10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_2] rpc :TIRPC :DEBUG :svc_rqst_xprt_task before
SVC_RELEASE 0x7fffd000b600 487 2*
*10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_2] rpc :TIRPC :DEBUG :svc_rqst_xprt_task after
SVC_RELEASE 0x7fffd000b600 487 1*
*10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_79] rpc :TIRPC :DEBUG :svc_vc_wait: 0x7fffd000b600
fd 487 recv closed (will set dead), before SVC_DESTROY refcnt 2*
*10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_79] rpc :TIRPC :DEBUG :svc_vc_wait: 0x7fffd000b600
fd 487 recv closed (will set dead), after SVC_DESTROY refcnt 1*
*10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_79] rpc :TIRPC :DEBUG :svc_rqst_xprt_task before
SVC_RELEASE 0x7fffd000b600 487 1*
*10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_79] rpc :TIRPC :DEBUG :svc_rqst_xprt_task after
SVC_RELEASE 0x7fffd000b600 487 0*
As we can see in the logs refcnt is going to zero for the connection on
which UMNT came.
But there are logs for other connections also, which we are not cleaning up
as there is no UMNT on them, but we are polling on them and they are
getting closed,
I just have single client and running same script, looks like client is
opening multiple connections and closing them on UMNT.
*10/12/2018 05:25:13 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_42] rpc :TIRPC :DEBUG :svc_vc_wait: 0x7fffd401b2c0
fd 1045 recv closed (will set dead), before SVC_DESTROY refcnt 3*
*10/12/2018 05:25:13 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_42] rpc :TIRPC :DEBUG :svc_vc_wait: 0x7fffd401b2c0
fd 1045 recv closed (will set dead), after SVC_DESTROY refcnt 2*
*10/12/2018 05:25:13 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_42] rpc :TIRPC :DEBUG :svc_rqst_xprt_task
before SVC_RELEASE 0x7fffd401b2c0 1045 2*
*10/12/2018 05:25:13 : epoch 5c0e3e5a : Gaurav-centos7-1 :
ganesha.nfsd-94024[svc_42] rpc :TIRPC :DEBUG :svc_rqst_xprt_task
after SVC_RELEASE 0x7fffd401b2c0 1045 1*
So this fix is not working for connection close without UMNT, there is
still fd leak.
One suggestion, should we have svc_rqst_clean_dead just
like svc_rqst_clean_idle?
svc_rqst_clean_dead will iterate through xprts and do SVC_RELEASE for xprts
with SVC_XPRT_FLAG_DESTROYING set and have xp_refcnt == 1.
Check this patch,
https://paste.fedoraproject.org/paste/1nIK~GC5Ril98nlc-DcpgQ
Regards,
Gaurav
On Mon, Dec 10, 2018 at 4:22 PM gaurav gangalwar <gaurav.gangalwar(a)gmail.com>
wrote:
> I tried with this fix, as suggested added SVC_DESTROY in UMNT call, added
> some logs for debugging,
> https://paste.fedoraproject.org/paste/MmpBT2vTwF8DMBvaLTu5rQ
>
> Issue remains same.
>
> *10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
> ganesha.nfsd-78524[svc_2] mnt_Umnt :NFS3 :DEBUG :REQUEST PROCESSING:
> Calling MNT_UMNT path /export*
>
> *10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
> ganesha.nfsd-78524[svc_2] nfs_rpc_process_request :DISP :DEBUG :After
> svc_sendreply for umount before SVC_DESTROY 0x7fff38024450 1045 4*
>
> *10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
> ganesha.nfsd-78524[svc_2] nfs_rpc_process_request :DISP :DEBUG :After
> svc_sendreply for umount after SVC_DESTROY 0x7fff38024450 1045 3*
>
> *10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
> ganesha.nfsd-78524[svc_2] nfs_rpc_decode_request :DISP :DEBUG :SVC_DECODE
> on 0x7fff38024450 fd 1045 (::ffff:10.5.192.59:911 <http://10.5.192.59:911>)
> xid=1123634942 returned XPRT_DESTROYED*
>
> *10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
> ganesha.nfsd-78524[svc_2] free_nfs_request :DISP :DEBUG :free_nfs_request:
> 0x7fff38024450 fd 1045 xp_refcnt 3 rq_refcnt 0*
>
> *10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
> ganesha.nfsd-78524[svc_2] rpc :TIRPC :DEBUG :svc_rqst_xprt_task before
> SVC_RELEASE 0x7fff38024450 1045 2*
>
> *10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
> ganesha.nfsd-78524[svc_2] rpc :TIRPC :DEBUG :svc_rqst_xprt_task after
> SVC_RELEASE 0x7fff38024450 1045 1*
>
> *10/12/2018 03:30:57 : epoch 5c0e234e : Gaurav-centos7-1 :
> ganesha.nfsd-78524[svc_4] rpc :TIRPC :DEBUG :Event on already destroyed
> xprt 0x7fff38024450 1045 1*
>
>
> As we can see in the log highlighted we are still left with one ref even
> after SVC_DESTROY in UMNT and all SVC_RELEASE.
>
>
> I tried with SVC_RELEASE instead of SVC_DESTROY in same patch, it
> worked at least for connection on which UMNT came, we are releasing the
> xprt for it.
>
>
> *10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_2] mnt_Umnt :NFS3 :DEBUG :REQUEST PROCESSING:
> Calling MNT_UMNT path /export*
>
> *10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_2] nfs_rpc_process_request :DISP :DEBUG :After
> svc_sendreply for umount before SVC_RELEASE 0x7fffd000b600 487 4*
>
> *10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_2] nfs_rpc_process_request :DISP :DEBUG :After
> svc_sendreply for umount after SVC_RELEASE 0x7fffd000b600 487 3*
>
> *10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_2] nfs_rpc_decode_request :DISP :DEBUG :SVC_DECODE
> on 0x7fffd000b600 fd 487 (::ffff:10.5.192.59:774 <http://10.5.192.59:774>)
> xid=457315812 returned XPRT_IDLE*
>
> *10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_2] free_nfs_request :DISP :DEBUG :free_nfs_request:
> 0x7fffd000b600 fd 487 xp_refcnt 3 rq_refcnt 0*
>
> *10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_2] rpc :TIRPC :DEBUG :svc_rqst_xprt_task before
> SVC_RELEASE 0x7fffd000b600 487 2*
>
> *10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_2] rpc :TIRPC :DEBUG :svc_rqst_xprt_task after
> SVC_RELEASE 0x7fffd000b600 487 1*
>
> *10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_79] rpc :TIRPC :DEBUG :svc_vc_wait: 0x7fffd000b600
> fd 487 recv closed (will set dead), before SVC_DESTROY refcnt 2*
>
> *10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_79] rpc :TIRPC :DEBUG :svc_vc_wait: 0x7fffd000b600
> fd 487 recv closed (will set dead), after SVC_DESTROY refcnt 1*
>
> *10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_79] rpc :TIRPC :DEBUG :svc_rqst_xprt_task before
> SVC_RELEASE 0x7fffd000b600 487 1*
>
> *10/12/2018 05:23:23 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_79] rpc :TIRPC :DEBUG :svc_rqst_xprt_task after
> SVC_RELEASE 0x7fffd000b600 487 0*
>
> As we can see in the logs refcnt is going to zero for the connection on
> which UMNT came.
> But there are logs for other connections also, which we are not cleaning
> up as there is no UMNT on them, but we are polling on them and they are
> getting closed,
> I just have single client and running same script, looks like client is
> opening multiple connections and closing them on UMNT.
>
> *10/12/2018 05:25:13 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_42] rpc :TIRPC :DEBUG :svc_vc_wait: 0x7fffd401b2c0
> fd 1045 recv closed (will set dead), before SVC_DESTROY refcnt 3*
>
> *10/12/2018 05:25:13 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_42] rpc :TIRPC :DEBUG :svc_vc_wait: 0x7fffd401b2c0
> fd 1045 recv closed (will set dead), after SVC_DESTROY refcnt 2*
>
> *10/12/2018 05:25:13 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_42] rpc :TIRPC :DEBUG :svc_rqst_xprt_task before
> SVC_RELEASE 0x7fffd401b2c0 1045 2*
> *10/12/2018 05:25:13 : epoch 5c0e3e5a : Gaurav-centos7-1 :
> ganesha.nfsd-94024[svc_42] rpc :TIRPC :DEBUG :svc_rqst_xprt_task after
> SVC_RELEASE 0x7fffd401b2c0 1045 1*
>
> So this fix is not working for connection close without UMNT, there is
> still fd leak.
> Attached log file.
>
> One suggestion, should we have svc_rqst_clean_dead just like
> svc_rqst_clean_idle?
> svc_rqst_clean_dead will iterate through xprts and do SVC_RELEASE for
> xprts with SVC_XPRT_FLAG_DESTROYING set and have xp_refcnt == 1.
> Regards,
> Gaurav
>
>
> On Thu, Dec 6, 2018 at 7:37 PM Matt Benjamin <mbenjami(a)redhat.com> wrote:
>
>> As the function naming (which partly predates ntirpc fork) and
>> comments clearly imply, the semantics of svc_clean_idle is to do
>> periodic processing of idle, not closed, connections. At some point
>> in the not too distant past, regular processing of closed connections
>> reliably triggered the conn_set_dead condition, hence caused
>> svc_destroy() to be called on the xprt handles.
>>
>> Matt
>> On Wed, Dec 5, 2018 at 3:11 PM William Allen Simpson
>> <william.allen.simpson(a)gmail.com> wrote:
>> >
>> > Wow, I really hate top posts. Very hard to comprehend your responses.
>> >
>> >
>> > On 12/5/18 12:28 AM, gaurav gangalwar wrote:
>> > > I waited for more that 14 hours. This is the script I ran.
>> > > for i in {1..300}; do echo $i; mount -t nfs -o vers=3,tcp
>> 10.15.196.92:/export /mnt1; umount /mnt1; done
>> > > It went out of ads at 169th iteration.
>> > > 169
>> > > mount.nfs: Connection timed out
>> > > umount: /mnt1: not mounted
>> > >
>> > I really don't understand. There are no constants in the current
>> V2.8-dev code base
>> > that add up to more than 14 hours, and no constant that would yield 169.
>> >
>> > In any case, this particular denial of service attack should be easy to
>> fix by
>> > adding SVC_DESTROY to the Ganesha umount code path(s). However,
>> because it seems
>> > rather unlikely this could happen in production, it's not currently a
>> high priority.
>> >
>> > Do you have a production environment or customer report where this
>> occurred?
>> >
>> > Would you like help writing the Ganesha patch?
>> >
>> > Are you with Nutanix? Or IBM?
>> >
>> >
>> > > After this I was not able to mount or do any operation. There was no
>> active mount on my client. So there was no activity from client side, so
>> does it mean it will never cleanup?
>> > >
>> > No, as I wrote,
>> > # If you stop doing anything and simply wait, that will be 8.24
>> hours
>> > # (1023 * 29 seconds).
>> >
>> > I've discussed this with DanG, and that ntirpc design logic from before
>> my time
>> > seems faulty. It does cleanup more frequently on a busy system, but is
>> very
>> > slow on an idle system (the most likely time to have an fd become idle).
>> >
>> > DanG suggested that a better approach would be to trigger cleanup based
>> upon a
>> > high-water-mark. The best approach would be to order the list of fds
>> by latest
>> > recv, and clean out the idle ones as soon as they expire -- instead of
>> running
>> > through the list of (tens of) thousands of fds. That shouldn't be too
>> hard,
>> > but we must be careful that we don't add new locking in the fast path.
>> >
>> > But this is an own-time project for me, and my primary interest is RDMA
>> and
>> > performance. So it may be some time before I've a chance to look at
>> it. Maybe
>> > over the holiday....
>> > _______________________________________________
>> > Devel mailing list -- devel(a)lists.nfs-ganesha.org
>> > To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
>>
>>
>>
>> --
>>
>> 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
>>
>
5 years, 4 months
Change in ffilz/nfs-ganesha[next]: NFSv4 detailed statistics via ganesha_stats
by Sachin Punadikar (GerritHub)
Sachin Punadikar has uploaded this change for review. ( https://review.gerrithub.io/437820
Change subject: NFSv4 detailed statistics via ganesha_stats
......................................................................
NFSv4 detailed statistics via ganesha_stats
Currently detailed stats are collected only for read & write
operation, but for performance analysis detailed reports are
required for all operations.
Provision made for counting and extracting NFSv4 detailed statistics.
By default the detailed stats counting is disabled. Over DBUS, via
ganesha_stats interface one can enable/disable/extract these
statistics.
Currently the NFSv4 stats are not categorized based on its minor
version. So here we get stats for all minor versions.
Change-Id: Id4b760500c9fd528d71946ba4f22a1f4437055ff
Signed-off-by: Sachin Punadikar <psachin(a)in.ibm.com>
---
M src/config_samples/config.txt
M src/doc/man/ganesha-core-config.rst
M src/include/gsh_config.h
M src/include/server_stats_private.h
M src/scripts/ganeshactl/Ganesha/glib_dbus_stats.py
M src/scripts/ganeshactl/ganesha_stats.py
M src/support/export_mgr.c
M src/support/nfs_read_conf.c
M src/support/server_stats.c
9 files changed, 271 insertions(+), 8 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/20/437820/1
--
To view, visit https://review.gerrithub.io/437820
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: Id4b760500c9fd528d71946ba4f22a1f4437055ff
Gerrit-Change-Number: 437820
Gerrit-PatchSet: 1
Gerrit-Owner: Sachin Punadikar <psachin(a)in.ibm.com>
5 years, 4 months
Nested netgroup support
by Sachin Punadikar
Hello,
Does Ganesha's internal caching do support nested netgroups ?
One customer is reporting that one client from nested netgroup is allowed
to access while another one from same nested group is not allowed.
Any hints on possible cause of such scenario ?
Is there any way by which one can purge the netgroup cache in Ganesha ?
--
with regards,
Sachin Punadikar
5 years, 4 months
Change in ffilz/nfs-ganesha[next]: rpm/selinux: fix %pre install and %postun uninstall of selinux policy
by Anonymous Coward (GerritHub)
kaleb(a)redhat.com has uploaded this change for review. ( https://review.gerrithub.io/437742
Change subject: rpm/selinux: fix %pre install and %postun uninstall of selinux policy
......................................................................
rpm/selinux: fix %pre install and %postun uninstall of selinux policy
As written the selinux %pre, %postun, etc., do not actually install
the policy. By deleting '-s ...' and taking the default behavior
then the %selinux_modules_install will actuall do `semodule -i ...`,
check if selinux is enabled, and run load_policy; and the reverse
for %postun.
Change-Id: I6c82169e214dfecf283a642e06b99de2a263846d
Signed-off-by: Kaleb S. KEITHLEY <kkeithle(a)redhat.com>
---
M src/nfs-ganesha.spec-in.cmake
1 file changed, 5 insertions(+), 8 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/42/437742/1
--
To view, visit https://review.gerrithub.io/437742
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: I6c82169e214dfecf283a642e06b99de2a263846d
Gerrit-Change-Number: 437742
Gerrit-PatchSet: 1
Gerrit-Owner: Anonymous Coward <kaleb(a)redhat.com>
5 years, 4 months
Change in ffilz/nfs-ganesha[next]: ganesha_status.py - fix missing parens
by Daniel Gryniewicz (GerritHub)
Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/437682
Change subject: ganesha_status.py - fix missing parens
......................................................................
ganesha_status.py - fix missing parens
Change-Id: If8e416abeddbda9fd9f6d401c5cf3df00110b82c
Signed-off-by: Daniel Gryniewicz <dang(a)redhat.com>
---
M src/scripts/ganeshactl/ganesha_stats.py
1 file changed, 1 insertion(+), 1 deletion(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/82/437682/1
--
To view, visit https://review.gerrithub.io/437682
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: If8e416abeddbda9fd9f6d401c5cf3df00110b82c
Gerrit-Change-Number: 437682
Gerrit-PatchSet: 1
Gerrit-Owner: Daniel Gryniewicz <dang(a)redhat.com>
5 years, 4 months
Change in ffilz/nfs-ganesha[next]: WIP - TEMP NTIRPC PULLUP
by Frank Filz (GerritHub)
Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/437471
Change subject: WIP - TEMP NTIRPC PULLUP
......................................................................
WIP - TEMP NTIRPC PULLUP
Change-Id: I0d25f08ad1487d1175d46e9759075af26acf0942
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
---
M .gitmodules
M src/libntirpc
2 files changed, 2 insertions(+), 2 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/71/437471/1
--
To view, visit https://review.gerrithub.io/437471
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: I0d25f08ad1487d1175d46e9759075af26acf0942
Gerrit-Change-Number: 437471
Gerrit-PatchSet: 1
Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com>
5 years, 4 months
liburcu
by William Allen Simpson
I hadn't updated my tree in some months, and was trying ntirpc/next today.
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LIBURCU
linked by target "ntirpc" in directory /home/bill/rdma/ntirpc/src
-- Configuring incomplete, errors occurred!
sudo dnf install liburcu-devel
enabling fedora-modular-debuginfo repository
enabling updates-modular-debuginfo repository
enabling updates-debuginfo repository
enabling fedora-debuginfo repository
Last metadata expiration check: 0:01:19 ago on Mon 17 Dec 2018 09:37:04 AM EST.
No match for argument: liburcu-devel
Error: Unable to find a match
Anybody know the current name? dnf search isn't coming up with anything.
5 years, 4 months
Change in ffilz/nfs-ganesha[next]: NFSv3 detailed statistics via ganesha_stats
by Sachin Punadikar (GerritHub)
Sachin Punadikar has uploaded this change for review. ( https://review.gerrithub.io/437455
Change subject: NFSv3 detailed statistics via ganesha_stats
......................................................................
NFSv3 detailed statistics via ganesha_stats
Currently detailed stats are collected only for read & write
operation, but for performance analysis detailed reports are
required for all operations.
Provision made for counting and extracting NFSv3 detailed statistics.
By default the detailed stats counting is disabled. Over DBUS, via
ganesha_stats interface one can enable/disable/extract these
statistics.
Change-Id: I0083f846ddf986b9b3ef4fac067677b79193a796
Signed-off-by: Sachin Punadikar <psachin(a)in.ibm.com>
---
M src/config_samples/config.txt
M src/doc/man/ganesha-core-config.rst
M src/include/gsh_config.h
M src/include/server_stats_private.h
M src/scripts/ganeshactl/Ganesha/glib_dbus_stats.py
M src/scripts/ganeshactl/ganesha_stats.py
M src/support/export_mgr.c
M src/support/nfs_read_conf.c
M src/support/server_stats.c
9 files changed, 300 insertions(+), 20 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/55/437455/1
--
To view, visit https://review.gerrithub.io/437455
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: I0083f846ddf986b9b3ef4fac067677b79193a796
Gerrit-Change-Number: 437455
Gerrit-PatchSet: 1
Gerrit-Owner: Sachin Punadikar <psachin(a)in.ibm.com>
5 years, 4 months
Change in ffilz/nfs-ganesha[next]: Add malloc trace and untrace dbus methods
by Malahal (GerritHub)
Malahal has uploaded this change for review. ( https://review.gerrithub.io/437421
Change subject: Add malloc trace and untrace dbus methods
......................................................................
Add malloc trace and untrace dbus methods
Enable and disable malloc traces using dbus.
The following dbus command would enable malloc traces to
/tmp/mtraces.out file which can be analysed using mtrace
command (from glibc-utils)
dbus-send --print-reply --system --dest=org.ganesha.nfsd
/org/ganesha/nfsd/admin org.ganesha.nfsd.admin.malloc_trace
string:/tmp/mtrace.out
The following dbus command would stop malloc traces:
dbus-send --print-reply --system --dest=org.ganesha.nfsd
/org/ganesha/nfsd/admin org.ganesha.nfsd.admin.malloc_untrace
Change-Id: I9e475be822e5a2a6ff26a48520a4d89cc072cbc6
Signed-off-by: Malahal Naineni <malahal(a)us.ibm.com>
---
M src/MainNFSD/nfs_admin_thread.c
1 file changed, 88 insertions(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/21/437421/1
--
To view, visit https://review.gerrithub.io/437421
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: I9e475be822e5a2a6ff26a48520a4d89cc072cbc6
Gerrit-Change-Number: 437421
Gerrit-PatchSet: 1
Gerrit-Owner: Malahal <malahal(a)gmail.com>
5 years, 4 months
Announce Push of V2.8-dev.9
by Frank Filz
Branch next
Tag:V2.8-dev.9
Release Highlights
* Set op_ctx for lock_avail and lock_grant
* Replaced a LogCrit() with LogEvent() in commonlib.c
* SAL: Allow READs under write delegation
* Added a script to convert knfs exports to ganesha.
* SAL: fix multiple state reference leaks
* Read/Write - Don't leak owners/states
* CEPH: do a getattr after creating a dir and applying extra attributes
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
687748e Frank S. Filz V2.8-dev.9
1c3eb0e Jeff Layton CEPH: do a getattr after creating a dir and applying
extra attributes
bcf30d8 Daniel Gryniewicz Read/Write - Don't leak owners/states
17d354b Fatih Acar SAL: fix multiple state reference leaks
5f3cedd Malahal Naineni Added a script to convert knfs exports to ganesha.
67d7a53 Soumya Koduri SAL: Allow READs under write delegation
266a005 Trishali Nayar Replaced a LogCrit() with LogEvent() in commonlib.c
c79c3e4 Sachin Punadikar Set op_ctx for lock_avail and lock_grant
5 years, 4 months
