glusterfs.git/xlators/protocol, branch v3.7.7

protocol/server: Race between server_reconfigure and server_setvolume

2016-01-26T06:28:17+00:00

During server_reconfigure we authenticate each connected clients
against the current options. To do this authentication we store
previous values in a dictionary during the connection establishment
phase (server_setvolume). If the authentication fails during
reconfigure then we will disconnect the transport.

Here it introduce a race between server_setvolume and reconfugure.
If a reconfigure called before doing a setvolume, the transport
will be disconnected

Backport of>
>Change-Id: Icce2c28a171481327a06efd3901f8a5ee67b05ab
>BUG: 1300564
>Signed-off-by: Mohammed Rafi KC 
>Reviewed-on: http://review.gluster.org/13271
>Smoke: Gluster Build System 
>Reviewed-by: Raghavendra G 
>CentOS-regression: Gluster Build System 
>Reviewed-by: Raghavendra Talur 
>NetBSD-regression: NetBSD Build System 

(cherry picked from commit 16f6579cb3e1214b1386fb530b8e16c8cbfdef33)

Change-Id: I8ab7ad4bd5d2d70bcdae7bcbc233930bcfbeb411
BUG: 1300978
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/13280
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Raghavendra G

upcall: free the xdr* allocations

2016-01-24T17:13:08+00:00

Free the xdr string allocations after decoding the upcall
cache_invalidation request.

This is backport of the below fix
   - http://review.gluster.org/13232

Change-Id: I0ffc64f587d6c8566cba76cf08148f937a735926
BUG: 1300924
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/13232
Reviewed-by: Niels de Vos 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-on: http://review.gluster.org/13277
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

protocol/client: prevent use-after-free of frame->root

2015-12-03T00:03:02+00:00

A regression failure generated a coredump on the glusterfs-client side:

  (gdb) f 0
  #0  0x00007fba6cd76432 in client_submit_request (this=0x7fba68006fc0,
                  req=0x7fba6579aa70, frame=0x7fba5c0058cc,
                  prog=0x7fba6cfb53c0 , procnum=41,
                  cbkfn=0x7fba6cd9206d ,
                  iobref=0x0, rsphdr=0x0, rsphdr_count=0,
                  rsp_payload=0x0, rsp_payload_count=0, rsp_iobref=0x0,
                  xdrproc=0x7fba79801075 ) at
  /home/jenkins/root/workspace/rackspace-regression-2GB-triggered/xlators/protocol/client/src/client.c:324
  324                   frame->root->ngrps = ngroups;
  (gdb) l
  319                   gf_msg_debug (this->name, 0, "rpc_clnt_submit failed");
  320           }
  321
  322           if (!conf->send_gids) {
  323                   /* restore previous values */
  324                   frame->root->ngrps = ngroups;
  325                   if (ngroups <= SMALL_GROUP_COUNT)
  326                           frame->root->groups_small[0] = gid;
  327           }
  328
  (gdb) p *frame->root
  Cannot access memory at address 0x64185df000000000

After looking at this in more detail, the flow is like this:

  client_submit_request()
    |
    '- rpc_clnt_submit() // on line 314
         |
         '- cbkfn() // = client3_3_release_cbk
              |
              :- STACK_DESTROY (frame->root);
         .----'
    .----'
    |
    :- frame->root->ngrps = ngroups; // on line 324
    '

So, there is a use-after-free, and it is not needed to restore the
previous groups in frame->root.

Cherry picked from commit dc3aa7524e4974f9d02465e2e5dd6ed9b6d319e1:
> Change-Id: I9e7d712183692ed92cfc2f75cd3c2781a9db20e2
> BUG: 1281285 (was incorrect in original patch)
> Signed-off-by: Niels de Vos 
> Reviewed-on: http://review.gluster.org/12575
> Reviewed-by: Dan Lambright 
> Tested-by: NetBSD Build System 
> Reviewed-by: Jeff Darcy 

Change-Id: I9e7d712183692ed92cfc2f75cd3c2781a9db20e2
BUG: 1283138
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/12639
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Dan Lambright 
Reviewed-by: Vijay Bellur

geo-rep: Don't log geo-rep safe errors in mount logs

2015-11-23T19:10:41+00:00

ENOENT is a safe error for geo-replication in case of
rm -rf. RMDIR is recorded in changelog of each brick,
geo-rep processes all changelogs among which one will
succeed and rest will get ENOENT which can be ignored.
Similarly ENOENT can also be ignored in case of all
unlink operation during changelog replay that can
happen when worker goes down and comes back.

Change-Id: I6756f8f4c3fce7a159751a2bfce891ff16ad31a4
BUG: 1283473
Signed-off-by: Kotresh HR 
Reviewed-on: http://review.gluster.org/11833
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Aravinda VK 
Reviewed-by: Milind Changire 
Reviewed-by: Saravanakumar Arumugam 
Reviewed-by: Venky Shankar 
 (cherry picked from commit a52fd2cb7fa3aaff74461f58f32f4ff0b8e0904d)
Reviewed-on: http://review.gluster.org/12651
Reviewed-by: Vijay Bellur

server/protocol: option for dynamic authorization of client permissions

2015-10-13T16:05:37+00:00

problem:
assuming gluster volume is already mounted (for gfapi: say client transport
connection has already established), now if somebody change the volume
permissions say *.allow | *.reject for a client, gluster should allow/terminate
the client connection based on the fresh set of volume options immediately,
but in existing scenario neither we have any option to set this behaviour nor
we take any action until and unless we remount the volume manually

solution:
Introduce 'dynamic-auth' option (default: on).
If 'dynamic-auth' is 'on' gluster will perform dynamic authentication to
allow/terminate client transport connection immediately in response to
*.allow | *.reject volume set options, thus if volume permissions have changed
for a particular client (say client is added to auth.reject list), his
transport connection to gluster volume will be terminated immediately.

Backport of:
> Change-Id: I6243a6db41bf1e0babbf050a8e4f8620732e00d8
> BUG: 1245380
> Signed-off-by: Prasanna Kumar Kalever 
> Reviewed-on: http://review.gluster.org/12229
> Tested-by: NetBSD Build System 
> Reviewed-by: Raghavendra G 
> (cherry picked from commit 84e90b756566bc211535a8627ed16d4231110ade)

Change-Id: If7e5c9be912412ea388391ef406ee2c8bedb26b8
BUG: 1271065 
Signed-off-by: Prasanna Kumar Kalever 
Reviewed-on: http://review.gluster.org/12343
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G

protocol/client: give preference to loc->gfid over inode->gfid

2015-10-13T11:26:35+00:00

Backport of review.gluster.org/#/c/12233/

There are xlators which perform fops even before inode gets linked. Because of this loc.gfid is preferred at the time of inodelk/entrylk but by the time unlock can happen, inode could be linked with a different gfid than the one in loc.gfid (because of the way dht was giving preference) Due to this unlock goes on a different inode than the one we sent inodelk on, which leads to hang.

Credits to Pranith for the fix.

Change-Id: I7d162d44852ba876f35aa1bb83e4afdb184d85b9
BUG: 1266836
Signed-off-by: Ravishankar N 
Reviewed-on: http://review.gluster.org/12234
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri

protocol/server : porting missing gf_log's to gf_msg

2015-08-31T09:45:09+00:00

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

Cherry-picked form commit a26dbb38acdb2ec5fe16068caee189709faae76e
> Change-Id: I8818931fafea3c013551a5de23a9f77c81164841
> BUG: 1252808
> Signed-off-by: Manikandan Selvaganesh 
> Reviewed-on: http://review.gluster.org/11895
> Tested-by: NetBSD Build System 
> Reviewed-by: Raghavendra G 

Change-Id: I8818931fafea3c013551a5de23a9f77c81164841
BUG: 1257193
Signed-off-by: Manikandan Selvaganesh 
Reviewed-on: http://review.gluster.org/12018
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G

protocol/server: forget the inodes which got ENOENT in lookup

2015-08-21T11:48:48+00:00

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

If a looked up object is removed from the backend, then upon getting a
revalidated lookup on that object ENOENT error is received. protocol/server
xlator handles it by removing dentry upon which ENOENT is received. But the
inode associated with it still remains in the inode table, and whoever does
nameless lookup on the gfid of that object will be able to do it successfully
despite the object being not present.

For handling this issue, upon getting ENOENT on a looked up entry in revalidate
lookups, protocol/server should forget the inode as well.

Though removing files directly from the backend is not allowed, in case of
objects corrupted due to bitrot and marked as bad by scrubber, objects are
removed directly from the backend in case of replicate volumes, so that the
object is healed from the good copy. For handling this, the inode of the bad
object removed from the backend should be forgotten. Otherwise, the inode which
knows the object it represents is bad, does not allow read/write operations
happening as part of self-heal.

Change-Id: I268eeaf37969458687425187be6622347a6cc1f1
BUG: 1255604
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11973
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G

rpc: add owner xlator argument to rpc_clnt_new

2015-08-14T10:10:47+00:00

The @owner argument tells RPC layer the xlator that owns
the connection and to which xlator THIS needs be set during
network notifications like CONNECT and DISCONNECT.

Code paths that originate from the head of a (volume) graph and use
STACK_WIND ensure that the RPC local endpoint has the right xlator saved
in the frame of the call (callback pair). This guarantees that the
callback is executed in the right xlator context.

The client handshake process which includes fetching of brick ports from
glusterd, setting lk-version on the brick for the session, don't have
the correct xlator set in their frames. The problem lies with RPC
notifications. It doesn't have the provision to set THIS with the xlator
that is registered with the corresponding RPC programs. e.g,
RPC_CLNT_CONNECT event received by protocol/client doesn't have THIS set
to its xlator. This implies, call(-callbacks) originating from this
thread don't have the right xlator set too.

The fix would be to save the xlator registered with the RPC connection
during rpc_clnt_new. e.g, protocol/client's xlator would be saved with
the RPC connection that it 'owns'. RPC notifications such as CONNECT,
DISCONNECT, etc inherit THIS from the RPC connection's xlator.

Change-Id: I9dea2c35378c511d800ef58f7fa2ea5552f2c409
BUG: 1253212
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/11436
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G 
(cherry picked from commit f7668938cd7745d024f3d2884e04cd744d0a69ab)
Reviewed-on: http://review.gluster.org/11908
Reviewed-by: Pranith Kumar Karampuri

tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created

2015-08-14T08:12:41+00:00

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

This test sets the lru limit of the inode table to 1 and checks if inode forgets
and resolve cause any problem with bit-rot xattrs (especially bad-file xattr).

Change-Id: I3a19f90384c980368152bb723e7263eab2bed6bd
BUG: 1252348
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11881
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Venky Shankar