glusterfs.git/libglusterfs/src/syncop.c, branch v3.4.1rc1

gfapi: link inodes in relevant entry FOPs

2013-06-08T21:51:04+00:00

Do not let inode linking to happen only in lookup(). While
that works, it is inefficient.

Change-Id: I51bbfb6255ec4324ab17ff00566375f49d120c06
BUG: 953694
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/5162
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

syncop: copy inode pointer in readdirplus

2013-06-08T21:50:48+00:00

Change-Id: I9ab2b8ac2da9fe13f56b8b08f715a0b603ece0cb
BUG: 953694
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/5161
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

gfapi: POSIX locking support

2013-06-08T21:49:10+00:00

Change-Id: I37d9e1fb4a715094876be6af3856c1b4cf398021
BUG: 953694
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/5155
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

syncop: synctask shouldn't yawn, it could miss a 'wake'

2013-05-23T14:24:42+00:00

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

Change-Id: I7731fd33ca0c925cc52f8d105275b44fc625a1e2
BUG: 948686
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/5071
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy

syncop: Remove task from syncbarrier's waitq before 'wake'

2013-05-21T13:03:40+00:00

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

Removing task from syncbarrier's waitq after wake could result in a
subsequent syncbarrier_wake, wake'ing up the already running task.  This
fix makes the removal from waitq and wake 'atomic'

The root cause and the fix are similar in spirit to what was observed
in synclock's waitq implementation.

Change-Id: I7dd9e6ad5945742bcda20eb5a06a9376bb18528e
BUG: 948686
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/5054
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

syncop: Update synctask state appropriately

2013-05-21T13:03:14+00:00

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

* Earlier, SYNCOP macro, the only consumer of synctask_yield, would set
the task->state to SYNCTASK_SUSPEND. Today, we have glusterd having its
own wrapper macros which don't set task's state. There is also the
syncbarrier and synclock framework, which also participate in a
synctask's scheduling (and need to keep a task's state up to date). It
only makes more sense to leave a synctask's state to the synctask
library, since its an internal affair.

* Need to 'yawn' before 'yield' to avoid re-running tasks to set
  task->woken appropriately.

Change-Id: Ic7a59e6ebcc46f03e53223ca237668d45a3cba40
BUG: 948686
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/5053
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

glusterd: Refresh glusterd-syncop fixes from master

2013-05-17T03:44:44+00:00

Following commits were cherry-picked from master,
044f8ce syncop: Remove task from synclock's waitq before 'wake'
cb6aeed glusterd: Give up big lock before performing any RPC
46572fe Revert "glusterd: Fix spurious wakeups in glusterd syncops"
5021e04 synctask: implement barriers around yield, not the other way
4843937 glusterd: Syncop callbks should take big lock too

Change-Id: I5ae71ab98f9a336dc9bbf0e7b2ec50a6ed42b0f5
BUG: 948686
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/4938
Reviewed-by: Amar Tumballi 
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati 
Reviewed-on: http://review.gluster.org/5021
Reviewed-by: Vijay Bellur

Fix uninitialized mutex usage in synctask_destroy

2013-05-04T07:32:22+00:00

synctask_new() initialize task->mutex is task->synccbk is NULL.
synctask_done() calls synctask_destroy() if task->synccbk is not NULL.
synctask_destroy() always destroys the mutex.

Fix that by checking for task->synccbk in synctask_destroy()

This is a backport of I50bb53bc6e2738dc0aa830adc4c1ea37b24ee2a0

BUG: 764655
Change-Id: I3d6292f05a986ae3ceee35161791348ce3771c12
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/4920
Reviewed-by: Kaleb KEITHLEY 
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

syncenv: be robust against spurious wake()s

2013-04-17T12:46:09+00:00

In the current implementation, when the callers of synctasks perform
a spurious wake() of a sleeping synctask (i.e, an extra wake() soon
after a wake() which already woke up a yielded synctask), there is
now a possibility of two sync threacs picking up the same synctask.
This can result in a crash. The fix is to change ->slept = 0|1 and
membership of synctask in runqueue atomically.

Today we dequeue a task from the runqueue in syncenv_task(), but
reset ->slept = 0 much later in synctask_switchto() in an unlocked
manner -- which is safe, when there are no spurious wake()s.

However, this opens a race window where, if a second wake() happens
after the dequeue, but before setting ->slept = 0, it results in
queueing the same synctask in the runqueue once again, and get
picked up by a different synctask.

This is has been diagnosed to be the crashes in the regression tests
of http://review.gluster.org/4784. However that patch still has a
spurious wake() [the trigger for this bug] which is yet to be fixed.

BUG: 948686
Change-Id: I51858e887cad2680e46fb973629f8465f4429363
Original-author: Anand Avati 
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/4833
Reviewed-by: Vijay Bellur 
Tested-by: Gluster Build System

synctask: introduce synclocks for co-operative locking

2013-04-17T08:53:20+00:00

This patch introduces a synclocks - co-operative locks for synctasks.
Synctasks yield themselves when a lock cannot be acquired at the time
of the lock call, and the unlocker will wake the yielded locker at
the time of unlock.

The implementation is safe in a multi-threaded syncenv framework.

It is also safe for sharing the lock between non-synctasks. i.e, the
same lock can be used for synchronization between a synctask and
a regular thread. In such a situation, waiting synctasks will yield
themselves while non-synctasks will sleep on a cond variable. The
unlocker (which could be either a synctask or a regular thread) will
wake up any type of lock waiter (synctask or regular).

Usage:

    Declaration and Initialization
    ------------------------------

    synclock_t lock;

    ret = synclock_init (&lock);
    if (ret) {
        /* lock could not be allocated */
    }

   Locking and non-blocking lock attempt
   -------------------------------------

   ret = synclock_trylock (&lock);
   if (ret && (errno == EBUSY)) {
      /* lock is held by someone else */
      return;
   }

   synclock_lock (&lock);
   {
      /* critical section */
   }
   synclock_unlock (&lock);

BUG: 763820
Change-Id: I23066f7b66b41d3d9fb2311fdaca333e98dd7442
Signed-off-by: Krishnan Parthasarathi 
Original-author: Anand Avati 
Reviewed-on: http://review.gluster.org/4830
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur