glusterfs.git/xlators/nfs/server/src, branch v3.5.2

nfs: prevent assertion error with MOUNT over UDP

2014-07-10T07:15:18+00:00

The MOUNT service over UDP runs in a separate thread. This thread does
not have the correct *THIS xlator set. *THIS points to the global (base)
xlator structure, but GF_CALLOC() requires it to be the NFS-xlator so
that assertions can get validated correctly.

This is solved by passing the NFS-xlator to the pthread function, and
setting the *THIS pointer explicitly in the new thread.

It seems that on occasion (needs further investigation) MOUNT over UDP
does not unregister itself. There can also be issues when the kernel NLM
implementation has been registered at portmap/rpcbind, so adding some
unregister procedures in the cleanup of the test-cases.

Cherry picked from commit ec74ceedaa41047b88d270c00eeb071b73e19664:
> Change-Id: I3be5a420fc800bbcc14198d0b6faf4cf2c7300b1
> BUG: 1116503
> Signed-off-by: Niels de Vos 
> Reviewed-on: http://review.gluster.org/8241
> Reviewed-by: Santosh Pradhan 
> Tested-by: Gluster Build System 
> Reviewed-by: Vijay Bellur 

Change-Id: I3be5a420fc800bbcc14198d0b6faf4cf2c7300b1
BUG: 1116997
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/8258
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Santosh Pradhan

rpcsvc: Validate RPC procedure number before fetch

2014-07-08T10:36:18+00:00

While accessing the procedures of given RPC program in,
rpcsvc_get_program_vector_sizer(), It was not checking boundary
conditions which would cause buffer overflow and subsequently SEGV.

Make sure rpcsvc_actor_t arrays have numactors number of actors.

FIX:
Validate the RPC procedure number before fetching the actor.

Upstream main review: http://review.gluster.org/7726

BUG: 1096020

Change-Id: Iaf207ee976cb56fa9a554ec82c9eab36d3b289ed
Signed-off-by: Santosh Kumar Pradhan 
Reviewed-on: http://review.gluster.org/8228
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

gNFS: Support wildcard in RPC auth allow/reject

2014-07-02T11:28:21+00:00

RFE: Support wildcard in "nfs.rpc-auth-allow" and
"nfs.rpc-auth-reject". e.g.
  *.redhat.com
  192.168.1[1-5].*
  192.168.1[1-5].*, *.redhat.com, 192.168.21.9

  Along with wildcard, support for subnetwork or IP range e.g.
  192.168.10.23/24

The option will be validated for following categories:
1) Anonymous i.e. "*"
2) Wildcard pattern i.e. string containing any ('*', '?', '[')
3) IPv4 address
4) IPv6 address
5) FQDN
6) subnetwork or IPv4 range

Currently this does not support IPv6 subnetwork.

Cherry-picked from 00e247ee44067f2b3e7ca5f7e6dc2f7934c97181:
> Change-Id: Iac8caf5e490c8174d61111dad47fd547d4f67bf4
> BUG: 1086097
> Signed-off-by: Santosh Kumar Pradhan 
> Reviewed-on: http://review.gluster.org/7485
> Reviewed-by: Poornima G 
> Reviewed-by: Harshavardhana 
> Tested-by: Gluster Build System 
> Reviewed-by: Vijay Bellur 

Change-Id: I18ef0a914cd403c1f9e66d1b03ecd29465cbce95
BUG: 1115369
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/8223
Tested-by: Gluster Build System 
Reviewed-by: Santosh Pradhan

gNFS: Fix multi-homed m/c issue in NFS subdir auth

2014-07-02T07:53:18+00:00

NFS subdir authentication doesn't correctly handle multi-homed
(host with multiple NIC having multiple IP addr) OR multi-protocol
(IPv4 and IPv6) network addresses.

When user/admin sets HOSTNAME in gluster CLI for NFS subdir auth,
mnt3_verify_auth() routine does not iterate over all the resolved
n/w addrs returned by getaddrinfo() n/w API. Instead, it just tests
with the one returned first.

1. Iterate over all the n/w addrs (linked list) returned by getaddrinfo().
2. Move the n/w mask calculation part to mnt3_export_fill_hostspec()
   instead of doing it in mnt3_verify_auth() i.e. calculating for each
   mount request. It does not change for MOUNT req.
3. Integrate "subnet support code rpc-auth.addr..allow"
   and "NFS subdir auth code" to remove code duplication.

Cherry-picked from commit d3f0de90d0c5166e63f5764d2f21703fd29ce976:
> Change-Id: I26b0def52c22cda35ca11766afca3df5fd4360bf
> BUG: 1102293
> Signed-off-by: Santosh Kumar Pradhan 
> Reviewed-on: http://review.gluster.org/8048
> Reviewed-by: Rajesh Joseph 
> Tested-by: Gluster Build System 
> Reviewed-by: Niels de Vos 

Change-Id: Ie92a8ac602bec2cd77268acb7b23ad8ba3c52f5f
BUG: 1112980
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/8198
Tested-by: Gluster Build System 
Reviewed-by: Santosh Pradhan

gNFS: Make NFS DRC off by default

2014-06-10T09:37:13+00:00

DRC in NFS causes memory bloat and there are known memory corruptions.
It would be good to disable drc by default till the feature is stable.

Cherry picked from 4215d071cec4fc8a62ca4fd6212d83f931838829:
> Change-Id: I93db6ef5298672c56fb117370bb582a5e5550b17
> BUG: 1105524
> Original-patch-by: Santosh Kumar Pradhan 
> Signed-off-by: Niels de Vos 
> Reviewed-on: http://review.gluster.org/8004
> Tested-by: Gluster Build System 
> Reviewed-by: Krishnan Parthasarathi 
> Reviewed-by: Santosh Pradhan 
> Reviewed-by: Vijay Bellur 

Change-Id: I93db6ef5298672c56fb117370bb582a5e5550b17
BUG: 1105524
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/8013
Reviewed-by: Santosh Pradhan 
Tested-by: Gluster Build System

rpc: warn and truncate grouplist if RPC/AUTH can not hold everything

2014-05-22T13:02:21+00:00

The GlusterFS protocol currently uses AUTH_GLUSTERFS_V2 in the RPC/AUTH
header. This header contains the uid, gid and auxiliary groups of the
user/process that accesses the Gluster Volume.

The AUTH_GLUSTERFS_V2 structure allows up to 65535 auxiliary groups to
be passed on. Unfortunately, the RPC/AUTH header is limited to 400 bytes
by the RPC specification: http://tools.ietf.org/html/rfc5531#section-8.2

In order to not cause complete failures on the client-side when trying
to encode a AUTH_GLUSTERFS_V2 that would result in more than 400 bytes,
we can calculate the expected size of the other elements:

    1 | pid
    1 | uid
    1 | gid
    1 | groups_len
   XX | groups_val (GF_MAX_AUX_GROUPS=65535)
    1 | lk_owner_len
   YY | lk_owner_val (GF_MAX_LOCK_OWNER_LEN=1024)
  ----+-------------------------------------------
    5 | total xdr-units

  one XDR-unit is defined as BYTES_PER_XDR_UNIT = 4 bytes
  MAX_AUTH_BYTES = 400 is the maximum, this is 100 xdr-units.
  XX + YY can be 95 to fill the 100 xdr-units.

  Note that the on-wire protocol has tighter requirements than the
  internal structures. It is possible for xlators to use more groups and
  a bigger lk_owner than that can be sent by a GlusterFS-client.

This change prevents overflows when allocating the RPC/AUTH header. Two
new macros are introduced to calculate the number of groups that fit in
the RPC/AUTH header, when taking the size of the lk_owner in account. In
case the list of groups exceeds the maximum possible, only the first
groups are passed over the RPC/GlusterFS protocol to the bricks.
A warning is added to the logs, so that most system administrators will
get informed.

The reducing of the number of groups is not a new inventions. The
RPC/AUTH header (AUTH_SYS or AUTH_UNIX) that NFS uses has a limit of 16
groups. Most, if not all, NFS-clients will reduce any bigger number of
groups to 16. (nfs.server-aux-gids can be used to workaround the limit
of 16 groups, but the Gluster NFS-server will be limited to a maximum of
93 groups, or fewer in case the lk_owner structure contains more items.)

Cherry picked from commit 8235de189845986a535d676b1fd2c894b9c02e52:
> BUG: 1053579
> Signed-off-by: Niels de Vos 
> Reviewed-on: http://review.gluster.org/7202
> Tested-by: Gluster Build System 
> Reviewed-by: Harshavardhana 
> Reviewed-by: Santosh Pradhan 
> Reviewed-by: Vijay Bellur 

Change-Id: I8410e59d0fd246d601b54b961d3ae9cb5a858c10
BUG: 1096425
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/7829
Reviewed-by: Lalatendu Mohanty 
Tested-by: Gluster Build System

gNFS: Set default outstanding RPC limit to 16

2014-03-07T20:11:28+00:00

Backport of http://review.gluster.org/#/c/6696/

With 64, NFS server hangs with large I/O load (~ 64 threads writing
to NFS server). The test results from Ben England (Performance expert)
suggest to set it as 16 instead of 64.

Change-Id: Iaa9dda512904d2e359d8122a05e5bf65f99a7e78
BUG: 1073441
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/7200
Tested-by: Gluster Build System 
Reviewed-by: Santosh Pradhan

rpc,glusterd: Use rpc_clnt notifyfn to cleanup mydata

2013-12-23T14:58:18+00:00

        Backport of http://review.gluster.org/5512

rpc:
- On a RPC_TRANSPORT_CLEANUP event, rpc_clnt_notify calls the registered
  notifyfn with a RPC_CLNT_DESTROY event. The notifyfn should properly
  cleanup the saved mydata on this event.
- Break the reconnect chain when an rpc client is disabled. This will
  prevent new disconnect events which can lead to crashes.

glusterd:
- Added support for RPC_CLNT_DESTROY in glusterd_brick_rpc_notify
- Use a common glusterd_rpc_clnt_unref() function throught glusterd in
  place of rpc_clnt_unref(). This function correctly gives up the
  big-lock before performing the unref.

Change-Id: I93230441c5089039643fc9f5632477ef1b695348
BUG: 962619
Signed-off-by: Kaushal M 
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/6566
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

gNFS: Client cache invalidation with bad fsid

2013-12-17T18:26:10+00:00

1. Problem:
Couple of issues are seen when NFS-ACL is turned ON. i.e.
i) NFS directory access is too slow, impacting customer workflows
   with ACL
ii)dbench fails with 100 directories.

2. Root cause: Frequent cache invalidation in the client side when ACL
is turned ON with NFS because NFS server getacl() code returns the
wrong fsid to the client.

3. This attr-cache invlaidation triggers the frequent LOOKUP ops for
each file instead of relying on the readdir or readdirp data. As
a result performance gets impacted.

4. In case of dbench workload, the problem is more severe. e.g.

Client side rpcdebug output:
===========================

Dec 16 10:16:53 santosh-3 kernel: NFS:
         nfs_update_inode(0:1b/12061953567282551806 ct=2 info=0x7e7f)
Dec 16 10:16:53 santosh-3 kernel: NFS:
         nfs_fhget(0:1b/12061953567282551806 ct=2)
Dec 16 10:16:53 santosh-3 kernel: <-- nfs_xdev_get_sb() = -116 [splat]
Dec 16 10:16:53 santosh-3 kernel: nfs_do_submount: done
Dec 16 10:16:53 santosh-3 kernel: <-- nfs_do_submount() =
ffffffffffffff8c
Dec 16 10:16:53 santosh-3 kernel: <-- nfs_follow_mountpoint() =
ffffffffffffff8c
Dec 16 10:16:53 santosh-3 kernel: NFS: dentry_delete(clients/client77,
20008)

As per Jeff Layton, This occurs when the client detects that the fsid on
a filehandle is different from its parent. At that point, it tries to
do a new submount of the new filesystem onto the correct point. It means
client got a superblock reference for the new fs and is now looking to
set up the root of the mount. It calls nfs_get_root to do that, which
basically takes the superblock and a filehandle and returns a dentry.
The problem here is that the dentry->d_inode you're getting back looks
wrong. It's not a directory as expected -- it's something else. So the
client gives up and tosses back an ESTALE.

Which clearly says that, In getacl() code while it does the stat() call
to get the attrs, it forgets to populate the deviceid or fsid before
going ahead and does getxattr().

FIX:
1. Fill the deviceid in iatt.
2. Do bit more clean up for the confusing part of the code.

NB: Many many thanks to Niels de Vos and Jeff Layton for their
help to debug the issue.

Change-Id: I44d8d2fa3ec7fb33a67dfdd4bbe2c45cdf67db8c
BUG: 1043737
Signed-off-by: Santosh Kumar Pradhan 
Reviewed-on: http://review.gluster.org/6526
Reviewed-by: Niels de Vos 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

gNFS: Inconsistent behaviour of setfacl/getfacl

2013-12-05T18:36:11+00:00

The permissions returned by NFS ACL are wrong, which are rejected
by NFS client as "Invalid argument". Refactor the NFS ACL code
to return the proper permissions which would match with the
requested permissions.

Upstream master review: http://review.gluster.org/6368

Change-Id: Ieb079b5da98b061291b44655e18a1dee92a8e463
BUG: 1035218
Signed-off-by: Santosh Kumar Pradhan 
Reviewed-on: http://review.gluster.org/6418
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur