timerfd: Protect the might cancel mechanism proper

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: Ib0fc09f70b40be38badbbf674aacaa5c24a466b7
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>
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git


Git-commit: 1e38da300e1e395a15048b0af1e5305bd91402f6
Signed-off-by: Dennis Cagle <dcagle@codeaurora.org>