linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adam Wallis <awallis@codeaurora.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Tejun Heo <tj@kernel.org>,
	Arjan van de Ven <arjan@linux.intel.com>
Cc: stable@vger.kernel.org, Lai Jiangshan <laijs@cn.fujitsu.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Revert "async: simplify lowest_in_progress()"
Date: Mon, 20 Nov 2017 17:59:33 -0500	[thread overview]
Message-ID: <0c3b980a-7360-4698-80d9-5f58c608850a@codeaurora.org> (raw)
In-Reply-To: <20171120225147.3880-1-linux@rasmusvillemoes.dk>

On 11/20/2017 5:51 PM, Rasmus Villemoes wrote:
> This reverts commit 92266d6ef60c2381c980c6cdcb2a5c1667b36b49, which
> was simply wrong: In the case where domain is NULL, we now use the
> wrong offsetof() in the list_first_entry macro, so we don't actually
> fetch the ->cookie value, but rather the eight bytes located
> sizeof(struct list_head) further into the struct async_entry.
> 
> On 64 bit, that's the data member, while on 32 bit, we get a u64 built
> from func and data in some order.
> 
> I think the bug happens to be harmless in practice: It obviously only
> affects callers which pass a NULL domain, and AFAICT the only such
> caller is
> 
>   async_synchronize_full() ->
>   async_synchronize_full_domain(NULL) ->
>   async_synchronize_cookie_domain(ASYNC_COOKIE_MAX, NULL)
> 
> and the ASYNC_COOKIE_MAX means that in practice we end up waiting for
> the async_global_pending list to be empty - but it would break if
> somebody happened to pass (void*)-1 as the data element to
> async_schedule, and of course also if somebody ever does a
> async_synchronize_cookie_domain(, NULL) with a "finite" cookie value.
> 
> Cc: stable@vger.kernel.org # 3.10+

Recommend adding "Fixes" notation here referencing the original broken commit.

> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
[..]

-- 
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

  reply	other threads:[~2017-11-20 22:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-20 22:51 [PATCH] Revert "async: simplify lowest_in_progress()" Rasmus Villemoes
2017-11-20 22:59 ` Adam Wallis [this message]
2017-11-27 19:36 ` Tejun Heo
2017-11-28 10:49 ` [PATCH resend] " Rasmus Villemoes

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=0c3b980a-7360-4698-80d9-5f58c608850a@codeaurora.org \
    --to=awallis@codeaurora.org \
    --cc=arjan@linux.intel.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=stable@vger.kernel.org \
    --cc=tj@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).