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

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

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

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

client, rpc: make ping-timeout configurable for glusterfs clients

2015-08-13T05:05:57+00:00

Change-Id: Idd94adb0457aaffce7330f56f98cebafa2c4dae8
BUG: 1250810
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/11818
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: NetBSD Build System 
(cherry picked from commit 3403370ebeaf16567b79022c6ac48b2e0cd50db5)
Reviewed-on: http://review.gluster.org/11848

logging: client3_3_removexattr_cbk should not log expected ENODATA

2015-07-26T08:10:24+00:00

Commit 379dbbfd changed the log level of an expected error message from
GF_LOG_DEBUG to '0'. This causes the message to always get logged. It is
intended to log the warning when the xattr could not be removed (but
exists), removing a non-existing xattr is sufficient as debug.

Backported from:
> BUG: 1246736
> Change-Id: If11d15d699e8152cc32e0c0c1d65b587c5c48892
> Reviewed-on: http://review.gluster.org/11759
> Signed-off-by: Niels de Vos 

Change-Id: If11d15d699e8152cc32e0c0c1d65b587c5c48892
BUG: 1246728
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/11760
Tested-by: NetBSD Build System 
Reviewed-by: Joe Julian 
Tested-by: Joe Julian 
Tested-by: Gluster Build System

protocol/client : removing duplicate printing in gf_msg

2015-06-27T12:04:47+00:00

Since the 3rd and 5th argument of gf_msg framework
prints the error string in case of strerror(),
the 5th argument is removed.

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

Cherry picked from commit 4acd9d1bfc2be5179ddb611f61afaaeaa15be2cb
> Change-Id: Ib1794ea2d4cb5c46a39311f0afcfd7e494540506
> BUG: 1194640
> Signed-off-by: Manikandan Selvaganesh 
> Reviewed-on: http://review.gluster.org/11280
> Tested-by: NetBSD Build System 
> Reviewed-by: Raghavendra Bhat 
> Reviewed-by: Vijay Bellur 

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

protocol/client : porting log messages to new framework

2015-06-17T12:11:43+00:00

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

Cherry picked from 379dbbfd683d2b0e1704c098b1f020567328122c
> Change-Id: I9bf2ca08fef969e566a64475d0f7a16d37e66eeb
> BUG: 1194640
> Signed-off-by: Manikandan Selvaganesh 
> Reviewed-on: http://review.gluster.org/10042
> Tested-by: Gluster Build System 
> Reviewed-by: Raghavendra G 
> Tested-by: Raghavendra G 

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

logging: log "Stale filehandle" on the client as Debug

2015-06-14T06:35:58+00:00

There are valid use-cases where a "Stale filehandle" is expected. One of
these is deleting a file through NFS-Ganesha. When the "filename" is
deleted, Ganesha will stat the file-handle to update its attributes. The
file-handle would still be valid in the case where there are hardlinks.

There is no need to log "Stale filehandle" as Warning. It is perfectly
fine to have this logged as Debug.

Cherry picked from commit ec7d0c3de11cbee1470308dcc10ec9f02e7fdfff:
> Change-Id: Ib9006d95a5d1f7dd394bf5d5994ad70740ad4ab2
> BUG: 1228731
> Signed-off-by: Niels de Vos 
> Reviewed-on: http://review.gluster.org/11107
> Reviewed-by: Kaleb KEITHLEY 
> Tested-by: Gluster Build System 
> Reviewed-by: soumya k 
> Reviewed-by: jiffin tony Thottan 

Change-Id: Ib9006d95a5d1f7dd394bf5d5994ad70740ad4ab2
BUG: 1228729
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/11169
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur