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

[Jens Axboe <axboe@kernel.dk>]

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