Re: linux-next: manual merge of the block tree with the arm64 tree

From: Jens Axboe
Date: Thu Dec 03 2020 - 10:58:58 EST


On 12/3/20 8:05 AM, Catalin Marinas wrote:
> On Thu, Dec 03, 2020 at 07:36:10AM -0700, Jens Axboe wrote:
>> On 12/3/20 4:01 AM, Catalin Marinas wrote:
>>> On Thu, Dec 03, 2020 at 02:25:30PM +1100, Stephen Rothwell wrote:
>>>> diff --cc arch/arm64/include/asm/thread_info.h
>>>> index 015beafe58f5,cdcf307764aa..000000000000
>>>> --- a/arch/arm64/include/asm/thread_info.h
>>>> +++ b/arch/arm64/include/asm/thread_info.h
>>>> @@@ -63,7 -66,9 +63,8 @@@ void arch_release_task_struct(struct ta
>>>> #define TIF_NOTIFY_RESUME 2 /* callback before returning to user */
>>>> #define TIF_FOREIGN_FPSTATE 3 /* CPU's FP state is not current's */
>>>> #define TIF_UPROBE 4 /* uprobe breakpoint or singlestep */
>>>> - #define TIF_MTE_ASYNC_FAULT 5 /* MTE Asynchronous Tag Check Fault */
>>>> -#define TIF_FSCHECK 5 /* Check FS is USER_DS on return */
>>>> ++#define TIF_NOTIFY_SIGNAL 5 /* signal notifications exist */
>>>> + #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 */
>>>> @@@ -96,7 -103,8 +98,8 @@@
>>>>
>>>> #define _TIF_WORK_MASK (_TIF_NEED_RESCHED | _TIF_SIGPENDING | \
>>>> _TIF_NOTIFY_RESUME | _TIF_FOREIGN_FPSTATE | \
>>>> - _TIF_UPROBE | _TIF_MTE_ASYNC_FAULT)
>>>> - _TIF_UPROBE | _TIF_FSCHECK | _TIF_MTE_ASYNC_FAULT | \
>>>> ++ _TIF_UPROBE | _TIF_MTE_ASYNC_FAULT | \
>>>> + _TIF_NOTIFY_SIGNAL)
>>>
>>> Thanks Stephen. It looks alright to me.
>>
>> Agree - I'll rebase my tree when -rc7 is out so we won't have this issue once
>> the 5.11 merge window opens.
>
> I don't think rebasing on -rc7 will help since the arm64 commit
> b5a5a01d8e9a is queued for 5.11 (so not in -rc7).

Ah indeed, I saw some changes come in yesterday for mainline and assumed
it was those.

> It shouldn't matter much, Linus likes the occasional conflict ;).
> Anyway, I can wait for your pull request to go in if you'd prefer (and
> if it happens in the first week of the merging window).

Right, not an issue, it's a trivial resolve anyway. That branch is
dependent on an x86/core branch, so I'll push it out when that goes in.
But Linus usually pulls those early, so don't think we'll have much of
an issue there.

--
Jens Axboe