All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	x86@kernel.org
Subject: Re: linux-next: build warnings after merge of the crc tree
Date: Mon, 17 Feb 2025 19:51:06 +0100	[thread overview]
Message-ID: <20250217185106.GA7304@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20250217181611.GA1258@sol.localdomain>

On Mon, Feb 17, 2025 at 10:16:11AM -0800, Eric Biggers wrote:
> On Mon, Feb 17, 2025 at 05:05:55PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the crc tree, today's linux-next build (x86_84 allmodconfig)
> > produced these warnings:
> > 
> > vmlinux.o: warning: objtool: crc32_x86_init+0x1c0: relocation to !ENDBR: crc32_lsb_vpclmul_avx10_256+0x0
> > vmlinux.o: warning: objtool: crc64_x86_init+0x183: relocation to !ENDBR: crc64_msb_vpclmul_avx10_256+0x0
> > vmlinux.o: warning: objtool: crc_t10dif_x86_init+0x183: relocation to !ENDBR: crc16_msb_vpclmul_avx10_256+0x0
> > vmlinux.o: warning: objtool: __SCK__crc32_lsb_pclmul+0x0: data relocation to !ENDBR: crc32_lsb_pclmul_sse+0x0
> > vmlinux.o: warning: objtool: __SCK__crc64_lsb_pclmul+0x0: data relocation to !ENDBR: crc64_lsb_pclmul_sse+0x0
> > vmlinux.o: warning: objtool: __SCK__crc64_msb_pclmul+0x0: data relocation to !ENDBR: crc64_msb_pclmul_sse+0x0
> > vmlinux.o: warning: objtool: __SCK__crc16_msb_pclmul+0x0: data relocation to !ENDBR: crc16_msb_pclmul_sse+0x0
> > 
> > I have no idea what has caused these.  Just sending to the crc tree
> > owner (due to the symbol names) and Peter (since he made the only new
> > change to objtool - though it doesn't look vrey related).
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> 
> Thanks.  I'm wondering if this means the crc assembly functions need to use
> SYM_TYPED_FUNC_START instead of SYM_FUNC_START.  But they are only called via
> static_calls, not indirect calls, so previously this didn't seem to be necessary
> even with CFI enabled.  I'll look into it.  Peter, any thoughts on this?

I removed the ENDBR from SYM_FUNC_START() because it is insufficient vs
CFI, so no point in having it there.

If these functions are not indirectly called and only ever used through
static_call() (as you say) you can adorn them with:

	ANNOTATE_NOENDBR

to tell objtool to STFU :-)

      reply	other threads:[~2025-02-17 18:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-17  6:05 linux-next: build warnings after merge of the crc tree Stephen Rothwell
2025-02-17 18:16 ` Eric Biggers
2025-02-17 18:51   ` Peter Zijlstra [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250217185106.GA7304@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=ebiggers@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.