Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp3109198rwb; Fri, 20 Jan 2023 11:17:24 -0800 (PST) X-Google-Smtp-Source: AMrXdXtOSk6alnvKKeV7MT8emxr+OmzpQyZ7/3UYu7r8GMfY4ap9Xd/r66ZjrmGJhQXmEFRzFixX X-Received: by 2002:a17:902:9a4c:b0:192:4f32:3ba7 with SMTP id x12-20020a1709029a4c00b001924f323ba7mr16723544plv.18.1674242244697; Fri, 20 Jan 2023 11:17:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674242244; cv=none; d=google.com; s=arc-20160816; b=f3ArtKbmUNvKVxyMW2ygD6bWn/unZCrKOMxLp5vVkO1nyUI2QqCiER8H8KkyfTbl0x /fEifmH9JDoz4b9l/Y+wMrzDkO8YGzxO+gcT56AHrOMHkn1hO03szwm9TBgSEBJH6i+i eXVWMLSwQbrGESXCvOwVIlb3bv/cVVJmhsAZ0m+Q80VCpdjTbAekRkmq7VRZufKuvpMu X3ZNkFUiGo464rANLrUulVyZIjVhDrMXbFJWgZjjaF+oHfFAnyZTITEgZ2OR7QWiv5xw 0taRD7vnzDTKWwPvyP5TaIZRSlKiM4Z9tiuQpgY8VSrtcXIow9Cc6nrsxVxLWU2n1iy+ +lzg== 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:dkim-signature; bh=M8C63zTwQBUjrTk/kJI56nuPI2mFRz5lVROZ3ipEjfo=; b=xtuBtIOVoF3HyRmuwyiLxO7gGQL7COK26JqjyGg7dBAn0pkFkMKwx3ACHF+BMUv5tR fSx2QaVYKmxHbfpviouqNIiLKh6y3SS/BBbRMi3EQhLwxPMyJBYCb7gvchBaQNvLDUd6 eynFR1Kq1tsd3hJ24OrhBQiyxWHgjtl2jQnK09P6I6UKkjpKvhLBA/QLjJdP4zi057La 4SVhvdDqnpjBwOcsyZIgBYRfMj+uUR44/YzwD0/6442+qX8ny0fuwidl+yqALUhNZIrz cuAz52r800DE5ww+ltRl6JBJye0Ju0/cWtmHP1CTRdcXjBkE94xgkBkF09w+Rk+A7y4H hvtg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Mv9cWPEO; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m10-20020a170902db0a00b001929883dd95si9147289plx.70.2023.01.20.11.17.18; Fri, 20 Jan 2023 11:17:24 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Mv9cWPEO; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229902AbjATS0s (ORCPT + 50 others); Fri, 20 Jan 2023 13:26:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38066 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229862AbjATS0q (ORCPT ); Fri, 20 Jan 2023 13:26:46 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33856DBCD for ; Fri, 20 Jan 2023 10:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674239162; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=M8C63zTwQBUjrTk/kJI56nuPI2mFRz5lVROZ3ipEjfo=; b=Mv9cWPEO4lEiDOffaLRz07au7drwKtTloo8d7MfZAJUzJN4GMNg8DgJUEqWE1Vfvtv0h/n ibybqaQcQdjGsqGIYwt5sr0sW3cFgV795GSOcusrBgAOOeIaHEHT35e1lPJ3UzHRYKyv0V EHQZFnc4u5EamX+iW24UxYACjpgipow= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-540-j-aOVJzAMAyxYZ7oFB-e7A-1; Fri, 20 Jan 2023 13:26:00 -0500 X-MC-Unique: j-aOVJzAMAyxYZ7oFB-e7A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8D967282381D; Fri, 20 Jan 2023 18:25:59 +0000 (UTC) Received: from localhost (unknown [10.22.8.197]) by smtp.corp.redhat.com (Postfix) with ESMTP id A32662166B2A; Fri, 20 Jan 2023 18:25:58 +0000 (UTC) Date: Fri, 20 Jan 2023 15:25:57 -0300 From: "Luis Claudio R. Goncalves" To: Mark Rutland 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-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,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 03:37:35PM +0000, Mark Rutland wrote: > 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. Thank you, that's really helpful! > 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... Just to avoid confusion here, this change is specific to the v5.10-rt, not applicable upstream nor to newer RT. We only saw the problem because TIF_NOTIFY_SIGNAL was mapped to a bit used by TIF_NEED_RESCHED_LAZY in v5.10-rt (the PREEMPT_RT changes on top of stable v5.10). This is why nobody from the arm64 side was copied initially, as we were trying to assert what was the problem. > > 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. Would something like this be a good interpretation of your suggestion? diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h index 6eb36a212..2afd9ceb6 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_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_NEED_RESCHED_LAZY 8 +#define TIF_SYSCALL_TRACE 9 /* syscall trace active */ +#define TIF_SYSCALL_AUDIT 10 /* syscall auditing */ +#define TIF_SYSCALL_TRACEPOINT 11 /* syscall tracepoint for ftrace */ +#define TIF_SECCOMP 12 /* syscall secure computing */ +#define TIF_SYSCALL_EMU 13 /* syscall emulation active */ #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ #define TIF_FREEZE 19 #define TIF_RESTORE_SIGMASK 20