Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp2832787rwb; Fri, 20 Jan 2023 07:57:20 -0800 (PST) X-Google-Smtp-Source: AMrXdXu+7m0J0huGNBJsGN7XGA4dAER9q/vHQoRfvTF56JWZJFRU4zuzSVhdRF0oLfpYG72QuWIj X-Received: by 2002:aa7:cd8f:0:b0:499:4130:fae with SMTP id x15-20020aa7cd8f000000b0049941300faemr14289297edv.10.1674230240713; Fri, 20 Jan 2023 07:57:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674230240; cv=none; d=google.com; s=arc-20160816; b=jJ1uDB30lMtgvhOy33sG2cO+3fYKKlSWUS9GsOeOnTvuXOetbplsVLnGqIAg3wYqrZ 6z/Ppr8nLsPdqAfhyg90hCDV2HwLcQbzMEirpqzwDzzCEhCbNcrNf8sxekAd3b2mkutP rhjhK2s5vThD5ExC0QGAdMIvsmw+tavipDTvaMvKyggbH+bDKfoKKQMTa6feJAteAIYQ Wvcmf6E2cmAttsCIgtW5wj6XuTYL6qWWO7lF+9NtONk881u5LS5lSA8nazIcToi9J5jo ZLASy/kUOhHGjpnDLGVj5EnYpc0A6z38T00HuAndCdNAfNuYXDkUa4prudRpy3WITkAS kKsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=4M5kMObHDaQPMMnVL+zSJo3VyugCjbeVGVZ+emJ5AT0=; b=v21P9AwIS+TcJxA71xt3FsamXGWcJANO9158KxntVMpBERQBnRzy+mBHOmIhAVt7Bh qXaEG1/bmGYc8WOQ2yr/MpkCAeivx+Rg1iwk2QlsjLiLxe020emqQZEHWuh530oKiPtB UwniP/Mt76Fhemo50CRfcCnsW3w4k79JcszsQ0sBes9n+QvWQ6ol1Bwwwcr5bBhB/ace FjTT8ln1Dlw4DkLpnn7dadyKRQAV2BstkgqDclNTsHIPO2NsZ4m3OOTxvCeGSpHAZxO+ mFtqKwlesd+HCxMiBtD57eHvQUZhzk581Rq64MYTYtBNJWygzfSPRNGgztD5R+rIGYWo mtsQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t14-20020a056402524e00b0049e2d2eb5aesi16930680edd.229.2023.01.20.07.57.07; Fri, 20 Jan 2023 07:57:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229814AbjATPpr (ORCPT + 50 others); Fri, 20 Jan 2023 10:45:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231357AbjATPpp (ORCPT ); Fri, 20 Jan 2023 10:45:45 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A95AC9741; Fri, 20 Jan 2023 07:45:42 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 10A951650; Fri, 20 Jan 2023 07:38:23 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.11.233]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7F1B63F67D; Fri, 20 Jan 2023 07:37:38 -0800 (PST) Date: Fri, 20 Jan 2023 15:37:35 +0000 From: Mark Rutland To: "Luis Claudio R. Goncalves" Cc: Jens Axboe , Salvatore Bonaccorso , Pavel Machek , Vignesh Raghavendra , LKML , linux-rt-users , stable-rt , Steven Rostedt , Thomas Gleixner , Carsten Emde , Sebastian Andrzej Siewior , Daniel Wagner , Tom Zanussi , Clark Williams , Mark Gross , Jeff Brady Subject: Re: [ANNOUNCE] 5.10.162-rt78 Message-ID: References: <40de655e-26f3-aa7b-f1ec-6877396a9f1e@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 20, 2023 at 09:51:07AM -0300, Luis Claudio R. Goncalves wrote: > On Thu, Jan 19, 2023 at 08:49:28PM -0700, Jens Axboe wrote: > > On 1/19/23 8:44?PM, Luis Claudio R. Goncalves wrote: > > > On Thu, Jan 19, 2023 at 04:09:44PM -0700, Jens Axboe wrote: > > >> On 1/19/23 2:03?PM, Salvatore Bonaccorso wrote: > > >>> Hi Luis, all, > > >>> > > >>> On Thu, Jan 19, 2023 at 10:16:34AM -0300, Luis Claudio R. Goncalves wrote: > > >>>> On Thu, Jan 19, 2023 at 12:38:25PM +0100, Pavel Machek wrote: > > >>>>> Hi! > > >>>>> > > >>>>>>> I'm pleased to announce the 5.10.162-rt78 stable release. > > >>>>>>> > > >>>>>>> You can get this release via the git tree at: > > >>>>>>> > > >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > >>>>>>> > > >>>>>>> branch: v5.10-rt > > >>>>>>> Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 > > >>>>>>> > > >>>>>>> Or to build 5.10.162-rt78 directly, the following patches should be applied: > > >>>>> > > >>>>>> I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] > > >>>>>> Any pointers on what maybe wrong? > > >>>>> > > >>>>> We see the same failure. > > >>>>> > > >>>>>> AS arch/arm64/kernel/entry.o > > >>>>>> arch/arm64/kernel/entry.S: Assembler messages: > > >>>>>> arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' > > >>>>>> make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 > > >>>>>> make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 > > >>>>>> make: *** [Makefile:1837: arch/arm64] Error 2 > > >>>>> > > >>>>> The line is: > > >>>>> > > >>>>>> and x2, x19, #_TIF_WORK_MASK > > >>>> > > >>>> I believe this is related to the arch/arm64/include/asm/thread_info.h > > >>>> changes in 5.10.162-rt78, specifically: > > >>>> > > >>>> 79a9991e87fe arm64: add support for TIF_NOTIFY_SIGNAL > > >>>> 1ba44dcf789d Merge tag 'v5.10.162' into v5.10-rt > > >>>> > > >>>> The first one is the original change, coming from stable v5.10.162 and the > > >>>> second one has the merge conflict I fixed in that file due to the existence > > >>>> of TIF_NEED_RESCHED_LAZY in PREEMPT_RT. > > >>>> > > >>>> It escaped me that having TIF_NEED_RESCHED_LAZY set to 13 breaks the AND > > >>>> statement reported above. Looking at > > >>>> > > >>>> b5a5a01d8e9a arm64: uaccess: remove addr_limit_user_check() > > >>>> > > >>>> specially this note > > >>>> > > >>>> To ensure that _TIF_WORK_MASK can be used as an immediate value in an > > >>>> AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is > > >>>> renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. > > >>>> > > >>>> I understand that I need to either have to renumber TIF_NEED_RESCHED_LAZY > > >>>> to 8, with the risk of breaking something else, or backport commit > > >>>> b5a5a01d8e9a in order to remove TIF_FSCHECK and then safely renumber > > >>>> TIF_NEED_RESCHED_LAZY. > > >>>> > > >>>> Guidance is welcome here :) > > >>> > > >>> Should we loop in here Jens, as having some overview of the needed > > >>> changes for io_uring rebase in the 5.10.y version? (doing so in the > > >>> mail). > > >> > > >> Huh that's funky, I built and (runtime) tested this on arm64 > > >> specifically. But I do remember some details about the first 8 bits on > > >> arm, but not arm64. > > >> > > >> I guess we need to twiddle that asm to deal with eg 16 bits, rather than > > >> attempt to backport any TIF removal patches. > > > > > > One simple solution, tested with defconfig plus FTRACE options (including > > > FTRACE_SYSCALLS) enabled, is: > > > > > > diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h > > > index 6eb36a2126e8..37f19bb49d38 100644 > > > --- a/arch/arm64/include/asm/thread_info.h > > > +++ b/arch/arm64/include/asm/thread_info.h > > > @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); > > > #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ > > > #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ > > > #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ > > > -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ > > > +#define TIF_NEED_RESCHED_LAZY 8 > > > #define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ > > > #define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ > > > #define TIF_SECCOMP 11 /* syscall secure computing */ > > > #define TIF_SYSCALL_EMU 12 /* syscall emulation active */ > > > -#define TIF_NEED_RESCHED_LAZY 13 > > > +#define TIF_SYSCALL_TRACE 13 /* syscall trace active */ > > > #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ > > > #define TIF_FREEZE 19 > > > #define TIF_RESTORE_SIGMASK 20 > > > > > > Would that be acceptable? With that we ensure the bits in > > > _TIF_WORK_MASK are contiguous and within the 8 bits limit you > > > mentioned. And TIF_SYSCALL_TRACE did not seem to have any (build) > > > problem with the new value. > > > > That should work too, the _TIF_WORK_MASK bits being in the lower 8 bits > > is really all we should care about. > > Jens, Salvatore, Mike, I ran a few tests and confirmed that the current asm > code is not restricted to 8 bits. The problems is that there is a > requirement for the mask bits to be contiguous in that specific context. Just to confirm from the arm64 side, the instruction using this just requires the bits to be contiguous, there's no restriction on *which* bits those are. If you're going to mess around with the arm64 bits, please could you Cc someone form the arm64 side? e.g. I fixed a similar issue in mainline in commit: 870d16757ba8918c ("arm64: make _TIF_WORK_MASK bits contiguous") ... and either Will Deacon or Catalin Marinas may have had comments as they're the arm64 maintainers... > The explanation from commit b5a5a01d8e9a ("arm64: uaccess: remove > addr_limit_user_check()") describes quite well our case: > > To ensure that _TIF_WORK_MASK can be used as an immediate value in an > AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is > renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. > > My question is: do you prefer renumbering the bits or the neat asm hack > that Mike proposed? I would strongly recommend renumbering the bits over changing the asm. That's going to be closer to what mainline has already done, and it avoids introducing weird ifdeffery. That said, rather than swapping TIF_SYSCALL_TRACE and TIF_NEED_RESCHED_LAZY, you could just shuffle the bits down-by-one, keeping all the existing contiguity, e.g. #define TIF_NEED_RESCHED_LAZY 8 #define TIF_SYSCALL_TRACE 9 #define TIF_SYSCALL_AUDIT 10 #define TIF_SYSCALL_TRACEPOINT 11 ... and so on. Thanks, Mark.