glusterfs-afrv1.git/rpc/rpc-lib/src, branch master

rpc: transport may be destroyed while rpc isn't

2014-03-06T05:26:59+00:00

rpc_clnt object is destroyed after the corresponding transport object is
destroyed. But rpc_clnt_reconnect, a timer driven function, refers to
the transport object beyond its 'life'. Instead, using the embedded
connection object prevents use after free problem wrt transport object.

Also, access transport object under conn->lock.

Change-Id: Iae28e8a657d02689963c510114ad7cb7e6764e62
BUG: 962619
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/6751
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

rpc: Fix a crash due to NULL dereference

2014-02-16T18:50:55+00:00

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

protocol/server: do not do root-squashing for trusted clients

2014-02-11T07:32:05+00:00

* As of now clients mounting within the storage pool using that machine's
  ip/hostname are trusted clients (i.e clients local to the glusterd).

* Be careful when the request itself comes in as nfsnobody (ex: posix tests).
  So move the squashing part to protocol/server when it creates a new frame
  for the request, instead of auth part of rpc layer.

* For nfs servers do root-squashing without checking if it is trusted client,
  as all the nfs servers would be running within the storage pool, hence will
  be trusted clients for the bricks.

* Provide one more option for mounting which actually says root-squash
  should/should not happen. This value is given priority only for the trusted
  clients. For non trusted clients, the volume option takes the priority. But
  for trusted clients if root-squash should not happen, then they have to be
  mounted with root-squash=no option. (This is done because by default
  blocking root-squashing for the trusted clients will cause problems for smb
  and UFO clients for which the requests have to be squashed if the option is
  enabled).

* For geo-replication and defrag clients do not do root-squashing.

* Introduce a new option in open-behind for doing read after successful open.

Change-Id: I8a8359840313dffc34824f3ea80a9c48375067f0
BUG: 954057
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/4863
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

glusterd: Volume locks and transaction specific opinfos

2014-02-11T07:25:40+00:00

With this patch we are replacing the existing cluster-wide
lock taken on glusterds across the cluster, with volume locks
which are also taken on glusterds across the cluster, but are
volume specific. So with the volume locks we are able to perform
more than one gluster operation at the same time, as long as the
operations are being performed on different volumes.

We maintain a global list of volume-locks (using a dict for a list)
where the key is the volume name, and which saves the uuid of the
originator glusterd. These locks are held and released per volume
transaction.

In order to acheive multiple gluster operations occuring at the
same time, we also separate opinfos in the op-state-machine, as a
part of this patch. To do so, we generate a unique transaction-id
(uuid) per gluster transaction. An opinfo is then associated with
this transaction id, which is used throughout the transaction. We
maintain a run-time global list(using a dict) of transaction-ids,
and their respective opinfos to achieve this.

Upstream Feature Page: http://www.gluster.org/community/documentation/index.php/Features/glusterd-volume-locks

Change-Id: Iaad505a854bac8de8f83beec0357eb6cde3f7ea8
BUG: 1011470
Signed-off-by: Avra Sengupta 
Reviewed-on: http://review.gluster.org/5994
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

rpc: use GF_FREE when a string is gf_strdup'd.

2014-01-22T14:09:46+00:00

Change-Id: I522c30a600e712be9cc09393104e228e4d8e13f5
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/6752
Reviewed-by: Vijay Bellur 
Tested-by: Gluster Build System

build: Start using library versioning for various libraries

2014-01-18T16:51:14+00:00

According to libtool three individual numbers stand for
CURRENT:REVISION:AGE, or C:R:A for short. The libtool
script typically tacks these three numbers onto the end
of the name of the .so file it creates. The formula for
calculating the file numbers on Linux and Solaris is

   /path/to/library/.(C - A).(A).(R)

As you release new versions of your library, you will
update the library's C:R:A. Although the rules for changing
these version numbers can quickly become confusing, a few
simple tips should help keep you on track. The libtool
documentation goes into greater depth.

In essence, every time you make a change to the library and
release it, the C:R:A should change. A new library should start
with 0:0:0. Each time you change the public interface
(i.e., your installed header files), you should increment the
CURRENT number. This is called your interface number. The main
use of this interface number is to tag successive revisions
of your API.

The AGE number is how many consecutive versions of the API the
current implementation supports. Thus if the CURRENT library
API is the sixth published version of the interface and it is
also binary compatible with the fourth and fifth versions
(i.e., the last two), the C:R:A might be 6:0:2. When you break
binary compatibility, you need to set AGE to 0 and of course
increment CURRENT.

The REVISION marks a change in the source code of the library
that doesn't affect the interface-for example, a minor bug fix.
Anytime you increment CURRENT, you should set REVISION back to 0.

Change-Id: Id72e74c1642c804fea6f93ec109135c7c16f1810
BUG: 862082
Signed-off-by: Harshavardhana 
Reviewed-on: http://review.gluster.org/5645
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos 
Reviewed-by: Vijay Bellur

gNFS: Set default outstanding RPC limit to 16

2014-01-15T21:47:32+00:00

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: I418ff5ba0a3e9fdb14f395b8736438ee1bbd95f4
BUG: 1008301
Signed-off-by: Santosh Kumar Pradhan 
Reviewed-on: http://review.gluster.org/6696
Tested-by: Gluster Build System 
Reviewed-by: ben england

rpc/auth: Avoid NULL dereference in rpcsvc_auth_request_init()

2014-01-09T04:42:15+00:00

Code section is bogus!
------------------------------------------
370:       if (!auth->authops->request_init)
371:              ret = auth->authops->request_init (req, auth->authprivate);
------------------------------------------

Seems to have been never been used historically since
logically above code has never been true to actually execute
"authops->request_init() --> auth_glusterfs_{v2,}_request_init()"

On top of that under "rpcsvc_request_init()"
verf.flavour and verf.datalen are initialized from what is
provided through 'callmsg'.
------------------------------------------
        req->verf.flavour = rpc_call_verf_flavour (callmsg);
        req->verf.datalen = rpc_call_verf_len (callmsg);

        /* AUTH */
        rpcsvc_auth_request_init (req);
        return req;
------------------------------------------

So the code in 'auth_glusterfs_{v2,}_request_init()'
performing this operation will over-write the original
flavour and datalen.

------------------------------------------
      if (!req)
                return -1;
        memset (req->verf.authdata, 0, GF_MAX_AUTH_BYTES);
        req->verf.datalen = 0;
        req->verf.flavour = AUTH_NULL;
------------------------------------------

Refactoring the whole code into a more understandable version
and also avoiding a potential NULL dereference

Change-Id: I1a430fcb4d26de8de219bd0cb3c46c141649d47d
BUG: 1049735
Signed-off-by: Harshavardhana 
Reviewed-on: http://review.gluster.org/6591
Reviewed-by: Santosh Pradhan 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

gNFS: Small memory leak in rpcsvc_drc_init()

2014-01-04T06:17:35+00:00

1. The routine rpcsvc_drc_init() is only used while initialization of
NFS xlator. It should just check for nfs.drc option and init DRC feature
accordingly. If it's set to OFF, then rpcsvc_drc_init() allocates memory
for svc.drc and set ret value to 0 and goes to out: block where drc is
leaked.

2. rpcsvc_drc_init() should just allocate svc.drc and init it. Here
svc.drc can never be valid.

3. If svc.drc gets init'd here, no point of checking for drc type here.

Change-Id: I4085771cdb8c9c15d1b9c548b77929a37f27c124
BUG: 1047902
Signed-off-by: Santosh Kumar Pradhan 
Reviewed-on: http://review.gluster.org/6628
Reviewed-by: Niels de Vos 
Reviewed-by: Rajesh Joseph 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

gNFS: Possible SEGV crash in NFS while DRC is OFF

2014-01-04T06:15:01+00:00

In rpcsvc_submit_generic(), FILE: rpc/rpc-lib/src/rpcsvc.c, while caching
the reply (DRC), the code does not check if DRC is ON and goes ahead
assuming DRC is on and try to take a LOCK on drc.

FIX: Put a check on svc->drc by rpcsvc_need_drc().

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