glusterfs.git/xlators/protocol, branch release-3.5

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

2015-12-12T10:01:34+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: 1283691
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/12666
Tested-by: Gluster Build System

protocol: Log ENODATA & ENOATTR logs at DEBUG loglevel in removexattr_cbk.

2015-02-25T08:55:24+00:00

Prevents messages of the following type from being seen by default in the log files:

[2014-09-19 07:57:39.877806] W
[client-rpc-fops.c:1232:client3_3_removexattr_cbk] 0--client-0:
remote operation failed: No data available
[2014-09-19 07:57:39.877963] W
[client-rpc-fops.c:1232:client3_3_removexattr_cbk] 0--client-1:
remote operation failed: No data available

Change-Id: I3b1a121b0fc272eb772547275bb8085ed19db5a1
BUG: 1192832
Signed-off-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8781
Reviewed-by: Niels de Vos 
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-on: http://review.gluster.org/9655

logs: Do selective logging for errnos

2014-10-22T07:32:40+00:00

        Backport of http://review.gluster.org/8918
                    http://review.gluster.org/8955

Problem:
Just after replace-brick the mount logs are filled with ENOENT/ESTALE
warning logs because the file is yet to be self-healed now that the
brick is new.

Fix:
Do conditional logging for the logs. ENOENT/ESTALE will be logged at
lower log level. Only when debug logs are enabled, these logs will
be written to the logfile.

BUG: 1155073
Change-Id: Icf06f2fc4f2f91e199de24a88bcb0ce9b8955ebd
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8960
Reviewed-by: Krutika Dhananjay 
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

protocol/client: change log level for lookup

2014-10-21T15:41:25+00:00

Problem:
On 3.5 branch, http://review.gluster.org/8294 causes the server to return ENOENT
(as opposed to ESTALE in master branch) if file does not exist. When AFR does
entry self-heals (either from the mount or shd or by the `heal info` command), it
does a gfid-lookup with loc.name == NULL, causing the corresponding log file to be
flooded with messages like this:

[2014-10-15 11:12:57.405428] W [client-rpc-fops.c:2761:client3_3_lookup_cbk]
0-testvol-client-1: remote operation failed: No such file or directory. Path:

(760b4427-2fb9-4a67-9f55-e8e8d78e452f)

Fix:
Change log level for ENOENT and ESTALE errors to DEBUG

Change-Id: Ideb88d9cb609d077e02efe703cd28155985d7513
BUG: 1153904
Signed-off-by: Ravishankar N 
Reviewed-on: http://review.gluster.org/8937
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: Niels de Vos

client_t: Fix memory leaks

2014-07-14T09:38:19+00:00

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

- Assign frame->root->client so that gf_client_unref happens
  in server_connection_cleanup_flush_cbk
- Avoid taking extra ref in gf_client_get

TODO:
The whole reason why there are two types of refs
bind, ref-count is to avoid lock inside lock which
is not the case now. I will be sending one more patch
which will accomplish that as well as changing the
tablearray to list

BUG: 1116672
Change-Id: Ica87b9cbf02cae34c10789cfb56d1ccdc393cbf0
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8289
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

protocol/server: '/s/ESTALE/ENOENT' only in lookup path

2014-07-14T09:22:14+00:00

Problem:
[1] modified the server resolver code to send ENOENT instead of
ESTALE to older clients for all FOPS. This caused dht_mkdir
to fail under certain conditions (see bug description).

Fix:
Since [1] is needed by AFR only in its lookup path, reverted the changes
introduced by [1]  in resolve_entry_simple () an resolve_inode_simple () and
made the change instead in server_lookup_resume().

[1] http://review.gluster.org/#/c/8080

Change-Id: Idb2de25839fe712550486f2263a60c0531530d8f
BUG: 1118574
Signed-off-by: Ravishankar N 
Reviewed-on: http://review.gluster.org/8294
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Reviewed-by: Niels de Vos

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

protocol/client: conn-id should be unique when lk-heal is off

2014-06-27T08:42:03+00:00

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

Problem:
It was observed that in some cases client disconnects
and re-connects before server xlator could detect that a
disconnect happened. So it still uses previous fdtable and ltable.
But it can so happen that in between disconnect and re-connect
an 'unlock' fop may fail because the fds are marked 'bad' in client
xlator upon disconnect. Due to this stale locks remain on the brick
which lead to hangs/self-heals not happening etc.

For the exact bug RCA please look at
https://bugzilla.redhat.com/show_bug.cgi?id=1049932#c0

Fix:
When lk-heal is not enabled make sure connection-id is different for
every setvolume. This will make sure that a previous connection's
resources are not re-used in server xlator.

BUG: 1113894
Change-Id: I5090f832730e4072c4b6b6758e64f757b911bd49
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8187
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

cluster/afr: Fix resolution issues with afr

2014-06-24T16:26:13+00:00

Problem with afr:
Lets say there is a directory hierarchy a/b/c/d on the mount and the
user is cd'ed into the directory. Bring down one of the bricks of replica and
remove all directories/files to simulate disk replacement on that brick. Now
this brick is brought back up. Creates on the cd'ed directory fail with ESTALE.
Basically before sending a create of 'f' inside 'd', fuse sends a lookup to
make sure the file is not present.  On one of the bricks  'd' is present and
'f' is not so it sends ENOENT as response. On the new brick 'd' itself is not
present. So it sends ESTALE. In afr ESTALE is considered to be special errno on
witnessing which lookup has to fail. And ESTALE is given more priority than
ENOENT. Due to these reasons lookup fails with ESTALE rather than ENOENT. Since
lookup didn't fail with ENOENT, 'create' can't be issued so the command is
failed with ESTALE.

Solution:
Afr needs to consider ESTALE errno normally and ENOENT needs to
be given more priority so that operations like create can proceed even when
only one of the brick is up and running. Whenever client xlator identifies
that gfid-changed, it sets that information in lookup xdata. Afr uses this
information to fail the lookup with ESTALE so that top xlator can send
fresh lookup.

Change-Id: Ie8e0e327542fd644409eb5dadf451679afa1c0e5
BUG: 1112348
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8154
Tested-by: Justin Clift 
Tested-by: Gluster Build System 
Reviewed-by: Ravishankar N 
Reviewed-by: Niels de Vos

protocol/client,server: Suppress ESTALE logs

2014-06-24T07:27:12+00:00

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

Change-Id: I5372b45243ad9a68a7c20290e9f5fd5ca9ab28f2
BUG: 1095256
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8087
Reviewed-by: Atin Mukherjee 
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos