linux-next: build warnings after merge of the tip tree

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

After merging the tip tree, today's linux-next build (x864 allmodconfig)
produced these new warnings:

vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0

[ Note I was already getting these:
arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_2block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_4block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx() falls through to next function poly1305_blocks_x86_64()
arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_emit_avx() falls through to next function poly1305_emit_x86_64()
arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx2() falls through to next function poly1305_blocks_x86_64()
]

I have no idea what has caused this ...

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x864 allmodconfig)
> produced these new warnings:
> 
> vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0

Hurmph, lemme go figure out where that code comes from, I've not seen
those.

> [ Note I was already getting these:
> arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_2block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
> arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_4block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
> arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx() falls through to next function poly1305_blocks_x86_64()
> arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_emit_avx() falls through to next function poly1305_emit_x86_64()
> arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx2() falls through to next function poly1305_blocks_x86_64()

Yes, those are somewhere on the todo list, lemme bump them.

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > produced these new warnings:
> > 
> > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> 
> Hurmph, lemme go figure out where that code comes from, I've not seen
> those.

Ahh, something tracing. I'll go do some patches on top of it.

Also, folks, I'm thinking we should start to move to __fexit__, if CET
SHSTK ever wants to come to kernel land return trampolines will
insta-stop working.

Hjl, do you think we could get -mfexit to go along with -mfentry ?

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > produced these new warnings:
> > > 
> > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > 
> > Hurmph, lemme go figure out where that code comes from, I've not seen
> > those.
> 
> Ahh, something tracing. I'll go do some patches on top of it.

Also, that x86 patch has never his x86@kernel.org and doesn't have an
ACK from any x86 person :-(((

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Mon, Mar 21, 2022 at 02:08:23PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > > 
> > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > produced these new warnings:
> > > > 
> > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > 
> > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > those.
> > 
> > Ahh, something tracing. I'll go do some patches on top of it.
> 
> Also, that x86 patch has never his x86@kernel.org and doesn't have an
> ACK from any x86 person :-(((

Worse, it adds a 3rd return trampoline without replacing any of the
existing two :-(

Why was this merged?

Re: linux-next: build warnings after merge of the tip tree

[Mark Rutland]

On Mon, Mar 21, 2022 at 02:45:16PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 02:08:23PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > > 
> > > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > > produced these new warnings:
> > > > > 
> > > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > 
> > > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > > those.
> > > 
> > > Ahh, something tracing. I'll go do some patches on top of it.
> > 
> > Also, that x86 patch has never his x86@kernel.org and doesn't have an
> > ACK from any x86 person :-(((
> 
> Worse, it adds a 3rd return trampoline without replacing any of the
> existing two :-(

Likewise; I have the same complaints for the arm64 patch.

I haven't had the chance to review/ack that, and I'm actively working on
improving out unwinder and the way it interacts with the various *existing*
trampolines, so adding yat another is *not* good.

> Why was this merged?

Likewise, same question for arm64?

Thanks,
Mark.

Re: linux-next: build warnings after merge of the tip tree

[Steven Rostedt]

On Mon, 21 Mar 2022 14:04:05 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> Ahh, something tracing. I'll go do some patches on top of it.
> 
> Also, folks, I'm thinking we should start to move to __fexit__, if CET
> SHSTK ever wants to come to kernel land return trampolines will
> insta-stop working.
> 
> Hjl, do you think we could get -mfexit to go along with -mfentry ?

If we do every add a -mfexit, we will need to add a __ftail__ call.
Because, the current function exit tracing works for functions, even with
tail calls.


int funcA () {
	[..]
	return funcB();
}

Can turn into:

	[..]
	pop all stack from funcA
	load reg params to funcB
	jmp funcB

Then when funcB does does it's

	[..]
	ret

It will pop the call site of funcA (not the call site of funcB) and return
to wherever called funcA with the proper return values.

This currently works with function graph and kretprobe tracing because of
the shadow stack. Let's say we traced both funcA and funcB

funcA:
	call __fentry__

			Replace caller address with graph_trampoline and
			store the return caller into the shadow stack.

	[..]
	jmp funcB

funcB:
	call __fentry__

			Replace caller address with graph_trampoline and
			store the return caller (which is the
			graph_trampoline that was switched earlier) in the
			shadow stack.

	[..]
	ret

			Returns to the graph_trampoline and we trace the
			return of funcB. Then we pop off the shadow stack
			and jump to that. But the shadow stack had a call
			to the graph_trampoline, which gets called again.

			Returns to the graph_trampoline and we trace the
			return of funcA. Then we pop off the shadow stack
			and jump to that, which is the original caller to
			funcA.

That is, the current algorithm traces the end of both funcA and funcB
without issue, because of how the shadow stack works.

Now if we add a __fexit__, we will need a way to tell the tracers how to
record this scenario. That is why I'm thinking of a jmp to __ftail__.

Perhaps something like:

funcA:
	call __fentry__
	[..]
	push address of funcB
	jmp __ftail__
	jmp funcB

Where, __ftail__ would do at the end:

	ret

To jump to funcB and we skip the jmp to funcB anyway.

And to "nop" it out, we would have to convert it to.

funcA:
	call __fentry__
	[..]
	jmp 1
	jmp __ftail__
1:	jmp funcB


This is one way I can think of if we include a __fexit__. But to maintain
backward compatibility to function graph tracing (which is a requirement),
we need to be able to handle such cases.

Perhaps this is a good topic to bring up at Plumbers? :-)

Do I need to submit a tracing MC, or can we have this conversation at a
compiler / toolchain MC?

-- Steve

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Mon, Mar 21, 2022 at 02:45:16PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 02:08:23PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > > 
> > > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > > produced these new warnings:
> > > > > 
> > > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > 
> > > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > > those.
> > > 
> > > Ahh, something tracing. I'll go do some patches on top of it.
> > 
> > Also, that x86 patch has never his x86@kernel.org and doesn't have an
> > ACK from any x86 person :-(((
> 
> Worse, it adds a 3rd return trampoline without replacing any of the
> existing two :-(
> 
> Why was this merged?

It additionally gets ret wrong:

  vmlinux.o: warning: objtool: arch_rethook_trampoline()+0x4a: missing int3 after ret

and afaict regs->ss is garbage (much like kretprobes it appears).

Can we please unmerge this stuff and try again later?

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Mon, Mar 21, 2022 at 04:28:06PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 02:45:16PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 02:08:23PM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > > > produced these new warnings:
> > > > > > 
> > > > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > 
> > > > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > > > those.
> > > > 
> > > > Ahh, something tracing. I'll go do some patches on top of it.
> > > 
> > > Also, that x86 patch has never his x86@kernel.org and doesn't have an
> > > ACK from any x86 person :-(((
> > 
> > Worse, it adds a 3rd return trampoline without replacing any of the
> > existing two :-(
> > 
> > Why was this merged?
> 
> It additionally gets ret wrong:
> 
>   vmlinux.o: warning: objtool: arch_rethook_trampoline()+0x4a: missing int3 after ret
> 
> and afaict regs->ss is garbage (much like kretprobes it appears).
> 
> Can we please unmerge this stuff and try again later?

This landing in -next only today (after having been committed last
friday night) is another clue it should probably go next round.

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Mon, Mar 21, 2022 at 11:28:05AM -0400, Steven Rostedt wrote:
> On Mon, 21 Mar 2022 14:04:05 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:

> > Also, folks, I'm thinking we should start to move to __fexit__, if CET
> > SHSTK ever wants to come to kernel land return trampolines will
> > insta-stop working.
> > 
> > Hjl, do you think we could get -mfexit to go along with -mfentry ?

> int funcA () {
> 	[..]
> 	return funcB();
> }

> This currently works with function graph and kretprobe tracing because of
> the shadow stack. Let's say we traced both funcA and funcB
> 
> funcA:
> 	call __fentry__
			push funcA on trace-stack
> 
> 	[..]
> 	jmp funcB
> 
> funcB:
> 	call __fentry__
			push funcB on trace-stack
> 
> 	[..]
	call __fexit__
			pop trace-stack until empty
			  'exit funcB'
			  'exit funcA'

> 	ret

> 
> That is, the current algorithm traces the end of both funcA and funcB
> without issue, because of how the shadow stack works.

And it all works, no? Or what am I missing?

Re: linux-next: build warnings after merge of the tip tree

[Steven Rostedt]

On Mon, 21 Mar 2022 17:04:28 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Mar 21, 2022 at 11:28:05AM -0400, Steven Rostedt wrote:
> > On Mon, 21 Mar 2022 14:04:05 +0100
> > Peter Zijlstra <peterz@infradead.org> wrote:  
> 
> > > Also, folks, I'm thinking we should start to move to __fexit__, if CET
> > > SHSTK ever wants to come to kernel land return trampolines will
> > > insta-stop working.
> > > 
> > > Hjl, do you think we could get -mfexit to go along with -mfentry ?  
> 
> > int funcA () {
> > 	[..]
> > 	return funcB();
> > }  
> 
> > This currently works with function graph and kretprobe tracing because of
> > the shadow stack. Let's say we traced both funcA and funcB
> > 
> > funcA:
> > 	call __fentry__  
> 			push funcA on trace-stack
> > 
> > 	[..]
> > 	jmp funcB
> > 
> > funcB:
> > 	call __fentry__  
> 			push funcB on trace-stack
> > 
> > 	[..]  
> 	call __fexit__
> 			pop trace-stack until empty
> 			  'exit funcB'
> 			  'exit funcA'

And what happens if funcC called funcA and it too was on the stack. We pop
that too? But it's not done yet, because calling of funcA was not a tail
call.

-- Steve


> 
> > 	ret  
> 
> > 
> > That is, the current algorithm traces the end of both funcA and funcB
> > without issue, because of how the shadow stack works.  
> 
> And it all works, no? Or what am I missing?

Re: linux-next: build warnings after merge of the tip tree

[Steven Rostedt]

On Mon, 21 Mar 2022 12:12:09 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> > > funcB:
> > > 	call __fentry__    
> > 			push funcB on trace-stack  
> > > 
> > > 	[..]    
> > 	call __fexit__
> > 			pop trace-stack until empty
> > 			  'exit funcB'
> > 			  'exit funcA'  
> 
> And what happens if funcC called funcA and it too was on the stack. We pop
> that too? But it's not done yet, because calling of funcA was not a tail
> call.

And I just thought of another issue, where even my solution wont fix it.
What happens if we trace funcA but not funcB? How do we get to trace the
end of funcA?

-- Steve

Re: linux-next: build warnings after merge of the tip tree

[Steven Rostedt]

On Mon, 21 Mar 2022 12:15:49 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> And I just thought of another issue, where even my solution wont fix it.
> What happens if we trace funcA but not funcB? How do we get to trace the
> end of funcA?

The only solution I can think of to handle all these cases is if you enable
-mfexit, you have to disable tail calls completely. That's going to cause
a performance impact.

Perhaps we need need compiler help to give us a way to hijack the return
address. But is there a way to do this and still not give up the security
that CET SHSTK gives us?

Or maybe another solution is:

funcA:
	[..]
	jmp funcB
	call __fexit__
	ret

And if funcA is being traced, we change jmp to a call.

	[..]
	call funcB
	call __fexit__
	ret

Such that we only remove the tail calls if we enable tracing on the
function with the tail call.

-- Steve

Re: linux-next: build warnings after merge of the tip tree

[Linus Torvalds]

On Mon, Mar 21, 2022 at 8:46 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> This landing in -next only today (after having been committed last
> friday night) is another clue it should probably go next round.

I went and looked at lore to get the context that I didn't get in this
email that I was added to the participants for.

I didn't find the context there either.

Sure, I found the thread, but the whole "that x86 patch" that you
refer to was never actually specified even in the full thread as far
as I can tell. I see that there is an arm64 equivalent too of what you
are complaining about, and I have no idea about that one either..

Mind actually giving the full details so that we don't have to go
re-do the work you already did?

Because right now I know something is wrong, I know the warnings, but
I don't actually have any handle on the actual patches to look out
for.

It's presumably not in any of the pull requests I already have
pending, but it would be nice if I saw some details of _what_ you are
complaining about, and not just the complaint itself ;)

                     Linus

Re: linux-next: build warnings after merge of the tip tree

[Steven Rostedt]

On Mon, 21 Mar 2022 12:22:59 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> Or maybe another solution is:
> 
> funcA:
> 	[..]
> 	jmp funcB
> 	call __fexit__
> 	ret
> 
> And if funcA is being traced, we change jmp to a call.
> 
> 	[..]
> 	call funcB
> 	call __fexit__

We could also make __fexit__ a tail call:

> 	ret


funcA:
	[..]
	call funcB
	jmp __fexit__

We would also need a way to know that funcA has a tail call at the end. So
more help from either the compiler or objtool.

-- Steve

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Mon, Mar 21, 2022 at 12:15:49PM -0400, Steven Rostedt wrote:
> On Mon, 21 Mar 2022 12:12:09 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > > > funcB:
> > > > 	call __fentry__    
> > > 			push funcB on trace-stack  
> > > > 
> > > > 	[..]    
> > > 	call __fexit__
> > > 			pop trace-stack until empty
> > > 			  'exit funcB'
> > > 			  'exit funcA'  
> > 
> > And what happens if funcC called funcA and it too was on the stack. We pop
> > that too? But it's not done yet, because calling of funcA was not a tail
> > call.

Hmm, yeah, how about we have __ftail__ mark the left function.

func_B()
{
	...
}

func_A()
{
	...
	return func_B();
}

func_C()
{
	func_A();
	...
	return;
}

func_B:
	call __fentry__	/* push func_B */
	...
	call __fexit__	/* pop 1 + tails */
	ret

func_A:
	call __fentry__ /* push func_A */
	...
	call __ftail__  /* mark func_A tail */
	jmp func_B

func_C:
	call __fentry__ /* push func_C */
	call func_A;
	...
	call __fexit__  /* pop 1 + tails */
	ret;


Then the stack at the end of func_B looks something like:

	func_C
	func_A (tail)
	func_B

And it will pop func_B plus all tails (func_A).

> And I just thought of another issue, where even my solution wont fix it.
> What happens if we trace funcA but not funcB? How do we get to trace the
> end of funcA?

Disallow tail calls to notrace?

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Mon, Mar 21, 2022 at 09:37:35AM -0700, Linus Torvalds wrote:
> On Mon, Mar 21, 2022 at 8:46 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > This landing in -next only today (after having been committed last
> > friday night) is another clue it should probably go next round.
> 
> I went and looked at lore to get the context that I didn't get in this
> email that I was added to the participants for.
> 
> I didn't find the context there either.
> 
> Sure, I found the thread, but the whole "that x86 patch" that you
> refer to was never actually specified even in the full thread as far
> as I can tell. I see that there is an arm64 equivalent too of what you
> are complaining about, and I have no idea about that one either..
> 
> Mind actually giving the full details so that we don't have to go
> re-do the work you already did?
> 
> Because right now I know something is wrong, I know the warnings, but
> I don't actually have any handle on the actual patches to look out
> for.
> 
> It's presumably not in any of the pull requests I already have
> pending, but it would be nice if I saw some details of _what_ you are
> complaining about, and not just the complaint itself ;)

Duh, right. It's this series:

  https://lore.kernel.org/bpf/164757541675.26179.17727138330733641017.git-patchwork-notify@kernel.org/

That went into bpf-next last Friday. I just checked but haven't found a
pull for it yet.

Re: linux-next: build warnings after merge of the tip tree

[Steven Rostedt]

On Mon, 21 Mar 2022 17:40:32 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> func_B:
> 	call __fentry__	/* push func_B */
> 	...
> 	call __fexit__	/* pop 1 + tails */
> 	ret
> 
> func_A:
> 	call __fentry__ /* push func_A */
> 	...
> 	call __ftail__  /* mark func_A tail */
> 	jmp func_B
> 
> func_C:
> 	call __fentry__ /* push func_C */
> 	call func_A;
> 	...
> 	call __fexit__  /* pop 1 + tails */
> 	ret;

This also assumes that we need to trace everything that is marked. I
mentioned in another email, what do we do if we only trace funcA?

-- Steve

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > produced these new warnings:
> > > 
> > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > 
> > Hurmph, lemme go figure out where that code comes from, I've not seen
> > those.
> 
> Ahh, something tracing. I'll go do some patches on top of it.

The below gets rid of the objtool warnings.

But I still think it's fairly terrible to get a (flawed) carbon copy of
the kretprobe code. Also, I think both should fix regs->ss.

---
diff --git a/arch/x86/kernel/rethook.c b/arch/x86/kernel/rethook.c
index f0f2f0608282..227a1890a984 100644
--- a/arch/x86/kernel/rethook.c
+++ b/arch/x86/kernel/rethook.c
@@ -20,6 +20,7 @@ asm(
 	".type arch_rethook_trampoline, @function\n"
 	"arch_rethook_trampoline:\n"
 #ifdef CONFIG_X86_64
+	ANNOTATE_NOENDBR
 	/* Push a fake return address to tell the unwinder it's a kretprobe. */
 	"	pushq $arch_rethook_trampoline\n"
 	UNWIND_HINT_FUNC
@@ -48,7 +49,7 @@ asm(
 	"	addl $4, %esp\n"
 	"	popfl\n"
 #endif
-	"	ret\n"
+	ASM_RET
 	".size arch_rethook_trampoline, .-arch_rethook_trampoline\n"
 );
 NOKPROBE_SYMBOL(arch_rethook_trampoline);

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Mon, Mar 21, 2022 at 12:45:51PM -0400, Steven Rostedt wrote:
> On Mon, 21 Mar 2022 17:40:32 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > func_B:
> > 	call __fentry__	/* push func_B */
> > 	...
> > 	call __fexit__	/* pop 1 + tails */
> > 	ret
> > 
> > func_A:
> > 	call __fentry__ /* push func_A */
> > 	...
> > 	call __ftail__  /* mark func_A tail */
> > 	jmp func_B
> > 
> > func_C:
> > 	call __fentry__ /* push func_C */
> > 	call func_A;
> > 	...
> > 	call __fexit__  /* pop 1 + tails */
> > 	ret;
> 
> This also assumes that we need to trace everything that is marked. I
> mentioned in another email, what do we do if we only trace funcA?

Like I said later on; if we inhibit tail-calls to notrace, this goes
away.

Re: linux-next: build warnings after merge of the tip tree

[Linus Torvalds]

On Mon, Mar 21, 2022 at 9:45 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > It's presumably not in any of the pull requests I already have
> > pending, but it would be nice if I saw some details of _what_ you are
> > complaining about, and not just the complaint itself ;)
>
> Duh, right. It's this series:
>
>   https://lore.kernel.org/bpf/164757541675.26179.17727138330733641017.git-patchwork-notify@kernel.org/
>
> That went into bpf-next last Friday. I just checked but haven't found a
> pull for it yet.

Thanks. I can confirm it's not in any of the pull requests I have
pending, so I'll just start doing my normal work and try to remember
to look out for this issue later.

                 Linus

Re: linux-next: build warnings after merge of the tip tree

[Steven Rostedt]

On Mon, 21 Mar 2022 17:50:50 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> > This also assumes that we need to trace everything that is marked. I
> > mentioned in another email, what do we do if we only trace funcA?  
> 
> Like I said later on; if we inhibit tail-calls to notrace, this goes
> away.

Please no. The number of "notrace" functions is increasing to the point
that it's starting to make function tracing useless in a lot of
circumstances. I've already lost my ability to see when user space goes
into the kernel (which I have to hack up custom coding to enable again).

-- Steve

Re: linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

On Mon, 21 Mar 2022 09:52:58 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Mon, Mar 21, 2022 at 9:45 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > It's presumably not in any of the pull requests I already have
> > > pending, but it would be nice if I saw some details of _what_ you are
> > > complaining about, and not just the complaint itself ;)  
> >
> > Duh, right. It's this series:
> >
> >   https://lore.kernel.org/bpf/164757541675.26179.17727138330733641017.git-patchwork-notify@kernel.org/
> >
> > That went into bpf-next last Friday. I just checked but haven't found a
> > pull for it yet.  
> 
> Thanks. I can confirm it's not in any of the pull requests I have
> pending, so I'll just start doing my normal work and try to remember
> to look out for this issue later.

The normal path for bpf-next code is via the net-next tree.  But the
above series has not yet been merged into the net-next tree so is only
in the bpf-next tree.

So, what am I to do?  Drop the bpf-next tree from linux-next until this
is resolved?  Some input from the BPF people would be useful.

Dave, Jakub, please do not merge the bpf-bext tree into the net-next
tree for now.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Alexei Starovoitov]

On Mon, Mar 21, 2022 at 3:05 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Mon, 21 Mar 2022 09:52:58 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> > On Mon, Mar 21, 2022 at 9:45 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > > >
> > > > It's presumably not in any of the pull requests I already have
> > > > pending, but it would be nice if I saw some details of _what_ you are
> > > > complaining about, and not just the complaint itself ;)
> > >
> > > Duh, right. It's this series:
> > >
> > >   https://lore.kernel.org/bpf/164757541675.26179.17727138330733641017.git-patchwork-notify@kernel.org/
> > >
> > > That went into bpf-next last Friday. I just checked but haven't found a
> > > pull for it yet.
> >
> > Thanks. I can confirm it's not in any of the pull requests I have
> > pending, so I'll just start doing my normal work and try to remember
> > to look out for this issue later.
>
> The normal path for bpf-next code is via the net-next tree.  But the
> above series has not yet been merged into the net-next tree so is only
> in the bpf-next tree.
>
> So, what am I to do?  Drop the bpf-next tree from linux-next until this
> is resolved?  Some input from the BPF people would be useful.
>
> Dave, Jakub, please do not merge the bpf-bext tree into the net-next
> tree for now.

That makes little sense. It's not an unusual merge conflict.
Peter's endbr series conflict with Masami's fprobe.
Peter has a trivial patch that fixes objtool warning.
The question is how to land that patch.
I think the best is for Linus to apply it after bpf-next->net-next gets
merged.

We're preparing bpf-next PR right now.

Re: linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi Alexei,

On Mon, 21 Mar 2022 15:12:05 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> That makes little sense. It's not an unusual merge conflict.
> Peter's endbr series conflict with Masami's fprobe.
> Peter has a trivial patch that fixes objtool warning.
> The question is how to land that patch.
> I think the best is for Linus to apply it after bpf-next->net-next gets
> merged.

Peter has other concerns, please read the thread and consider them.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Alexei Starovoitov]

On Mon, Mar 21, 2022 at 3:46 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Alexei,
>
> On Mon, 21 Mar 2022 15:12:05 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> >
> > That makes little sense. It's not an unusual merge conflict.
> > Peter's endbr series conflict with Masami's fprobe.
> > Peter has a trivial patch that fixes objtool warning.
> > The question is how to land that patch.
> > I think the best is for Linus to apply it after bpf-next->net-next gets
> > merged.
>
> Peter has other concerns, please read the thread and consider them.

Masami is an expert in kprobe. He copy pasted a bit of kprobe logic
to make it into 'multi kprobe' (he calls it fprobe).
I believe he knows what he's doing.
Steven reviewed and tested that set.
We've tested it as well and don't have any correctness or api concerns.

Re: linux-next: build warnings after merge of the tip tree

[Steven Rostedt]

On Mon, 21 Mar 2022 15:50:17 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> > Peter has other concerns, please read the thread and consider them.  
> 
> Masami is an expert in kprobe. He copy pasted a bit of kprobe logic
> to make it into 'multi kprobe' (he calls it fprobe).
> I believe he knows what he's doing.
> Steven reviewed and tested that set.
> We've tested it as well and don't have any correctness or api concerns.

I tested it from a ftrace perspective, not an IBT or other work being done
in the x86 world.

I'm fine with the work being done in kernel/tracing/ but it still requires
the arch maintainer's acks for anything in arch/. I was under the
impression that the arch specific code was Cc'ing the arch maintainers
(which I always do when I touch their code). But I missed that they were
not. That's my fault, I should have caught that.

-- Steve

Re: linux-next: build warnings after merge of the tip tree

[Masami Hiramatsu]

On Mon, 21 Mar 2022 14:45:16 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Mar 21, 2022 at 02:08:23PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > > 
> > > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > > produced these new warnings:
> > > > > 
> > > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > 
> > > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > > those.
> > > 
> > > Ahh, something tracing. I'll go do some patches on top of it.
> > 
> > Also, that x86 patch has never his x86@kernel.org and doesn't have an
> > ACK from any x86 person :-(((
> 
> Worse, it adds a 3rd return trampoline without replacing any of the
> existing two :-(

Sorry about this. I missed to add Ccing to arch maintainers.
Let me check how I can fix those errors.

Thanks.

> 
> Why was this merged?


-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: linux-next: build warnings after merge of the tip tree

[Masami Hiramatsu]

On Mon, 21 Mar 2022 15:50:17 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> On Mon, Mar 21, 2022 at 3:46 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi Alexei,
> >
> > On Mon, 21 Mar 2022 15:12:05 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > >
> > > That makes little sense. It's not an unusual merge conflict.
> > > Peter's endbr series conflict with Masami's fprobe.
> > > Peter has a trivial patch that fixes objtool warning.
> > > The question is how to land that patch.
> > > I think the best is for Linus to apply it after bpf-next->net-next gets
> > > merged.
> >
> > Peter has other concerns, please read the thread and consider them.
> 
> Masami is an expert in kprobe. He copy pasted a bit of kprobe logic
> to make it into 'multi kprobe' (he calls it fprobe).
> I believe he knows what he's doing.
> Steven reviewed and tested that set.
> We've tested it as well and don't have any correctness or api concerns.

Sorry, that's my mistake to not Ccing to arch maintainers for the arch
dependent patches. Let me update and send v13 for this fprobe series.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: linux-next: build warnings after merge of the tip tree

[Alexei Starovoitov]

On Mon, Mar 21, 2022 at 9:51 PM Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> On Mon, 21 Mar 2022 15:50:17 -0700
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> > On Mon, Mar 21, 2022 at 3:46 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Hi Alexei,
> > >
> > > On Mon, 21 Mar 2022 15:12:05 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > > >
> > > > That makes little sense. It's not an unusual merge conflict.
> > > > Peter's endbr series conflict with Masami's fprobe.
> > > > Peter has a trivial patch that fixes objtool warning.
> > > > The question is how to land that patch.
> > > > I think the best is for Linus to apply it after bpf-next->net-next gets
> > > > merged.
> > >
> > > Peter has other concerns, please read the thread and consider them.
> >
> > Masami is an expert in kprobe. He copy pasted a bit of kprobe logic
> > to make it into 'multi kprobe' (he calls it fprobe).
> > I believe he knows what he's doing.
> > Steven reviewed and tested that set.
> > We've tested it as well and don't have any correctness or api concerns.
>
> Sorry, that's my mistake to not Ccing to arch maintainers for the arch
> dependent patches. Let me update and send v13 for this fprobe series.

No. Please read what I've said earlier.

Re: linux-next: build warnings after merge of the tip tree

[Masami Hiramatsu]

On Mon, 21 Mar 2022 17:48:54 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > > 
> > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > produced these new warnings:
> > > > 
> > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > 
> > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > those.
> > 
> > Ahh, something tracing. I'll go do some patches on top of it.
> 
> The below gets rid of the objtool warnings.

Yes, I confirmed that.

> 
> But I still think it's fairly terrible to get a (flawed) carbon copy of
> the kretprobe code.

Indeed. I would like to replace the trampoline code of kretprobe with
rethook, eventually. There is no reason why we keep the clone.
(But I need more arch maintainers help for that, there are too many
 archs implemented kretprobes)

> Also, I think both should fix regs->ss.

I'm not sure this part. Since the return trampoline should run in the same
context of the called function, isn't ss same there too?

Thank you,

> 
> ---
> diff --git a/arch/x86/kernel/rethook.c b/arch/x86/kernel/rethook.c
> index f0f2f0608282..227a1890a984 100644
> --- a/arch/x86/kernel/rethook.c
> +++ b/arch/x86/kernel/rethook.c
> @@ -20,6 +20,7 @@ asm(
>  	".type arch_rethook_trampoline, @function\n"
>  	"arch_rethook_trampoline:\n"
>  #ifdef CONFIG_X86_64
> +	ANNOTATE_NOENDBR
>  	/* Push a fake return address to tell the unwinder it's a kretprobe. */
>  	"	pushq $arch_rethook_trampoline\n"
>  	UNWIND_HINT_FUNC
> @@ -48,7 +49,7 @@ asm(
>  	"	addl $4, %esp\n"
>  	"	popfl\n"
>  #endif
> -	"	ret\n"
> +	ASM_RET
>  	".size arch_rethook_trampoline, .-arch_rethook_trampoline\n"
>  );
>  NOKPROBE_SYMBOL(arch_rethook_trampoline);


-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Mon, Mar 21, 2022 at 03:12:05PM -0700, Alexei Starovoitov wrote:
> 
> That makes little sense. It's not an unusual merge conflict.

It is not only that; it is adding code that with an x86 arch maintainer
hat on I've never seen and don't agree with. Same for arm64 apparently.

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Mon, Mar 21, 2022 at 12:54:19PM -0400, Steven Rostedt wrote:
> On Mon, 21 Mar 2022 17:50:50 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > > This also assumes that we need to trace everything that is marked. I
> > > mentioned in another email, what do we do if we only trace funcA?  
> > 
> > Like I said later on; if we inhibit tail-calls to notrace, this goes
> > away.
> 
> Please no. The number of "notrace" functions is increasing to the point
> that it's starting to make function tracing useless in a lot of
> circumstances. I've already lost my ability to see when user space goes
> into the kernel (which I have to hack up custom coding to enable again).

I really can't follow the argument there, nor on IRC.

Suppose:

notrace func_B()
{
	...
}

func_A()
{
	...
	return func_B();
}

then inhibiting tail calls would end up looking like:

func_A:
	call __fentry__
	...
	call func_B
	call __fexit__
	ret

Then A is fully traced, B is invisible, as per spec. What is the
problem?

The problem you initially had, of doing a tail-call into a notrace, was
that the __fexit__ call went missing, because notrace will obviously not
have that. But that's avoided by inhibiting all tail-calls between
notrace and !notrace functions (note that notrace must also not
tail-call !notrace).

Your worry seems to stem about loosing visiblilty of !notrace functions,
but AFAICT that doesn't happen.

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Tue, Mar 22, 2022 at 02:31:36PM +0900, Masami Hiramatsu wrote:

> > Also, I think both should fix regs->ss.
> 
> I'm not sure this part. Since the return trampoline should run in the same
> context of the called function, isn't ss same there too?

It creates pt_regs on the stack, so the trampolines do:

	push $arch_rethook_trampoline
	push %rsp
	pushf
	sub $24, %rsp /* cs, ip, orig_ax */
	push %rdi
	...
	push %r15

That means that if anybody looks at regs->ss, it'll find
$arch_rethook_trampoline, which isn't a valid segment descriptor, or am
I just really bad at counting today?

I'm thinking you want a copy of __KERNEL_DS in that stack slot, not a
function pointer.

Re: linux-next: build warnings after merge of the tip tree

[Masami Hiramatsu]

On Tue, 22 Mar 2022 09:08:22 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Mar 22, 2022 at 02:31:36PM +0900, Masami Hiramatsu wrote:
> 
> > > Also, I think both should fix regs->ss.
> > 
> > I'm not sure this part. Since the return trampoline should run in the same
> > context of the called function, isn't ss same there too?
> 
> It creates pt_regs on the stack, so the trampolines do:
> 
> 	push $arch_rethook_trampoline
> 	push %rsp
> 	pushf
> 	sub $24, %rsp /* cs, ip, orig_ax */
> 	push %rdi
> 	...
> 	push %r15
> 
> That means that if anybody looks at regs->ss, it'll find
> $arch_rethook_trampoline, which isn't a valid segment descriptor, or am
> I just really bad at counting today?

Ah, got it. It seems that the ss was skipped from the beginning, and
no one argued that.

> I'm thinking you want a copy of __KERNEL_DS in that stack slot, not a
> function pointer.

The function pointer is for unwinding stack which involves the kretprobe.
Anyway, I can add a slot for ss if it is neeeded. But if it always be
__KERNEL_DS, is it worth to save it?

Thank you,


-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:

> > [ Note I was already getting these:
> > arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_2block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
> > arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_4block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
> > arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx() falls through to next function poly1305_blocks_x86_64()
> > arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_emit_avx() falls through to next function poly1305_emit_x86_64()
> > arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx2() falls through to next function poly1305_blocks_x86_64()
> 
> Yes, those are somewhere on the todo list, lemme bump them.

So the chacha one seems relatively simple, see below.

---
diff --git a/arch/x86/crypto/chacha-avx512vl-x86_64.S b/arch/x86/crypto/chacha-avx512vl-x86_64.S
index 946f74dd6fba..259383e1ad44 100644
--- a/arch/x86/crypto/chacha-avx512vl-x86_64.S
+++ b/arch/x86/crypto/chacha-avx512vl-x86_64.S
@@ -172,7 +172,7 @@ SYM_FUNC_START(chacha_2block_xor_avx512vl)
 	# xor remaining bytes from partial register into output
 	mov		%rcx,%rax
 	and		$0xf,%rcx
-	jz		.Ldone8
+	jz		.Ldone2
 	mov		%rax,%r9
 	and		$~0xf,%r9
 
@@ -438,7 +438,7 @@ SYM_FUNC_START(chacha_4block_xor_avx512vl)
 	# xor remaining bytes from partial register into output
 	mov		%rcx,%rax
 	and		$0xf,%rcx
-	jz		.Ldone8
+	jz		.Ldone4
 	mov		%rax,%r9
 	and		$~0xf,%r9
 

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Tue, Mar 22, 2022 at 11:46:04AM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:

> > > arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx() falls through to next function poly1305_blocks_x86_64()
> > > arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_emit_avx() falls through to next function poly1305_emit_x86_64()
> > > arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx2() falls through to next function poly1305_blocks_x86_64()
> > 
> > Yes, those are somewhere on the todo list, lemme bump them.

The poly one is a little more involved since it's a perl script writing
asm O_O

Looking at the generated asm tough, the these are conditional tail-calls
and objtool *should* recognise them but doesn't...

This seems to cure.

---
 tools/objtool/check.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 6de5085e3e5a..b848e1ddd5d8 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1239,11 +1239,20 @@ static bool same_function(struct instruction *insn1, struct instruction *insn2)
 	return insn1->func->pfunc == insn2->func->pfunc;
 }
 
-static bool is_first_func_insn(struct instruction *insn)
+static bool is_first_func_insn(struct objtool_file *file, struct instruction *insn)
 {
-	return insn->offset == insn->func->offset ||
-	       (insn->type == INSN_ENDBR &&
-		insn->offset == insn->func->offset + insn->len);
+	if (insn->offset == insn->func->offset)
+		return true;
+
+	if (ibt) {
+		struct instruction *prev = prev_insn_same_sym(file, insn);
+
+		if (prev && prev->type == INSN_ENDBR &&
+		    insn->offset == insn->func->offset + prev->len)
+			return true;
+	}
+
+	return false;
 }
 
 /*
@@ -1327,7 +1336,7 @@ static int add_jump_destinations(struct objtool_file *file)
 				insn->jump_dest->func->pfunc = insn->func;
 
 			} else if (!same_function(insn, insn->jump_dest) &&
-				   is_first_func_insn(insn->jump_dest)) {
+				   is_first_func_insn(file, insn->jump_dest)) {
 				/* internal sibling call (without reloc) */
 				add_call_dest(file, insn, insn->jump_dest->func, true);
 			}

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Tue, Mar 22, 2022 at 06:14:54PM +0900, Masami Hiramatsu wrote:
> On Tue, 22 Mar 2022 09:08:22 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Tue, Mar 22, 2022 at 02:31:36PM +0900, Masami Hiramatsu wrote:
> > 
> > > > Also, I think both should fix regs->ss.
> > > 
> > > I'm not sure this part. Since the return trampoline should run in the same
> > > context of the called function, isn't ss same there too?
> > 
> > It creates pt_regs on the stack, so the trampolines do:
> > 
> > 	push $arch_rethook_trampoline
> > 	push %rsp
> > 	pushf
> > 	sub $24, %rsp /* cs, ip, orig_ax */
> > 	push %rdi
> > 	...
> > 	push %r15
> > 
> > That means that if anybody looks at regs->ss, it'll find
> > $arch_rethook_trampoline, which isn't a valid segment descriptor, or am
> > I just really bad at counting today?
> 
> Ah, got it. It seems that the ss was skipped from the beginning, and
> no one argued that.

Yeah, this is a long-standing issue, but I noticed it when looking at
the code yesterday.

> > I'm thinking you want a copy of __KERNEL_DS in that stack slot, not a
> > function pointer.
> 
> The function pointer is for unwinding stack which involves the kretprobe.
> Anyway, I can add a slot for ss if it is neeeded. But if it always be
> __KERNEL_DS, is it worth to save it?

Probably, to save someone future head-aches. The insn-eval.c stuff will
actually look at SS when it tries to decode BP/SP fields, and I've got
vague memories of actually using that a while ago. I think I was playing
around with double-fault and the whole espfix64 mess and hit the ESPFIX
segment.

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Tue, Mar 22, 2022 at 02:31:36PM +0900, Masami Hiramatsu wrote:

> > But I still think it's fairly terrible to get a (flawed) carbon copy of
> > the kretprobe code.
> 
> Indeed. I would like to replace the trampoline code of kretprobe with
> rethook, eventually. There is no reason why we keep the clone.
> (But I need more arch maintainers help for that, there are too many
>  archs implemented kretprobes)

CONFIG_KPROBE_ON_RETHOOK - and then implement archs one by one?

Re: linux-next: build warnings after merge of the tip tree

[Masami Hiramatsu]

On Tue, 22 Mar 2022 13:17:18 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Mar 22, 2022 at 02:31:36PM +0900, Masami Hiramatsu wrote:
> 
> > > But I still think it's fairly terrible to get a (flawed) carbon copy of
> > > the kretprobe code.
> > 
> > Indeed. I would like to replace the trampoline code of kretprobe with
> > rethook, eventually. There is no reason why we keep the clone.
> > (But I need more arch maintainers help for that, there are too many
> >  archs implemented kretprobes)
> 
> CONFIG_KPROBE_ON_RETHOOK - and then implement archs one by one?

Sounds good! Maybe we will see different data structure fields
which depends on that config, but those are internal fields, so
user will not access it.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: linux-next: build warnings after merge of the tip tree

[Steven Rostedt]

On Tue, 22 Mar 2022 08:54:55 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Mar 21, 2022 at 12:54:19PM -0400, Steven Rostedt wrote:
> > On Mon, 21 Mar 2022 17:50:50 +0100
> > Peter Zijlstra <peterz@infradead.org> wrote:
> >   
> > > > This also assumes that we need to trace everything that is marked. I
> > > > mentioned in another email, what do we do if we only trace funcA?    
> > > 
> > > Like I said later on; if we inhibit tail-calls to notrace, this goes
> > > away.  
> > 
> > Please no. The number of "notrace" functions is increasing to the point
> > that it's starting to make function tracing useless in a lot of
> > circumstances. I've already lost my ability to see when user space goes
> > into the kernel (which I have to hack up custom coding to enable again).  
> 
> I really can't follow the argument there, nor on IRC.
> 
> Suppose:
> 
> notrace func_B()
> {
> 	...
> }
> 
> func_A()
> {
> 	...
> 	return func_B();
> }
> 
> then inhibiting tail calls would end up looking like:

If we inhibit tail calls, then we do not need to make func_B notrace.

> 
> func_A:
> 	call __fentry__
> 	...
> 	call func_B
> 	call __fexit__
> 	ret
> 
> Then A is fully traced, B is invisible, as per spec. What is the
> problem?

The above is fine, but then func_B is not a tail call and can also be
traced.

> 
> The problem you initially had, of doing a tail-call into a notrace, was
> that the __fexit__ call went missing, because notrace will obviously not
> have that. But that's avoided by inhibiting all tail-calls between
> notrace and !notrace functions (note that notrace must also not
> tail-call !notrace).

I'm confused by the above. Why can't a notrace tail call a !notrace?
If we tail call to a

func_B:
	call __fentry__
	...
	call __fexit__
	ret

then the fentry and fexit show a perfectly valid trace of func_B.


> 
> Your worry seems to stem about loosing visiblilty of !notrace functions,
> but AFAICT that doesn't happen.

My worry is:

func_A:
	call __fentry__
	...
	jmp func_B

Where do we do the call __fexit__ ?

That was the original concern, and I think the proposed solutions have
convoluted our thoughts about what we are trying to fix. So let's go back
to the beginning, and see how to deal with it.

That is, we have:

func_C:
	call __fenty__
	...
	call func_A:
	...
	call func_B:
	...
	call __fexit__
	ret

func_A:
	call __fentry__
	...
	jmp func_B

func_B:
	call __fentry__
	...
	call __fexit__
	ret

Where the above is C calling A and B as normal functions, A calling B as a
tail call and B just being a normal function called by both A and C (and
many other functions).

And note, I do not want to limit function tracing (which does not rely on
__fexit__) just because we can't figure out how to handle __fexit__.

-- Steve

Re: linux-next: build warnings after merge of the tip tree

[Mark Rutland]

On Tue, Mar 22, 2022 at 02:31:36PM +0900, Masami Hiramatsu wrote:
> On Mon, 21 Mar 2022 17:48:54 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > > 
> > > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > > produced these new warnings:
> > > > > 
> > > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > 
> > > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > > those.
> > > 
> > > Ahh, something tracing. I'll go do some patches on top of it.
> > 
> > The below gets rid of the objtool warnings.
> 
> Yes, I confirmed that.
> 
> > But I still think it's fairly terrible to get a (flawed) carbon copy of
> > the kretprobe code.
> 
> Indeed. I would like to replace the trampoline code of kretprobe with
> rethook, eventually. There is no reason why we keep the clone.
> (But I need more arch maintainers help for that, there are too many
>  archs implemented kretprobes)

FWIW, I'm more than happy to help on the arm64 side if you could Cc me for
that; I'm aware of other things in this area I'd like to clean up for
backtracing, too.

Thanks,
Mark.

Re: linux-next: build warnings after merge of the tip tree

[Steven Rostedt]

On Tue, 22 Mar 2022 21:46:29 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> > > Indeed. I would like to replace the trampoline code of kretprobe with
> > > rethook, eventually. There is no reason why we keep the clone.
> > > (But I need more arch maintainers help for that, there are too many
> > >  archs implemented kretprobes)  
> > 
> > CONFIG_KPROBE_ON_RETHOOK - and then implement archs one by one?  
> 
> Sounds good! Maybe we will see different data structure fields
> which depends on that config, but those are internal fields, so
> user will not access it.

Which is basically what I do for ftrace. Which is why we have all these:

        select HAVE_DYNAMIC_FTRACE
        select HAVE_DYNAMIC_FTRACE_WITH_REGS
        select HAVE_DYNAMIC_FTRACE_WITH_ARGS
        select HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
        select HAVE_SAMPLE_FTRACE_DIRECT
        select HAVE_SAMPLE_FTRACE_DIRECT_MULTI

in the architecture Kconfigs.

-- Steve

Re: linux-next: build warnings after merge of the tip tree

[Masami Hiramatsu]

On Tue, 22 Mar 2022 13:15:58 +0000
Mark Rutland <mark.rutland@arm.com> wrote:

> On Tue, Mar 22, 2022 at 02:31:36PM +0900, Masami Hiramatsu wrote:
> > On Mon, 21 Mar 2022 17:48:54 +0100
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Mon, Mar 21, 2022 at 02:04:05PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 21, 2022 at 01:55:49PM +0100, Peter Zijlstra wrote:
> > > > > On Mon, Mar 21, 2022 at 02:03:27PM +1100, Stephen Rothwell wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > After merging the tip tree, today's linux-next build (x864 allmodconfig)
> > > > > > produced these new warnings:
> > > > > > 
> > > > > > vmlinux.o: warning: objtool: arch_rethook_prepare()+0x55: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: arch_rethook_trampoline_callback()+0x3e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x93e: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x5f2: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: unwind_next_frame()+0x4a7: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x81: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: __rethook_find_ret_addr()+0x90: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x8c: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > > vmlinux.o: warning: objtool: rethook_trampoline_handler()+0x9b: relocation to !ENDBR: arch_rethook_trampoline+0x0
> > > > > 
> > > > > Hurmph, lemme go figure out where that code comes from, I've not seen
> > > > > those.
> > > > 
> > > > Ahh, something tracing. I'll go do some patches on top of it.
> > > 
> > > The below gets rid of the objtool warnings.
> > 
> > Yes, I confirmed that.
> > 
> > > But I still think it's fairly terrible to get a (flawed) carbon copy of
> > > the kretprobe code.
> > 
> > Indeed. I would like to replace the trampoline code of kretprobe with
> > rethook, eventually. There is no reason why we keep the clone.
> > (But I need more arch maintainers help for that, there are too many
> >  archs implemented kretprobes)
> 
> FWIW, I'm more than happy to help on the arm64 side if you could Cc me for
> that; I'm aware of other things in this area I'd like to clean up for
> backtracing, too.

Thank you for your warm help. OK, let me update and submit the rethook
for arm64 :-)

Thanks.

-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: linux-next: build warnings after merge of the tip tree

[Masami Hiramatsu]

On Mon, 21 Mar 2022 12:12:09 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Mon, 21 Mar 2022 17:04:28 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Mon, Mar 21, 2022 at 11:28:05AM -0400, Steven Rostedt wrote:
> > > On Mon, 21 Mar 2022 14:04:05 +0100
> > > Peter Zijlstra <peterz@infradead.org> wrote:  
> > 
> > > > Also, folks, I'm thinking we should start to move to __fexit__, if CET
> > > > SHSTK ever wants to come to kernel land return trampolines will
> > > > insta-stop working.
> > > > 
> > > > Hjl, do you think we could get -mfexit to go along with -mfentry ?  
> > 
> > > int funcA () {
> > > 	[..]
> > > 	return funcB();
> > > }  
> > 
> > > This currently works with function graph and kretprobe tracing because of
> > > the shadow stack. Let's say we traced both funcA and funcB
> > > 
> > > funcA:
> > > 	call __fentry__  
> > 			push funcA on trace-stack
> > > 
> > > 	[..]
> > > 	jmp funcB
> > > 
> > > funcB:
> > > 	call __fentry__  
> > 			push funcB on trace-stack
> > > 
> > > 	[..]  
> > 	call __fexit__
> > 			pop trace-stack until empty

This seems wrong. We don't pop the trace-stack until empty, but we will
record the real stack pointer at funcA.

> > 			  'exit funcB'
> > 			  'exit funcA'
> 
> And what happens if funcC called funcA and it too was on the stack. We pop
> that too? But it's not done yet, because calling of funcA was not a tail
> call.

Thus when the funcC is called, the trace-stack will be poped until funcA,
because we can see the real stack pointer at the 'ret'.
So the funcC is still on the trace-stack after that.

Thank you,


> 
> -- Steve
> 
> 
> > 
> > > 	ret  
> > 
> > > 
> > > That is, the current algorithm traces the end of both funcA and funcB
> > > without issue, because of how the shadow stack works.  
> > 
> > And it all works, no? Or what am I missing?
> 
> 
> 


-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Tue, Mar 22, 2022 at 09:12:42AM -0400, Steven Rostedt wrote:

> > Suppose:
> > 
> > notrace func_B()
> > {
> > 	...
> > }
> > 
> > func_A()
> > {
> > 	...
> > 	return func_B();
> > }
> > 
> > then inhibiting tail calls would end up looking like:
> 
> If we inhibit tail calls, then we do not need to make func_B notrace.

Dude, you're arguing in circles :-( the notrace was a given.

> > func_A:
> > 	call __fentry__
> > 	...
> > 	call func_B
> > 	call __fexit__
> > 	ret
> > 
> > Then A is fully traced, B is invisible, as per spec. What is the
> > problem?
> 
> The above is fine, but then func_B is not a tail call and can also be
> traced.

Again, B is notrace as a given. This was all about how to deal with
notrace functions.

I suggested inhibiting tail-call to notrace, you said no. You now seem to
agree that solves it.

> > The problem you initially had, of doing a tail-call into a notrace, was
> > that the __fexit__ call went missing, because notrace will obviously not
> > have that. But that's avoided by inhibiting all tail-calls between
> > notrace and !notrace functions (note that notrace must also not
> > tail-call !notrace).
> 
> I'm confused by the above. Why can't a notrace tail call a !notrace?
> If we tail call to a
> 
> func_B:
> 	call __fentry__
> 	...
> 	call __fexit__
> 	ret
> 
> then the fentry and fexit show a perfectly valid trace of func_B.

Bah; I thought I had a case this morning, but now I can't seem to recall
:/

> > Your worry seems to stem about loosing visiblilty of !notrace functions,
> > but AFAICT that doesn't happen.
> 
> My worry is:
> 
> func_A:
> 	call __fentry__
> 	...
> 	jmp func_B
> 
> Where do we do the call __fexit__ ?

In B (or wherever if B again does a tail-call).

> That was the original concern, and I think the proposed solutions have
> convoluted our thoughts about what we are trying to fix. So let's go back
> to the beginning, and see how to deal with it.
> 
> That is, we have:
> 
> func_C:
> 	call __fenty__
> 	...
> 	call func_A:
> 	...
> 	call func_B:
> 	...
> 	call __fexit__
> 	ret
> 
> func_A:
> 	call __fentry__
> 	...
	call __ftail__
> 	jmp func_B
> 
> func_B:
> 	call __fentry__
> 	...
> 	call __fexit__
> 	ret
> 
> Where the above is C calling A and B as normal functions, A calling B as a
> tail call and B just being a normal function called by both A and C (and
> many other functions).

We need the __ftail__ thing to mark the trace-stack entry of func_A as
complete, then any future __fexit__ will be able to pop all completed
entries.

In recap:

	__fentry__ -- push on trace-stack
	__ftail__  -- mark top-most entry complete
	__fexit__  -- mark top-most entry complete;
	              pop all completed entries

inhibit tail-calls to notrace.

> And note, I do not want to limit function tracing (which does not rely on
> __fexit__) just because we can't figure out how to handle __fexit__.

I'm not following. Regular function tracing needs none of this.

It's function graph tracing, kretprobes and whatever else this rethook
stuff is about that needs this because return trampolines will stop
working somewhere in the not too distant future.

Re: linux-next: build warnings after merge of the tip tree

[Steven Rostedt]

On Tue, 22 Mar 2022 15:35:54 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Mar 22, 2022 at 09:12:42AM -0400, Steven Rostedt wrote:
> 
> > > Suppose:
> > > 
> > > notrace func_B()
> > > {
> > > 	...
> > > }
> > > 
> > > func_A()
> > > {
> > > 	...
> > > 	return func_B();
> > > }
> > > 
> > > then inhibiting tail calls would end up looking like:  
> > 
> > If we inhibit tail calls, then we do not need to make func_B notrace.  
> 
> Dude, you're arguing in circles :-( the notrace was a given.

Why is it notrace? Sorry to be dense, but it's not a given to me.

> 
> > > func_A:
> > > 	call __fentry__
> > > 	...
> > > 	call func_B
> > > 	call __fexit__
> > > 	ret
> > > 
> > > Then A is fully traced, B is invisible, as per spec. What is the
> > > problem?  
> > 
> > The above is fine, but then func_B is not a tail call and can also be
> > traced.  
> 
> Again, B is notrace as a given. This was all about how to deal with
> notrace functions.


No, it was about how to deal with notrace functions that were tail calls.
That was what I had an issue with. Because the solution you proposed had
func_A depend on func_B executing its call __fexit__ which it would not, if
it was not traced.

> 
> I suggested inhibiting tail-call to notrace, you said no. You now seem to
> agree that solves it.

I said inhibiting tail-calls was a solution, but only inhibiting it to
notrace would probably have a significant performance impact.

I thought you were talking about adding notrace to tail calls, not the
other way around. Maybe that is our confusion in this conversation.

> 
> > > The problem you initially had, of doing a tail-call into a notrace, was
> > > that the __fexit__ call went missing, because notrace will obviously not
> > > have that. But that's avoided by inhibiting all tail-calls between
> > > notrace and !notrace functions (note that notrace must also not
> > > tail-call !notrace).  
> > 
> > I'm confused by the above. Why can't a notrace tail call a !notrace?
> > If we tail call to a
> > 
> > func_B:
> > 	call __fentry__
> > 	...
> > 	call __fexit__
> > 	ret
> > 
> > then the fentry and fexit show a perfectly valid trace of func_B.  
> 
> Bah; I thought I had a case this morning, but now I can't seem to recall
> :/

That happens to all of us ;-)

> 
> > > Your worry seems to stem about loosing visiblilty of !notrace functions,
> > > but AFAICT that doesn't happen.  
> > 
> > My worry is:
> > 
> > func_A:
> > 	call __fentry__
> > 	...
> > 	jmp func_B
> > 
> > Where do we do the call __fexit__ ?  
> 
> In B (or wherever if B again does a tail-call).

But there's no guarantee that the call __fexit__ will not be a nop in
func_B. Remember, these are all turned on and off. If we just trace func_A
and not func_B, we will never have a call __fexit__ for func_A.

> 
> > That was the original concern, and I think the proposed solutions have
> > convoluted our thoughts about what we are trying to fix. So let's go back
> > to the beginning, and see how to deal with it.
> > 
> > That is, we have:
> > 
> > func_C:
> > 	call __fenty__
> > 	...
> > 	call func_A:
> > 	...
> > 	call func_B:
> > 	...
> > 	call __fexit__
> > 	ret
> > 
> > func_A:
> > 	call __fentry__
> > 	...  
> 	call __ftail__
> > 	jmp func_B
> > 
> > func_B:
> > 	call __fentry__
> > 	...
> > 	call __fexit__
> > 	ret
> > 
> > Where the above is C calling A and B as normal functions, A calling B as a
> > tail call and B just being a normal function called by both A and C (and
> > many other functions).  
> 
> We need the __ftail__ thing to mark the trace-stack entry of func_A as
> complete, then any future __fexit__ will be able to pop all completed
> entries.
> 
> In recap:
> 
> 	__fentry__ -- push on trace-stack
> 	__ftail__  -- mark top-most entry complete
> 	__fexit__  -- mark top-most entry complete;
> 	              pop all completed entries

Again, this would require that the tail-calls are also being traced.

> 
> inhibit tail-calls to notrace.

Just inhibiting tail-calls to notrace would work without any of the above.
But my fear is that will cause a noticeable performance impact.

> 
> > And note, I do not want to limit function tracing (which does not rely on
> > __fexit__) just because we can't figure out how to handle __fexit__.  
> 
> I'm not following. Regular function tracing needs none of this.

The regular function tracing does not need this. Only function graph
tracing. I was thinking you were *adding* notrace to tail calls and such,
which is what I was against. But apparently that is not what you were
saying.

> 
> It's function graph tracing, kretprobes and whatever else this rethook
> stuff is about that needs this because return trampolines will stop
> working somewhere in the not too distant future.

Another crazy solution is to have:

func_A:
	call __fentry__
	...
tail:	jmp 1f 
	call 1f
	call __fexit__
	ret
1:	jmp func_B


where the compiler tells us about "tail:" and that we know that func_A ends
with a tail call, and if we want to trace the end of func_A we convert that
jmp 1f into a nop. And then we call the func_B and it's return comes back
to where we call __fexit__ and then return normally.

-- Steve

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Tue, Mar 22, 2022 at 11:04:38AM -0400, Steven Rostedt wrote:
> On Tue, 22 Mar 2022 15:35:54 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:

> > I suggested inhibiting tail-call to notrace, you said no. You now seem to
> > agree that solves it.
> 
> I said inhibiting tail-calls was a solution, but only inhibiting it to
> notrace would probably have a significant performance impact.
> 
> I thought you were talking about adding notrace to tail calls, not the
> other way around. Maybe that is our confusion in this conversation.

Yeah, I meant inhibiting the compiler from doing tail-calls.

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Tue, Mar 22, 2022 at 11:04:38AM -0400, Steven Rostedt wrote:

> > In recap:
> > 
> > 	__fentry__ -- push on trace-stack
> > 	__ftail__  -- mark top-most entry complete
> > 	__fexit__  -- mark top-most entry complete;
> > 	              pop all completed entries
> 
> Again, this would require that the tail-calls are also being traced.

Which is why we should inhibit tail-calls if the function is notrace.

> > inhibit tail-calls to notrace.
> 
> Just inhibiting tail-calls to notrace would work without any of the above.

I'm lost again; what? Without any of the above you got nothing because
return-trampoline will not work.

> But my fear is that will cause a noticeable performance impact.

Most code isn't in fact notrace, and call+ret aren't *that* expensive.

> > It's function graph tracing, kretprobes and whatever else this rethook
> > stuff is about that needs this because return trampolines will stop
> > working somewhere in the not too distant future.
> 
> Another crazy solution is to have:
> 
> func_A:
> 	call __fentry__
> 	...
> tail:	jmp 1f 
> 	call 1f
	
> 	call __fexit__
> 	ret
> 1:	jmp func_B
> 
> 
> where the compiler tells us about "tail:" and that we know that func_A ends
> with a tail call, and if we want to trace the end of func_A we convert that
> jmp 1f into a nop. And then we call the func_B and it's return comes back
> to where we call __fexit__ and then return normally.

At that point giving us something like:

1:
	pushsection __ftail_loc
	.long	1b - .
	popsection

	jmp.d32	func_B
	call	__fexit__
	ret

is smaller and simpler, we can patch the jmp.d32 to call when tracing.
The only problem is SLS, that might wants an int3 after jmp too
( https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1026 ).

That does avoid the need for __ftail__ I suppose.

Re: linux-next: build warnings after merge of the tip tree

[Steven Rostedt]

On Tue, 22 Mar 2022 16:48:02 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Mar 22, 2022 at 11:04:38AM -0400, Steven Rostedt wrote:
> 
> > > In recap:
> > > 
> > > 	__fentry__ -- push on trace-stack
> > > 	__ftail__  -- mark top-most entry complete
> > > 	__fexit__  -- mark top-most entry complete;
> > > 	              pop all completed entries  
> > 
> > Again, this would require that the tail-calls are also being traced.  
> 
> Which is why we should inhibit tail-calls if the function is notrace.
> 
> > > inhibit tail-calls to notrace.  
> > 
> > Just inhibiting tail-calls to notrace would work without any of the above.  
> 
> I'm lost again; what? Without any of the above you got nothing because
> return-trampoline will not work.


I think this got "lost in translation".

 "Inhibiting tail-calls to notrace"

Is a bit ambiguous because of the "to notrace" which would be different if
I had said "on notrace" which I may have screwed up the grammar here. Let
me be more precise.

 "Limiting tail-calls to only notrace functions"

That I think is a bit less ambiguous. English sucks.

> 
> > But my fear is that will cause a noticeable performance impact.  
> 
> Most code isn't in fact notrace, and call+ret aren't *that* expensive.

  "isn't in fact notrace" Ug! Double negatives!

This gets even more confusing when we are saying "notrace" which is a
negative. We should probably just say "traced" functions which makes
communication a bit more straight forward.

> 
> > > It's function graph tracing, kretprobes and whatever else this rethook
> > > stuff is about that needs this because return trampolines will stop
> > > working somewhere in the not too distant future.  
> > 
> > Another crazy solution is to have:
> > 
> > func_A:
> > 	call __fentry__
> > 	...
> > tail:	jmp 1f 
> > 	call 1f  
> 	
> > 	call __fexit__
> > 	ret
> > 1:	jmp func_B
> > 
> > 
> > where the compiler tells us about "tail:" and that we know that func_A ends
> > with a tail call, and if we want to trace the end of func_A we convert that
> > jmp 1f into a nop. And then we call the func_B and it's return comes back
> > to where we call __fexit__ and then return normally.  
> 
> At that point giving us something like:
> 
> 1:
> 	pushsection __ftail_loc
> 	.long	1b - .
> 	popsection
> 
> 	jmp.d32	func_B
> 	call	__fexit__
> 	ret
> 
> is smaller and simpler, we can patch the jmp.d32 to call when tracing.
> The only problem is SLS, that might wants an int3 after jmp too
> ( https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1026 ).
> 
> That does avoid the need for __ftail__ I suppose.

Which is basically what I said earlier ;-)

  https://lore.kernel.org/all/20220321122259.28146a7a@gandalf.local.home/

> Or maybe another solution is:
> 
> funcA:
> 	[..]
> 	jmp funcB
> 	call __fexit__
> 	ret
> 
> And if funcA is being traced, we change jmp to a call.
> 
> 	[..]
> 	call funcB
> 	call __fexit__
> 	ret
> 
> Such that we only remove the tail calls if we enable tracing on the
> function with the tail call.

-- Steve

Re: linux-next: build warnings after merge of the tip tree

[Masami Hiramatsu]

On Tue, 22 Mar 2022 15:35:54 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Mar 22, 2022 at 09:12:42AM -0400, Steven Rostedt wrote:
> 
> > > Suppose:
> > > 
> > > notrace func_B()
> > > {
> > > 	...
> > > }
> > > 
> > > func_A()
> > > {
> > > 	...
> > > 	return func_B();
> > > }
> > > 
> > > then inhibiting tail calls would end up looking like:
> > 
> > If we inhibit tail calls, then we do not need to make func_B notrace.
> 
> Dude, you're arguing in circles :-( the notrace was a given.
> 
> > > func_A:
> > > 	call __fentry__
> > > 	...
> > > 	call func_B
> > > 	call __fexit__
> > > 	ret
> > > 
> > > Then A is fully traced, B is invisible, as per spec. What is the
> > > problem?
> > 
> > The above is fine, but then func_B is not a tail call and can also be
> > traced.
> 
> Again, B is notrace as a given. This was all about how to deal with
> notrace functions.
> 
> I suggested inhibiting tail-call to notrace, you said no. You now seem to
> agree that solves it.
> 
> > > The problem you initially had, of doing a tail-call into a notrace, was
> > > that the __fexit__ call went missing, because notrace will obviously not
> > > have that. But that's avoided by inhibiting all tail-calls between
> > > notrace and !notrace functions (note that notrace must also not
> > > tail-call !notrace).
> > 
> > I'm confused by the above. Why can't a notrace tail call a !notrace?
> > If we tail call to a
> > 
> > func_B:
> > 	call __fentry__
> > 	...
> > 	call __fexit__
> > 	ret
> > 
> > then the fentry and fexit show a perfectly valid trace of func_B.
> 
> Bah; I thought I had a case this morning, but now I can't seem to recall
> :/
> 
> > > Your worry seems to stem about loosing visiblilty of !notrace functions,
> > > but AFAICT that doesn't happen.
> > 
> > My worry is:
> > 
> > func_A:
> > 	call __fentry__
> > 	...
> > 	jmp func_B
> > 
> > Where do we do the call __fexit__ ?
> 
> In B (or wherever if B again does a tail-call).
> 
> > That was the original concern, and I think the proposed solutions have
> > convoluted our thoughts about what we are trying to fix. So let's go back
> > to the beginning, and see how to deal with it.
> > 
> > That is, we have:
> > 
> > func_C:
> > 	call __fenty__
> > 	...
> > 	call func_A:
> > 	...
> > 	call func_B:
> > 	...
> > 	call __fexit__
> > 	ret
> > 
> > func_A:
> > 	call __fentry__
> > 	...
> 	call __ftail__
> > 	jmp func_B
> > 
> > func_B:
> > 	call __fentry__
> > 	...
> > 	call __fexit__
> > 	ret
> > 
> > Where the above is C calling A and B as normal functions, A calling B as a
> > tail call and B just being a normal function called by both A and C (and
> > many other functions).
> 
> We need the __ftail__ thing to mark the trace-stack entry of func_A as
> complete, then any future __fexit__ will be able to pop all completed
> entries.
> 
> In recap:
> 
> 	__fentry__ -- push on trace-stack
> 	__ftail__  -- mark top-most entry complete
> 	__fexit__  -- mark top-most entry complete;
> 	              pop all completed entries
> 
> inhibit tail-calls to notrace.
> 
> > And note, I do not want to limit function tracing (which does not rely on
> > __fexit__) just because we can't figure out how to handle __fexit__.
> 
> I'm not following. Regular function tracing needs none of this.
> 
> It's function graph tracing, kretprobes and whatever else this rethook
> stuff is about that needs this because return trampolines will stop
> working somewhere in the not too distant future.

I see the __fexit__ is needed, but why __ftail__ is needed? I guess because
func_B is notrace, in that case the __fexit__ will not be in the func_B.
Am I correct?

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: linux-next: build warnings after merge of the tip tree

[Steven Rostedt]

On Wed, 23 Mar 2022 11:23:23 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> I see the __fexit__ is needed, but why __ftail__ is needed? I guess because
> func_B is notrace, in that case the __fexit__ will not be in the func_B.
> Am I correct?

I believe Peter and I agreed that the "best" solution so far, that has the
least amount of regressions (doesn't remove anything currently being
function graph traced, nor removes current tail calls) is:

> At that point giving us something like:
> 
> 1:
> 	pushsection __ftail_loc
> 	.long	1b - .
> 	popsection
> 
> 	jmp.d32	func_B
> 	call	__fexit__
> 	ret


Functions with a tail call will not have a __fexit__ and we can not rely on
the function that is the tail call to do the __fexit__ for the parent
function. Thus, the compromise is to add a label where the jmp to the
tail-call function is, and when we want to trace the return of that
function, we first have to patch the jmp into a call, which will then
return back to the call to __fexit__.

-- Steve

Re: linux-next: build warnings after merge of the tip tree

[Masami Hiramatsu]

On Tue, 22 Mar 2022 22:42:36 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Wed, 23 Mar 2022 11:23:23 +0900
> Masami Hiramatsu <mhiramat@kernel.org> wrote:
> 
> > I see the __fexit__ is needed, but why __ftail__ is needed? I guess because
> > func_B is notrace, in that case the __fexit__ will not be in the func_B.
> > Am I correct?
> 
> I believe Peter and I agreed that the "best" solution so far, that has the
> least amount of regressions (doesn't remove anything currently being
> function graph traced, nor removes current tail calls) is:
> 
> > At that point giving us something like:
> > 
> > 1:
> > 	pushsection __ftail_loc
> > 	.long	1b - .
> > 	popsection
> > 
> > 	jmp.d32	func_B
> > 	call	__fexit__
> > 	ret
> 
> 
> Functions with a tail call will not have a __fexit__ and we can not rely on
> the function that is the tail call to do the __fexit__ for the parent
> function. Thus, the compromise is to add a label where the jmp to the
> tail-call function is, and when we want to trace the return of that
> function, we first have to patch the jmp into a call, which will then
> return back to the call to __fexit__.

Got it. So the tail call "jump" will be replaced with a normal call when
we trace it.

That's a good idea :) 


> 
> -- Steve


-- 
Masami Hiramatsu <mhiramat@kernel.org>

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

After merging the tip tree, today's linux-next build (htmldocs) produced
these warnings:

Documentation/virt/coco/sev-guest.rst:75: WARNING: Inline emphasis start-string without end-string.
Documentation/virt/coco/sev-guest.rst:78: WARNING: Inline emphasis start-string without end-string.
Documentation/virt/coco/sev-guest.rst:81: WARNING: Inline emphasis start-string without end-string.
Documentation/virt/coco/sev-guest.rst:83: WARNING: Definition list ends without a blank line; unexpected unindent.

Introduced by commit

  f5db8841ebe5 ("crypto: ccp: Add the SNP_PLATFORM_STATUS command")

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Uros Bizjak]

On Mon, Dec 11, 2023 at 6:19 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Mon, 4 Dec 2023 08:02:56 +0100 Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > On Mon, Dec 4, 2023 at 5:08 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > On Fri, 1 Dec 2023 13:09:45 +0100 Uros Bizjak <ubizjak@gmail.com> wrote:
> > > >
> > > > On Fri, Dec 1, 2023 at 1:29 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > >
> > >  > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > > > produced these warnings:
> > > > >
> > > > > WARNING: modpost: EXPORT symbol "const_pcpu_hot" [vmlinux] version generation failed, symbol will not be versioned.
> > > > > Is "const_pcpu_hot" prototyped in <asm/asm-prototypes.h>?
> > > > > WARNING: modpost: "const_pcpu_hot" [arch/x86/kernel/msr.ko] has no CRC!
> > > > > WARNING: modpost: "const_pcpu_hot" [arch/x86/kvm/kvm.ko] has no CRC!
> > > >
> > > > My build doesn't produce any warnings. A defconfig + enabling kvm.ko as module:
> > > >
> > > > ...
> > > >  AR      built-in.a
> > > >  AR      vmlinux.a
> > > >  LD      vmlinux.o
> > > >  OBJCOPY modules.builtin.modinfo
> > > >  GEN     modules.builtin
> > > >  MODPOST Module.symvers
> > > >  CC      .vmlinux.export.o
> > > >  CC [M]  arch/x86/kvm/kvm.mod.o
> > > >  CC [M]  fs/efivarfs/efivarfs.mod.o
> > > > ...
> > > >
> > > > Does the attached patch help? Or is there anything else I should do to
> > > > trigger the above problem?
> > >
> > > The patch does not help.  I am just doing an X86_64 allmodconfig build
> > > with CONFIG_WERROR=n. gcc is
> > >
> > > $ x86_64-linux-gnu-gcc --version
> > > x86_64-linux-gnu-gcc (Debian 13.2.0-2) 13.2.0
> > >
> > > This is a cross build with a ppc64le host.
>
> I am still seeing the warnings ...

The -v3 patch series that fixes this and the remaining sparse warnings
sits unreviewed for a week at [1].

I don't know why it is not being considered.

[1] https://lore.kernel.org/lkml/20231204210320.114429-1-ubizjak@gmail.com/

Thanks,
Uros.

Re: linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

On Mon, 4 Dec 2023 08:02:56 +0100 Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Mon, Dec 4, 2023 at 5:08 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Fri, 1 Dec 2023 13:09:45 +0100 Uros Bizjak <ubizjak@gmail.com> wrote:  
> > >
> > > On Fri, Dec 1, 2023 at 1:29 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> > > >  
> >  > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)  
> > > > produced these warnings:
> > > >
> > > > WARNING: modpost: EXPORT symbol "const_pcpu_hot" [vmlinux] version generation failed, symbol will not be versioned.
> > > > Is "const_pcpu_hot" prototyped in <asm/asm-prototypes.h>?
> > > > WARNING: modpost: "const_pcpu_hot" [arch/x86/kernel/msr.ko] has no CRC!
> > > > WARNING: modpost: "const_pcpu_hot" [arch/x86/kvm/kvm.ko] has no CRC!  
> > >
> > > My build doesn't produce any warnings. A defconfig + enabling kvm.ko as module:
> > >
> > > ...
> > >  AR      built-in.a
> > >  AR      vmlinux.a
> > >  LD      vmlinux.o
> > >  OBJCOPY modules.builtin.modinfo
> > >  GEN     modules.builtin
> > >  MODPOST Module.symvers
> > >  CC      .vmlinux.export.o
> > >  CC [M]  arch/x86/kvm/kvm.mod.o
> > >  CC [M]  fs/efivarfs/efivarfs.mod.o
> > > ...
> > >
> > > Does the attached patch help? Or is there anything else I should do to
> > > trigger the above problem?  
> >
> > The patch does not help.  I am just doing an X86_64 allmodconfig build
> > with CONFIG_WERROR=n. gcc is
> >
> > $ x86_64-linux-gnu-gcc --version
> > x86_64-linux-gnu-gcc (Debian 13.2.0-2) 13.2.0
> >
> > This is a cross build with a ppc64le host.  
> 
> The warning is triggered by CONFIG_MODVERSIONS=y and will be fixed in
> a different way by the patch in [1].
> 
> [1] https://lore.kernel.org/lkml/20231203232017.994963-1-ubizjak@gmail.com/

I am still seeing the warnings ...

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Uros Bizjak]

On Mon, Dec 4, 2023 at 5:08 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Uros,
>
> On Fri, 1 Dec 2023 13:09:45 +0100 Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > On Fri, Dec 1, 2023 at 1:29 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
>  > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > produced these warnings:
> > >
> > > WARNING: modpost: EXPORT symbol "const_pcpu_hot" [vmlinux] version generation failed, symbol will not be versioned.
> > > Is "const_pcpu_hot" prototyped in <asm/asm-prototypes.h>?
> > > WARNING: modpost: "const_pcpu_hot" [arch/x86/kernel/msr.ko] has no CRC!
> > > WARNING: modpost: "const_pcpu_hot" [arch/x86/kvm/kvm.ko] has no CRC!
> >
> > My build doesn't produce any warnings. A defconfig + enabling kvm.ko as module:
> >
> > ...
> >  AR      built-in.a
> >  AR      vmlinux.a
> >  LD      vmlinux.o
> >  OBJCOPY modules.builtin.modinfo
> >  GEN     modules.builtin
> >  MODPOST Module.symvers
> >  CC      .vmlinux.export.o
> >  CC [M]  arch/x86/kvm/kvm.mod.o
> >  CC [M]  fs/efivarfs/efivarfs.mod.o
> > ...
> >
> > Does the attached patch help? Or is there anything else I should do to
> > trigger the above problem?
>
> The patch does not help.  I am just doing an X86_64 allmodconfig build
> with CONFIG_WERROR=n. gcc is
>
> $ x86_64-linux-gnu-gcc --version
> x86_64-linux-gnu-gcc (Debian 13.2.0-2) 13.2.0
>
> This is a cross build with a ppc64le host.

The warning is triggered by CONFIG_MODVERSIONS=y and will be fixed in
a different way by the patch in [1].

[1] https://lore.kernel.org/lkml/20231203232017.994963-1-ubizjak@gmail.com/

Thanks,
Uros.

Re: linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi Uros,

On Fri, 1 Dec 2023 13:09:45 +0100 Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Fri, Dec 1, 2023 at 1:29 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
 > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > produced these warnings:
> >
> > WARNING: modpost: EXPORT symbol "const_pcpu_hot" [vmlinux] version generation failed, symbol will not be versioned.
> > Is "const_pcpu_hot" prototyped in <asm/asm-prototypes.h>?
> > WARNING: modpost: "const_pcpu_hot" [arch/x86/kernel/msr.ko] has no CRC!
> > WARNING: modpost: "const_pcpu_hot" [arch/x86/kvm/kvm.ko] has no CRC!  
> 
> My build doesn't produce any warnings. A defconfig + enabling kvm.ko as module:
> 
> ...
>  AR      built-in.a
>  AR      vmlinux.a
>  LD      vmlinux.o
>  OBJCOPY modules.builtin.modinfo
>  GEN     modules.builtin
>  MODPOST Module.symvers
>  CC      .vmlinux.export.o
>  CC [M]  arch/x86/kvm/kvm.mod.o
>  CC [M]  fs/efivarfs/efivarfs.mod.o
> ...
> 
> Does the attached patch help? Or is there anything else I should do to
> trigger the above problem?

The patch does not help.  I am just doing an X86_64 allmodconfig build
with CONFIG_WERROR=n. gcc is

$ x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 13.2.0-2) 13.2.0

This is a cross build with a ppc64le host.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Uros Bizjak]

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

On Fri, Dec 1, 2023 at 1:29 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced these warnings:
>
> WARNING: modpost: EXPORT symbol "const_pcpu_hot" [vmlinux] version generation failed, symbol will not be versioned.
> Is "const_pcpu_hot" prototyped in <asm/asm-prototypes.h>?
> WARNING: modpost: "const_pcpu_hot" [arch/x86/kernel/msr.ko] has no CRC!
> WARNING: modpost: "const_pcpu_hot" [arch/x86/kvm/kvm.ko] has no CRC!

My build doesn't produce any warnings. A defconfig + enabling kvm.ko as module:

...
 AR      built-in.a
 AR      vmlinux.a
 LD      vmlinux.o
 OBJCOPY modules.builtin.modinfo
 GEN     modules.builtin
 MODPOST Module.symvers
 CC      .vmlinux.export.o
 CC [M]  arch/x86/kvm/kvm.mod.o
 CC [M]  fs/efivarfs/efivarfs.mod.o
...

Does the attached patch help? Or is there anything else I should do to
trigger the above problem?

Thanks,
Uros.

[-- Attachment #2: p.diff.txt --]
[-- Type: text/plain, Size: 478 bytes --]

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 4d4b87c6885d..1277d4e0aa42 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -2056,7 +2056,7 @@ DEFINE_PER_CPU_ALIGNED(struct pcpu_hot, pcpu_hot) = {
 	.top_of_stack	= TOP_OF_INIT_STACK,
 };
 EXPORT_PER_CPU_SYMBOL(pcpu_hot);
-EXPORT_PER_CPU_SYMBOL(const_pcpu_hot);
+EXPORT_SYMBOL(const_pcpu_hot);
 
 #ifdef CONFIG_X86_64
 DEFINE_PER_CPU_FIRST(struct fixed_percpu_data,

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

WARNING: modpost: EXPORT symbol "const_pcpu_hot" [vmlinux] version generation failed, symbol will not be versioned.
Is "const_pcpu_hot" prototyped in <asm/asm-prototypes.h>?
WARNING: modpost: "const_pcpu_hot" [arch/x86/kernel/msr.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [arch/x86/kvm/kvm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [arch/x86/kvm/kvm-intel.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [arch/x86/kvm/kvm-amd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [kernel/locking/locktorture.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [kernel/locking/test-ww_mutex.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [kernel/rcu/rcutorture.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [kernel/rcu/rcuscale.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [kernel/rcu/refscale.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [kernel/trace/ring_buffer_benchmark.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [kernel/trace/preemptirq_delay_test.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [kernel/kcsan/kcsan_test.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [kernel/torture.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [kernel/scftorture.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [mm/dmapool_test.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/binfmt_misc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/dlm/dlm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/netfs/netfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/fscache/fscache.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/reiserfs/reiserfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/ext4/ext4.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/ext2/ext2.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/jbd2/jbd2.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/squashfs/squashfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/coda/coda.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/minix/minix.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/fat/fat.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/exfat/exfat.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/isofs/isofs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/hfsplus/hfsplus.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/hfs/hfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/ecryptfs/ecryptfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/nfs/nfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/nfs/nfsv3.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/nfs/nfsv4.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/nfs/filelayout/nfs_layout_nfsv41_files.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/nfs/blocklayout/blocklayoutdriver.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/nfs/flexfilelayout/nfs_layout_flexfiles.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/nfsd/nfsd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/lockd/lockd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/smb/client/cifs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/smb/server/ksmbd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/hpfs/hpfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/ntfs/ntfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/ntfs3/ntfs3.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/jffs2/jffs2.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/ubifs/ubifs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/affs/affs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/autofs/autofs4.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/adfs/adfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/fuse/fuse.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/overlayfs/overlay.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/orangefs/orangefs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/udf/udf.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/omfs/omfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/jfs/jfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/xfs/xfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/9p/9p.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/afs/kafs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/nilfs2/nilfs2.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/befs/befs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/cachefiles/cachefiles.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/ocfs2/ocfs2.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/ocfs2/dlmfs/ocfs2_dlmfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/ocfs2/dlm/ocfs2_dlm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/btrfs/btrfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/gfs2/gfs2.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/f2fs/f2fs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/bcachefs/bcachefs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/ceph/ceph.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/efivarfs/efivarfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/erofs/erofs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/vboxsf/vboxsf.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [fs/zonefs/zonefs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [crypto/asymmetric_keys/x509_selftest.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [crypto/arc4.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [crypto/af_alg.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [crypto/async_tx/async_memcpy.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [block/bfq.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [lib/kunit/kunit.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [lib/kunit/kunit-test.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [lib/kunit/kunit-example-test.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [lib/test_rhashtable.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [lib/test_user_copy.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [lib/test_lockup.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [lib/test_hmm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/video/fbdev/omap2/omapfb/dss/omapdss.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/video/fbdev/arcfb.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/char/ipmi/ipmi_si.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/char/ipmi/ipmi_watchdog.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/acpi/acpi_dbg.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/acpi/acpi_pad.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/dma/idxd/idxd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/dma/dmatest.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/virtio/virtio_mem.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/xen/xen-evtchn.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/xen/xen-gntdev.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/xen/xen-privcmd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/xen/xen-scsiback.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/tty/serial/max3100.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/tty/serial/ucc_uart.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/tty/n_hdlc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/tty/n_gsm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/tty/mxser.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/char/agp/agpgart.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/char/tpm/st33zp24/tpm_st33zp24.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/char/tpm/xen-tpmfront.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/char/virtio_console.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/char/lp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/char/applicom.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/char/hw_random/rng-core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/char/ppdev.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/char/mwave/mwave.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/iommu/iommufd/iommufd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/display/drm_display_helper.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/panel/panel-dsi-cm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/panel/panel-sony-acx565akm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/drm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/drm_exec.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/drm_suballoc_helper.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/ttm/ttm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/scheduler/gpu-sched.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/radeon/radeon.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/i915/i915.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/i915/kvmgt.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/vc4/vc4.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/vmwgfx/vmwgfx.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/nouveau/nouveau.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/exynos/exynosdrm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/gma500/gma500_gfx.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/qxl/qxl.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/virtio/virtio-gpu.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/msm/msm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/tegra/tegra-drm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/etnaviv/etnaviv.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/lima/lima.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/gpu/drm/hyperv/hyperv_drm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/block/rnbd/rnbd-client.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/block/brd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/block/loop.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/block/pktcdvd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/block/nbd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/block/xen-blkfront.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/block/xen-blkback/xen-blkback.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/block/drbd/drbd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/block/zram/zram.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/block/null_blk/null_blk.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/block/ublk_drv.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/misc/lis3lv02d/lis3lv02d.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/misc/cardreader/rtsx_pci.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/misc/ibmasm/ibmasm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/misc/lkdtm/lkdtm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/misc/tifm_core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/misc/fastrpc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/misc/sgi-xp/xpc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/misc/sgi-gru/gru.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/misc/c2port/core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/misc/mei/mei.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/misc/vmw_vmci/vmw_vmci.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/misc/genwqe/genwqe_card.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/misc/bcm-vk/bcm_vk.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/misc/uacce/uacce.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mfd/ti_am335x_tscadc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/dax/device_dax.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/dma-buf/dmabuf_selftests.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/cxl/cxl_pci.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/megaraid/megaraid_sas.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/scsi_mod.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/libsas/libsas.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/libfc/libfc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/fcoe/fcoe.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/fcoe/libfcoe.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/bnx2fc/bnx2fc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/qedf/qedf.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/libiscsi.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/libiscsi_tcp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/iscsi_tcp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/arcmsr/arcmsr.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/aacraid/aacraid.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/pm8001/pm80xx.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/isci/isci.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/qla2xxx/qla2xxx.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/qla2xxx/tcm_qla2xxx.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/qla4xxx/qla4xxx.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/lpfc/lpfc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/bfa/bfa.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/csiostor/csiostor.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/megaraid.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/mpi3mr/mpi3mr.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/ppa.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/imm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/mvsas/mvsas.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/mvumi.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/cxgbi/libcxgbi.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/bnx2i/bnx2i.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/qedi/qedi.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/xen-scsifront.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/st.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/sd_mod.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/sg.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/scsi/ch.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/nvme/common/nvme-keyring.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/nvme/host/nvme-core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/nvme/host/nvme-tcp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/amazon/ena/ena.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/amd/pds_core/pds_core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/broadcom/tg3.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/broadcom/bnxt/bnxt_en.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/cavium/liquidio/liquidio.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/chelsio/cxgb3/cxgb3.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/chelsio/cxgb4/cxgb4.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/fungible/funcore/funcore.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/google/gve/gve.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/microsoft/mana/mana.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/netronome/nfp/nfp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/qualcomm/qcaspi.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/sfc/sfc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ethernet/sfc/falcon/sfc-falcon.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/hamradio/hdlcdrv.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/wireless/ath/ath6kl/ath6kl_core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/wireless/broadcom/b43legacy/b43legacy.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/wireless/marvell/libertas/libertas.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/wireless/marvell/mwl8k.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/wireless/mediatek/mt76/mt76.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/wireless/realtek/rtlwifi/rtlwifi.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/wireless/realtek/rtw88/rtw88_sdio.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/wireless/rsi/rsi_sdio.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/wireless/st/cw1200/cw1200_wlan_spi.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/mctp/mctp-i2c.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/bonding/bonding.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/wireguard/wireguard.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/eql.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/tun.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/tap.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/can/usb/peak_usb/peak_usb.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/can/softing/softing.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/fddi/skfp/skfp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/plip/plip.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/ppp/ppp_generic.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/slip/slip.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/wwan/t7xx/mtk_t7xx.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/xen-netback/xen-netback.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/usb/hso.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/usb/lan78xx.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/usb/smsc95xx.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/usb/usbnet.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/usb/qmi_wwan.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/net/netdevsim/netdevsim.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/firewire/firewire-core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/cdrom/cdrom.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/host/xhci-hcd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/host/max3421-hcd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/core/usbcore.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/cdns3/cdnsp-udc-pci.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/mon/usbmon.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/class/cdc-acm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/class/usblp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/storage/usb-storage.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/image/mdc800.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/serial/usbserial.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/serial/digi_acceleport.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/serial/io_edgeport.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/misc/adutux.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/misc/idmouse.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/misc/uss720.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/misc/yurex.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/misc/chaoskey.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/atm/ueagle-atm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/gadget/udc/udc-core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/gadget/udc/max3420_udc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/gadget/function/usb_f_mass_storage.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/gadget/function/usb_f_fs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/gadget/legacy/gadgetfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/usbip/usbip-core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/usb/usbip/usbip-host.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/input/misc/uinput.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/input/evdev.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/i2c/cx25840/cx25840.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/i2c/video-i2c.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/i2c/ir-kbd-i2c.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/i2c/msp3400.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/i2c/saa7110.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/i2c/saa717x.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/i2c/tvaudio.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/i2c/vpx3220.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/rc/rc-core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/rc/imon.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/common/saa7146/saa7146_vv.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/common/videobuf2/videobuf2-common.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/platform/amphion/amphion-vpu.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/platform/aspeed/aspeed-video.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/platform/samsung/exynos-gsc/exynos-gsc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/platform/samsung/exynos4-is/s5p-fimc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/platform/samsung/s3c-camif/s3c-camif.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/pci/pt1/earth-pt1.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/pci/pt3/earth-pt3.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/pci/cx18/cx18.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/pci/cx88/cx88xx.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/pci/ivtv/ivtv.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/pci/ivtv/ivtvfb.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/pci/saa7134/saa7134.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/pci/saa7164/saa7164.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/pci/solo6x10/solo6x10.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/usb/gspca/gspca_cpia1.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/usb/gspca/m5602/gspca_m5602.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/usb/pvrusb2/pvrusb2.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/test-drivers/vimc/vimc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/test-drivers/vivid/vivid.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/v4l2-core/videodev.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/media/dvb-core/dvb-core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/power/supply/tps65090-charger.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/power/supply/tps65217_charger.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/raid1.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/raid10.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/raid456.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/md-cluster.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/bcache/bcache.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/md-mod.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/dm-mod.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/dm-bufio.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/dm-crypt.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/dm-delay.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/dm-multipath.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/dm-snapshot.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/persistent-data/dm-persistent-data.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/dm-log-userspace.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/dm-cache.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/dm-log-writes.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/dm-integrity.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/dm-zoned.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/md/dm-writecache.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/accessibility/speakup/speakup_acntpc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/accessibility/speakup/speakup_apollo.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/accessibility/speakup/speakup_dectlk.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/accessibility/speakup/speakup_decext.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/accessibility/speakup/speakup_decpc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/accessibility/speakup/speakup_dtlk.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/accessibility/speakup/speakup_keypc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/accessibility/speakup/speakup_soft.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/accessibility/speakup/speakup.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/isdn/hardware/mISDN/hfcpci.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/isdn/hardware/mISDN/hfcmulti.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/isdn/mISDN/mISDN_core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/isdn/mISDN/l1oip.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/cpuidle/cpuidle-haltpoll.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mmc/host/tmio_mmc_core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mmc/host/vub300.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mmc/core/mmc_core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mmc/core/sdio_uart.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/crypto/ccp/ccp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/hid/hid.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/hid/uhid.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/hid/hid-roccat.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/hid/usbhid/usbhid.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/staging/wlan-ng/prism2_usb.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/staging/rtl8723bs/r8723bs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/staging/rts5208/rts5208.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/staging/greybus/gb-uart.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/staging/vc04_services/vchiq.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/platform/x86/intel/speed_select_if/isst_if_common.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/platform/x86/thinkpad_acpi.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/platform/x86/intel_ips.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/platform/chrome/cros_ec_chardev.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/platform/chrome/cros_ec_lightbar.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/platform/surface/surface3_power.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mailbox/mailbox-test.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/virt/vboxguest/vboxguest.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/virt/nitro_enclaves/nitro_enclaves.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/virt/acrn/acrn.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/accel/habanalabs/habanalabs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/accel/ivpu/intel_vpu.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/accel/qaic/qaic.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/rapidio/rio_cm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/rapidio/devices/tsi721_mport.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/rapidio/devices/rio_mport_cdev.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/vdpa/mlx5/mlx5_vdpa.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/vdpa/vdpa_user/vduse.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/parport/parport.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/parport/parport_pc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/nvdimm/libnvdimm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/nvdimm/nd_pmem.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/nvdimm/nd_btt.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/ata/libata.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/target/target_core_mod.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/target/target_core_user.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/target/tcm_fc/tcm_fc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/target/iscsi/iscsi_target_mod.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/target/iscsi/cxgbit/cxgbit.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/chips/cfi_cmdset_0020.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/chips/cfi_cmdset_0002.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/chips/cfi_cmdset_0001.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/lpddr/lpddr_cmds.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/nand/onenand/onenand.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/nand/raw/nandsim.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/nand/raw/meson_nand.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/tests/mtd_oobtest.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/tests/mtd_pagetest.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/tests/mtd_readtest.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/tests/mtd_speedtest.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/tests/mtd_stresstest.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/tests/mtd_subpagetest.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/tests/mtd_torturetest.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/tests/mtd_nandecctest.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/tests/mtd_nandbiterrs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/spi-nor/spi-nor.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/ubi/ubi.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/ubi/gluebi.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/mtd/hyperbus/hbmc-am654.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/atm/iphase.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/atm/eni.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/atm/solos-pci.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/atm/atmtcp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/atm/he.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/uio/uio.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/vfio/vfio.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/vfio/vfio_iommu_type1.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/pcmcia/pcmcia_core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/block/aoe/aoe.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/w1/wire.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/hwmon/abituguru.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/hwmon/nzxt-smart2.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/hwmon/occ/occ-p8-hwmon.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/bluetooth/bluecard_cs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/bluetooth/btmrvl.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/edac/edac_core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/memstick/core/memstick.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/memstick/host/tifm_ms.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/memstick/host/jmb38x_ms.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/memstick/host/r592.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/core/ib_core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/core/rdma_cm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/core/ib_umad.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/core/ib_uverbs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/core/rdma_ucm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/hw/mthca/ib_mthca.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/hw/qib/ib_qib.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/hw/efa/efa.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/hw/mlx5/mlx5_ib.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/hw/usnic/usnic_verbs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/hw/hfi1/hfi1.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/hw/erdma/erdma.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/ulp/ipoib/ib_ipoib.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/ulp/isert/ib_isert.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/ulp/rtrs/rtrs-client.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/sw/rdmavt/rdmavt.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/infiniband/sw/siw/siw.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/dca/dca.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/vhost/vhost_net.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/vhost/vhost_scsi.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/vhost/vhost_vdpa.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/vhost/vhost.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/comedi/comedi.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/comedi/drivers/ni_atmio.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/comedi/drivers/ni_pcidio.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/comedi/drivers/ni_pcimio.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/comedi/drivers/ni_mio_cs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/iio/industrialio.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/thunderbolt/thunderbolt.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/hwtracing/stm/stm_core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/fpga/dfl-afu.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/fsi/fsi-occ.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/tee/tee.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [drivers/siox/siox-core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/core/oss/snd-pcm-oss.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/core/snd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/core/snd-hwdep.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/core/snd-timer.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/core/snd-pcm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/core/snd-rawmidi.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/core/seq/snd-seq.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/core/seq/oss/snd-seq-oss.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/drivers/snd-aloop.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/isa/gus/snd-gus-lib.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/isa/msnd/snd-msnd-lib.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/isa/opti9xx/snd-miro.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/isa/sb/snd-sbawe.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/isa/sb/snd-emu8000-synth.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/isa/wavefront/snd-wavefront.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/pci/korg1212/snd-korg1212.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/pci/mixart/snd-mixart.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/pci/rme9652/snd-rme9652.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/pci/rme9652/snd-hdsp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/pci/rme9652/snd-hdspm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/pci/ymfpci/snd-ymfpci.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/usb/line6/snd-usb-line6.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/firewire/dice/snd-dice.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/firewire/oxfw/snd-oxfw.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/firewire/fireworks/snd-fireworks.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/firewire/bebob/snd-bebob.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/firewire/digi00x/snd-firewire-digi00x.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/firewire/tascam/snd-firewire-tascam.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/firewire/motu/snd-firewire-motu.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/firewire/fireface/snd-fireface.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/soc/intel/avs/snd-soc-avs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [sound/soc/sof/snd-sof.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [samples/kprobes/kretprobe_example.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [samples/trace_events/trace-events-sample.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [samples/ftrace/ftrace-direct-modify.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [samples/ftrace/ftrace-direct-multi-modify.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [samples/ftrace/sample-trace-array.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/core/pktgen.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/sched/cls_cgroup.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/netfilter/nfnetlink.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/netfilter/nf_conntrack.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/netfilter/nf_tables.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/netfilter/x_tables.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/netfilter/xt_owner.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/netfilter/ipvs/ip_vs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/ipv4/netfilter/ip_tables.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/ipv4/netfilter/arp_tables.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/xfrm/xfrm_user.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/ipv6/netfilter/ip6_tables.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/ipv6/ipv6.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/bpfilter/bpfilter.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/dsa/dsa_core.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/wireless/cfg80211.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/llc/llc2.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/tls/tls.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/bridge/netfilter/ebtables.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/bridge/bridge.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/appletalk/appletalk.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/x25/x25.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/netrom/netrom.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/rose/rose.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/ax25/ax25.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/bluetooth/bluetooth.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/bluetooth/rfcomm/rfcomm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/bluetooth/bnep/bnep.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/bluetooth/cmtp/cmtp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/bluetooth/hidp/hidp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/sunrpc/sunrpc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/sunrpc/auth_gss/auth_rpcgss.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/sunrpc/xprtrdma/rpcrdma.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/rxrpc/rxrpc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/rxrpc/rxperf.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/kcm/kcm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/atm/atm.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/l2tp/l2tp_ppp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/l2tp/l2tp_debugfs.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/phonet/phonet.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/phonet/pn_pep.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/dccp/dccp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/sctp/sctp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/rds/rds.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/rds/rds_rdma.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/rds/rds_tcp.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/tipc/tipc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/smc/smc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/9p/9pnet.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/9p/9pnet_fd.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/9p/9pnet_rdma.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/caif/caif_socket.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/dns_resolver/dns_resolver.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/ceph/libceph.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/nfc/nfc.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/vmw_vsock/vsock.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] has no CRC!
WARNING: modpost: "const_pcpu_hot" [net/qrtr/qrtr.ko] has no CRC!

Presumably introduced by commit

  4604c052b84d ("x86/percpu: Declare const_pcpu_hot as extern const variable")

-- 
Cheers,
Stephen Rothwell

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

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

drivers/input/tests/input_test.o: warning: objtool: input_test_init+0x1cb: stack state mismatch: cfa1=4+64 cfa2=4+56
drivers/gpu/drm/tests/drm_buddy_test.o: warning: objtool: drm_test_buddy_alloc_optimistic+0x3ab: stack state mismatch: cfa1=4+176 cfa2=4+184
drivers/gpu/drm/tests/drm_buddy_test.o: warning: objtool: drm_test_buddy_alloc_pathological+0x741: stack state mismatch: cfa1=4+216 cfa2=4+232
drivers/gpu/drm/tests/drm_buddy_test.o: warning: objtool: drm_test_buddy_alloc_pessimistic+0x486: stack state mismatch: cfa1=4+200 cfa2=4+208
drivers/gpu/drm/tests/drm_buddy_test.o: warning: objtool: drm_test_buddy_alloc_range+0x46e: stack state mismatch: cfa1=4+232 cfa2=4+248
drivers/gpu/drm/tests/drm_mm_test.o: warning: objtool: drm_test_mm_debug+0x1fa: stack state mismatch: cfa1=4+656 cfa2=4+640
lib/kunit/kunit-test.o: warning: objtool: kunit_log_newline_test+0xfb: return with modified stack frame
lib/strscpy_kunit.o: warning: objtool: tc+0x560: stack state mismatch: cfa1=4+128 cfa2=4+136
lib/memcpy_kunit.o: warning: objtool: inner_loop+0x4fc: stack state mismatch: cfa1=4+168 cfa2=4+192
lib/memcpy_kunit.o: warning: objtool: copy_large_test+0xfa: stack state mismatch: cfa1=4+128 cfa2=4+176
lib/stackinit_kunit.o: warning: objtool: test_packed_assigned_dynamic_all+0x2ef: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_trailing_hole_assigned_dynamic_all+0x31c: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_small_hole_assigned_dynamic_all+0x31a: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_packed_dynamic_all+0x2ef: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_trailing_hole_dynamic_all+0x31c: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_small_hole_dynamic_all+0x31a: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_packed_assigned_copy+0x2ef: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_trailing_hole_assigned_copy+0x31c: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_small_hole_assigned_copy+0x31a: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_switch_2_none+0x282: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_switch_1_none+0x282: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_user+0x2ea: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_packed_none+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_trailing_hole_none+0x2ea: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_small_hole_none+0x2e8: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_char_array_none+0x2d3: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_u64_none+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_u32_none+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_u16_none+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_u8_none+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_trailing_hole_runtime_all+0x2ea: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_trailing_hole_assigned_static_all+0x2ea: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_small_hole_runtime_all+0x2e8: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_small_hole_assigned_static_all+0x2e8: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_packed_runtime_partial+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_trailing_hole_runtime_partial+0x2ea: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_small_hole_runtime_partial+0x2e8: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_packed_static_all+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_packed_assigned_static_all+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_packed_runtime_all+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_trailing_hole_static_all+0x2ea: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_small_hole_static_all+0x2e8: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_packed_zero+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_packed_assigned_static_partial+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_packed_static_partial+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_trailing_hole_zero+0x2ea: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_trailing_hole_assigned_static_partial+0x2ea: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_trailing_hole_static_partial+0x2ea: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_small_hole_zero+0x2e8: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_small_hole_assigned_static_partial+0x2e8: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_small_hole_static_partial+0x2e8: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_char_array_zero+0x2d3: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_u64_zero+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_u32_zero+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_u16_zero+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_u8_zero+0x2c1: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_packed_assigned_dynamic_partial+0x2c5: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_trailing_hole_assigned_dynamic_partial+0x323: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_small_hole_assigned_dynamic_partial+0x321: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_packed_dynamic_partial+0x2c5: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_trailing_hole_dynamic_partial+0x323: return with modified stack frame
lib/stackinit_kunit.o: warning: objtool: test_small_hole_dynamic_partial+0x321: return with modified stack frame

Presumably introduced by some change to objtool.

-- 
Cheers,
Stephen Rothwell

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

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

After merging the tip tree, today's linux-next build (htmldocs) produced
these warnings:

Documentation/PCI/msi-howto:380: drivers/pci/msi/api.c:148: ERROR: Unexpected indentation.
Documentation/PCI/msi-howto:380: drivers/pci/msi/api.c:149: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/PCI/msi-howto:380: drivers/pci/msi/api.c:236: ERROR: Unexpected indentation.
Documentation/PCI/msi-howto:380: drivers/pci/msi/api.c:259: ERROR: Unexpected indentation.

Introduced by commits

  5c0997dc33ac ("PCI/MSI: Move pci_alloc_irq_vectors() to api.c")
  017239c8db20 ("PCI/MSI: Move pci_irq_vector() to api.c")
  be37b8428b7b ("PCI/MSI: Move pci_irq_get_affinity() to api.c")

-- 
Cheers,
Stephen Rothwell

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

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

vmlinux.o: warning: objtool: vc_switch_off_ist+0x76: relocation to !ENDBR: entry_SYSCALL_64+0x15c
vmlinux.o: warning: objtool: vc_switch_off_ist+0x8e: relocation to !ENDBR: entry_SYSCALL_compat+0xa5
vmlinux.o: warning: objtool: vc_switch_off_ist+0x96: relocation to !ENDBR: .entry.text+0x21ca
vmlinux.o: warning: objtool: vc_switch_off_ist+0xee: relocation to !ENDBR: .entry.text+0x162
vmlinux.o: warning: objtool: __sev_es_ist_enter+0x5f: relocation to !ENDBR: entry_SYSCALL_64+0x15c
vmlinux.o: warning: objtool: __sev_es_ist_enter+0x6b: relocation to !ENDBR: .entry.text+0x162
vmlinux.o: warning: objtool: __sev_es_ist_enter+0x89: relocation to !ENDBR: entry_SYSCALL_compat+0xa5
vmlinux.o: warning: objtool: __sev_es_ist_enter+0xc0: relocation to !ENDBR: .entry.text+0x21ca

I don't know what caused this.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Tom Lendacky]

On 4/27/22 06:31, Borislav Petkov wrote:
> On Wed, Apr 27, 2022 at 10:10:59AM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (htmldocs) produced
>> these warnings:
>>
>> Documentation/virt/index.rst:7: WARNING: toctree contains reference to nonexisting document 'virt/coco/sev-guest'
>> Documentation/virt/coco/sevguest.rst: WARNING: document isn't included in any toctree
>>
>> Introduced by commit
>>
>>    9617f2f48310 ("virt: sevguest: Rename the sevguest dir and files to sev-guest")
> 
> It looks like Tom forgot to do git mv.
> 
> Fixed now.

Thanks Boris!

Tom

> 
> Thanks!
> 

Re: linux-next: build warnings after merge of the tip tree

[Borislav Petkov]

On Wed, Apr 27, 2022 at 10:10:59AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (htmldocs) produced
> these warnings:
> 
> Documentation/virt/index.rst:7: WARNING: toctree contains reference to nonexisting document 'virt/coco/sev-guest'
> Documentation/virt/coco/sevguest.rst: WARNING: document isn't included in any toctree
> 
> Introduced by commit
> 
>   9617f2f48310 ("virt: sevguest: Rename the sevguest dir and files to sev-guest")

It looks like Tom forgot to do git mv.

Fixed now.

Thanks!

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

After merging the tip tree, today's linux-next build (htmldocs) produced
these warnings:

Documentation/virt/index.rst:7: WARNING: toctree contains reference to nonexisting document 'virt/coco/sev-guest'
Documentation/virt/coco/sevguest.rst: WARNING: document isn't included in any toctree

Introduced by commit

  9617f2f48310 ("virt: sevguest: Rename the sevguest dir and files to sev-guest")

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

On Tue, 15 Mar 2022 13:32:49 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I gained these new ones after merging today's tip tree:
> 
> arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_2block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
> arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_4block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
> arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx() falls through to next function poly1305_blocks_x86_64()
> arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_emit_avx() falls through to next function poly1305_emit_x86_64()
> arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx2() falls through to next function poly1305_blocks_x86_64()
> arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx512() falls through to next function poly1305_blocks_x86_64()

All we have left are the poly1305_ ones.  They are in Linus' tree now.
-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi Peter,

On Tue, 22 Mar 2022 22:52:52 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Tue, Mar 22, 2022 at 02:51:08PM +1100, Stephen Rothwell wrote:
> > 
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > produced these warnings:
> > 
> > WARNING: modpost: EXPORT symbol "device_match_devt" [vmlinux] version ...
> > Is "device_match_devt" prototyped in <asm/asm-prototypes.h>?
> > 
> > I get thousands like this :-(
> > 
> > I don't know what has done this, but there is a new Kbuild and modpost
> > change:
> > 
> >   2f35e67f621f ("kbuild: Fixup the IBT kbuild changes")  
> 
> It was; I rebased that commit and asked Boris to regen tip so you should
> have it fixed for the next round.

Excellent thanks (I just picked up the new tip tree).

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Peter Zijlstra]

On Tue, Mar 22, 2022 at 02:51:08PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced these warnings:
> 
> WARNING: modpost: EXPORT symbol "device_match_devt" [vmlinux] version ...
> Is "device_match_devt" prototyped in <asm/asm-prototypes.h>?
> 
> I get thousands like this :-(
> 
> I don't know what has done this, but there is a new Kbuild and modpost
> change:
> 
>   2f35e67f621f ("kbuild: Fixup the IBT kbuild changes")

It was; I rebased that commit and asked Boris to regen tip so you should
have it fixed for the next round.

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

WARNING: modpost: EXPORT symbol "device_match_devt" [vmlinux] version ...
Is "device_match_devt" prototyped in <asm/asm-prototypes.h>?

I get thousands like this :-(

I don't know what has done this, but there is a new Kbuild and modpost
change:

  2f35e67f621f ("kbuild: Fixup the IBT kbuild changes")

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

On Sat, 22 Jan 2022 10:58:06 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Fri, 17 Dec 2021 14:40:04 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > produced these warnings:
> > 
> > lib/strnlen_user.o: warning: objtool: strnlen_user()+0xc9: call to do_strnlen_user() with UACCESS enabled
> > lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x129: call to do_strncpy_from_user() with UACCESS enabled
> > vmlinux.o: warning: objtool: mce_start()+0x5c: call to __kasan_check_write() leaves .noinstr.text section
> > vmlinux.o: warning: objtool: mce_gather_info()+0x5f: call to v8086_mode.constprop.0() leaves .noinstr.text section
> > vmlinux.o: warning: objtool: mce_read_aux()+0x8a: call to mca_msr_reg() leaves .noinstr.text section
> > vmlinux.o: warning: objtool: do_machine_check()+0x192: call to mce_no_way_out() leaves .noinstr.text section
> > vmlinux.o: warning: objtool: mce_severity_amd.constprop.0()+0xca: call to mce_severity_amd_smca() leaves .noinstr.text section
> > 
> > I am not sure which changes caused the above.  
> 
> I currently still get the following warnings from an x86_64
> allmodconfig build fo Linus' tree:
> 
> vmlinux.o: warning: objtool: mce_start()+0x5c: call to __kasan_check_write() leaves .noinstr.text section
> vmlinux.o: warning: objtool: mce_gather_info()+0x5f: call to v8086_mode.constprop.0() leaves .noinstr.text section
> vmlinux.o: warning: objtool: mce_read_aux()+0x8a: call to mca_msr_reg() leaves .noinstr.text section
> vmlinux.o: warning: objtool: do_machine_check()+0x192: call to mce_no_way_out() leaves .noinstr.text section
> vmlinux.o: warning: objtool: mce_severity_amd.constprop.0()+0xca: call to mce_severity_amd_smca() leaves .noinstr.text section
> 
> $ x86_64-linux-gnu-gcc --version
> x86_64-linux-gnu-gcc (Debian 11.2.0-9) 11.2.0
> $ x86_64-linux-gnu-ld --version
> GNU ld (GNU Binutils for Debian) 2.37

I gained these new ones after merging today's tip tree:

arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_2block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
arch/x86/crypto/chacha-x86_64.o: warning: objtool: chacha_4block_xor_avx512vl() falls through to next function chacha_8block_xor_avx512vl()
arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx() falls through to next function poly1305_blocks_x86_64()
arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_emit_avx() falls through to next function poly1305_emit_x86_64()
arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx2() falls through to next function poly1305_blocks_x86_64()
arch/x86/crypto/poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx512() falls through to next function poly1305_blocks_x86_64()

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

On Fri, 17 Dec 2021 14:40:04 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced these warnings:
> 
> lib/strnlen_user.o: warning: objtool: strnlen_user()+0xc9: call to do_strnlen_user() with UACCESS enabled
> lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x129: call to do_strncpy_from_user() with UACCESS enabled
> vmlinux.o: warning: objtool: mce_start()+0x5c: call to __kasan_check_write() leaves .noinstr.text section
> vmlinux.o: warning: objtool: mce_gather_info()+0x5f: call to v8086_mode.constprop.0() leaves .noinstr.text section
> vmlinux.o: warning: objtool: mce_read_aux()+0x8a: call to mca_msr_reg() leaves .noinstr.text section
> vmlinux.o: warning: objtool: do_machine_check()+0x192: call to mce_no_way_out() leaves .noinstr.text section
> vmlinux.o: warning: objtool: mce_severity_amd.constprop.0()+0xca: call to mce_severity_amd_smca() leaves .noinstr.text section
> 
> I am not sure which changes caused the above.

I currently still get the following warnings from an x86_64
allmodconfig build fo Linus' tree:

vmlinux.o: warning: objtool: mce_start()+0x5c: call to __kasan_check_write() leaves .noinstr.text section
vmlinux.o: warning: objtool: mce_gather_info()+0x5f: call to v8086_mode.constprop.0() leaves .noinstr.text section
vmlinux.o: warning: objtool: mce_read_aux()+0x8a: call to mca_msr_reg() leaves .noinstr.text section
vmlinux.o: warning: objtool: do_machine_check()+0x192: call to mce_no_way_out() leaves .noinstr.text section
vmlinux.o: warning: objtool: mce_severity_amd.constprop.0()+0xca: call to mce_severity_amd_smca() leaves .noinstr.text section

$ x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 11.2.0-9) 11.2.0
$ x86_64-linux-gnu-ld --version
GNU ld (GNU Binutils for Debian) 2.37

-- 
Cheers,
Stephen Rothwell

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

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

lib/strnlen_user.o: warning: objtool: strnlen_user()+0xc9: call to do_strnlen_user() with UACCESS enabled
lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x129: call to do_strncpy_from_user() with UACCESS enabled
vmlinux.o: warning: objtool: mce_start()+0x5c: call to __kasan_check_write() leaves .noinstr.text section
vmlinux.o: warning: objtool: mce_gather_info()+0x5f: call to v8086_mode.constprop.0() leaves .noinstr.text section
vmlinux.o: warning: objtool: mce_read_aux()+0x8a: call to mca_msr_reg() leaves .noinstr.text section
vmlinux.o: warning: objtool: do_machine_check()+0x192: call to mce_no_way_out() leaves .noinstr.text section
vmlinux.o: warning: objtool: mce_severity_amd.constprop.0()+0xca: call to mce_severity_amd_smca() leaves .noinstr.text section

I am not sure which changes caused the above.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[André Almeida]

Hi Stephen,

Às 07:20 de 12/10/21, Stephen Rothwell escreveu:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (htmldocs) produced
> these warnings:
> 
> Error: Cannot open file kernel/futex.c
> Error: Cannot open file kernel/futex.c
> Error: Cannot open file kernel/futex.c
> Error: Cannot open file kernel/futex.c
> 
> Introduced by commit
> 
>   77e52ae35463 ("futex: Move to kernel/futex/")
> 
> $ git grep kernel/futex Documentation
> Documentation/kernel-hacking/locking.rst:.. kernel-doc:: kernel/futex.c
> Documentation/translations/it_IT/kernel-hacking/locking.rst:.. kernel-doc:: kernel/futex.c
> 

Thanks for pointing that out. I posted a fix:

https://lore.kernel.org/lkml/20211012135549.14451-1-andrealmeid@collabora.com/

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

After merging the tip tree, today's linux-next build (htmldocs) produced
these warnings:

Error: Cannot open file kernel/futex.c
Error: Cannot open file kernel/futex.c
Error: Cannot open file kernel/futex.c
Error: Cannot open file kernel/futex.c

Introduced by commit

  77e52ae35463 ("futex: Move to kernel/futex/")

$ git grep kernel/futex Documentation
Documentation/kernel-hacking/locking.rst:.. kernel-doc:: kernel/futex.c
Documentation/translations/it_IT/kernel-hacking/locking.rst:.. kernel-doc:: kernel/futex.c

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Borislav Petkov]

On Mon, Nov 30, 2020 at 09:56:27PM +0000, Ernst, Justin wrote:
> After scratching my head for a while, I found that the issue was
> missing empty lines before three different code-block sections.

Oh great.

> The line number is definitely bogus, but I wasn't able to discover
> why.

Very helpful that tool. :-\

> You can find my patch at: https://lkml.org/lkml/2020/11/30/1196 The
> patch depends on the v2 patch set Mike Travis <mike.travis@hpe.com>
> submitted, which hasn't made it to tip yet.

Yeah, thanks for figuring this out.

I'll simply rebase your previous patch on the tip:x86/platform branch
since it is documentation stuff only and there's only one patch ontop
which updates MAINTAINERS but I don't think it'll be the end of the
world if those two got rebased.

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

RE: linux-next: build warnings after merge of the tip tree

[Ernst, Justin]

> On Mon, Nov 30, 2020 at 06:05:03PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (htmldocs) produced
> > these warnings:
> >
> > Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> > Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> > Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> >
> > Introduced by commit
> >
> >   7ac2f1017115 ("x86/platform/uv: Update ABI documentation of /sys/firmware/sgi_uv/")
> 
> Yah, I can reproduce but I have no clue what sphinx wants from me. Line
> 2 looks ok which could mean that the warning line it points to is bogus.
> 
> Justin, this is all yours. :)

After scratching my head for a while, I found that the issue was missing empty lines before three different code-block sections.
The line number is definitely bogus, but I wasn't able to discover why.

You can find my patch at: https://lkml.org/lkml/2020/11/30/1196
The patch depends on the v2 patch set Mike Travis <mike.travis@hpe.com> submitted, which hasn't made it to tip yet.

Thanks,
-Justin

> 
> Thx.
> 
> --
> Regards/Gruss,
>     Boris.
> 
> SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

Re: linux-next: build warnings after merge of the tip tree

[Borislav Petkov]

On Mon, Nov 30, 2020 at 06:05:03PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (htmldocs) produced
> these warnings:
> 
> Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
> 
> Introduced by commit
> 
>   7ac2f1017115 ("x86/platform/uv: Update ABI documentation of /sys/firmware/sgi_uv/")

Yah, I can reproduce but I have no clue what sphinx wants from me. Line
2 looks ok which could mean that the warning line it points to is bogus.

Justin, this is all yours. :)

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

After merging the tip tree, today's linux-next build (htmldocs) produced
these warnings:

Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.
Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected indentation.

Introduced by commit

  7ac2f1017115 ("x86/platform/uv: Update ABI documentation of /sys/firmware/sgi_uv/")

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Jarkko Sakkinen]

On Mon, Nov 23, 2020 at 06:19:22PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (htmldocs) produced
> these warnings:
> 
> arch/x86/kernel/cpu/sgx/ioctl.c:666: warning: Function parameter or member 'encl' not described in 'sgx_ioc_enclave_provision'
> arch/x86/kernel/cpu/sgx/ioctl.c:666: warning: Excess function parameter 'enclave' description in 'sgx_ioc_enclave_provision'
> 
> Introduced by commit
> 
>   c82c61865024 ("x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION")
> 
> -- 
> Cheers,
> Stephen Rothwell

Thanks, was about sending a fix but saw that Boris put already one out,
when adding "Link: https://lore.kernel.org/linux-next/20201123101334.GC29678@zn.tnic/"

/Jarkko

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

After merging the tip tree, today's linux-next build (htmldocs) produced
these warnings:

arch/x86/kernel/cpu/sgx/ioctl.c:666: warning: Function parameter or member 'encl' not described in 'sgx_ioc_enclave_provision'
arch/x86/kernel/cpu/sgx/ioctl.c:666: warning: Excess function parameter 'enclave' description in 'sgx_ioc_enclave_provision'

Introduced by commit

  c82c61865024 ("x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION")

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Thu, 2 Nov 2017 13:53:51 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced these warnings:
> 
> net/dccp/probe.c: In function 'dccpprobe_init':
> net/dccp/probe.c:166:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>   ret = register_jprobe(&dccp_send_probe);
>   ^
> In file included from net/dccp/probe.c:26:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/dccp/probe.c:170:4: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>     ret = register_jprobe(&dccp_send_probe);
>     ^
> In file included from net/dccp/probe.c:26:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/dccp/probe.c: In function 'dccpprobe_exit':
> net/dccp/probe.c:190:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
>   unregister_jprobe(&dccp_send_probe);
>   ^
> In file included from net/dccp/probe.c:26:0:
> include/linux/kprobes.h:479:33: note: declared here
>  static inline void __deprecated unregister_jprobe(struct jprobe *p)
>                                  ^
> net/ipv4/tcp_probe.c: In function 'tcpprobe_init':
> net/ipv4/tcp_probe.c:280:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>   ret = register_jprobe(&tcp_jprobe);
>   ^
> In file included from net/ipv4/tcp_probe.c:24:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/ipv4/tcp_probe.c: In function 'tcpprobe_exit':
> net/ipv4/tcp_probe.c:298:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
>   unregister_jprobe(&tcp_jprobe);
>   ^
> In file included from net/ipv4/tcp_probe.c:24:0:
> include/linux/kprobes.h:479:33: note: declared here
>  static inline void __deprecated unregister_jprobe(struct jprobe *p)
>                                  ^
> net/sctp/probe.c: In function 'sctp_setup_jprobe':
> net/sctp/probe.c:189:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>   int ret = register_jprobe(&sctp_recv_probe);
>   ^
> In file included from net/sctp/probe.c:28:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/sctp/probe.c:194:3: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>    ret = register_jprobe(&sctp_recv_probe);
>    ^
> In file included from net/sctp/probe.c:28:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/sctp/probe.c: In function 'sctpprobe_exit':
> net/sctp/probe.c:240:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
>   unregister_jprobe(&sctp_recv_probe);
>   ^
> In file included from net/sctp/probe.c:28:0:
> include/linux/kprobes.h:479:33: note: declared here
>  static inline void __deprecated unregister_jprobe(struct jprobe *p)
>                                  ^
> 
> Introduced by commit
> 
>   590c84593045 ("kprobes: Disable the jprobes APIs")
> 
> These days we normally don't deprecate things, just remove them.  But we
> do that *after* fixing up all the usages in the tree, please.

Just a reminder that I am still getting these warnings.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warnings after merge of the tip tree

[Masami Hiramatsu]

On Sat, 4 Nov 2017 09:01:34 +0100
Ingo Molnar <mingo@kernel.org> wrote:

> 
> * Masami Hiramatsu <mhiramat@kernel.org> wrote:
> 
> > > net/sctp/probe.c: In function 'sctpprobe_exit':
> > > net/sctp/probe.c:240:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
> > >   unregister_jprobe(&sctp_recv_probe);
> > >   ^
> > > In file included from net/sctp/probe.c:28:0:
> > > include/linux/kprobes.h:479:33: note: declared here
> > >  static inline void __deprecated unregister_jprobe(struct jprobe *p)
> > >                                  ^
> > > 
> > > Introduced by commit
> > > 
> > >   590c84593045 ("kprobes: Disable the jprobes APIs")
> > > 
> > > These days we normally don't deprecate things, just remove them.  But we
> > > do that *after* fixing up all the usages in the tree, please.
> > 
> > OK, should I remove __deprecated or revert above patch?
> > I pinged such users but no response. I can just rewrite it but not sure they can reply.
> 
> Ideal would be to just fix all these places: convert code where the facility 
> appears to be actively used, remove code where it looks unused. If maintainers 
> don't reply, I can apply them to a separate branch in -tip.

Thanks, that will help me.

> 
> For example I'm pretty sure we can just remove the jprobes usage in SCTP.

Actually TCP and DCCP jprobes usages are similar to that SCTP usage 
(maybe derived from TCP one). For those usages, we can not replace
it with kprobe/ftrace because it depends on the arguments of target funcs.
For such use-cases, we have 3 options;
 - Remove entirely feature if possible (like no more used).
 - Replace it with trace-events, and handle the event from kernel as sched tracer does.
 - Just introduce trace-events, remove usage, and trace it via ftrace or perf.

At a glance, all network probes are just used for printing out the event,
so we can just introduce trace-events and remove usage. I will try it.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: linux-next: build warnings after merge of the tip tree

[Ingo Molnar]

* Masami Hiramatsu <mhiramat@kernel.org> wrote:

> > net/sctp/probe.c: In function 'sctpprobe_exit':
> > net/sctp/probe.c:240:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
> >   unregister_jprobe(&sctp_recv_probe);
> >   ^
> > In file included from net/sctp/probe.c:28:0:
> > include/linux/kprobes.h:479:33: note: declared here
> >  static inline void __deprecated unregister_jprobe(struct jprobe *p)
> >                                  ^
> > 
> > Introduced by commit
> > 
> >   590c84593045 ("kprobes: Disable the jprobes APIs")
> > 
> > These days we normally don't deprecate things, just remove them.  But we
> > do that *after* fixing up all the usages in the tree, please.
> 
> OK, should I remove __deprecated or revert above patch?
> I pinged such users but no response. I can just rewrite it but not sure they can reply.

Ideal would be to just fix all these places: convert code where the facility 
appears to be actively used, remove code where it looks unused. If maintainers 
don't reply, I can apply them to a separate branch in -tip.

For example I'm pretty sure we can just remove the jprobes usage in SCTP.

Thanks,

	Ingo

Re: linux-next: build warnings after merge of the tip tree

[Masami Hiramatsu]

On Thu, 2 Nov 2017 13:53:51 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced these warnings:
> 
> net/dccp/probe.c: In function 'dccpprobe_init':
> net/dccp/probe.c:166:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>   ret = register_jprobe(&dccp_send_probe);
>   ^
> In file included from net/dccp/probe.c:26:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/dccp/probe.c:170:4: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>     ret = register_jprobe(&dccp_send_probe);
>     ^
> In file included from net/dccp/probe.c:26:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/dccp/probe.c: In function 'dccpprobe_exit':
> net/dccp/probe.c:190:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
>   unregister_jprobe(&dccp_send_probe);
>   ^
> In file included from net/dccp/probe.c:26:0:
> include/linux/kprobes.h:479:33: note: declared here
>  static inline void __deprecated unregister_jprobe(struct jprobe *p)
>                                  ^
> net/ipv4/tcp_probe.c: In function 'tcpprobe_init':
> net/ipv4/tcp_probe.c:280:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>   ret = register_jprobe(&tcp_jprobe);
>   ^
> In file included from net/ipv4/tcp_probe.c:24:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/ipv4/tcp_probe.c: In function 'tcpprobe_exit':
> net/ipv4/tcp_probe.c:298:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
>   unregister_jprobe(&tcp_jprobe);
>   ^
> In file included from net/ipv4/tcp_probe.c:24:0:
> include/linux/kprobes.h:479:33: note: declared here
>  static inline void __deprecated unregister_jprobe(struct jprobe *p)
>                                  ^
> net/sctp/probe.c: In function 'sctp_setup_jprobe':
> net/sctp/probe.c:189:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>   int ret = register_jprobe(&sctp_recv_probe);
>   ^
> In file included from net/sctp/probe.c:28:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/sctp/probe.c:194:3: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
>    ret = register_jprobe(&sctp_recv_probe);
>    ^
> In file included from net/sctp/probe.c:28:0:
> include/linux/kprobes.h:471:32: note: declared here
>  static inline int __deprecated register_jprobe(struct jprobe *p)
>                                 ^
> net/sctp/probe.c: In function 'sctpprobe_exit':
> net/sctp/probe.c:240:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
>   unregister_jprobe(&sctp_recv_probe);
>   ^
> In file included from net/sctp/probe.c:28:0:
> include/linux/kprobes.h:479:33: note: declared here
>  static inline void __deprecated unregister_jprobe(struct jprobe *p)
>                                  ^
> 
> Introduced by commit
> 
>   590c84593045 ("kprobes: Disable the jprobes APIs")
> 
> These days we normally don't deprecate things, just remove them.  But we
> do that *after* fixing up all the usages in the tree, please.

OK, should I remove __deprecated or revert above patch?
I pinged such users but no response. I can just rewrite it but not sure they can reply.

Thank you,

> 
> -- 
> Cheers,
> Stephen Rothwell


-- 
Masami Hiramatsu <mhiramat@kernel.org>

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

net/dccp/probe.c: In function 'dccpprobe_init':
net/dccp/probe.c:166:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
  ret = register_jprobe(&dccp_send_probe);
  ^
In file included from net/dccp/probe.c:26:0:
include/linux/kprobes.h:471:32: note: declared here
 static inline int __deprecated register_jprobe(struct jprobe *p)
                                ^
net/dccp/probe.c:170:4: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
    ret = register_jprobe(&dccp_send_probe);
    ^
In file included from net/dccp/probe.c:26:0:
include/linux/kprobes.h:471:32: note: declared here
 static inline int __deprecated register_jprobe(struct jprobe *p)
                                ^
net/dccp/probe.c: In function 'dccpprobe_exit':
net/dccp/probe.c:190:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
  unregister_jprobe(&dccp_send_probe);
  ^
In file included from net/dccp/probe.c:26:0:
include/linux/kprobes.h:479:33: note: declared here
 static inline void __deprecated unregister_jprobe(struct jprobe *p)
                                 ^
net/ipv4/tcp_probe.c: In function 'tcpprobe_init':
net/ipv4/tcp_probe.c:280:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
  ret = register_jprobe(&tcp_jprobe);
  ^
In file included from net/ipv4/tcp_probe.c:24:0:
include/linux/kprobes.h:471:32: note: declared here
 static inline int __deprecated register_jprobe(struct jprobe *p)
                                ^
net/ipv4/tcp_probe.c: In function 'tcpprobe_exit':
net/ipv4/tcp_probe.c:298:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
  unregister_jprobe(&tcp_jprobe);
  ^
In file included from net/ipv4/tcp_probe.c:24:0:
include/linux/kprobes.h:479:33: note: declared here
 static inline void __deprecated unregister_jprobe(struct jprobe *p)
                                 ^
net/sctp/probe.c: In function 'sctp_setup_jprobe':
net/sctp/probe.c:189:2: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
  int ret = register_jprobe(&sctp_recv_probe);
  ^
In file included from net/sctp/probe.c:28:0:
include/linux/kprobes.h:471:32: note: declared here
 static inline int __deprecated register_jprobe(struct jprobe *p)
                                ^
net/sctp/probe.c:194:3: warning: 'register_jprobe' is deprecated [-Wdeprecated-declarations]
   ret = register_jprobe(&sctp_recv_probe);
   ^
In file included from net/sctp/probe.c:28:0:
include/linux/kprobes.h:471:32: note: declared here
 static inline int __deprecated register_jprobe(struct jprobe *p)
                                ^
net/sctp/probe.c: In function 'sctpprobe_exit':
net/sctp/probe.c:240:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
  unregister_jprobe(&sctp_recv_probe);
  ^
In file included from net/sctp/probe.c:28:0:
include/linux/kprobes.h:479:33: note: declared here
 static inline void __deprecated unregister_jprobe(struct jprobe *p)
                                 ^

Introduced by commit

  590c84593045 ("kprobes: Disable the jprobes APIs")

These days we normally don't deprecate things, just remove them.  But we
do that *after* fixing up all the usages in the tree, please.

-- 
Cheers,
Stephen Rothwell

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

In file included from arch/x86/include/asm/paravirt_types.h:44:0,
                 from arch/x86/include/asm/ptrace.h:71,
                 from arch/x86/include/asm/math_emu.h:4,
                 from arch/x86/include/asm/processor.h:11,
                 from arch/x86/include/asm/cpufeature.h:4,
                 from arch/x86/include/asm/thread_info.h:52,
                 from include/linux/thread_info.h:37,
                 from arch/x86/include/asm/preempt.h:6,
                 from include/linux/preempt.h:80,
                 from include/linux/spinlock.h:50,
                 from include/linux/seqlock.h:35,
                 from include/linux/time.h:5,
                 from include/uapi/linux/timex.h:56,
                 from include/linux/timex.h:56,
                 from include/linux/clocksource.h:12,
                 from arch/x86/include/asm/vgtod.h:5,
                 from arch/x86/entry/vdso/vdso32/../vclock_gettime.c:15,
                 from arch/x86/entry/vdso/vdso32/vclock_gettime.c:32:
arch/x86/include/asm/pgtable.h: In function 'pte_flags_pkey':
arch/x86/include/asm/pgtable_types.h:56:43: warning: left shift count >= width of type [-Wshift-count-overflow]
 #define _PAGE_PKEY_BIT0 (_AT(pteval_t, 1) << _PAGE_BIT_PKEY_BIT0)
                                           ^
arch/x86/include/asm/pgtable_types.h:68:26: note: in expansion of macro '_PAGE_PKEY_BIT0'
 #define _PAGE_PKEY_MASK (_PAGE_PKEY_BIT0 | \
                          ^
arch/x86/include/asm/pgtable.h:1187:22: note: in expansion of macro '_PAGE_PKEY_MASK'
  return (pte_flags & _PAGE_PKEY_MASK) >> _PAGE_BIT_PKEY_BIT0;
                      ^
arch/x86/include/asm/pgtable_types.h:57:43: warning: left shift count >= width of type [-Wshift-count-overflow]
 #define _PAGE_PKEY_BIT1 (_AT(pteval_t, 1) << _PAGE_BIT_PKEY_BIT1)
                                           ^
arch/x86/include/asm/pgtable_types.h:69:5: note: in expansion of macro '_PAGE_PKEY_BIT1'
     _PAGE_PKEY_BIT1 | \
     ^
arch/x86/include/asm/pgtable.h:1187:22: note: in expansion of macro '_PAGE_PKEY_MASK'
  return (pte_flags & _PAGE_PKEY_MASK) >> _PAGE_BIT_PKEY_BIT0;
                      ^
arch/x86/include/asm/pgtable_types.h:58:43: warning: left shift count >= width of type [-Wshift-count-overflow]
 #define _PAGE_PKEY_BIT2 (_AT(pteval_t, 1) << _PAGE_BIT_PKEY_BIT2)
                                           ^
arch/x86/include/asm/pgtable_types.h:70:5: note: in expansion of macro '_PAGE_PKEY_BIT2'
     _PAGE_PKEY_BIT2 | \
     ^
arch/x86/include/asm/pgtable.h:1187:22: note: in expansion of macro '_PAGE_PKEY_MASK'
  return (pte_flags & _PAGE_PKEY_MASK) >> _PAGE_BIT_PKEY_BIT0;
                      ^
arch/x86/include/asm/pgtable_types.h:59:43: warning: left shift count >= width of type [-Wshift-count-overflow]
 #define _PAGE_PKEY_BIT3 (_AT(pteval_t, 1) << _PAGE_BIT_PKEY_BIT3)
                                           ^
arch/x86/include/asm/pgtable_types.h:71:5: note: in expansion of macro '_PAGE_PKEY_BIT3'
     _PAGE_PKEY_BIT3)
     ^
arch/x86/include/asm/pgtable.h:1187:22: note: in expansion of macro '_PAGE_PKEY_MASK'
  return (pte_flags & _PAGE_PKEY_MASK) >> _PAGE_BIT_PKEY_BIT0;
                      ^
In file included from include/linux/kasan.h:16:0,
                 from include/linux/slab.h:120,
                 from include/linux/irq.h:25,
                 from arch/x86/include/asm/hardirq.h:5,
                 from include/linux/hardirq.h:8,
                 from include/linux/interrupt.h:12,
                 from arch/x86/include/asm/mshyperv.h:5,
                 from arch/x86/entry/vdso/vdso32/../vclock_gettime.c:20,
                 from arch/x86/entry/vdso/vdso32/vclock_gettime.c:32:
arch/x86/include/asm/pgtable.h:1187:39: warning: right shift count >= width of type [-Wshift-count-overflow]
  return (pte_flags & _PAGE_PKEY_MASK) >> _PAGE_BIT_PKEY_BIT0;
                                       ^

I have no idea what caused this.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Thu, 14 Jul 2016 13:37:29 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (powerpc64le perf)
> produced these warnings:
> 
> Warning: tools/include/uapi/linux/bpf.h differs from kernel
> Warning: tools/arch/x86/include/asm/disabled-features.h differs from kernel
> Warning: tools/arch/x86/include/asm/required-features.h differs from kernel
> Warning: tools/arch/x86/include/asm/cpufeatures.h differs from kernel
> 
> Introduced by commits
> 
>   7d7d1bf1d1da ("perf bench: Copy kernel files needed to build mem{cpy,set} x86_64 benchmarks")
>   971e827bffef ("tools lib bpf: Copy bpf.h and bpf_common.h from the kernel")

The kvm tree has introduced a few more:

Warning: tools/arch/s390/include/uapi/asm/kvm.h
Warning: tools/arch/s390/include/uapi/asm/sie.h

-- 
Cheers,
Stephen Rothwell

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

In file included from tools/include/linux/hashtable.h:12:0,
                 from elf.h:24,
                 from builtin-check.c:33:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from tools/include/linux/types.h:9,
                 from tools/include/linux/list.h:4,
                 from elf.h:23,
                 from builtin-check.c:33:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the previous definition
 #define BITS_PER_LONG 32
 ^
In file included from tools/include/linux/hashtable.h:12:0,
                 from elf.h:24,
                 from special.h:22,
                 from special.c:26:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from tools/include/linux/types.h:9,
                 from tools/include/linux/list.h:4,
                 from elf.h:23,
                 from special.h:22,
                 from special.c:26:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the previous definition
 #define BITS_PER_LONG 32
 ^
In file included from tools/include/linux/hashtable.h:12:0,
                 from elf.h:24,
                 from elf.c:30:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from tools/include/linux/types.h:9,
                 from tools/include/linux/list.h:4,
                 from elf.h:23,
                 from elf.c:30:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the previous definition
 #define BITS_PER_LONG 32
 ^
cc1: all warnings being treated as errors
In file included from tools/include/linux/hashtable.h:12:0,
                 from arch/x86/../../elf.h:24,
                 from arch/x86/decode.c:26:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from tools/include/linux/types.h:9,
                 from tools/include/linux/list.h:4,
                 from arch/x86/../../elf.h:23,
                 from arch/x86/decode.c:26:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the previous definition
 #define BITS_PER_LONG 32
 ^

Introduced (I think) by commit

  bb9707077b4e ("tools: Copy the bitsperlong.h files from the kernel")

I saw some discussion of this, so I assume ti will be fixed soon.

-- 
Cheers,
Stephen Rothwell

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (powerpc64le perf)
produced these warnings:

Warning: tools/include/uapi/linux/bpf.h differs from kernel
Warning: tools/arch/x86/include/asm/disabled-features.h differs from kernel
Warning: tools/arch/x86/include/asm/required-features.h differs from kernel
Warning: tools/arch/x86/include/asm/cpufeatures.h differs from kernel

Introduced by commits

  7d7d1bf1d1da ("perf bench: Copy kernel files needed to build mem{cpy,set} x86_64 benchmarks")
  971e827bffef ("tools lib bpf: Copy bpf.h and bpf_common.h from the kernel")

-- 
Cheers,
Stephen Rothwell

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

After merging the tip tree, today's linux-next build (powerpc allnoconfig)
produced these warnings:

kernel/sched/fair.c:801:22: warning: 'task_h_load' declared 'static' but never defined [-Wunused-function]
kernel/sched/fair.c:1013:13: warning: 'account_offnode_enqueue' defined but not used [-Wunused-function]

Introduced by commit 4ae834f767c5 ("sched/numa: Implement NUMA home-node
selection code").

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

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

Re: linux-next: build warnings after merge of the tip tree

[Jaswinder Singh]

Hello,

On Mon, Jan 31, 2011 at 9:57 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) produced these warnings:
>
> kernel/sched.c:3719: warning: 'irqtime_account_idle_ticks' defined but not used
> kernel/sched.c:3720: warning: 'irqtime_account_process_tick' defined but not used
>

These functions should move inside ifndef CONFIG_VIRT_CPU_ACCOUNTING

Thanks,
--
Jaswinder Singh.

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

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

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:

kernel/sched.c:3719: warning: 'irqtime_account_idle_ticks' defined but not used
kernel/sched.c:3720: warning: 'irqtime_account_process_tick' defined but not used

Introduced by commit abb74cefa9c682fb38ba86c17ca3c86fed6cc464 ("sched:
Export ns irqtimes through /proc/stat").
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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