The patch titled Subject: kernel/async.c: revert "async: simplify lowest_in_progress()" has been added to the -mm tree. Its filename is revert-async-simplify-lowest_in_progress.patch

This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/revert-async-simplify-lowest_in_pro... and later at http://ozlabs.org/~akpm/mmotm/broken-out/revert-async-simplify-lowest_in_pro...

Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/SubmitChecklist when testing your code ***

The -mm tree is included into linux-next and is updated there every 3-4 working days

------------------------------------------------------ From: Rasmus Villemoes linux@rasmusvillemoes.dk Subject: kernel/async.c: revert "async: simplify lowest_in_progress()"

This reverts 92266d6ef60c2381 ("async: simplify lowest_in_progress()"), 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, that's 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.

Maybe the "harmless in practice" means this isn't -stable material. But I'm not completely confident my quick git grep'ing is enough, and there might be affected code in one of the earlier kernels that has since been removed, so I'll leave the decision to the stable guys.

Link: http://lkml.kernel.org/r/20171128104938.3921-1-linux@rasmusvillemoes.dk Fixes: 92266d6ef60c "async: simplify lowest_in_progress()" Signed-off-by: Rasmus Villemoes linux@rasmusvillemoes.dk Acked-by: Tejun Heo tj@kernel.org Cc: Arjan van de Ven arjan@linux.intel.com Cc: Adam Wallis awallis@codeaurora.org Cc: Lai Jiangshan laijs@cn.fujitsu.com Cc: stable@vger.kernel.org [3.10+] Signed-off-by: Andrew Morton akpm@linux-foundation.org ---

kernel/async.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-)

diff -puN kernel/async.c~revert-async-simplify-lowest_in_progress kernel/async.c --- a/kernel/async.c~revert-async-simplify-lowest_in_progress +++ a/kernel/async.c @@ -84,20 +84,24 @@ static atomic_t entry_count;

static async_cookie_t lowest_in_progress(struct async_domain *domain) { - struct list_head *pending; + struct async_entry *first = NULL; async_cookie_t ret = ASYNC_COOKIE_MAX; unsigned long flags;

spin_lock_irqsave(&async_lock, flags);

- if (domain) - pending = &domain->pending; - else - pending = &async_global_pending; + if (domain) { + if (!list_empty(&domain->pending)) + first = list_first_entry(&domain->pending, + struct async_entry, domain_list); + } else { + if (!list_empty(&async_global_pending)) + first = list_first_entry(&async_global_pending, + struct async_entry, global_list); + }

- if (!list_empty(pending)) - ret = list_first_entry(pending, struct async_entry, - domain_list)->cookie; + if (first) + ret = first->cookie;

spin_unlock_irqrestore(&async_lock, flags); return ret; _

Patches currently in -mm which might be from linux@rasmusvillemoes.dk are

revert-async-simplify-lowest_in_progress.patch