Re: linux-next: manual merge of the rcu tree with the ftrace tree

[Yonghong Song <yonghong.song@linux.dev>]

On 11/14/25 9:05 AM, Paul E. McKenney wrote:
> On Fri, Nov 14, 2025 at 07:42:55AM -0500, Steven Rostedt wrote:
>> On Fri, 14 Nov 2025 13:52:26 +1100
>> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>>> Hi all,
>>>
>>> Today's linux-next merge of the rcu tree got a conflict in:
>>>
>>>    kernel/trace/trace_syscalls.c
>>>
>>> between commit:
>>>
>>>    a544d9a66bdf ("tracing: Have syscall trace events read user space string")
>>>
>>> from the ftrace tree and commit:
>>>
>>>    35587dbc58dd ("tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast")
>>>
>>> from the rcu tree.
>>>
>>> I fixed it up (Maybe - see below) and can carry the fix as necessary. This
>>> is now fixed as far as linux-next is concerned, but any non trivial
>>> conflicts should be mentioned to your upstream maintainer when your tree
>>> is submitted for merging.  You may also want to consider cooperating
>>> with the maintainer of the conflicting tree to minimise any particularly
>>> complex conflicts.
>> Thanks for the update.
>>
>>> diff --cc kernel/trace/trace_syscalls.c
>>> index e96d0063cbcf,3f699b198c56..000000000000
>>> --- a/kernel/trace/trace_syscalls.c
>>> +++ b/kernel/trace/trace_syscalls.c
>>> @@@ -878,6 -322,8 +890,7 @@@ static void ftrace_syscall_enter(void *
>>>    	 * buffer and per-cpu data require preemption to be disabled.
>>>    	 */
>>>    	might_fault();
>>> + 	preempt_rt_guard();
>>>   -	guard(preempt_notrace)();
>> My code made it so that preemption is not needed here but is moved later
>> down for the logic that does the reading of user space data.
>>
>> Note, it must have preemption disabled for all configs (including RT).
>> Otherwise, the data it has can get corrupted.
>>
>> Paul, can you change it so that you *do not* touch this file?
> I could, but I believe that this would re-introduce the migration failure.
>
> Maybe we should just defer this until both your patch and the RCU
> stack hit mainline, and port on top of those?  Perhaps later in the
> merge window?
>
> I believe that migration needs to be disabled at this point, but I am
> again adding Yonghong on CC for his perspective.

Yes, migration needs to be disabled for rt kernel in order to let
bpf program running properly.

Regarding to non-rt kernel, currently preempt disable is used.
Is preempt disalbe just for bpf program or for something else
as well? Certainly perempt disable can help improve bpf prog
performance. From bpf prog itself, typically we can do with
migration disable, but in some places we may have to add
preempt disable, e.g.,
   https://lore.kernel.org/bpf/20251114064922.11650-1-chandna.sahil@gmail.com/T/#u
   https://lore.kernel.org/bpf/20251112163148.100949-1-chen.dylane@linux.dev/T/#m556837a5987bc048b8b9bbcc6b50728c441c139f

>
> 							Thanx, Paul
>
>> Thanks,
>>
>> -- Steve
>>
>>
>>>    
>>>    	syscall_nr = trace_get_syscall_nr(current, regs);
>>>    	if (syscall_nr < 0 || syscall_nr >= NR_syscalls)