Hello,
The userfaultfd_shmem selftest is currently locking up in D state
pretty quickly on current -mm and on the aa.git userfault branch based
on upstream.
Nothing changed on the userfault side of things and I surely let it
run the shmem stress test a while without noticing issues. I initially
thought some other recent change in shmem broke something. After
finishing reviewing all lock/unlock_page I figured it had to be
something else as nobody was holding the lock and surprisingly lockdep
never complained about locking errors.
Something must have changed that gives the lookup more concurrency and
exposed this problem in the page->flags non atomic update that
corrupts the PG_lock bit.
Good thing the userfault selftest is very aggressive at reproducing
any sort of SMP race conditions by starting 3 threads per CPU.
This fix solves the lockup for me. Mike can you verify on your setup
that reproduced this originally?
On a side note: the fix for the false positive SIGBUS is already
included in -mm and it happened to apply clean at the end. I would
suggest to apply that at the top of the userfault queue as it's the
only "fix" in queue for the upstream userfault code (even if not
particularly concerning and unnoticeable in real workloads). This new
fix is not relevant for upstream, but for -mm only.
Thanks.
Andrea Arcangeli (1):
userfaultfd: shmem: avoid a lockup resulting from corrupted
page->flags
mm/shmem.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>