From: Darren Hart <dvhart@infradead.org>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
lkml <linux-kernel@vger.kernel.org>,
Darren Hart <darren@dvhart.com>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 2/2] futex: Fix argument handling in futex_lock_pi() calls
Date: Fri, 16 Jan 2015 18:04:01 -0800 [thread overview]
Message-ID: <20150117020401.GB6494@vmdeb7> (raw)
In-Reply-To: <54B96646.8010200@gmail.com>
On Fri, Jan 16, 2015 at 08:28:06PM +0100, Michael Kerrisk (man-pages) wrote:
> From: Michael Kerrisk <mtk.manpages@gmail.com>
>
> This patch fixes two separate buglets in calls to futex_lock_pi():
>
> * Eliminate unused 'detect' argument
> * Change unused 'timeout' argument of FUTEX_TRYLOCK_PI to NULL
One might argue these should be two separate fixes. Since both are trivial and functional
no-ops, I'm going to ignore it and consider it a "cleanup" :-) Thomas may
disagree.
>
> The 'detect' argument of futex_lock_pi() seems never to have been
> used (when it was included with the initial PI mutex implementation
> in Linux 2.6.18, all checks against its value were disabled by
> ANDing against 0 (i.e., if (detect... && 0)), and with
> commit 778e9a9c3e7193ea9f434f382947155ffb59c755, any mention of
> this argument in futex_lock_pi() went way altogether. Its presence
> now serves only to confuse readers of the code, by giving the
> impression that the futex() FUTEX_LOCK_PI operation actually does
> use the 'val' argument. This patch removes the argument.
>
> The futex_lock_pi() call that corresponds to FUTEX_TRYLOCK_PI includes
> 'timeout' as one of its arguments. This misleads the reader into thinking
> that the FUTEX_TRYLOCK_PI operation does employ timeouts for some sensible
> purpose; but it does not. Indeed, it cannot, because the checks at the
> start of sys_futex() exclude FUTEX_TRYLOCK_PI from the set of operations
> that do copy_from_user() on the timeout argument. So, in the
> FUTEX_TRYLOCK_PI futex_lock_pi() call it would be simplest to change
> 'timeout' to 'NULL'. This patch does that.
>
> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Good and correct changes each.
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
Thanks Michael,
--
Darren Hart
Intel Open Source Technology Center
next prev parent reply other threads:[~2015-01-17 2:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-16 19:28 [PATCH 2/2] futex: Fix argument handling in futex_lock_pi() calls Michael Kerrisk (man-pages)
2015-01-17 2:04 ` Darren Hart [this message]
2015-01-17 8:42 ` Michael Kerrisk (man-pages)
2015-01-19 11:10 ` [tip:locking/core] futex: Fix argument handling in futex_lock_pi( ) calls tip-bot for Michael Kerrisk
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=20150117020401.GB6494@vmdeb7 \
--to=dvhart@infradead.org \
--cc=darren@dvhart.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mtk.manpages@gmail.com \
--cc=tglx@linutronix.de \
/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.