All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	syzkaller <syzkaller@googlegroups.com>
Subject: Re: [PATCH] timerfd: Protect the might cancel mechanism proper
Date: Thu, 2 Feb 2017 19:54:48 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1702021951380.3575@nanos> (raw)
In-Reply-To: <CACT4Y+Ye47OticsSsdUHbieyEyvFcUzHqWad00bp6k0tXM2fsQ@mail.gmail.com>

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'.

Thanks,

	tglx

  reply	other threads:[~2017-02-02 18:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-31 14:24 [PATCH] timerfd: Protect the might cancel mechanism proper Thomas Gleixner
2017-02-01 12:43 ` Dmitry Vyukov
2017-02-02 18:54   ` Thomas Gleixner [this message]
2017-02-02 19:04     ` Dmitry Vyukov
2017-02-10 10:13       ` Thomas Gleixner
2017-02-10 10:26         ` Dmitry Vyukov
2017-02-10 10:51           ` Thomas Gleixner
2017-02-10 10:19 ` [tip:timers/core] " tip-bot for Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1702021951380.3575@nanos \
    --to=tglx@linutronix.de \
    --cc=dvyukov@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzkaller@googlegroups.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.