[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Feb 2017 20:04:01 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Al Viro <viro@...iv.linux.org.uk>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
syzkaller <syzkaller@...glegroups.com>
Subject: Re: [PATCH] timerfd: Protect the might cancel mechanism proper
On Thu, Feb 2, 2017 at 7:54 PM, Thomas Gleixner <tglx@...utronix.de> 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 concurrent
>> timerfd_settime calls, one that needs cancel and another that does not
>> need cancel, can't we end up with inconsistent setup? E.g. setup timer
>> that needs cancel, but it won't be in cancel_list. Or vice versa.
>
> Do we really care? If an application arms the timer with cancel in one
> thread and the same timer without cancel in another thread, then it's
> probably completely irrelevant whether the state pair timeout/cancel is
> correct or not. That's clearly an application bug and I don't want to add
> more locking just to make something which is broken by definition pseudo
> 'atomic'.
I agree that the program is bogus, and don't have to ensure any sane
behavior for it. But I am concerned about potential kernel corruptions
due to this. For example, maybe kernel code will decide to not remove
such timer from the cancel list on destruction because based on
clockid/flags it should not be in the cancel list, but the timer is
actually there and we will end up with a leak or a dangling pointer. I
did not check that this actually happens, such inconsistent state just
looks like a red flag for me.
Powered by blists - more mailing lists