The handling of the might_cancel queueing is not properly protected,
so parallel operations on the file descriptor can race with each
other and lead to list corruptions or use after free.
Protect the context for these operations with a seperate lock.
The wait queue lock cannot be reused for this because that would
create a lock inversion scenario vs. the cancel lock. Replacing
might_cancel with an atomic (atomic_t or atomic bit) does not help
either because it still can race vs. the actual list operation.
Change-Id: I43c9338fd2f7306aefc538328f09669376da4bea
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: "linux-fsdevel@vger.kernel.org"
Cc: syzkaller <syzkaller@googlegroups.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701311521430.3457@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
a6c9e9ca13