linux-kernel - Re: [ANNOUNCE] 5.10.162-rt78

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a4f62523-b01e-3986-7914-767f999b4153@kernel.dk>
Date:   Thu, 19 Jan 2023 16:09:44 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Salvatore Bonaccorso <carnil@...ian.org>,
        "Luis Claudio R. Goncalves" <lgoncalv@...hat.com>
Cc:     Pavel Machek <pavel@...x.de>,
        Vignesh Raghavendra <vigneshr@...com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-rt-users <linux-rt-users@...r.kernel.org>,
        stable-rt <stable-rt@...r.kernel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Carsten Emde <C.Emde@...dl.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Daniel Wagner <daniel.wagner@...e.com>,
        Tom Zanussi <tom.zanussi@...ux.intel.com>,
        Clark Williams <williams@...hat.com>,
        Mark Gross <markgross@...nel.org>,
        Jeff Brady <jeffreyjbrady@...il.com>
Subject: Re: [ANNOUNCE] 5.10.162-rt78

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.

-- 
Jens Axboe