LU-9679 osc: simplify osc_extent_wait()

LU-9679 osc: simplify osc_extent_wait()

Taking a spinlock to check the current value of the state is
unnecessary.  The wake_up() and wait_event() calls have sufficient
barriers to ensure that the value will be seen and the wait will abort
properly.

In most cases, osc_extent_wait() is followed by osc_object_lock()
before any shared data is touched - in those cases there is no need
for osc_extent_wait() to wait for the spinlock to be released.

The one case where osc_object_lock() does not immediately follow is in
osc_cache_truncate_start().  The extra locking was introduced in a
patch which fixed a problem with truncation, so it is likely that this
is the call that was thought to be relevant.

In that case, following osc_extent_wait(), an extent that had been
detached from the per-object list (oe_link linkage) is worked on it
without any locking.

In this case the code is waiting for OES_TRUNC, so any changes that
happen after the osc_extent_state_set(ext, OES_TRUNC) and when the
lock is dropped, might not be seen by the woken code.  The only thing
changed is ->oe_trunc_pending, and the woken code doesn't look at
that.

The only remaining possible need for extra synchronization is if some
other value was changed before the wakeup and is needed after the
wait.  According to memory-barriers.txt, a barrier might be needed to
ensure that is visible.  Such a barrier is most clearly presented by
used smp_store_release() to set the state before wakeup, and
smp_load_acquire() to view it after waiting.

Also use a simple wake_up() instead of wake_up_all() - the latter is
only needed when exclusive waiting is being used.

Linux-Commit: 2a7e8a40cb11 ("lustre: osc: simplify osc_extent_wait()")

Signed-off-by: Mr NeilBrown <neilb@suse.com>
Change-Id: I0945902b55d598af263779787b9641a86e9476c3
Reviewed-on: https://review.whamcloud.com/37598
Tested-by: jenkins <devops@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Reviewed-by: Patrick Farrell <farr0186@gmail.com>
Reviewed-by: James Simmons <jsimmons@infradead.org>
Reviewed-by: Oleg Drokin <green@whamcloud.com>