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
| ||
|
Date: Wed, 27 Nov 2019 20:00:22 -0500 From: Steven Rostedt <rostedt@...dmis.org> To: Stephen Rothwell <sfr@...b.auug.org.au> Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>, Linux Next Mailing List <linux-next@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Ben Dooks <ben.dooks@...ethink.co.uk>, Linus <torvalds@...ux-foundation.org> Subject: Re: linux-next: manual merge of the ftrace tree with the tip tree On Thu, 28 Nov 2019 11:47:04 +1100 Stephen Rothwell <sfr@...b.auug.org.au> wrote: > Hi all, > > On Thu, 21 Nov 2019 15:10:40 +1100 Stephen Rothwell <sfr@...b.auug.org.au> wrote: > > > > Today's linux-next merge of the ftrace tree got a conflict in: > > > > kernel/trace/trace_export.c > > > > between commit: > > > > 60fdad00827c ("ftrace: Rework event_create_dir()") > > > > from the tip tree and commit: > > > > 6dff4d7dd3e0 ("tracing: Make internal ftrace events static") > > > > from the ftrace tree. > > > > I fixed it up (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. > > > > -- > > Cheers, > > Stephen Rothwell > > > > diff --cc kernel/trace/trace_export.c > > index 6d64c1c19fd5,2e6d2e9741cc..000000000000 > > --- a/kernel/trace/trace_export.c > > +++ b/kernel/trace/trace_export.c > > @@@ -142,10 -168,12 +142,10 @@@ static struct trace_event_fields ftrace > > #define F_printk(fmt, args...) __stringify(fmt) ", " __stringify(args) > > > > #undef FTRACE_ENTRY_REG > > -#define FTRACE_ENTRY_REG(call, struct_name, etype, tstruct, print, filter,\ > > - regfn) \ > > - \ > > +#define FTRACE_ENTRY_REG(call, struct_name, etype, tstruct, print, regfn) \ > > - struct trace_event_class __refdata event_class_ftrace_##call = { \ > > + static struct trace_event_class __refdata event_class_ftrace_##call = { \ > > .system = __stringify(TRACE_SYSTEM), \ > > - .define_fields = ftrace_define_fields_##call, \ > > + .fields_array = ftrace_event_fields_##call, \ > > .fields = LIST_HEAD_INIT(event_class_ftrace_##call.fields),\ > > .reg = regfn, \ > > }; \ > > This is now a conflict between the tip tree and Linus' tree. This looks to be a trivial conflict, as the change in the ftrace (now Linus's) tree just makes event_class_ftrace_##call static, and shouldn't interfere with the changes in tip. -- Steve
Powered by blists - more mailing lists