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

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: <E027D78E-E372-44A9-AD3C-234B109DDD28@oracle.com>
Date:   Tue, 15 Mar 2022 17:33:18 +0000
From:   Chuck Lever III <chuck.lever@...cle.com>
To:     Steven Rostedt <rostedt@...dmis.org>
CC:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: linux-next: manual merge of the ftrace tree with the nfsd tree



> On Mar 15, 2022, at 1:31 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> On Tue, 15 Mar 2022 13:33:30 +0000
> Chuck Lever III <chuck.lever@...cle.com> wrote:
> 
>>> On Mar 14, 2022, at 11:58 PM, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>>> 
>>> Hi all,
>>> 
>>> Today's linux-next merge of the ftrace tree got a conflict in:
>>> 
>>> include/trace/trace_events.h
>>> 
>>> between commit:
>>> 
>>> d07c9ad62247 ("tracing: Introduce helpers to safely handle dynamic-sized sockaddrs")
>>> 
>>> from the nfsd tree and commit:
>>> 
>>> af6b9668e85f ("tracing: Move the defines to create TRACE_EVENTS into their own files")
>>> 
>>> from the ftrace tree.
>>> 
>>> Well, this is a pain :-(  
>> 
>> Apologies. Steven, can you take the sockaddr patches in your tree
>> and resolve the x86_64 build issue?
> 
> Actually, the issue is not with your tree. It's a conflict with:
> 
>  fa2c3254d7cff ("sched/tracing: Don't re-read p->state when emitting sched_switch event")
> 
> Which changed the sched_switch event that my example was attaching to.

Thanks for troubleshooting!


> At least this proves that it will not compile if your custom event does not
> match the prototype of the event that the custom event is modifying :-)
> 
> 
>>> 
>>> However, my x86_64 allmodconfig build then failed like this:
>>> 
>>> In file included from include/trace/define_custom_trace.h:55,
>>>                from samples/trace_events/trace_custom_sched.h:95,
>>>                from samples/trace_events/trace_custom_sched.c:24:
>>> samples/trace_events/./trace_custom_sched.h: In function 'ftrace_test_custom_probe_sched_switch':
>>> include/trace/trace_custom_events.h:178:42: error: passing argument 1 of 'check_trace_callback_type_sched_switch' from incompatible pointer type [-Werror=incompatible-pointer-types]
>>> 178 |         check_trace_callback_type_##call(trace_custom_event_raw_event_##template); \
>>>     |                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>     |                                          |
>>>     |                                          void (*)(void *, bool,  struct task_struct *, struct task_struct *) {aka void (*)(void *, _Bool,  struct task_struct *, struct task_struct *)}
>>> include/trace/trace_custom_events.h:34:9: note: in expansion of macro 'DEFINE_CUSTOM_EVENT'
>>>  34 |         DEFINE_CUSTOM_EVENT(name, name, PARAMS(proto), PARAMS(args));
>>>     |         ^~~~~~~~~~~~~~~~~~~
>>> samples/trace_events/./trace_custom_sched.h:21:1: note: in expansion of macro 'TRACE_CUSTOM_EVENT'
>>>  21 | TRACE_CUSTOM_EVENT(sched_switch,
>>>     | ^~~~~~~~~~~~~~~~~~
>>> In file included from include/linux/trace_events.h:11,
>>>                from samples/trace_events/trace_custom_sched.c:10:
>>> include/linux/tracepoint.h:279:49: note: expected 'void (*)(void *, bool,  unsigned int,  struct task_struct *, struct task_struct *)' {aka 'void (*)(void *, _Bool,  unsigned int,  struct task_struct *, struct task_struct *)'} but argument is of type 'void (*)(void *, bool,  struct task_struct *, struct task_struct *)' {aka 'void (*)(void *, _Bool,  struct task_struct *, struct task_struct *)'}
>>> 279 |         check_trace_callback_type_##name(void (*cb)(data_proto))        \
> 
> 
> It's the type check code that failed. The above is complaining that it
> expects:
> 
> 'void (*)(void *, bool,  unsigned int,  struct task_struct *, struct
> task_struct *)' {aka 'void (*)(void *, _Bool,  unsigned int,  struct task_struct *, struct task_struct *)'}
> 
> But it found:
> 
> 'void (*)(void *, bool,  struct task_struct *, struct task_struct *)' {aka
> 'void (*)(void *, _Bool,  struct task_struct *, struct task_struct *)'}
> 
> 
> That's because the sched_switch event had the int prev_state added to it,
> but my custom event was unaware of that.
> 
> Stephen, I pushed out a branch on my tree that merges my for-next branch
> with next-20220315 and pushed it to:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
> 
> branch: trace-merge-next-20220315
> 
> -- Steve
> 
> 
> 
> 
>>>     |                                          ~~~~~~~^~~~~~~~~~~~~~~
>>> include/linux/tracepoint.h:419:9: note: in expansion of macro '__DECLARE_TRACE'
>>> 419 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
>>>     |         ^~~~~~~~~~~~~~~
>>> include/linux/tracepoint.h:553:9: note: in expansion of macro 'DECLARE_TRACE'
>>> 553 |         DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
>>>     |         ^~~~~~~~~~~~~
>>> include/trace/events/sched.h:222:1: note: in expansion of macro 'TRACE_EVENT'
>>> 222 | TRACE_EVENT(sched_switch,
>>>     | ^~~~~~~~~~~
>>> 
>>> So I gave up and uses the ftrace tree from next-20220310 for today.
>>> 
>>> I am going to need some help with this mess, please.
>>> -- 
>>> Cheers,
>>> Stephen Rothwell  
>> 
>> --
>> Chuck Lever

--
Chuck Lever