linux-next: manual merge of the ftrace tree with Linus' tree

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  kernel/trace/trace.c

between commit:

  eecb91b9f98d ("tracing: Fix memleak due to race between current_tracer and trace")

from Linus' tree and commit:

  9182b519b8c9 ("tracing: Remove unnecessary copying of tr->current_trace")

from the ftrace tree.

I fixed it up (I just used the latter version - more may be
necessary?) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  scripts/sorttable.h

between commit:

  0210d251162f ("scripts/sorttable: fix orc_sort_cmp() to maintain symmetry and transitivity")

from Linus' tree and commit:

  4f1d0c914628 ("scripts/sorttable: Move code from sorttable.h into sorttable.c")

from the ftrace tree.

I fixed it up (I deleted the file and applied the following merge fix
patch) 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.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 8 Jan 2025 13:23:17 +1100
Subject: [PATCH] fix up for "scripts/sorttable: Move code from sorttable.h
 into sorttable.c"

interacting with commit

  0210d251162f ("scripts/sorttable: fix orc_sort_cmp() to maintain symmetry and transitivity")

from Linus' tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 scripts/sorttable.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/sorttable.c b/scripts/sorttable.c
index cd3b2145a827..656c1e9b5ad9 100644
--- a/scripts/sorttable.c
+++ b/scripts/sorttable.c
@@ -368,7 +368,7 @@ static inline unsigned long orc_ip(const int *ip)
 
 static int orc_sort_cmp(const void *_a, const void *_b)
 {
-	struct orc_entry *orc_a;
+	struct orc_entry *orc_a, *orc_b;
 	const int *a = g_orc_ip_table + *(int *)_a;
 	const int *b = g_orc_ip_table + *(int *)_b;
 	unsigned long a_val = orc_ip(a);
@@ -386,6 +386,9 @@ static int orc_sort_cmp(const void *_a, const void *_b)
 	 * whitelisted .o files which didn't get objtool generation.
 	 */
 	orc_a = g_orc_table + (a - g_orc_ip_table);
+	orc_b = g_orc_table + (b - g_orc_ip_table);
+	if (orc_a->type == ORC_TYPE_UNDEFINED && orc_b->type == ORC_TYPE_UNDEFINED)
+		return 0;
 	return orc_a->type == ORC_TYPE_UNDEFINED ? -1 : 1;
 }
 
-- 
2.45.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Steven Rostedt]

On Wed, 8 Jan 2025 13:32:07 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the ftrace tree got a conflict in:
> 
>   scripts/sorttable.h
> 
> between commit:
> 
>   0210d251162f ("scripts/sorttable: fix orc_sort_cmp() to maintain symmetry and transitivity")
> 
> from Linus' tree and commit:
> 
>   4f1d0c914628 ("scripts/sorttable: Move code from sorttable.h into sorttable.c")
> 
> from the ftrace tree.
> 
> I fixed it up (I deleted the file and applied the following merge fix
> patch) 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.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 8 Jan 2025 13:23:17 +1100
> Subject: [PATCH] fix up for "scripts/sorttable: Move code from sorttable.h
>  into sorttable.c"
> 
> interacting with commit
> 
>   0210d251162f ("scripts/sorttable: fix orc_sort_cmp() to maintain symmetry and transitivity")
> 
> from Linus' tree.

Thanks for letting me know. I'll likely just rebase it on v6.13-rc6 and
retest it.

-- Steve

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  kernel/trace/ring_buffer.c

between commit:

  09661f75e75c ("ring-buffer: Fix reader locking when changing the sub buffer order")

from Linus' tree and commit:

  1f1c2bc9d075 ("ring-buffer: Limit time with disabled interrupts in rb_check_pages()")

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/ring_buffer.c
index 3ea4f7bb1837,696d422d5b35..000000000000
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@@ -6757,9 -6800,14 +6803,10 @@@ int ring_buffer_subbuf_order_set(struc
  						     struct buffer_page, list);
  		list_del_init(&cpu_buffer->reader_page->list);
  
 -		/* The cpu_buffer pages are a link list with no head */
 +		/* Install the new pages, remove the head from the list */
  		cpu_buffer->pages = cpu_buffer->new_pages.next;
 -		cpu_buffer->new_pages.next->prev = cpu_buffer->new_pages.prev;
 -		cpu_buffer->new_pages.prev->next = cpu_buffer->new_pages.next;
+ 		cpu_buffer->cnt++;
 -
 -		/* Clear the new_pages list */
 -		INIT_LIST_HEAD(&cpu_buffer->new_pages);
 +		list_del_init(&cpu_buffer->new_pages);
  
  		cpu_buffer->head_page
  			= list_entry(cpu_buffer->pages, struct buffer_page, list);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Steven Rostedt]

On Mon, 21 Oct 2024 13:26:36 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the ftrace tree got a conflict in:
> 
>   kernel/trace/ring_buffer.c
> 
> between commit:
> 
>   09661f75e75c ("ring-buffer: Fix reader locking when changing the sub buffer order")
> 
> from Linus' tree and commit:
> 
>   1f1c2bc9d075 ("ring-buffer: Limit time with disabled interrupts in rb_check_pages()")
> 
> 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.
> 

Thanks, but I screwed up my ring-buffer branch. I have a new one
tested, and I'll be rebasing it today.

-- Steve

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  kernel/trace/trace_uprobe.c

between commit:

  10cdb82aa77f ("uprobes: turn trace_uprobe's nhit counter to be per-CPU one")

from Linus' tree and commit:

  ca088d067ebd ("uprobes: make trace_uprobe->nhit counter a per-CPU one")

from the ftrace tree.

I fixed it up (I just used the version from Linus' tree) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Andrii Nakryiko]

On Thu, Sep 26, 2024 at 6:36 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the ftrace tree got a conflict in:
>
>   kernel/trace/trace_uprobe.c
>
> between commit:
>
>   10cdb82aa77f ("uprobes: turn trace_uprobe's nhit counter to be per-CPU one")
>
> from Linus' tree and commit:
>
>   ca088d067ebd ("uprobes: make trace_uprobe->nhit counter a per-CPU one")
>
> from the ftrace tree.

Hm... sounds like two versions of my patch were applied to two
different trees or something? FWIW, 10cdb82aa77f is the right one cto
pick (I didn't check which one is in Linus' tree), but the differences
are tiny.

diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 87b468d93f6a..c3df411a2684 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -834,7 +834,7 @@ static int probes_profile_seq_show(struct seq_file
*m, void *v)

        nhits = 0;
        for_each_possible_cpu(cpu) {
-               nhits += READ_ONCE(*per_cpu_ptr(tu->nhits, cpu));
+               nhits += per_cpu(*tu->nhits, cpu);
        }

        seq_printf(m, "  %s %-44s %15lu\n", tu->filename,

>
> I fixed it up (I just used the version from Linus' tree) 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

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

[Steven Rostedt]

On Fri, 27 Sep 2024 11:13:30 -0700
Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:

> Hm... sounds like two versions of my patch were applied to two
> different trees or something? FWIW, 10cdb82aa77f is the right one cto
> pick (I didn't check which one is in Linus' tree), but the differences
> are tiny.
> 
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index 87b468d93f6a..c3df411a2684 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -834,7 +834,7 @@ static int probes_profile_seq_show(struct seq_file
> *m, void *v)
> 
>         nhits = 0;
>         for_each_possible_cpu(cpu) {
> -               nhits += READ_ONCE(*per_cpu_ptr(tu->nhits, cpu));
> +               nhits += per_cpu(*tu->nhits, cpu);
>         }
> 
>         seq_printf(m, "  %s %-44s %15lu\n", tu->filename,
> 
> >

It looks like Masami rebased his tree and I didn't do the update yet.

I updated the latest for-next in the tracing repo, so everything should be
good again.

-- Steve

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  kernel/trace/ftrace.c

between commit:

  2a2d8c51defb ("ftrace: Fix issue that 'direct->addr' not restored in modify_ftrace_direct()")

from Linus' tree and commit:

  8788ca164eb4 ("ftrace: Remove the legacy _ftrace_direct API")

from the ftrace tree.

I fixed it up (the latter removed the lines changed by the latter, so I
did that) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Steven Rostedt]

On Tue, 11 Apr 2023 12:46:02 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the ftrace tree got a conflict in:
> 
>   kernel/trace/ftrace.c
> 
> between commit:
> 
>   2a2d8c51defb ("ftrace: Fix issue that 'direct->addr' not restored in modify_ftrace_direct()")
> 
> from Linus' tree and commit:
> 
>   8788ca164eb4 ("ftrace: Remove the legacy _ftrace_direct API")
> 
> from the ftrace tree.
> 
> I fixed it up (the latter removed the lines changed by the latter, so I
> did that) 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. I'll probably hit that before sending to Linus as well, as I should
hopefully remember to test merging my pull request before sending.

The one in Linus's tree is a stable fix for code that will become obsolete
in the next merge window (hence its removal).

-- Steve

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3288 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got conflicts in:

  include/linux/trace_recursion.h
  kernel/trace/ftrace.c

between commit:

  ed65df63a39a ("tracing: Have all levels of checks prevent recursion")

from Linus' tree and commit:

  ce5e48036c9e ("ftrace: disable preemption when recursion locked")

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 include/linux/trace_recursion.h
index fe95f0922526,a13f23b04d73..000000000000
--- a/include/linux/trace_recursion.h
+++ b/include/linux/trace_recursion.h
@@@ -139,8 -155,11 +135,11 @@@ extern void ftrace_record_recursion(uns
  # define do_ftrace_record_recursion(ip, pip)	do { } while (0)
  #endif
  
+ /*
+  * Preemption is promised to be disabled when return bit >= 0.
+  */
  static __always_inline int trace_test_and_set_recursion(unsigned long ip, unsigned long pip,
 -							int start, int max)
 +							int start)
  {
  	unsigned int val = READ_ONCE(current->trace_recursion);
  	int bit;
@@@ -148,10 -167,18 +147,14 @@@
  	bit = trace_get_context_bit() + start;
  	if (unlikely(val & (1 << bit))) {
  		/*
- 		 * It could be that preempt_count has not been updated during
- 		 * a switch between contexts. Allow for a single recursion.
+ 		 * If an interrupt occurs during a trace, and another trace
+ 		 * happens in that interrupt but before the preempt_count is
+ 		 * updated to reflect the new interrupt context, then this
+ 		 * will think a recursion occurred, and the event will be dropped.
+ 		 * Let a single instance happen via the TRANSITION_BIT to
+ 		 * not drop those events.
  		 */
 -		bit = TRACE_TRANSITION_BIT;
 +		bit = TRACE_CTX_TRANSITION + start;
  		if (val & (1 << bit)) {
  			do_ftrace_record_recursion(ip, pip);
  			return -1;
@@@ -162,12 -192,22 +165,18 @@@
  	current->trace_recursion = val;
  	barrier();
  
+ 	preempt_disable_notrace();
+ 
 -	return bit + 1;
 +	return bit;
  }
  
+ /*
+  * Preemption will be enabled (if it was previously enabled).
+  */
  static __always_inline void trace_clear_recursion(int bit)
  {
 -	if (!bit)
 -		return;
 -
+ 	preempt_enable_notrace();
  	barrier();
 -	bit--;
  	trace_recursion_clear(bit);
  }
  
diff --cc kernel/trace/ftrace.c
index 635fbdc9d589,b4ed1a301232..000000000000
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@@ -6977,7 -7198,12 +7198,12 @@@ __ftrace_ops_list_func(unsigned long ip
  	struct ftrace_ops *op;
  	int bit;
  
+ 	/*
+ 	 * The ftrace_test_and_set_recursion() will disable preemption,
+ 	 * which is required since some of the ops may be dynamically
+ 	 * allocated, they must be freed after a synchronize_rcu().
+ 	 */
 -	bit = trace_test_and_set_recursion(ip, parent_ip, TRACE_LIST_START, TRACE_LIST_MAX);
 +	bit = trace_test_and_set_recursion(ip, parent_ip, TRACE_LIST_START);
  	if (bit < 0)
  		return;
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Steven Rostedt]

On Thu, 28 Oct 2021 16:31:11 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Today's linux-next merge of the ftrace tree got conflicts in:
> 
>   include/linux/trace_recursion.h
>   kernel/trace/ftrace.c

Yeah, this is one of the times I will be sending Linus a link to the merge
of his tree in my repo for my pull request. I have this ready.

> @@@ -162,12 -192,22 +165,18 @@@
>   	current->trace_recursion = val;
>   	barrier();
>   
> + 	preempt_disable_notrace();
> + 

The only difference between what I have and yours, is that I nuked the
extra space ;-)

Thanks,

-- Steve


>  -	return bit + 1;
>  +	return bit;
>   }
>   

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  lib/bootconfig.c

between commit:

  77e02cf57b6c ("memblock: introduce saner 'memblock_free_ptr()' interface")

from Linus' tree and commit:

  6c7324bca2ec ("bootconfig: Fix to check the xbc_node is used before free it")

from the ftrace tree.

The new memblock_free_ptr() inroduced by Linus' tree copes with NULL
pointers, so I just used that.  Which means that the ftrace tree patch
will be redundant.

I fixed it up (see above) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Steven Rostedt]

On Wed, 15 Sep 2021 10:44:44 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the ftrace tree got a conflict in:
> 
>   lib/bootconfig.c
> 
> between commit:
> 
>   77e02cf57b6c ("memblock: introduce saner 'memblock_free_ptr()' interface")
> 
> from Linus' tree and commit:
> 
>   6c7324bca2ec ("bootconfig: Fix to check the xbc_node is used before free it")
> 
> from the ftrace tree.
> 
> The new memblock_free_ptr() inroduced by Linus' tree copes with NULL
> pointers, so I just used that.  Which means that the ftrace tree patch
> will be redundant.
> 
> I fixed it up (see above) 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.
> 

No need. Linus had issues with the commit in my tree and did his own fix
instead, which is what is conflicting. Let me go and remove those commits
from my for-next branch.

-- Steve

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  kernel/trace/trace.c

between commit:

  b220c049d519 ("tracing: Check length before giving out the filter buffer")

from Linus' tree and commit:

  36590c50b2d0 ("tracing: Merge irqflags + preempt counter.")

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.c
index b5815a022ecc,b79bcacdd6f9..000000000000
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@@ -2745,8 -2739,8 +2739,8 @@@ trace_event_buffer_lock_reserve(struct 
  	    (entry = this_cpu_read(trace_buffered_event))) {
  		/* Try to use the per cpu buffer first */
  		val = this_cpu_inc_return(trace_buffered_event_cnt);
 -		if (val == 1) {
 +		if ((len < (PAGE_SIZE - sizeof(*entry))) && val == 1) {
- 			trace_event_setup(entry, type, flags, pc);
+ 			trace_event_setup(entry, type, trace_ctx);
  			entry->array[0] = len;
  			return entry;
  		}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  kernel/trace/ring_buffer.c

between commit:

  68e10d5ff512 ("ring-buffer: Always check to put back before stamp when crossing pages")

from Linus' tree and commit:

  5b7be9c709e1 ("ring-buffer: Add test to validate the time stamp deltas")

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/ring_buffer.c
index a6268e09160a,7cd888ee9ac7..000000000000
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@@ -3234,12 -3391,16 +3391,14 @@@ __rb_reserve_next(struct ring_buffer_pe
  
  	/* See if we shot pass the end of this buffer page */
  	if (unlikely(write > BUF_PAGE_SIZE)) {
 -		if (tail != w) {
 -			/* before and after may now different, fix it up*/
 -			b_ok = rb_time_read(&cpu_buffer->before_stamp, &info->before);
 -			a_ok = rb_time_read(&cpu_buffer->write_stamp, &info->after);
 -			if (a_ok && b_ok && info->before != info->after)
 -				(void)rb_time_cmpxchg(&cpu_buffer->before_stamp,
 -						      info->before, info->after);
 -		}
 +		/* before and after may now different, fix it up*/
 +		b_ok = rb_time_read(&cpu_buffer->before_stamp, &info->before);
 +		a_ok = rb_time_read(&cpu_buffer->write_stamp, &info->after);
 +		if (a_ok && b_ok && info->before != info->after)
 +			(void)rb_time_cmpxchg(&cpu_buffer->before_stamp,
 +					      info->before, info->after);
+ 		if (a_ok && b_ok)
+ 			check_buffer(cpu_buffer, info, CHECK_FULL_PAGE);
  		return rb_move_tail(cpu_buffer, tail, info);
  	}
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]

Hi all,

On Tue, 8 Dec 2020 16:02:22 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the ftrace tree got a conflict in:
> 
>   kernel/trace/ring_buffer.c
> 
> between commit:
> 
>   68e10d5ff512 ("ring-buffer: Always check to put back before stamp when crossing pages")
> 
> from Linus' tree and commit:
> 
>   5b7be9c709e1 ("ring-buffer: Add test to validate the time stamp deltas")
> 
> 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/ring_buffer.c
> index a6268e09160a,7cd888ee9ac7..000000000000
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@@ -3234,12 -3391,16 +3391,14 @@@ __rb_reserve_next(struct ring_buffer_pe
>   
>   	/* See if we shot pass the end of this buffer page */
>   	if (unlikely(write > BUF_PAGE_SIZE)) {
>  -		if (tail != w) {
>  -			/* before and after may now different, fix it up*/
>  -			b_ok = rb_time_read(&cpu_buffer->before_stamp, &info->before);
>  -			a_ok = rb_time_read(&cpu_buffer->write_stamp, &info->after);
>  -			if (a_ok && b_ok && info->before != info->after)
>  -				(void)rb_time_cmpxchg(&cpu_buffer->before_stamp,
>  -						      info->before, info->after);
>  -		}
>  +		/* before and after may now different, fix it up*/
>  +		b_ok = rb_time_read(&cpu_buffer->before_stamp, &info->before);
>  +		a_ok = rb_time_read(&cpu_buffer->write_stamp, &info->after);
>  +		if (a_ok && b_ok && info->before != info->after)
>  +			(void)rb_time_cmpxchg(&cpu_buffer->before_stamp,
>  +					      info->before, info->after);
> + 		if (a_ok && b_ok)
> + 			check_buffer(cpu_buffer, info, CHECK_FULL_PAGE);
>   		return rb_move_tail(cpu_buffer, tail, info);
>   	}
>   

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Steven Rostedt]

On Tue, 15 Dec 2020 07:37:25 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:


> > + 			check_buffer(cpu_buffer, info, CHECK_FULL_PAGE);
> >   		return rb_move_tail(cpu_buffer, tail, info);
> >   	}
> >     
> 
> Just a reminder that this conflict still exists.
> 

Thanks for the reminder. Both updates were done by me, and I assumed that
the fix was trivial enough for Linus to figure out.

But I'll try to remember to include a note about it before sending to Linus.

Cheers,

-- Steve

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  include/linux/compiler.h

between commit:

  37686b1353cf ("tracing: Improve "if" macro code generation")

from Linus' tree and commit:

  a15fd609ad53 ("tracing: Simplify "if" macro code")

from the ftrace tree.

I fixed it up (I just used the latter version) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Steven Rostedt]

On Thu, 16 May 2019 11:05:48 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the ftrace tree got a conflict in:
> 
>   include/linux/compiler.h
> 
> between commit:
> 
>   37686b1353cf ("tracing: Improve "if" macro code generation")
> 
> from Linus' tree and commit:
> 
>   a15fd609ad53 ("tracing: Simplify "if" macro code")
> 
> from the ftrace tree.
> 
> I fixed it up (I just used the latter version) 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.
> 

Hi Stephen,

I mentioned this conflict and the entry_64.S one to Linus when
submitting my pull request. I fixed it up too in my ftrace/conflicts
branch.

Thanks!

-- Steve

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

Hi Steve,

On Wed, 15 May 2019 21:53:05 -0400 Steven Rostedt <rostedt@goodmis.org> wrote:
>
> I mentioned this conflict and the entry_64.S one to Linus when
> submitting my pull request. I fixed it up too in my ftrace/conflicts
> branch.

And he has merged your branch now, so all good.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2141 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  arch/x86/entry/entry_64.S

between commits:

  8f34c5b5afce ("x86/exceptions: Make IST index zero based")
  3207426925d2 ("x86/exceptions: Disconnect IST index and stack order")
  2a594d4ccf3f ("x86/exceptions: Split debug IST stack")

from Linus' tree and commit:

  2700fefdb2d9 ("x86_64: Add gap to int3 to allow for call emulation")

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 arch/x86/entry/entry_64.S
index 20e45d9b4e15,27fcc6fbdd52..000000000000
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@@ -878,7 -879,7 +878,7 @@@ apicinterrupt IRQ_WORK_VECTOR			irq_wor
   * @paranoid == 2 is special: the stub will never switch stacks.  This is for
   * #DF: if the thread stack is somehow unusable, we'll still get a useful OOPS.
   */
- .macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 ist_offset=0
 -.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 create_gap=0
++.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 ist_offset=0 create_gap=0
  ENTRY(\sym)
  	UNWIND_HINT_IRET_REGS offset=\has_error_code*8
  
@@@ -1128,8 -1143,8 +1142,8 @@@ apicinterrupt3 HYPERV_STIMER0_VECTOR 
  	hv_stimer0_callback_vector hv_stimer0_vector_handler
  #endif /* CONFIG_HYPERV */
  
 -idtentry debug			do_debug		has_error_code=0	paranoid=1 shift_ist=DEBUG_STACK
 +idtentry debug			do_debug		has_error_code=0	paranoid=1 shift_ist=IST_INDEX_DB ist_offset=DB_STACK_OFFSET
- idtentry int3			do_int3			has_error_code=0
+ idtentry int3			do_int3			has_error_code=0	create_gap=1
  idtentry stack_segment		do_stack_segment	has_error_code=1
  
  #ifdef CONFIG_XEN_PV

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]

Hi Steven,

Today's linux-next merge of the ftrace tree got a conflict in:

  kernel/events/uprobes.c

between commit:

  788faab70d5a ("perf, tools: Use correct articles in comments")

from Linus' tree and commit:

  38e967ae1e60 ("Uprobes: Simplify uprobe_register() body")

from the ftrace tree.

I fixed it up (the latter moved the uprobe_unregister function - 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/events/uprobes.c
index aed1ba569954,c0418ba52ba8..000000000000
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@@ -860,7 -856,28 +856,28 @@@ __uprobe_unregister(struct uprobe *upro
  }
  
  /*
-  * uprobe_register - register a probe
 - * uprobe_unregister - unregister a already registered probe.
++ * uprobe_unregister - unregister an already registered probe.
+  * @inode: the file in which the probe has to be removed.
+  * @offset: offset from the start of the file.
+  * @uc: identify which probe if multiple probes are colocated.
+  */
+ void uprobe_unregister(struct inode *inode, loff_t offset, struct uprobe_consumer *uc)
+ {
+ 	struct uprobe *uprobe;
+ 
+ 	uprobe = find_uprobe(inode, offset);
+ 	if (WARN_ON(!uprobe))
+ 		return;
+ 
+ 	down_write(&uprobe->register_rwsem);
+ 	__uprobe_unregister(uprobe, uc);
+ 	up_write(&uprobe->register_rwsem);
+ 	put_uprobe(uprobe);
+ }
+ EXPORT_SYMBOL_GPL(uprobe_unregister);
+ 
+ /*
+  * __uprobe_register - register a probe
   * @inode: the file in which the probe has to be placed.
   * @offset: offset from the start of the file.
   * @uc: information on howto handle the probe..

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

Hi Steven,

Today's linux-next merge of the ftrace tree got a conflict in:

  kernel/trace/trace_stack.c

between commit:

  a2d762904832 ("tracing: Have stack tracer force RCU to be watching")

from Linus' tree and commit:

  d332736df0c2 ("tracing: Rename max_stack_lock to stack_trace_max_lock")

from the ftrace tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/trace/trace_stack.c
index 8abf1ba18085,0bd212af406c..000000000000
--- a/kernel/trace/trace_stack.c
+++ b/kernel/trace/trace_stack.c
@@@ -85,19 -91,9 +91,19 @@@ check_stack(unsigned long ip, unsigned 
  	if (!object_is_on_stack(stack))
  		return;
  
 +	/* Can't do this from NMI context (can cause deadlocks) */
 +	if (in_nmi())
 +		return;
 +
  	local_irq_save(flags);
- 	arch_spin_lock(&max_stack_lock);
+ 	arch_spin_lock(&stack_trace_max_lock);
  
 +	/*
 +	 * RCU may not be watching, make it see us.
 +	 * The stack trace code uses rcu_sched.
 +	 */
 +	rcu_irq_enter();
 +
  	/* In case another CPU set the tracer_frame on us */
  	if (unlikely(!frame_size))
  		this_size -= tracer_frame;
@@@ -179,8 -175,7 +185,8 @@@
  	}
  
   out:
 +	rcu_irq_exit();
- 	arch_spin_unlock(&max_stack_lock);
+ 	arch_spin_unlock(&stack_trace_max_lock);
  	local_irq_restore(flags);
  }
  

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

[Steven Rostedt]

On Thu, 5 Nov 2015 13:51:40 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Steven,
> 
> Today's linux-next merge of the ftrace tree got a conflict in:
> 
>   kernel/trace/trace_stack.c
> 
> between commit:
> 
>   a2d762904832 ("tracing: Have stack tracer force RCU to be watching")
> 
> from Linus' tree and commit:
> 
>   d332736df0c2 ("tracing: Rename max_stack_lock to stack_trace_max_lock")
> 
> from the ftrace tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 

Thanks, the fix looks good.

-- Steve

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

Hi Steven,

Today's linux-next merge of the ftrace tree got a conflict in
kernel/panic.c between commit dcb6b45254e2 ("panic: add cpu/pid to
warn_slowpath_common in WARNING printk()s") from the  tree and commit
de7edd31457b ("tracing: Disable tracing on warning") from the ftrace tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/panic.c
index 9771231,4cea6cc..0000000
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@@ -399,9 -400,10 +400,11 @@@ struct slowpath_args 
  static void warn_slowpath_common(const char *file, int line, void *caller,
  				 unsigned taint, struct slowpath_args *args)
  {
+ 	disable_trace_on_warning();
+ 
 -	printk(KERN_WARNING "------------[ cut here ]------------\n");
 -	printk(KERN_WARNING "WARNING: at %s:%d %pS()\n", file, line, caller);
 +	pr_warn("------------[ cut here ]------------\n");
 +	pr_warn("WARNING: CPU: %d PID: %d at %s:%d %pS()\n",
 +		raw_smp_processor_id(), current->pid, file, line, caller);
  
  	if (args)
  		vprintk(args->fmt, args->args);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

Hi Steven,

Today's linux-next merge of the ftrace tree got a conflict in
kernel/trace/ftrace.c between commit b67bfe0d42ca ("hlist: drop the node
parameter from iterators") from Linus' tree and commit f1943977e664
("tracing: Get rid of unneeded key calculation in ftrace_hash_move()")
and e1df4cb682ab ("ftrace: Fix function probe to only enable needed
functions") from the ftrace tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/trace/ftrace.c
index b3fde6d,9b44abb..0000000
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@@ -761,9 -755,10 +754,9 @@@ ftrace_find_profiled_func(struct ftrace
  {
  	struct ftrace_profile *rec;
  	struct hlist_head *hhd;
 -	struct hlist_node *n;
  	unsigned long key;
  
- 	key = hash_long(ip, ftrace_profile_bits);
+ 	key = hash_long(ip, FTRACE_PROFILE_HASH_BITS);
  	hhd = &stat->hash[key];
  
  	if (hlist_empty(hhd))
@@@ -1371,11 -1354,7 +1363,7 @@@ ftrace_hash_move(struct ftrace_ops *ops
  	size = 1 << src->size_bits;
  	for (i = 0; i < size; i++) {
  		hhd = &src->buckets[i];
 -		hlist_for_each_entry_safe(entry, tp, tn, hhd, hlist) {
 +		hlist_for_each_entry_safe(entry, tn, hhd, hlist) {
- 			if (bits > 0)
- 				key = hash_long(entry->ip, bits);
- 			else
- 				key = 0;
  			remove_hash_entry(src, entry);
  			__add_hash_entry(new_hash, entry);
  		}
@@@ -3062,8 -3075,13 +3070,13 @@@ static voi
  __unregister_ftrace_function_probe(char *glob, struct ftrace_probe_ops *ops,
  				  void *data, int flags)
  {
+ 	struct ftrace_func_entry *rec_entry;
  	struct ftrace_func_probe *entry;
+ 	struct ftrace_func_probe *p;
+ 	struct ftrace_hash **orig_hash = &trace_probe_ops.filter_hash;
+ 	struct list_head free_list;
+ 	struct ftrace_hash *hash;
 -	struct hlist_node *n, *tmp;
 +	struct hlist_node *tmp;
  	char str[KSYM_SYMBOL_LEN];
  	int type = MATCH_FULL;
  	int i, len = 0;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]

Hi Steven,

Today's linux-next merge of the ftrace tree got a conflict in
kernel/trace/trace.c between commit 2930e04d00e1 ("tracing: Fix race with
update_max_tr_single and changing tracers") from Linus' tree and commits
2b6080f28c7c ("tracing: Encapsulate global_trace and remove dependencies
on global vars") and 45ad21ca5530 ("tracing: Have trace_array keep track
if snapshot buffer is allocated") from the ftrace tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/trace/trace.c
index 7ba7fc7,829b2be..963491a
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@@ -744,11 -904,8 +904,11 @@@ update_max_tr_single(struct trace_arra
  		return;
  
  	WARN_ON_ONCE(!irqs_disabled());
- 	if (!current_trace->allocated_snapshot) {
 -	if (WARN_ON_ONCE(!tr->allocated_snapshot))
++	if (!tr->allocated_snapshot) {
 +		/* Only the nop tracer should hit this when disabling */
- 		WARN_ON_ONCE(current_trace != &nop_trace);
++		WARN_ON_ONCE(tr->current_trace != &nop_trace);
  		return;
 +	}
  
  	arch_spin_lock(&ftrace_max_lock);
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the ftrace tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

Hi Steven,

Today's linux-next merge of the ftrace tree got a conflict in
kernel/trace/ftrace.c between commit b67bfe0d42ca ("hlist: drop the node
parameter from iterators") from Linus' tree and commit e1df4cb682ab
("ftrace: Fix function probe to only enable needed functions") from the
ftrace tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/trace/ftrace.c
index ab25b88,2577082..0000000
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@@ -3063,8 -3087,13 +3083,13 @@@ static voi
  __unregister_ftrace_function_probe(char *glob, struct ftrace_probe_ops *ops,
  				  void *data, int flags)
  {
+ 	struct ftrace_func_entry *rec_entry;
  	struct ftrace_func_probe *entry;
+ 	struct ftrace_func_probe *p;
+ 	struct ftrace_hash **orig_hash = &trace_probe_ops.filter_hash;
+ 	struct list_head free_list;
+ 	struct ftrace_hash *hash;
 -	struct hlist_node *n, *tmp;
 +	struct hlist_node *tmp;
  	char str[KSYM_SYMBOL_LEN];
  	int type = MATCH_FULL;
  	int i, len = 0;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Steven Rostedt]

On Mon, 2013-03-18 at 13:00 +1100, Stephen Rothwell wrote:
> Hi Steven,
> 
> Today's linux-next merge of the ftrace tree got a conflict in
> kernel/trace/ftrace.c between commit b67bfe0d42ca ("hlist: drop the node
> parameter from iterators") from Linus' tree and commit e1df4cb682ab
> ("ftrace: Fix function probe to only enable needed functions") from the
> ftrace tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 

Looks fine, thanks.

-- Steve