Re: [PATCH] timerfd: Protect the might cancel mechanism proper

2017-02-10 Thread Thomas Gleixner
Dmitry, On Thu, 2 Feb 2017, Dmitry Vyukov wrote: > On Thu, Feb 2, 2017 at 7:54 PM, Thomas Gleixner wrote: > > On Wed, 1 Feb 2017, Dmitry Vyukov wrote: > >> > >> Can't we still end up with an inconsistently setup timer? > >> do_timerfd_settime executes timerfd_setup_cancel and timerfd_setup as >

Re: [PATCH] timerfd: Protect the might cancel mechanism proper

2017-02-10 Thread Thomas Gleixner
On Fri, 10 Feb 2017, Dmitry Vyukov wrote: > On Fri, Feb 10, 2017 at 11:13 AM, Thomas Gleixner wrote: > > ctx->might_cancel and ctx->clist are always in sync with the new lock and > > that's the only interesting thing. On destruction we don't look at clockid > > or such, we only care about might_ca

Re: [PATCH] timerfd: Protect the might cancel mechanism proper

2017-02-10 Thread Dmitry Vyukov
On Fri, Feb 10, 2017 at 11:13 AM, Thomas Gleixner wrote: > Dmitry, > > On Thu, 2 Feb 2017, Dmitry Vyukov wrote: > >> On Thu, Feb 2, 2017 at 7:54 PM, Thomas Gleixner wrote: >> > On Wed, 1 Feb 2017, Dmitry Vyukov wrote: >> >> >> >> Can't we still end up with an inconsistently setup timer? >> >> do_

Re: [PATCH] timerfd: Protect the might cancel mechanism proper

2017-02-02 Thread Dmitry Vyukov
On Thu, Feb 2, 2017 at 7:54 PM, Thomas Gleixner wrote: > On Wed, 1 Feb 2017, Dmitry Vyukov wrote: >> >> Can't we still end up with an inconsistently setup timer? >> do_timerfd_settime executes timerfd_setup_cancel and timerfd_setup as >> two separate non-atomic actions. So if there are 2 concurren

Re: [PATCH] timerfd: Protect the might cancel mechanism proper

2017-02-02 Thread Thomas Gleixner
On Wed, 1 Feb 2017, Dmitry Vyukov wrote: > > Can't we still end up with an inconsistently setup timer? > do_timerfd_settime executes timerfd_setup_cancel and timerfd_setup as > two separate non-atomic actions. So if there are 2 concurrent > timerfd_settime calls, one that needs cancel and another

Re: [PATCH] timerfd: Protect the might cancel mechanism proper

2017-02-01 Thread Dmitry Vyukov
On Tue, Jan 31, 2017 at 3:24 PM, Thomas Gleixner wrote: > 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 wit

[PATCH] timerfd: Protect the might cancel mechanism proper

2017-01-31 Thread Thomas Gleixner
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