Zach Brown d71f7a24ec Don't check meta seq before locking ...

The block lock functions were trying to compare the block header seq and
the super seq to decide if the block is stable and if it should lock, or
not.  Readers trying to lock races with transaction commits.
Transaction commit can update the super after the reader locks and
before it unlocks.  The unlock will then fail the test and fail to
unlock.  fsstress triggered this in xfstests generic/013.

Instead we can always acquire the read lock on stable blocks.  We'll be
bouncing the rwsem cacheline around like the refcount cacheline.  If
this is a problem we can carefully maintain bits in the block to safely
indicate if it should be locked or unlocked but let's not go there if we
don't have to.

Signed-off-by: Zach Brown <zab@versity.com>
Reviewed-by: Mark Fasheh <mfasheh@versity.com>

2016-11-16 14:45:07 -08:00

kmod

Don't check meta seq before locking

2016-11-16 14:45:07 -08:00

Description

No description provided

6.7 MiB

Languages

C 87.2%

Shell 9.1%

Roff 2.5%

TeX 0.9%

Makefile 0.3%