Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1570020ybl; Fri, 13 Dec 2019 18:15:19 -0800 (PST) X-Google-Smtp-Source: APXvYqw//I3HMEJeP6oP5Z9S4ArPnlZ8hlVvOBn23dDq0JfA+O9XwmUl7Npli0ul49E16FGArxaG X-Received: by 2002:a9d:7b4a:: with SMTP id f10mr5773004oto.4.1576289719351; Fri, 13 Dec 2019 18:15:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576289719; cv=none; d=google.com; s=arc-20160816; b=SVNXeGXiR+0D30lBUTUOF7L67ugsxE17x0tw+uiDv81oct4zgaC+hAc/c1E7xm1XHg WbE8FliM8UQqmDs+fg0lT5aLpTMNU6V7e5QsFXnGvSI4RAd0yLdG+JYlcaPAyN6zfwsh viwkLylA/VQG86c/jLGd11ZxPoviajoIfDFxI3I3gMna8hTPKLBVNQj1vBeKkXQ1jVE+ RKVmazOiQZbvBRFqZe4NCjo8av6fHG/iaPsag7ZEuB4AhE+ZJ1SnQBqwJ9CZa+kLB61F n+AvttrFlEGUo4ihBgR9hdQt3ghtDxGwOCm38ol2ysuDe4X4iNzjpletsrh/bOpCtAtk BEpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=N881tb7TbRAgHjGg0M4bC7Pe9+SsJ3rsLbXpx1ccpRQ=; b=hPlP37Y3U8yPUyeHhkXyp8ZhBVBIPqDG2BZp0ywivNWJ7Qwxxrv2c+Ycf3NV8F5QXt sJtmz3NlHtu4ywEgCfcscLtz4BKYu4LjkRYmiQeyoO9lVSkzyIpHsfSTlcIl8z1AcYHm gJU7E4cq5NrYz1liOEhAuno/k1/hBeZ/82L8UnfQ0UOkCPmcBH7WEDXGVcikJhTrQfG6 +NYio0QwnzLaEETS0lcNo2NnJipuqPmpyxqMFckQStM98zyYfaJwPeNTfid3/J8Okuyf eoBQzULxnZeEJs1qV5eUJTakNgl2GcCBKWtsbyU/CW4WCFjJwp/sV0i00DZvrpt/gLeR nUCg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z13si6566335oti.272.2019.12.13.18.15.07; Fri, 13 Dec 2019 18:15:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726707AbfLNCOM (ORCPT + 99 others); Fri, 13 Dec 2019 21:14:12 -0500 Received: from mail.kernel.org ([198.145.29.99]:42612 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726334AbfLNCOM (ORCPT ); Fri, 13 Dec 2019 21:14:12 -0500 Received: from home.goodmis.org (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D05242073D; Sat, 14 Dec 2019 02:14:10 +0000 (UTC) Date: Fri, 13 Dec 2019 21:14:03 -0500 From: Steven Rostedt To: Sasha Levin Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Will Deacon , Ard Biesheuvel , "kernelci.org bot" , Kevin Hilman , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH AUTOSEL 4.19 031/219] arm64: preempt: Fix big-endian when checking preempt count in assembly Message-ID: <20191214021403.GA1357@home.goodmis.org> References: <20191122054911.1750-1-sashal@kernel.org> <20191122054911.1750-24-sashal@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191122054911.1750-24-sashal@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 22, 2019 at 12:46:03AM -0500, Sasha Levin wrote: > From: Will Deacon > > [ Upstream commit 7faa313f05cad184e8b17750f0cbe5216ac6debb ] > > Commit 396244692232 ("arm64: preempt: Provide our own implementation of > asm/preempt.h") extended the preempt count field in struct thread_info > to 64 bits, so that it consists of a 32-bit count plus a 32-bit flag > indicating whether or not the current task needs rescheduling. > > Whilst the asm-offsets definition of TSK_TI_PREEMPT was updated to point > to this new field, the assembly usage was left untouched meaning that a > 32-bit load from TSK_TI_PREEMPT on a big-endian machine actually returns > the reschedule flag instead of the count. > > Whilst we could fix this by pointing TSK_TI_PREEMPT at the count field, > we're actually better off reworking the two assembly users so that they > operate on the whole 64-bit value in favour of inspecting the thread > flags separately in order to determine whether a reschedule is needed. > > Acked-by: Ard Biesheuvel > Reported-by: "kernelci.org bot" > Tested-by: Kevin Hilman > Signed-off-by: Will Deacon > Signed-off-by: Sasha Levin > --- > arch/arm64/include/asm/assembler.h | 8 +++----- > arch/arm64/kernel/entry.S | 6 ++---- > 2 files changed, 5 insertions(+), 9 deletions(-) > > diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h > index 5a97ac8531682..0c100506a29aa 100644 > --- a/arch/arm64/include/asm/assembler.h > +++ b/arch/arm64/include/asm/assembler.h > @@ -683,11 +683,9 @@ USER(\label, ic ivau, \tmp2) // invalidate I line PoU > .macro if_will_cond_yield_neon > #ifdef CONFIG_PREEMPT > get_thread_info x0 > - ldr w1, [x0, #TSK_TI_PREEMPT] > - ldr x0, [x0, #TSK_TI_FLAGS] > - cmp w1, #PREEMPT_DISABLE_OFFSET > - csel x0, x0, xzr, eq > - tbnz x0, #TIF_NEED_RESCHED, .Lyield_\@ // needs rescheduling? > + ldr x0, [x0, #TSK_TI_PREEMPT] > + sub x0, x0, #PREEMPT_DISABLE_OFFSET > + cbz x0, .Lyield_\@ > /* fall through to endif_yield_neon */ > .subsection 1 > .Lyield_\@ : > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > index 5f800384cb9a8..bb68323530458 100644 > --- a/arch/arm64/kernel/entry.S > +++ b/arch/arm64/kernel/entry.S > @@ -622,10 +622,8 @@ el1_irq: > irq_handler > > #ifdef CONFIG_PREEMPT > - ldr w24, [tsk, #TSK_TI_PREEMPT] // get preempt count > - cbnz w24, 1f // preempt count != 0 > - ldr x0, [tsk, #TSK_TI_FLAGS] // get flags > - tbz x0, #TIF_NEED_RESCHED, 1f // needs rescheduling? > + ldr x24, [tsk, #TSK_TI_PREEMPT] // get preempt count > + cbnz x24, 1f // preempt count != 0 > bl el1_preempt While updating 4.19-rt, I stumbled on this change to arm64 backport. And was confused by it, but looking deeper, this is something that breaks without having 396244692232f ("arm64: preempt: Provide our own implementation of asm/preempt.h"). That commit inverts the TIF_NEED_RESCHED meaning where set means we don't need to resched, and clear means we need to resched. This way we can combine the preempt count with the need resched flag test as they share the same 64bit word. A 0 means we need to preempt (as NEED_RESCHED being zero means we need to resched, and this also means preempt_count is zero). If the TIF_NEED_RESCHED bit is set, that means we don't need to resched, and if preempt count is something other than zero, we don't need to resched, and since those two are together by commit 396244692232f, we can just test #TSK_TI_PREEMPT. But because that commit does not exist in 4.19, we can't remove the TIF_NEED_RESCHED check, that this backport does, and then breaks the kernel! -- Steve > 1: > #endif > -- > 2.20.1