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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox