Re: [PATCH] drivers: remoteproc: xlnx: Add Versal and Versal-NET support
Hi Tanmay,
On Thu, Apr 18, 2024 at 03:01:25PM -0700, Tanmay Shah wrote:
> AMD-Xilinx Versal platform is successor of ZynqMP platform.
> Real-time Processing Unit R5 cluster IP on Versal is same as
> of ZynqMP Platform. Power-domains ids for Versal platform is
> different than ZynqMP.
>
> AMD-Xilinx Versal-NET platform is successor of Versal platform.
> Versal-NET Real-Time Processing Unit has two clusters and each
> cluster contains dual core ARM Cortex-R52 processors. Each R52
> core is assigned 128KB of TCM memory.
>
> Signed-off-by: Tanmay Shah
> ---
> drivers/remoteproc/xlnx_r5_remoteproc.c | 53 -
> 1 file changed, 17 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
> b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 7b1c12108bff..a6d8ac7394e7 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -300,36 +300,6 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc,
> int vqid)
> dev_warn(dev, "failed to send message\n");
> }
>
> -/*
> - * zynqmp_r5_set_mode()
> - *
> - * set RPU cluster and TCM operation mode
> - *
> - * @r5_core: pointer to zynqmp_r5_core type object
> - * @fw_reg_val: value expected by firmware to configure RPU cluster mode
> - * @tcm_mode: value expected by fw to configure TCM mode (lockstep or split)
> - *
> - * Return: 0 for success and < 0 for failure
> - */
> -static int zynqmp_r5_set_mode(struct zynqmp_r5_core *r5_core,
> - enum rpu_oper_mode fw_reg_val,
> - enum rpu_tcm_comb tcm_mode)
> -{
> - int ret;
> -
> - ret = zynqmp_pm_set_rpu_mode(r5_core->pm_domain_id, fw_reg_val);
> - if (ret < 0) {
> - dev_err(r5_core->dev, "failed to set RPU mode\n");
> - return ret;
> - }
> -
> - ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
> - if (ret < 0)
> - dev_err(r5_core->dev, "failed to configure TCM\n");
> -
> - return ret;
> -}
> -
> /*
> * zynqmp_r5_rproc_start()
> * @rproc: single R5 core's corresponding rproc instance
> @@ -941,7 +911,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster
> *cluster,
> /* Maintain backward compatibility for zynqmp by using hardcode TCM
> address. */
> if (of_find_property(r5_core->np, "reg", NULL))
> ret = zynqmp_r5_get_tcm_node_from_dt(cluster);
> - else
> + else if (device_is_compatible(dev, "xlnx,zynqmp-r5fss"))
> ret = zynqmp_r5_get_tcm_node(cluster);
This change breaks the build with clang:
drivers/remoteproc/xlnx_r5_remoteproc.c:914:11: error: variable 'ret' is used
uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
914 | else if (device_is_compatible(dev, "xlnx,zynqmp-r5fss"))
| ^~
drivers/remoteproc/xlnx_r5_remoteproc.c:917:6: note: uninitialized use occurs
here
917 | if (ret) {
| ^~~
drivers/remoteproc/xlnx_r5_remoteproc.c:914:7: note: remove the 'if' if its
condition is always true
914 | else if (device_is_compatible(dev, "xlnx,zynqmp-r5fss"))
| ^~~
915 | ret = zynqmp_r5_get_tcm_node(cluster);
drivers/remoteproc/xlnx_r5_remoteproc.c:907:9: note: initialize the variable
'ret' to silence this warning
907 | int ret, i;
|^
| = 0
1 error generated.
Should ret be initialized to zero or should there be an else statement?
Cheers,
Nathan
>
> if (ret) {
> @@ -960,12 +930,21 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster
> *cluster,
> return ret;
> }
>
> - ret = zynqmp_r5_set_mode(r5_core, fw_reg_val, tcm_mode);
> - if (ret) {
> - dev_err(dev, "failed to set r5 cluster mode %d, err
> %d\n",
> - cluster->mode, ret);
> + ret = zynqmp_pm_set_rpu_mode(r5_core->pm_domain_id, fw_reg_val);
> + if (ret < 0) {
> + dev_err(r5_core->dev, "failed to set RPU mode\n");
> return ret;
> }
> +
> + if (of_find_property(dev_of_node(dev), "xlnx,tcm-mode", NULL) ||
> + device_is_compatible(dev, "xlnx,zynqmp-r5fss")) {
> + ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id,
> +tcm_mode);
> + if (ret < 0) {
> + dev_err(r5_core->dev, "failed to configure
> TCM\n");
> + return ret;
> + }
> + }
> }
>
> return 0;
> @@ -1022,7 +1001,7 @@ static int zynqmp_r5_cluster_init(struct
>
Re: [PATCH 0/2] tracing: Fully silence instance of -Wstring-compare
On Tue, Mar 19, 2024 at 06:15:09PM -0400, Steven Rostedt wrote:
> On Tue, 19 Mar 2024 09:07:51 -0700
> Nathan Chancellor wrote:
>
> > Hi all,
> >
> > This series fully resolves the new instance of -Wstring-compare from
> > within the __assign_str() macro. The first patch resolves a build
> > failure with GCC that would be seen with just the second patch applied.
> > The second patch actually hides the warning.
> >
> > NOTE: This is based on trace/for-next, which does not contain the
> > minimum LLVM version bump that occurred later in the current merge
> > window, so this uses
> >
> > __diag_ignore(clang, 11, ...
> >
> > instead of
> >
> > __diag_ignore(clang, 13, ...
> >
> > which will be required when this is merged into Linus's tree. If you can
> > base this series on a tree that has the merge commit e5eb28f6d1af ("Merge
> > tag 'mm-nonmm-stable-2024-03-14-09-36' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm") in it, then that
> > change can be done at application time, rather than merge time (or I can
> > send a v2). It would be really nice for this to make the merge window so
> > that this warning does not proliferate into other trees that base on
> > -rc1.
> >
>
> I'm guessing this isn't needed with the last update.
Correct, this is resolved in Linus's tree and should be in -next
tomorrow. The first patch may be worth sending standalone, I'll think
about sending it later but that can go in via some other tree, not
yours.
Cheers,
Nathan
[PATCH 2/2] tracing: Ignore -Wstring-compare with diagnostic macros
Commit b1afefa62ca9 ("tracing: Use strcmp() in __assign_str() WARN_ON()
check") addressed a clang warning, -Wstring-compare, with the use of
__builtin_constant_p() to dispatch to strcmp() if the source string is a
string literal and a direct comparison if not. Unfortunately, even with
this change, the warning is still present because __builtin_constant_p()
is not evaluated at this stage of the pipeline, so clang still thinks
the else branch could occur for this situation:
include/trace/events/sunrpc.h:705:4: error: result of comparison against a
string literal is unspecified (use an explicit string comparison function
instead) [-Werror,-Wstring-compare]
...
include/trace/stages/stage6_event_callback.h:40:15: note: expanded from macro
'__assign_str'
40 | (src) != __data_offsets.dst##_ptr_);
\
|^
...
Use the compiler diagnostic macros to disable this warning around the
WARN_ON_ONCE() expression since a string comparison function, strcmp(),
will always be used for the comparison of string literals.
Fixes: b1afefa62ca9 ("tracing: Use strcmp() in __assign_str() WARN_ON() check")
Reported-by: Linux Kernel Functional Testing
Closes:
https://lore.kernel.org/all/CA+G9fYs=otkazs6g1p1ewadfr0qoe6lgovsohqkxmfxoteo...@mail.gmail.com/
Signed-off-by: Nathan Chancellor
---
include/trace/stages/stage6_event_callback.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/trace/stages/stage6_event_callback.h
b/include/trace/stages/stage6_event_callback.h
index 83da83a0c14f..56a4eea5a48e 100644
--- a/include/trace/stages/stage6_event_callback.h
+++ b/include/trace/stages/stage6_event_callback.h
@@ -35,9 +35,14 @@
do {\
char *__str__ = __get_str(dst); \
int __len__ = __get_dynamic_array_len(dst) - 1; \
+ __diag_push(); \
+ __diag_ignore(clang, 11, "-Wstring-compare",\
+ "__builtin_constant_p() ensures strcmp()" \
+ "will be used for string literals"); \
WARN_ON_ONCE(__builtin_constant_p(src) ?\
strcmp((src), __data_offsets.dst##_ptr_) : \
(src) != __data_offsets.dst##_ptr_); \
+ __diag_pop(); \
memcpy(__str__, __data_offsets.dst##_ptr_ ? : \
EVENT_NULL_STR, __len__);\
__str__[__len__] = '\0';\
--
2.44.0
[PATCH 0/2] tracing: Fully silence instance of -Wstring-compare
Hi all,
This series fully resolves the new instance of -Wstring-compare from
within the __assign_str() macro. The first patch resolves a build
failure with GCC that would be seen with just the second patch applied.
The second patch actually hides the warning.
NOTE: This is based on trace/for-next, which does not contain the
minimum LLVM version bump that occurred later in the current merge
window, so this uses
__diag_ignore(clang, 11, ...
instead of
__diag_ignore(clang, 13, ...
which will be required when this is merged into Linus's tree. If you can
base this series on a tree that has the merge commit e5eb28f6d1af ("Merge
tag 'mm-nonmm-stable-2024-03-14-09-36' of
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm") in it, then that
change can be done at application time, rather than merge time (or I can
send a v2). It would be really nice for this to make the merge window so
that this warning does not proliferate into other trees that base on
-rc1.
---
Nathan Chancellor (2):
compiler_types: Ensure __diag_clang() is always available
tracing: Ignore -Wstring-compare with diagnostic macros
include/linux/compiler_types.h | 4
include/trace/stages/stage6_event_callback.h | 5 +
2 files changed, 9 insertions(+)
---
base-commit: 7604256cecef34a82333d9f78262d3180f4eb525
change-id: 20240319-tracing-fully-silence-wstring-compare-e71e2fd17b2a
Best regards,
--
Nathan Chancellor
[PATCH 1/2] compiler_types: Ensure __diag_clang() is always available
Attempting to use __diag_clang() and build with GCC results in a build
error:
include/linux/compiler_types.h:468:38: error: 'ignore' undeclared (first use
in this function); did you mean 'inode'?
468 | __diag_ ## compiler(version, ignore, option)
| ^~
This error occurs because __diag_clang() is only defined in
compiler-clang.h, which is only included when using clang as the
compiler. This error has not been seen before because __diag_clang() has
only been used in __diag_ignore_all(), which is defined in both
compiler-clang.h and compiler-gcc.h.
Add an empty stub for __diag_clang() in compiler_types.h, so that it is
always defined and just becomes a no-op when using GCC.
Fixes: f014a00bbeb0 ("compiler-clang.h: Add __diag infrastructure for clang")
Signed-off-by: Nathan Chancellor
---
include/linux/compiler_types.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 3e64ec0f7ac8..fb0c3ff5497d 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -461,6 +461,10 @@ struct ftrace_likely_data {
#define __diag_GCC(version, severity, string)
#endif
+#ifndef __diag_clang
+#define __diag_clang(version, severity, string)
+#endif
+
#define __diag_push() __diag(push)
#define __diag_pop() __diag(pop)
--
2.44.0
Re: net/sunrpc/sched.c: error: result of comparison against a string literal is unspecified (use an explicit string comparison function instead)
Hi Naresh,
On Mon, Mar 18, 2024 at 02:55:54PM +0530, Naresh Kamboju wrote:
> The following build warnings / errors noticed on x86 kselftests build with
> clang nightly / clang-17 on Linux next tag next-20240318.
>
> This build config is generated from kselftest merge configs [1].
>
> Reported-by: Linux Kernel Functional Testing
>
> Build log:
> ---
> In file included from net/sunrpc/sched.c:31:
> In file included from include/trace/events/sunrpc.h:2524:
> In file included from include/trace/define_trace.h:102:
> In file included from include/trace/trace_events.h:419:
> include/trace/events/sunrpc.h:707:4: error: result of comparison
> against a string literal is unspecified (use an explicit string
> comparison function instead) [-Werror,-Wstring-compare]
> 667 | __assign_str(progname,
> | ~~
> 668 |
> task->tk_client->cl_program->name);
> |
> ~~~
> 669 | __entry->version = task->tk_client->cl_vers;
> |
> 670 | __assign_str(procedure,
> task->tk_msg.rpc_proc->p_name);
> |
Thanks for the report. This is caused by commit 433e1d88a3be ("tracing:
Add warning if string in __assign_str() does not match __string()") from
the tracing tree, not a change on the netdev side (although I have left
them on CC for this reply so they are aware of that).
To resolve it, [1] needs to be applied then the following diff can be
applied on top of that to fully clear it up (as __builtin_constant_p()
does not influence diagnostics in the front end, so the warning still
triggers on the else branch when it will really use strcmp(), as Steve
tested at [2]).
[1]: https://lore.kernel.org/20240312113002.00031...@gandalf.local.home/
[2]: https://lore.kernel.org/20240313161420.3b668...@gandalf.local.home/
diff --git a/include/trace/stages/stage6_event_callback.h
b/include/trace/stages/stage6_event_callback.h
index 83da83a0c14f..dbd27adb1b83 100644
--- a/include/trace/stages/stage6_event_callback.h
+++ b/include/trace/stages/stage6_event_callback.h
@@ -35,9 +35,14 @@
do {\
char *__str__ = __get_str(dst); \
int __len__ = __get_dynamic_array_len(dst) - 1; \
+ __diag_push(); \
+ __diag_ignore(clang, 13, "-Wstring-compare",\
+ "__builtin_constant_p() ensures strcmp()" \
+ "will be used for string literals"); \
WARN_ON_ONCE(__builtin_constant_p(src) ?\
strcmp((src), __data_offsets.dst##_ptr_) : \
(src) != __data_offsets.dst##_ptr_); \
+ __diag_pop(); \
memcpy(__str__, __data_offsets.dst##_ptr_ ? : \
EVENT_NULL_STR, __len__);\
__str__[__len__] = '\0';\
Re: [PATCH] tracing: Use strcmp() in __assign_str() WARN_ON() check
On Tue, Mar 12, 2024 at 11:30:02AM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The WARN_ON() check in __assign_str() to catch where the source variable
> to the macro doesn't match the source variable to __string() gives an
> error in clang:
>
> >> include/trace/events/sunrpc.h:703:4: warning: result of comparison against
> >> a string literal is unspecified (use an explicit string comparison
> >> function instead) [-Wstring-compare]
> 670 | __assign_str(progname, "unknown");
>
> That's because the __assign_str() macro has:
>
>WARN_ON_ONCE((src) != __data_offsets.dst##_ptr_);
>
> Where "src" is a string literal. Clang warns when comparing a string
> literal directly as it is undefined to what the value of the literal is.
>
> Since this is still to make sure the same string that goes to __string()
> is the same as __assign_str(), for string literals do a test for that and
> then use strcmp() in those cases
>
> Note that this depends on commit 51270d573a8d ("tracing/net_sched: Fix
> tracepoints that save qdisc_dev() as a string") being applied, as this was
> what found that bug.
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202402292111.kidexylu-...@intel.com/
> Fixes: 433e1d88a3be ("tracing: Add warning if string in __assign_str() does
> not match __string()")
Is this change destined for 6.9 or 6.10? I applied it to current
trace/core (eb1533d156d3) along with 51270d573a8d but the warning is
still present. I even tried
__builtin_choose_expr(__is_constexpr((src)),
strcmp((src), __data_offsets.dst##_ptr_),
(src) != __data_offsets.dst##_ptr_));
but not even that silenced the warning. I think we will still need a
diag directive to fully silence this warning.
> Signed-off-by: Steven Rostedt (Google)
> ---
> include/trace/stages/stage6_event_callback.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/trace/stages/stage6_event_callback.h
> b/include/trace/stages/stage6_event_callback.h
> index a0c15f67eabe..83da83a0c14f 100644
> --- a/include/trace/stages/stage6_event_callback.h
> +++ b/include/trace/stages/stage6_event_callback.h
> @@ -35,7 +35,9 @@
> do {\
> char *__str__ = __get_str(dst); \
> int __len__ = __get_dynamic_array_len(dst) - 1; \
> - WARN_ON_ONCE((src) != __data_offsets.dst##_ptr_); \
> + WARN_ON_ONCE(__builtin_constant_p(src) ?\
> + strcmp((src), __data_offsets.dst##_ptr_) : \
> + (src) != __data_offsets.dst##_ptr_); \
> memcpy(__str__, __data_offsets.dst##_ptr_ ? : \
> EVENT_NULL_STR, __len__);\
> __str__[__len__] = '\0';\
> --
> 2.43.0
>
Re: [PATCH 1/6] tools/rtla: Fix Makefile compiler options for clang
On Tue, Feb 06, 2024 at 12:05:29PM +0100, Daniel Bristot de Oliveira wrote:
> The following errors are showing up when compiling rtla with clang:
>
> $ make HOSTCC=clang CC=clang LLVM_IAS=1
> [...]
>
> clang -O -g -DVERSION=\"6.8.0-rc1\" -flto=auto -ffat-lto-objects
> -fexceptions -fstack-protector-strong
> -fasynchronous-unwind-tables -fstack-clash-protection -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -Wno-maybe-uninitialized
> $(pkg-config --cflags libtracefs)-c -o src/utils.o src/utils.c
>
> clang: warning: optimization flag '-ffat-lto-objects' is not supported
> [-Wignored-optimization-argument]
For what it's worth, this flag is supported in clang 17.0.0 and newer:
https://github.com/llvm/llvm-project/commit/610fc5cbcc8b68879c562f6458608afe2473ab7f
But if it is not critical, just dropping the flag like you have done
here rather than conditionally supporting it is probably easier.
> warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean
> '-Wno-uninitialized'? [-Wunknown-warning-option]
> 1 warning generated.
>
> clang -o rtla -ggdb src/osnoise.o src/osnoise_hist.o src/osnoise_top.o
> src/rtla.o src/timerlat_aa.o src/timerlat.o src/timerlat_hist.o
> src/timerlat_top.o src/timerlat_u.o src/trace.o src/utils.o $(pkg-config
> --libs libtracefs)
>
> src/osnoise.o: file not recognized: file format not recognized
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> make: *** [Makefile:110: rtla] Error 1
>
> Solve these issues by:
> - removing -ffat-lto-objects and -Wno-maybe-uninitialized if using clang
> - informing the linker about -flto=auto
>
> Cc: sta...@vger.kernel.org
> Fixes: 1a7b22ab15eb ("tools/rtla: Build with EXTRA_{C,LD}FLAGS")
> Suggested-by: Donald Zickus
> Signed-off-by: Daniel Bristot de Oliveira
> ---
> tools/tracing/rtla/Makefile | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tools/tracing/rtla/Makefile b/tools/tracing/rtla/Makefile
> index 2456a399eb9a..afd18c678ff5 100644
> --- a/tools/tracing/rtla/Makefile
> +++ b/tools/tracing/rtla/Makefile
> @@ -28,10 +28,15 @@ FOPTS := -flto=auto -ffat-lto-objects
> -fexceptions -fstack-protector-strong \
> -fasynchronous-unwind-tables -fstack-clash-protection
> WOPTS:= -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -Wno-maybe-uninitialized
>
> +ifeq ($(CC),clang)
> + FOPTS := $(filter-out -ffat-lto-objects, $(FOPTS))
> + WOPTS := $(filter-out -Wno-maybe-uninitialized, $(WOPTS))
> +endif
> +
> TRACEFS_HEADERS := $$($(PKG_CONFIG) --cflags libtracefs)
>
> CFLAGS := -O -g -DVERSION=\"$(VERSION)\" $(FOPTS) $(MOPTS)
> $(WOPTS) $(TRACEFS_HEADERS) $(EXTRA_CFLAGS)
> -LDFLAGS := -ggdb $(EXTRA_LDFLAGS)
> +LDFLAGS := -flto=auto -ggdb $(EXTRA_LDFLAGS)
> LIBS := $$($(PKG_CONFIG) --libs libtracefs)
>
> SRC := $(wildcard src/*.c)
> --
> 2.43.0
>
[PATCH] eventfs: Use ERR_CAST() in eventfs_create_events_dir()
When building with clang and CONFIG_RANDSTRUCT_FULL=y, there is an error
due to a cast in eventfs_create_events_dir():
fs/tracefs/event_inode.c:734:10: error: casting from randomized structure
pointer type 'struct dentry *' to 'struct eventfs_inode *'
734 | return (struct eventfs_inode *)dentry;
|^
1 error generated.
Use the ERR_CAST() function to resolve the error, as it was designed for
this exact situation (casting an error pointer to another type).
Closes: https://github.com/ClangBuiltLinux/linux/issues/1947
Fixes: 5790b1fb3d67 ("eventfs: Remove eventfs_file and just use eventfs_inode")
Signed-off-by: Nathan Chancellor
---
fs/tracefs/event_inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
index 1ccd100bc565..9f19b6608954 100644
--- a/fs/tracefs/event_inode.c
+++ b/fs/tracefs/event_inode.c
@@ -731,7 +731,7 @@ struct eventfs_inode *eventfs_create_events_dir(const char
*name, struct dentry
return NULL;
if (IS_ERR(dentry))
- return (struct eventfs_inode *)dentry;
+ return ERR_CAST(dentry);
ei = kzalloc(sizeof(*ei), GFP_KERNEL);
if (!ei)
---
base-commit: 5ddd8baa4857709b4e5d84b376d735152851955b
change-id: 20231018-ftrace-fix-clang-randstruct-0cb6899523ac
Best regards,
--
Nathan Chancellor
Re: [PATCH 5/5] kbuild: unify no-compiler-targets and no-sync-config-targets
On Mon, Oct 09, 2023 at 09:42:10PM +0900, Masahiro Yamada wrote:
> Now that vdso_install does not depend on any in-tree build artifact,
> it no longer invokes a compiler, making no-compiler-targets the same
> as no-sync-config-targets.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Makefile | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 2170d56630e8..982b1ad33287 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -277,10 +277,6 @@ no-dot-config-targets := $(clean-targets) \
>$(version_h) headers headers_% archheaders archscripts
> \
>%asm-generic kernelversion %src-pkg dt_binding_check \
>outputmakefile rustavailable rustfmt rustfmtcheck
> -# Installation targets should not require compiler. Unfortunately,
> vdso_install
> -# is an exception where build artifacts may be updated. This must be fixed.
> -no-compiler-targets := $(no-dot-config-targets) install dtbs_install \
> - headers_install modules_install modules_sign
> kernelrelease image_name
> no-sync-config-targets := $(no-dot-config-targets) %install modules_sign
> kernelrelease \
> image_name
> single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.rsi %.s
> %.symtypes %/
> @@ -288,7 +284,6 @@ single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o
> %.rsi %.s %.symtypes %
> config-build :=
> mixed-build :=
> need-config := 1
> -need-compiler:= 1
> may-sync-config := 1
> single-build :=
>
> @@ -298,12 +293,6 @@ ifneq ($(filter $(no-dot-config-targets),
> $(MAKECMDGOALS)),)
> endif
> endif
>
> -ifneq ($(filter $(no-compiler-targets), $(MAKECMDGOALS)),)
> - ifeq ($(filter-out $(no-compiler-targets), $(MAKECMDGOALS)),)
> - need-compiler :=
> - endif
> -endif
> -
MIPS and LoongArch seem to have grown a usage of need-compiler in
4fe4a6374c4d ("MIPS: Only fiddle with CHECKFLAGS if `need-compiler'")
and 54c2c9df083f ("LoongArch: Only fiddle with CHECKFLAGS if
`need-compiler'"). With this removal, should those be updated as well?
> ifneq ($(filter $(no-sync-config-targets), $(MAKECMDGOALS)),)
> ifeq ($(filter-out $(no-sync-config-targets), $(MAKECMDGOALS)),)
> may-sync-config :=
> @@ -675,7 +664,7 @@ endif
>
> # Include this also for config targets because some architectures need
> # cc-cross-prefix to determine CROSS_COMPILE.
> -ifdef need-compiler
> +ifdef may-sync-config
> include $(srctree)/scripts/Makefile.compiler
> endif
>
> --
> 2.39.2
>
Re: [PATCH rebased] kbuild: rpm-pkg: Fix build with non-default MODLIB
On Thu, Oct 05, 2023 at 05:07:28PM +0200, Michal Suchanek wrote:
> The default MODLIB value is composed of two variables and the hardcoded
> string '/lib/modules/'.
>
> MODLIB = $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
>
> Defining this middle part as a variable was rejected on the basis that
> users can pass the whole MODLIB to make, such as
>
> make 'MODLIB=$(INSTALL_MOD_PATH)/usr/lib/modules/$(KERNELRELEASE)'
>
> However, this middle part of MODLIB is independently hardcoded by
> rpm-pkg, and when the user alters MODLIB this is not reflected when
> building the package.
>
> Given that $(INSTALL_MOD_PATH) is overridden during the rpm package build
> it is likely going to be empty. Then MODLIB can be passed to the rpm
> package, and used in place of the whole
> /usr/lib/modules/$(KERNELRELEASE) part.
>
> Signed-off-by: Michal Suchanek
This appears to work for me.
Reviewed-by: Nathan Chancellor
> ---
> scripts/package/kernel.spec | 8
> scripts/package/mkspec | 1 +
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec
> index 3eee0143e0c5..15f49c5077db 100644
> --- a/scripts/package/kernel.spec
> +++ b/scripts/package/kernel.spec
> @@ -67,7 +67,7 @@ cp $(%{make} %{makeflags} -s image_name)
> %{buildroot}/boot/vmlinuz-%{KERNELRELEA
> %{make} %{makeflags} INSTALL_HDR_PATH=%{buildroot}/usr headers_install
> cp System.map %{buildroot}/boot/System.map-%{KERNELRELEASE}
> cp .config %{buildroot}/boot/config-%{KERNELRELEASE}
> -ln -fns /usr/src/kernels/%{KERNELRELEASE}
> %{buildroot}/lib/modules/%{KERNELRELEASE}/build
> +ln -fns /usr/src/kernels/%{KERNELRELEASE} %{buildroot}%{MODLIB}/build
> %if %{with_devel}
> %{make} %{makeflags} run-command
> KBUILD_RUN_COMMAND='${srctree}/scripts/package/install-extmod-build
> %{buildroot}/usr/src/kernels/%{KERNELRELEASE}'
> %endif
> @@ -98,8 +98,8 @@ fi
>
> %files
> %defattr (-, root, root)
> -/lib/modules/%{KERNELRELEASE}
> -%exclude /lib/modules/%{KERNELRELEASE}/build
> +%{MODLIB}
> +%exclude %{MODLIB}/build
> /boot/*
>
> %files headers
> @@ -110,5 +110,5 @@ fi
> %files devel
> %defattr (-, root, root)
> /usr/src/kernels/%{KERNELRELEASE}
> -/lib/modules/%{KERNELRELEASE}/build
> +%{MODLIB}/build
> %endif
> diff --git a/scripts/package/mkspec b/scripts/package/mkspec
> index d41608efb747..d41b2e5304ac 100755
> --- a/scripts/package/mkspec
> +++ b/scripts/package/mkspec
> @@ -18,6 +18,7 @@ fi
> cat< %define ARCH ${ARCH}
> %define KERNELRELEASE ${KERNELRELEASE}
> +%define MODLIB ${MODLIB}
> %define pkg_release $("${srctree}/init/build-version")
> EOF
>
> --
> 2.42.0
>
Re: [patch 11/12] gcov: clang: fix clang-11+ build
On Fri, Apr 16, 2021 at 03:46:23PM -0700, Andrew Morton wrote:
> From: Johannes Berg
> Subject: gcov: clang: fix clang-11+ build
>
> With clang-11+, the code is broken due to my kvmalloc() conversion (which
> predated the clang-11 support code) leaving one vmalloc() in place. Fix
> that.
>
> Link:
> https://lkml.kernel.org/r/20210412214210.6e1ecca9cdc5.I24459763acf0591d5e6b31c7e3a59890d802f79c@changeid
> Signed-off-by: Johannes Berg
> Reviewed-by: Nick Desaulniers
> Tested-by: Nick Desaulniers
> Signed-off-by: Andrew Morton
> ---
>
> kernel/gcov/clang.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/kernel/gcov/clang.c~gcov-clang-fix-clang-11-build
> +++ a/kernel/gcov/clang.c
> @@ -369,7 +369,7 @@ static struct gcov_fn_info *gcov_fn_info
> INIT_LIST_HEAD(_dup->head);
>
> cv_size = fn->num_counters * sizeof(fn->counters[0]);
> - fn_dup->counters = vmalloc(cv_size);
> + fn_dup->counters = kvmalloc(cv_size, GFP_KERNEL);
> if (!fn_dup->counters) {
> kfree(fn_dup);
> return NULL;
> _
This should not have been merged into mainline by itself. It was a fix
for "gcov: use kvmalloc()", which is still in -mm/-next. Merging it
alone has now broken the build:
https://github.com/ClangBuiltLinux/continuous-integration2/runs/2384465683?check_suite_focus=true
Could it please be reverted in mainline then added as a fix patch for
the patch that is still in -mm:
https://www.ozlabs.org/~akpm/mmotm/broken-out/gcov-use-kvmalloc.patch
Cheers,
Nathan
[tip: perf/core] x86/events/amd/iommu: Fix sysfs type mismatch
The following commit has been merged into the perf/core branch of tip:
Commit-ID: de5bc7b425d4c27ae5faa00ea7eb6b9780b9a355
Gitweb:
https://git.kernel.org/tip/de5bc7b425d4c27ae5faa00ea7eb6b9780b9a355
Author:Nathan Chancellor
AuthorDate:Wed, 14 Apr 2021 17:11:11 -07:00
Committer: Peter Zijlstra
CommitterDate: Fri, 16 Apr 2021 18:58:52 +02:00
x86/events/amd/iommu: Fix sysfs type mismatch
dev_attr_show() calls _iommu_event_show() via an indirect call but
_iommu_event_show()'s type does not currently match the type of the
show() member in 'struct device_attribute', resulting in a Control Flow
Integrity violation.
$ cat /sys/devices/amd_iommu_1/events/mem_dte_hit
csource=0x0a
$ dmesg | grep "CFI failure"
[ 3526.735140] CFI failure (target: _iommu_event_show...):
Change _iommu_event_show() and 'struct amd_iommu_event_desc' to
'struct device_attribute' so that there is no more CFI violation.
Fixes: 7be6296fdd75 ("perf/x86/amd: AMD IOMMU Performance Counter PERF uncore
PMU implementation")
Signed-off-by: Nathan Chancellor
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20210415001112.3024673-1-nat...@kernel.org
---
arch/x86/events/amd/iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/events/amd/iommu.c b/arch/x86/events/amd/iommu.c
index be50ef8..6a98a76 100644
--- a/arch/x86/events/amd/iommu.c
+++ b/arch/x86/events/amd/iommu.c
@@ -81,12 +81,12 @@ static struct attribute_group amd_iommu_events_group = {
};
struct amd_iommu_event_desc {
- struct kobj_attribute attr;
+ struct device_attribute attr;
const char *event;
};
-static ssize_t _iommu_event_show(struct kobject *kobj,
- struct kobj_attribute *attr, char *buf)
+static ssize_t _iommu_event_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
struct amd_iommu_event_desc *event =
container_of(attr, struct amd_iommu_event_desc, attr);
[tip: perf/core] perf/amd/uncore: Fix sysfs type mismatch
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 5deac80d4571dffb51f452f0027979d72259a1b9
Gitweb:
https://git.kernel.org/tip/5deac80d4571dffb51f452f0027979d72259a1b9
Author:Nathan Chancellor
AuthorDate:Wed, 14 Apr 2021 17:11:12 -07:00
Committer: Peter Zijlstra
CommitterDate: Fri, 16 Apr 2021 18:58:52 +02:00
perf/amd/uncore: Fix sysfs type mismatch
dev_attr_show() calls the __uncore_*_show() functions via an indirect
call but their type does not currently match the type of the show()
member in 'struct device_attribute', resulting in a Control Flow
Integrity violation.
$ cat /sys/devices/amd_l3/format/umask
config:8-15
$ dmesg | grep "CFI failure"
[ 1258.174653] CFI failure (target: __uncore_umask_show...):
Update the type in the DEFINE_UNCORE_FORMAT_ATTR macro to match
'struct device_attribute' so that there is no more CFI violation.
Fixes: 06f2c24584f3 ("perf/amd/uncore: Prepare to scale for more attributes
that vary per family")
Signed-off-by: Nathan Chancellor
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20210415001112.3024673-2-nat...@kernel.org
---
arch/x86/events/amd/uncore.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index 7f014d4..582c0ff 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -275,14 +275,14 @@ static struct attribute_group amd_uncore_attr_group = {
};
#define DEFINE_UNCORE_FORMAT_ATTR(_var, _name, _format)
\
-static ssize_t __uncore_##_var##_show(struct kobject *kobj,\
- struct kobj_attribute *attr,\
+static ssize_t __uncore_##_var##_show(struct device *dev, \
+ struct device_attribute *attr, \
char *page) \
{ \
BUILD_BUG_ON(sizeof(_format) >= PAGE_SIZE); \
return sprintf(page, _format "\n"); \
} \
-static struct kobj_attribute format_attr_##_var = \
+static struct device_attribute format_attr_##_var =\
__ATTR(_name, 0444, __uncore_##_var##_show, NULL)
DEFINE_UNCORE_FORMAT_ATTR(event12, event, "config:0-7,32-35");
[tip: perf/core] x86/events/amd/iommu: Fix sysfs type mismatch
The following commit has been merged into the perf/core branch of tip:
Commit-ID: bccae9d7b013bd708ece414f74defaee56790e1d
Gitweb:
https://git.kernel.org/tip/bccae9d7b013bd708ece414f74defaee56790e1d
Author:Nathan Chancellor
AuthorDate:Wed, 14 Apr 2021 17:11:11 -07:00
Committer: Peter Zijlstra
CommitterDate: Fri, 16 Apr 2021 16:32:44 +02:00
x86/events/amd/iommu: Fix sysfs type mismatch
dev_attr_show() calls _iommu_event_show() via an indirect call but
_iommu_event_show()'s type does not currently match the type of the
show() member in 'struct device_attribute', resulting in a Control Flow
Integrity violation.
$ cat /sys/devices/amd_iommu_1/events/mem_dte_hit
csource=0x0a
$ dmesg | grep "CFI failure"
[ 3526.735140] CFI failure (target: _iommu_event_show...):
Change _iommu_event_show() and 'struct amd_iommu_event_desc' to
'struct device_attribute' so that there is no more CFI violation.
Fixes: 7be6296fdd75 ("perf/x86/amd: AMD IOMMU Performance Counter PERF uncore
PMU implementation")
Signed-off-by: Nathan Chancellor
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20210415001112.3024673-1-nat...@kernel.org
---
arch/x86/events/amd/iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/events/amd/iommu.c b/arch/x86/events/amd/iommu.c
index be50ef8..6a98a76 100644
--- a/arch/x86/events/amd/iommu.c
+++ b/arch/x86/events/amd/iommu.c
@@ -81,12 +81,12 @@ static struct attribute_group amd_iommu_events_group = {
};
struct amd_iommu_event_desc {
- struct kobj_attribute attr;
+ struct device_attribute attr;
const char *event;
};
-static ssize_t _iommu_event_show(struct kobject *kobj,
- struct kobj_attribute *attr, char *buf)
+static ssize_t _iommu_event_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
struct amd_iommu_event_desc *event =
container_of(attr, struct amd_iommu_event_desc, attr);
[tip: perf/core] perf/amd/uncore: Fix sysfs type mismatch
The following commit has been merged into the perf/core branch of tip:
Commit-ID: b04c0cddff6d1d6656c7f7c08c0b8f07eb287564
Gitweb:
https://git.kernel.org/tip/b04c0cddff6d1d6656c7f7c08c0b8f07eb287564
Author:Nathan Chancellor
AuthorDate:Wed, 14 Apr 2021 17:11:12 -07:00
Committer: Peter Zijlstra
CommitterDate: Fri, 16 Apr 2021 16:32:44 +02:00
perf/amd/uncore: Fix sysfs type mismatch
dev_attr_show() calls the __uncore_*_show() functions via an indirect
call but their type does not currently match the type of the show()
member in 'struct device_attribute', resulting in a Control Flow
Integrity violation.
$ cat /sys/devices/amd_l3/format/umask
config:8-15
$ dmesg | grep "CFI failure"
[ 1258.174653] CFI failure (target: __uncore_umask_show...):
Update the type in the DEFINE_UNCORE_FORMAT_ATTR macro to match
'struct device_attribute' so that there is no more CFI violation.
Fixes: 06f2c24584f3 ("perf/amd/uncore: Prepare to scale for more attributes
that vary per family")
Signed-off-by: Nathan Chancellor
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20210415001112.3024673-2-nat...@kernel.org
---
arch/x86/events/amd/uncore.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index 7f014d4..582c0ff 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -275,14 +275,14 @@ static struct attribute_group amd_uncore_attr_group = {
};
#define DEFINE_UNCORE_FORMAT_ATTR(_var, _name, _format)
\
-static ssize_t __uncore_##_var##_show(struct kobject *kobj,\
- struct kobj_attribute *attr,\
+static ssize_t __uncore_##_var##_show(struct device *dev, \
+ struct device_attribute *attr, \
char *page) \
{ \
BUILD_BUG_ON(sizeof(_format) >= PAGE_SIZE); \
return sprintf(page, _format "\n"); \
} \
-static struct kobj_attribute format_attr_##_var = \
+static struct device_attribute format_attr_##_var =\
__ATTR(_name, 0444, __uncore_##_var##_show, NULL)
DEFINE_UNCORE_FORMAT_ATTR(event12, event, "config:0-7,32-35");
[PATCH] drm/tegra: Fix shift overflow in tegra_shared_plane_atomic_update
Clang warns:
drivers/gpu/drm/tegra/hub.c:513:11: warning: shift count >= width of
type [-Wshift-count-overflow]
base |= BIT(39);
^~~
BIT is unsigned long, which is 32-bit on ARCH=arm, hence the overflow
warning. Switch to BIT_ULL, which is 64-bit and will not overflow.
Fixes: 7b6f846785f4 ("drm/tegra: Support sector layout on Tegra194")
Link: https://github.com/ClangBuiltLinux/linux/issues/1351
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/tegra/hub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 79bff8b48271..bfae8a02f55b 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -510,7 +510,7 @@ static void tegra_shared_plane_atomic_update(struct
drm_plane *plane,
* dGPU sector layout.
*/
if (tegra_plane_state->tiling.sector_layout ==
TEGRA_BO_SECTOR_LAYOUT_GPU)
- base |= BIT(39);
+ base |= BIT_ULL(39);
#endif
tegra_plane_writel(p, tegra_plane_state->format, DC_WIN_COLOR_DEPTH);
base-commit: 0265531f0897f890da3f9c2958707af099c7d974
--
2.31.1.272.g89b43f80a5
Re: [PATCH 1/2] x86/events/amd/iommu: Fix sysfs type mismatch
On Thu, Apr 15, 2021 at 08:53:35AM +0100, Christoph Hellwig wrote: > On Wed, Apr 14, 2021 at 05:11:11PM -0700, Nathan Chancellor wrote: > > dev_attr_show() calls _iommu_event_show() via an indirect call but > > _iommu_event_show()'s type does not currently match the type of the > > show() member in 'struct device_attribute', resulting in a Control Flow > > Integrity violation. > > While the fix looks fine I think we need to solve this kind of problem > by better type checking. The fact that we can use the wong type here > without a compiler warning is the real issue. I agree. Unfortunately, it seems that is going to be a much longer tail project because of how pervasive this is (using container_of() + attributes to get callbacks). https://lore.kernel.org/r/202006112217.2E6CE093@keescook/ https://lore.kernel.org/r/202104021823.64FA6119@keescook/ Cheers, Nathan
Re: [PATCH 2/3] habanalabs: support legacy and new pll indexes
On Sun, Mar 21, 2021 at 10:11:29PM +0200, Oded Gabbay wrote:
> From: Ohad Sharabi
>
> In order to use minimum of hard coded values common to LKD and F/W
> a dynamic method to work with PLLs is introduced in this patch.
> Formerly asic specific PLL numbering is now common for all asics.
> To be backward compatible a bit in dev status is defined, if the bit is
> not set LKD will keep working with old PLL numbering.
>
> Signed-off-by: Ohad Sharabi
> Reviewed-by: Oded Gabbay
> Signed-off-by: Oded Gabbay
> ---
> drivers/misc/habanalabs/common/firmware_if.c | 49 ++-
> drivers/misc/habanalabs/common/habanalabs.h | 14 --
> drivers/misc/habanalabs/common/sysfs.c| 24 ++---
> drivers/misc/habanalabs/gaudi/gaudi.c | 33 +
> drivers/misc/habanalabs/goya/goya.c | 26 ++
> .../misc/habanalabs/include/common/cpucp_if.h | 41
> .../habanalabs/include/common/hl_boot_if.h| 6 +++
> .../habanalabs/include/gaudi/gaudi_fw_if.h| 14 --
> .../misc/habanalabs/include/goya/goya_fw_if.h | 11 -
> 9 files changed, 182 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/misc/habanalabs/common/firmware_if.c
> b/drivers/misc/habanalabs/common/firmware_if.c
> index 2a58edaf984a..092691a8917d 100644
> --- a/drivers/misc/habanalabs/common/firmware_if.c
> +++ b/drivers/misc/habanalabs/common/firmware_if.c
> @@ -539,18 +539,63 @@ int hl_fw_cpucp_total_energy_get(struct hl_device
> *hdev, u64 *total_energy)
> return rc;
> }
>
> -int hl_fw_cpucp_pll_info_get(struct hl_device *hdev, u16 pll_index,
> +int get_used_pll_index(struct hl_device *hdev, enum pll_index
> input_pll_index,
> + enum pll_index *pll_index)
> +{
> + struct asic_fixed_properties *prop = >asic_prop;
> + u8 pll_byte, pll_bit_off;
> + bool dynamic_pll;
> +
> + if (input_pll_index >= PLL_MAX) {
> + dev_err(hdev->dev, "PLL index %d is out of range\n",
> + input_pll_index);
> + return -EINVAL;
> + }
> +
> + dynamic_pll = prop->fw_security_status_valid &&
> + (prop->fw_app_security_map & CPU_BOOT_DEV_STS0_DYN_PLL_EN);
> +
> + if (!dynamic_pll) {
> + /*
> + * in case we are working with legacy FW (each asic has unique
> + * PLL numbering) extract the legacy numbering
> + */
> + *pll_index = hdev->legacy_pll_map[input_pll_index];
> + return 0;
> + }
> +
> + /* PLL map is a u8 array */
> + pll_byte = prop->cpucp_info.pll_map[input_pll_index >> 3];
> + pll_bit_off = input_pll_index & 0x7;
> +
> + if (!(pll_byte & BIT(pll_bit_off))) {
> + dev_err(hdev->dev, "PLL index %d is not supported\n",
> + input_pll_index);
> + return -EINVAL;
> + }
> +
> + *pll_index = input_pll_index;
> +
> + return 0;
> +}
> +
> +int hl_fw_cpucp_pll_info_get(struct hl_device *hdev, enum pll_index
> pll_index,
> u16 *pll_freq_arr)
> {
> struct cpucp_packet pkt;
> + enum pll_index used_pll_idx;
> u64 result;
> int rc;
>
> + rc = get_used_pll_index(hdev, pll_index, _pll_idx);
> + if (rc)
> + return rc;
> +
> memset(, 0, sizeof(pkt));
>
> pkt.ctl = cpu_to_le32(CPUCP_PACKET_PLL_INFO_GET <<
> CPUCP_PKT_CTL_OPCODE_SHIFT);
> - pkt.pll_type = __cpu_to_le16(pll_index);
> + pkt.pll_type = __cpu_to_le16((u16)used_pll_idx);
>
> rc = hdev->asic_funcs->send_cpu_message(hdev, (u32 *) , sizeof(pkt),
> HL_CPUCP_INFO_TIMEOUT_USEC, );
> diff --git a/drivers/misc/habanalabs/common/habanalabs.h
> b/drivers/misc/habanalabs/common/habanalabs.h
> index 65f34918faed..dc8126b270d1 100644
> --- a/drivers/misc/habanalabs/common/habanalabs.h
> +++ b/drivers/misc/habanalabs/common/habanalabs.h
> @@ -1946,6 +1946,8 @@ struct hl_mmu_funcs {
> * @aggregated_cs_counters: aggregated cs counters among all contexts
> * @mmu_priv: device-specific MMU data.
> * @mmu_func: device-related MMU functions.
> + * @legacy_pll_map: map holding map between dynamic (common) PLL indexes and
> + * static (asic specific) PLL indexes.
> * @dram_used_mem: current DRAM memory consumption.
> * @timeout_jiffies: device CS timeout value.
> * @max_power: the max power of the device, as configured by the sysadmin.
> This
> @@ -2070,6 +2072,8 @@ struct hl_device {
> struct hl_mmu_priv mmu_priv;
> struct hl_mmu_funcs mmu_func[MMU_NUM_PGT_LOCATIONS];
>
> + enum pll_index *legacy_pll_map;
> +
> atomic64_t dram_used_mem;
> u64 timeout_jiffies;
> u64 max_power;
> @@ -2383,7 +2387,9 @@
Re: [PATCH] arm64: alternatives: Move length validation in alternative_{insn,endif}
On Thu, Apr 15, 2021 at 10:17:43AM +0100, Catalin Marinas wrote:
> Hi Nathan,
>
> On Tue, Apr 13, 2021 at 05:08:04PM -0700, Nathan Chancellor wrote:
> > After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
> > set atomically"), LLVM's integrated assembler fails to build entry.S:
> >
> > :5:7: error: expected assembly-time absolute expression
> > .org . - (664b-663b) + (662b-661b)
> > ^
> > :6:7: error: expected assembly-time absolute expression
> > .org . - (662b-661b) + (664b-663b)
> > ^
>
> I tried the latest Linus' tree and linux-next (defconfig) with this
> commit in and I can't get your build error. I used both clang-10 from
> Debian stable and clang-11 from Debian sid. So, which clang version did
> you use or which kernel config options?
>
> --
> Catalin
>
Hi Catalin,
Interesting, this reproduces for me with LLVM 12 or newer with just
defconfig.
$ make -j"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LLVM=1
LLVM_IAS=1 defconfig arch/arm64/kernel/entry.o
https://github.com/ClangBuiltLinux/continuous-integration2/runs/2350258778?check_suite_focus=true
Cheers,
Nathan
Re: [PATCH v2] arm64: vdso32: drop -no-integrated-as flag
On Wed, Apr 14, 2021 at 02:45:45PM -0700, Nick Desaulniers wrote: > Clang can assemble these files just fine; this is a relic from the top > level Makefile conditionally adding this. We no longer need --prefix, > --gcc-toolchain, or -Qunused-arguments flags either with this change, so > remove those too. > > To test building: > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \ > CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make LLVM=1 LLVM_IAS=1 \ > defconfig arch/arm64/kernel/vdso32/ > > Suggested-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor > --- > Changes V1 -> V2: > * Remove --prefix, --gcc-toolchain, COMPAT_GCC_TOOLCHAIN, and > COMPAT_GCC_TOOLCHAIN_DIR as per Nathan. > * Credit Nathan with Suggested-by tag. > * Remove -Qunused-arguments. > * Update commit message. > > arch/arm64/kernel/vdso32/Makefile | 8 > 1 file changed, 8 deletions(-) > > diff --git a/arch/arm64/kernel/vdso32/Makefile > b/arch/arm64/kernel/vdso32/Makefile > index 789ad420f16b..3dba0c4f8f42 100644 > --- a/arch/arm64/kernel/vdso32/Makefile > +++ b/arch/arm64/kernel/vdso32/Makefile > @@ -10,15 +10,7 @@ include $(srctree)/lib/vdso/Makefile > > # Same as cc-*option, but using CC_COMPAT instead of CC > ifeq ($(CONFIG_CC_IS_CLANG), y) > -COMPAT_GCC_TOOLCHAIN_DIR := $(dir $(shell which > $(CROSS_COMPILE_COMPAT)elfedit)) > -COMPAT_GCC_TOOLCHAIN := $(realpath $(COMPAT_GCC_TOOLCHAIN_DIR)/..) > - > CC_COMPAT_CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE_COMPAT:%-=%)) > -CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)$(notdir > $(CROSS_COMPILE_COMPAT)) > -CC_COMPAT_CLANG_FLAGS += -no-integrated-as -Qunused-arguments > -ifneq ($(COMPAT_GCC_TOOLCHAIN),) > -CC_COMPAT_CLANG_FLAGS += --gcc-toolchain=$(COMPAT_GCC_TOOLCHAIN) > -endif > > CC_COMPAT ?= $(CC) > CC_COMPAT += $(CC_COMPAT_CLANG_FLAGS) > -- > 2.31.1.295.g9ea45b61b8-goog > >
[PATCH 2/2] perf/amd/uncore: Fix sysfs type mismatch
dev_attr_show() calls the __uncore_*_show() functions via an indirect
call but their type does not currently match the type of the show()
member in 'struct device_attribute', resulting in a Control Flow
Integrity violation.
$ cat /sys/devices/amd_l3/format/umask
config:8-15
$ dmesg | grep "CFI failure"
[ 1258.174653] CFI failure (target: __uncore_umask_show...):
Update the type in the DEFINE_UNCORE_FORMAT_ATTR macro to match
'struct device_attribute' so that there is no more CFI violation.
Link: https://github.com/ClangBuiltLinux/linux/issues/1350
Fixes: 06f2c24584f3 ("perf/amd/uncore: Prepare to scale for more attributes
that vary per family")
Signed-off-by: Nathan Chancellor
---
arch/x86/events/amd/uncore.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index 7f014d450bc2..582c0ffb5e98 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -275,14 +275,14 @@ static struct attribute_group amd_uncore_attr_group = {
};
#define DEFINE_UNCORE_FORMAT_ATTR(_var, _name, _format)
\
-static ssize_t __uncore_##_var##_show(struct kobject *kobj,\
- struct kobj_attribute *attr,\
+static ssize_t __uncore_##_var##_show(struct device *dev, \
+ struct device_attribute *attr, \
char *page) \
{ \
BUILD_BUG_ON(sizeof(_format) >= PAGE_SIZE); \
return sprintf(page, _format "\n"); \
} \
-static struct kobj_attribute format_attr_##_var = \
+static struct device_attribute format_attr_##_var =\
__ATTR(_name, 0444, __uncore_##_var##_show, NULL)
DEFINE_UNCORE_FORMAT_ATTR(event12, event, "config:0-7,32-35");
--
2.31.1.272.g89b43f80a5
[PATCH 1/2] x86/events/amd/iommu: Fix sysfs type mismatch
dev_attr_show() calls _iommu_event_show() via an indirect call but
_iommu_event_show()'s type does not currently match the type of the
show() member in 'struct device_attribute', resulting in a Control Flow
Integrity violation.
$ cat /sys/devices/amd_iommu_1/events/mem_dte_hit
csource=0x0a
$ dmesg | grep "CFI failure"
[ 3526.735140] CFI failure (target: _iommu_event_show...):
Change _iommu_event_show() and 'struct amd_iommu_event_desc' to
'struct device_attribute' so that there is no more CFI violation.
Link: https://github.com/ClangBuiltLinux/linux/issues/1350
Fixes: 7be6296fdd75 ("perf/x86/amd: AMD IOMMU Performance Counter PERF uncore
PMU implementation")
Signed-off-by: Nathan Chancellor
---
arch/x86/events/amd/iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/events/amd/iommu.c b/arch/x86/events/amd/iommu.c
index be50ef8572cc..6a98a7651621 100644
--- a/arch/x86/events/amd/iommu.c
+++ b/arch/x86/events/amd/iommu.c
@@ -81,12 +81,12 @@ static struct attribute_group amd_iommu_events_group = {
};
struct amd_iommu_event_desc {
- struct kobj_attribute attr;
+ struct device_attribute attr;
const char *event;
};
-static ssize_t _iommu_event_show(struct kobject *kobj,
- struct kobj_attribute *attr, char *buf)
+static ssize_t _iommu_event_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
struct amd_iommu_event_desc *event =
container_of(attr, struct amd_iommu_event_desc, attr);
base-commit: d434405aaab7d0ebc516b68a8fc4100922d7f5ef
--
2.31.1.272.g89b43f80a5
Re: [PATCH 03/13] Makefile: Generate CLANG_FLAGS even in GCC builds
Hi Miguel,
On Wed, Apr 14, 2021 at 08:45:54PM +0200, oj...@kernel.org wrote:
> From: Miguel Ojeda
>
> To support Rust under GCC-built kernels, we need to save the flags that
> would have been passed if the kernel was being compiled with Clang.
>
> The reason is that bindgen -- the tool we use to generate Rust bindings
> to the C side of the kernel -- relies on libclang to parse C. Ideally:
>
> - bindgen would support a GCC backend (requested at [1]),
>
> - or the Clang driver would be perfectly compatible with GCC,
> including plugins. Unlikely, of course, but perhaps a big
> subset of configs may be possible to guarantee to be kept
> compatible nevertheless.
>
> This is also the reason why GCC builds are very experimental and some
> configurations may not work (e.g. GCC_PLUGIN_RANDSTRUCT). However,
> we keep GCC builds working (for some example configs) in the CI
> to avoid diverging/regressing further, so that we are better prepared
> for the future when a solution might become available.
>
> [1] https://github.com/rust-lang/rust-bindgen/issues/1949
>
> Link: https://github.com/Rust-for-Linux/linux/issues/167
>
> Co-developed-by: Alex Gaynor
> Signed-off-by: Alex Gaynor
> Co-developed-by: Geoffrey Thomas
> Signed-off-by: Geoffrey Thomas
> Co-developed-by: Finn Behrens
> Signed-off-by: Finn Behrens
> Co-developed-by: Adam Bratschi-Kaye
> Signed-off-by: Adam Bratschi-Kaye
> Co-developed-by: Wedson Almeida Filho
> Signed-off-by: Wedson Almeida Filho
> Signed-off-by: Miguel Ojeda
> ---
> Makefile | 27 ---
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index d4784d181123..9c75354324ed 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -559,26 +559,31 @@ ifdef building_out_of_srctree
> { echo "# this is build directory, ignore it"; echo "*"; } > .gitignore
> endif
>
> -# The expansion should be delayed until arch/$(SRCARCH)/Makefile is included.
> -# Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
> -# CC_VERSION_TEXT is referenced from Kconfig (so it needs export),
> -# and from include/config/auto.conf.cmd to detect the compiler upgrade.
> -CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | head -n 1 | sed
> 's/\#//g')
> +TENTATIVE_CLANG_FLAGS := -Werror=unknown-warning-option
>
> -ifneq ($(findstring clang,$(CC_VERSION_TEXT)),)
> ifneq ($(CROSS_COMPILE),)
> -CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%))
> +TENTATIVE_CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%))
> GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
Shuffling this around will cause this issue (I never saw you CC'd on the
thread).
https://lore.kernel.org/r/f6218ac526a04fa4d4406f935bcc4eb4a7df65c4.1617917438.git.msucha...@suse.de/
Perhaps that patch should be added to this series?
> -CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
> +TENTATIVE_CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir
> $(CROSS_COMPILE))
> GCC_TOOLCHAIN:= $(realpath $(GCC_TOOLCHAIN_DIR)/..)
> endif
> ifneq ($(GCC_TOOLCHAIN),)
> -CLANG_FLAGS += --gcc-toolchain=$(GCC_TOOLCHAIN)
> +TENTATIVE_CLANG_FLAGS+= --gcc-toolchain=$(GCC_TOOLCHAIN)
> endif
> ifneq ($(LLVM_IAS),1)
> -CLANG_FLAGS += -no-integrated-as
> +TENTATIVE_CLANG_FLAGS+= -no-integrated-as
> endif
> -CLANG_FLAGS += -Werror=unknown-warning-option
> +
> +export TENTATIVE_CLANG_FLAGS
> +
> +# The expansion should be delayed until arch/$(SRCARCH)/Makefile is included.
> +# Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
> +# CC_VERSION_TEXT is referenced from Kconfig (so it needs export),
> +# and from include/config/auto.conf.cmd to detect the compiler upgrade.
> +CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | head -n 1 | sed
> 's/\#//g')
> +
> +ifneq ($(findstring clang,$(CC_VERSION_TEXT)),)
> +CLANG_FLAGS += $(TENTATIVE_CLANG_FLAGS)
> KBUILD_CFLAGS+= $(CLANG_FLAGS)
> KBUILD_AFLAGS+= $(CLANG_FLAGS)
> export CLANG_FLAGS
> --
> 2.17.1
>
[PATCH] arm64: alternatives: Move length validation in alternative_{insn,endif}
After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
set atomically"), LLVM's integrated assembler fails to build entry.S:
:5:7: error: expected assembly-time absolute expression
.org . - (664b-663b) + (662b-661b)
^
:6:7: error: expected assembly-time absolute expression
.org . - (662b-661b) + (664b-663b)
^
The root cause is LLVM's assembler has a one-pass design, meaning it
cannot figure out these instruction lengths when the .org directive is
outside of the subsection that they are in, which was changed by the
.arch_extension directive added in the above commit.
Apply the same fix from commit 966a0acce2fc ("arm64/alternatives: move
length validation inside the subsection") to the alternative_endif
macro, shuffling the .org directives so that the length validation
happen will always happen in the same subsections. alternative_insn has
not shown any issue yet but it appears that it could have the same issue
in the future so just preemptively change it.
Cc: sta...@vger.kernel.org
Fixes: f7b93d42945c ("arm64/alternatives: use subsections for replacement
sequences")
Link: https://github.com/ClangBuiltLinux/linux/issues/1347
Signed-off-by: Nathan Chancellor
---
Apologies if my explanation or terminology is off, I am only now getting
more familiar with assembly.
arch/arm64/include/asm/alternative-macros.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/alternative-macros.h
b/arch/arm64/include/asm/alternative-macros.h
index 5df500dcc627..8a078fc662ac 100644
--- a/arch/arm64/include/asm/alternative-macros.h
+++ b/arch/arm64/include/asm/alternative-macros.h
@@ -97,9 +97,9 @@
.popsection
.subsection 1
663: \insn2
-664: .previous
- .org. - (664b-663b) + (662b-661b)
+664: .org. - (664b-663b) + (662b-661b)
.org. - (662b-661b) + (664b-663b)
+ .previous
.endif
.endm
@@ -169,11 +169,11 @@
*/
.macro alternative_endif
664:
+ .org. - (664b-663b) + (662b-661b)
+ .org. - (662b-661b) + (664b-663b)
.if .Lasm_alt_mode==0
.previous
.endif
- .org. - (664b-663b) + (662b-661b)
- .org. - (662b-661b) + (664b-663b)
.endm
/*
base-commit: 738fa58ee1328481d1d7889e7c430b3401c571b9
--
2.31.1.272.g89b43f80a5
Re: [PATCH] arm64: vdso32: drop -no-integrated-as flag
On Tue, Apr 13, 2021 at 04:06:06PM -0700, Nick Desaulniers wrote: > Clang can assemble these files just fine; this is a relic from the top > level Makefile conditionally adding this. > > To test building: > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \ > CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make LLVM=1 LLVM_IAS=1 \ > defconfig arch/arm64/kernel/vdso32/ > > Signed-off-by: Nick Desaulniers > --- > arch/arm64/kernel/vdso32/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/vdso32/Makefile > b/arch/arm64/kernel/vdso32/Makefile > index 789ad420f16b..7812717f8b79 100644 > --- a/arch/arm64/kernel/vdso32/Makefile > +++ b/arch/arm64/kernel/vdso32/Makefile > @@ -15,7 +15,7 @@ COMPAT_GCC_TOOLCHAIN := $(realpath > $(COMPAT_GCC_TOOLCHAIN_DIR)/..) > > CC_COMPAT_CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE_COMPAT:%-=%)) > CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)$(notdir > $(CROSS_COMPILE_COMPAT)) > -CC_COMPAT_CLANG_FLAGS += -no-integrated-as -Qunused-arguments > +CC_COMPAT_CLANG_FLAGS += -Qunused-arguments Might as well just eliminate '--prefix=' and '--gcc-toolchain=' along with the variables COMPAT_GCC_TOOLCHAIN_DIR and COMPAT_GCC_TOOLCHAIN while you are at it, they serve no purpose without '-no-integrated-as'. > ifneq ($(COMPAT_GCC_TOOLCHAIN),) > CC_COMPAT_CLANG_FLAGS += --gcc-toolchain=$(COMPAT_GCC_TOOLCHAIN) > endif > -- > 2.31.1.295.g9ea45b61b8-goog > >
Re: arch/arm64/kvm/perf.c:58:36: error: implicit declaration of function 'perf_num_counters'
On Fri, Mar 26, 2021 at 08:27:13PM +0800, kernel test robot wrote:
> Hi Marc,
>
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: db24726bfefa68c606947a86132591568a06bfb4
> commit: 6b5b368fccd7109b052e45af8ba1464c8d140a49 KVM: arm64: Turn
> kvm_arm_support_pmu_v3() into a static key
> date: 3 weeks ago
> config: arm64-randconfig-r005-20210326 (attached as .config)
> compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
> f490a5969bd52c8a48586f134ff8f02ccbb295b3)
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install arm64 cross compiling tool for clang build
> # apt-get install binutils-aarch64-linux-gnu
> #
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6b5b368fccd7109b052e45af8ba1464c8d140a49
> git remote add linus
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git fetch --no-tags linus master
> git checkout 6b5b368fccd7109b052e45af8ba1464c8d140a49
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
> All errors (new ones prefixed by >>):
>
> >> arch/arm64/kvm/perf.c:58:36: error: implicit declaration of function
> >> 'perf_num_counters' [-Werror,-Wimplicit-function-declaration]
>if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0)
> ^
>1 error generated.
>
>
> vim +/perf_num_counters +58 arch/arm64/kvm/perf.c
>
> 50
> 51int kvm_perf_init(void)
> 52{
> 53/*
> 54 * Check if HW_PERF_EVENTS are supported by checking
> the number of
> 55 * hardware performance counters. This could ensure the
> presence of
> 56 * a physical PMU and CONFIG_PERF_EVENT is selected.
> 57 */
> > 58if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() >
> 0)
> 59static_branch_enable(_arm_pmu_available);
> 60
> 61return
> perf_register_guest_info_callbacks(_guest_cbs);
> 62}
> 63
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
I just ran into this again. It is not a clang specific issue, it
reproduces quite easily with arm64 defconfig minus CONFIG_PERF_EVENTS
and gcc 10.3.0:
arch/arm64/kvm/perf.c: In function 'kvm_perf_init':
arch/arm64/kvm/perf.c:58:36: error: implicit declaration of function
'perf_num_counters'; did you mean 'dec_mm_counter'?
[-Werror=implicit-function-declaration]
58 | if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0)
|^
|dec_mm_counter
cc1: some warnings being treated as errors
I am not sure what the cleanest solution would be for providing a static
inline version of perf_num_counters() would be, as only arm64 actually
uses it (sh and s390 define it but it does not appear to be used) but it
is only available through CONFIG_ARM_PMU instead of just
CONFIG_PERF_EVENTS like the other two architectures mentioned above.
Cheers,
Nathan
[PATCH] crypto: arm/curve25519 - Move '.fpu' after '.arch'
Debian's clang carries a patch that makes the default FPU mode
'vfp3-d16' instead of 'neon' for 'armv7-a' to avoid generating NEON
instructions on hardware that does not support them:
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/raw/5a61ca6f21b4ad8c6ac4970e5ea5a7b5b4486d22/debian/patches/clang-arm-default-vfp3-on-armv7a.patch
https://bugs.debian.org/841474
https://bugs.debian.org/842142
https://bugs.debian.org/914268
This results in the following build error when clang's integrated
assembler is used because the '.arch' directive overrides the '.fpu'
directive:
arch/arm/crypto/curve25519-core.S:25:2: error: instruction requires: NEON
vmov.i32 q0, #1
^
arch/arm/crypto/curve25519-core.S:26:2: error: instruction requires: NEON
vshr.u64 q1, q0, #7
^
arch/arm/crypto/curve25519-core.S:27:2: error: instruction requires: NEON
vshr.u64 q0, q0, #8
^
arch/arm/crypto/curve25519-core.S:28:2: error: instruction requires: NEON
vmov.i32 d4, #19
^
Shuffle the order of the '.arch' and '.fpu' directives so that the code
builds regardless of the default FPU mode. This has been tested against
both clang with and without Debian's patch and GCC.
Cc: sta...@vger.kernel.org
Fixes: d8f1308a025f ("crypto: arm/curve25519 - wire up NEON implementation")
Link: https://github.com/ClangBuiltLinux/continuous-integration2/issues/118
Reported-by: Arnd Bergmann
Suggested-by: Arnd Bergmann
Suggested-by: Jessica Clarke
Signed-off-by: Nathan Chancellor
---
arch/arm/crypto/curve25519-core.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/crypto/curve25519-core.S
b/arch/arm/crypto/curve25519-core.S
index be18af52e7dc..b697fa5d059a 100644
--- a/arch/arm/crypto/curve25519-core.S
+++ b/arch/arm/crypto/curve25519-core.S
@@ -10,8 +10,8 @@
#include
.text
-.fpu neon
.arch armv7-a
+.fpu neon
.align 4
ENTRY(curve25519_neon)
base-commit: e49d033bddf5b565044e2abe4241353959bc9120
--
2.31.1.189.g2e36527f23
[PATCH] MIPS: generic: Update node names to avoid unit addresses
With the latest mkimage from U-Boot 2021.04, the generic defconfigs no
longer build, failing with:
/usr/bin/mkimage: verify_header failed for FIT Image support with exit code 1
This is expected after the linked U-Boot commits because '@' is
forbidden in the node names due to the way that libfdt treats nodes with
the same prefix but different unit addresses.
Switch the '@' in the node name to '-'. Drop the unit addresses from the
hash and kernel child nodes because there is only one node so they do
not need to have a number to differentiate them.
Cc: sta...@vger.kernel.org
Link:
https://source.denx.de/u-boot/u-boot/-/commit/79af75f7776fc20b0d7eb6afe1e27c00fdb4b9b4
Link:
https://source.denx.de/u-boot/u-boot/-/commit/3f04db891a353f4b127ed57279279f851c6b4917
Suggested-by: Simon Glass
Signed-off-by: Nathan Chancellor
---
arch/mips/generic/board-boston.its.S | 10 +-
arch/mips/generic/board-jaguar2.its.S | 16
arch/mips/generic/board-luton.its.S| 8
arch/mips/generic/board-ni169445.its.S | 10 +-
arch/mips/generic/board-ocelot.its.S | 20 ++--
arch/mips/generic/board-serval.its.S | 8
arch/mips/generic/board-xilfpga.its.S | 10 +-
arch/mips/generic/vmlinux.its.S| 10 +-
8 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/arch/mips/generic/board-boston.its.S
b/arch/mips/generic/board-boston.its.S
index a7f51f97b910..c45ad2759421 100644
--- a/arch/mips/generic/board-boston.its.S
+++ b/arch/mips/generic/board-boston.its.S
@@ -1,22 +1,22 @@
/ {
images {
- fdt@boston {
+ fdt-boston {
description = "img,boston Device Tree";
data = /incbin/("boot/dts/img/boston.dtb");
type = "flat_dt";
arch = "mips";
compression = "none";
- hash@0 {
+ hash {
algo = "sha1";
};
};
};
configurations {
- conf@boston {
+ conf-boston {
description = "Boston Linux kernel";
- kernel = "kernel@0";
- fdt = "fdt@boston";
+ kernel = "kernel";
+ fdt = "fdt-boston";
};
};
};
diff --git a/arch/mips/generic/board-jaguar2.its.S
b/arch/mips/generic/board-jaguar2.its.S
index fb0e589eeff7..c2b8d479b26c 100644
--- a/arch/mips/generic/board-jaguar2.its.S
+++ b/arch/mips/generic/board-jaguar2.its.S
@@ -1,23 +1,23 @@
/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
/ {
images {
- fdt@jaguar2_pcb110 {
+ fdt-jaguar2_pcb110 {
description = "MSCC Jaguar2 PCB110 Device Tree";
data = /incbin/("boot/dts/mscc/jaguar2_pcb110.dtb");
type = "flat_dt";
arch = "mips";
compression = "none";
- hash@0 {
+ hash {
algo = "sha1";
};
};
- fdt@jaguar2_pcb111 {
+ fdt-jaguar2_pcb111 {
description = "MSCC Jaguar2 PCB111 Device Tree";
data = /incbin/("boot/dts/mscc/jaguar2_pcb111.dtb");
type = "flat_dt";
arch = "mips";
compression = "none";
- hash@0 {
+ hash {
algo = "sha1";
};
};
@@ -26,14 +26,14 @@
configurations {
pcb110 {
description = "Jaguar2 Linux kernel";
- kernel = "kernel@0";
- fdt = "fdt@jaguar2_pcb110";
+ kernel = "kernel";
+ fdt = "fdt-jaguar2_pcb110";
ramdisk = "ramdisk";
};
pcb111 {
description = "Jaguar2 Linux kernel";
- kernel = "kernel@0";
- fdt = "fdt@jaguar2_pcb111";
+ kernel = "kernel";
+ fdt = "fdt-jaguar2_pcb111";
ramdisk = "ramdisk";
};
};
diff --git a/arch/mips/generic/board-luton.its.S
b/arch/mips/generic/board-luton.its.S
index 39a543f62f25..bd9837c9af97 100644
--
[PATCH] block: Disable -Walign-mismatch for blk-mq.c
LLVM 13 adds a new warning, -Walign-mismatch, which has an instance in
blk_mq_complete_send_ipi():
block/blk-mq.c:630:39: warning: passing 8-byte aligned argument to
32-byte aligned parameter 2 of 'smp_call_function_single_async' may
result in an unaligned pointer access [-Walign-mismatch]
smp_call_function_single_async(cpu, >csd);
^
1 warning generated.
This is expected after commit 4ccafe032005 ("block: unalign
call_single_data in struct request"), which purposefully unaligned the
structure to save space. Given that there is no real alignment
requirement and there have been no reports of issues since that change,
it should be safe to disable the warning for this one translation unit.
Link: https://github.com/ClangBuiltLinux/linux/issues/1328
Link: https://lore.kernel.org/r/20210310182307.zzcbi5w5jrmveld4@archlinux-ax161/
Link: https://lore.kernel.org/r/20210330230249.709221-1-jian...@google.com/
Signed-off-by: Nathan Chancellor
---
block/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/Makefile b/block/Makefile
index 8d841f5f986f..d69ac0bd8e61 100644
--- a/block/Makefile
+++ b/block/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_BLOCK) := bio.o elevator.o blk-core.o
blk-sysfs.o \
blk-mq-sysfs.o blk-mq-cpumap.o blk-mq-sched.o ioctl.o \
genhd.o ioprio.o badblocks.o partitions/ blk-rq-qos.o
+CFLAGS_blk-mq.o := $(call cc-disable-warning, align-mismatch)
obj-$(CONFIG_BOUNCE) += bounce.o
obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_ioctl.o
obj-$(CONFIG_BLK_DEV_BSG) += bsg.o
base-commit: e49d033bddf5b565044e2abe4241353959bc9120
--
2.31.1.189.g2e36527f23
Re: [PATCH] blk-mq: fix alignment mismatch.
Hi Jian, On Thu, Apr 08, 2021 at 10:57:54AM -0700, Jian Cai wrote: > So this issue is blocking the LLVM upgrading on ChromeOS. Nathan, do > you mind sending out the smaller patch like Nick suggested just to see > what feedback we could get? I could send it for you if you are busy, > and please let me know what tags I should use in that case. > > Thanks, > Jian I will go ahead and send the smaller patch at some point today. For what it's worth, Nick brought up https://reviews.llvm.org/D100037, which may be relevant here. Cheers, Nathan > On Wed, Mar 31, 2021 at 3:06 PM Nick Desaulniers > wrote: > > > > On Wed, Mar 31, 2021 at 2:58 PM Nathan Chancellor wrote: > > > > > > On Wed, Mar 31, 2021 at 02:27:03PM -0700, Jian Cai wrote: > > > > > > > > I just realized you already proposed solutions for skipping the check > > > > in > > > > https://lore.kernel.org/linux-block/20210310225240.4epj2mdmzt4vurr3@archlinux-ax161/#t. > > > > Do you have any plans to send them for review? > > > > > > I was hoping to gather some feedback on which option would be preferred > > > by Jens and the other ClangBuiltLinux folks before I sent them along. I > > > can send the first just to see what kind of feedback I can gather. > > > > Either approach is fine by me. The smaller might be easier to get > > accepted into stable. The larger approach will probably become more > > useful in the future (having the diag infra work properly with clang). > > I think the ball is kind of in Jens' court to decide. Would doing > > both be appropriate, Jens? Have the smaller patch tagged for stable > > disabling it for the whole file, then another commit on top not tagged > > for stable that adds the diag infra, and a third on top replacing the > > file level warning disablement with local diags to isolate this down > > to one case? It's a fair but small amount of churn IMO; but if Jens > > is not opposed it seems fine? > > -- > > Thanks, > > ~Nick Desaulniers
Re: [PATCH v9] pgo: add clang's Profile Guided Optimization infrastructure
Hi Bill, On Wed, Apr 07, 2021 at 02:17:04PM -0700, Bill Wendling wrote: > From: Sami Tolvanen > > Enable the use of clang's Profile-Guided Optimization[1]. To generate a > profile, the kernel is instrumented with PGO counters, a representative > workload is run, and the raw profile data is collected from > /sys/kernel/debug/pgo/profraw. > > The raw profile data must be processed by clang's "llvm-profdata" tool > before it can be used during recompilation: > > $ cp /sys/kernel/debug/pgo/profraw vmlinux.profraw > $ llvm-profdata merge --output=vmlinux.profdata vmlinux.profraw > > Multiple raw profiles may be merged during this step. > > The data can now be used by the compiler: > > $ make LLVM=1 KCFLAGS=-fprofile-use=vmlinux.profdata ... > > This initial submission is restricted to x86, as that's the platform we > know works. This restriction can be lifted once other platforms have > been verified to work with PGO. > > Note that this method of profiling the kernel is clang-native, unlike > the clang support in kernel/gcov. > > [1] https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization > > Signed-off-by: Sami Tolvanen > Co-developed-by: Bill Wendling > Signed-off-by: Bill Wendling > Tested-by: Nick Desaulniers > Reviewed-by: Nick Desaulniers > Reviewed-by: Fangrui Song Few small nits below, not sure they warrant a v10 versus just some follow up patches, up to you. Regardless: Reviewed-by: Nathan Chancellor > --- > v9: - [maskray] Remove explicit 'ALIGN' and 'KEEP' from PGO variables in > vmlinux.lds.h. > v8: - Rebased on top-of-tree. > v7: - [sedat.dilek] Fix minor build failure. > v6: - Add better documentation about the locking scheme and other things. > - Rename macros to better match the same macros in LLVM's source code. > v5: - [natechancellor] Correct padding calculation. > v4: - [ndesaulniers] Remove non-x86 Makfile changes and se "hweight64" instead > of using our own popcount implementation. > v3: - [sedat.dilek] Added change log section. > v2: - [natechancellor] Added "__llvm_profile_instrument_memop". > - [maskray] Corrected documentation, re PGO flags when using LTO. > --- > Documentation/dev-tools/index.rst | 1 + > Documentation/dev-tools/pgo.rst | 127 + > MAINTAINERS | 9 + > Makefile | 3 + > arch/Kconfig | 1 + > arch/x86/Kconfig | 1 + > arch/x86/boot/Makefile| 1 + > arch/x86/boot/compressed/Makefile | 1 + > arch/x86/crypto/Makefile | 4 + > arch/x86/entry/vdso/Makefile | 1 + > arch/x86/kernel/vmlinux.lds.S | 2 + > arch/x86/platform/efi/Makefile| 1 + > arch/x86/purgatory/Makefile | 1 + > arch/x86/realmode/rm/Makefile | 1 + > arch/x86/um/vdso/Makefile | 1 + > drivers/firmware/efi/libstub/Makefile | 1 + > include/asm-generic/vmlinux.lds.h | 34 +++ > kernel/Makefile | 1 + > kernel/pgo/Kconfig| 35 +++ > kernel/pgo/Makefile | 5 + > kernel/pgo/fs.c | 389 ++ > kernel/pgo/instrument.c | 189 + > kernel/pgo/pgo.h | 203 ++ > scripts/Makefile.lib | 10 + > 24 files changed, 1022 insertions(+) > create mode 100644 Documentation/dev-tools/pgo.rst > create mode 100644 kernel/pgo/Kconfig > create mode 100644 kernel/pgo/Makefile > create mode 100644 kernel/pgo/fs.c > create mode 100644 kernel/pgo/instrument.c > create mode 100644 kernel/pgo/pgo.h > > diff --git a/Documentation/dev-tools/index.rst > b/Documentation/dev-tools/index.rst > index 1b1cf4f5c9d9..6a30cd98e6f9 100644 > --- a/Documentation/dev-tools/index.rst > +++ b/Documentation/dev-tools/index.rst > @@ -27,6 +27,7 @@ whole; patches welcome! > kgdb > kselftest > kunit/index > + pgo > > > .. only:: subproject and html > diff --git a/Documentation/dev-tools/pgo.rst b/Documentation/dev-tools/pgo.rst > new file mode 100644 > index ..b7f11d8405b7 > --- /dev/null > +++ b/Documentation/dev-tools/pgo.rst > @@ -0,0 +1,127 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +=== > +Using PGO with the Linux kernel > +=== > + > +Clang's profiling kernel support (PGO_) enables profiling of the Linux kernel > +when building with Clang. The profiling data is exported via the ``pgo`` > +debugfs directory. > + > +..
[PATCH] ACPI / CPPC: Replace cppc_attr with kobj_attribute
All of the CPPC sysfs show functions are called via indirect call in
kobj_attr_show(), where they should be of type
ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr, char *buf);
because that is the type of the ->show() member in
'struct kobj_attribute' but they are actually of type
ssize_t (*show)(struct kobject *kobj, struct attribute *attr, char *buf);
because of the ->show() member in 'struct cppc_attr', resulting in a
Control Flow Integrity violation [1].
$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf
3400
$ dmesg | grep "CFI failure"
[ 175.970559] CFI failure (target: show_highest_perf+0x0/0x8):
As far as I can tell, the only different between 'struct cppc_attr' and
'struct kobj_attribute' aside from the type of the attr parameter is the
type of the count parameter in the ->store() member (ssize_t vs.
size_t), which does not actually matter because all of these nodes are
read-only.
Eliminate 'struct cppc_attr' in favor of 'struct kobj_attribute' to fix
the violation.
[1]: https://lore.kernel.org/r/20210401233216.2540591-1-samitolva...@google.com/
Fixes: 158c998ea44b ("ACPI / CPPC: add sysfs support to compute delivered
performance")
Link: https://github.com/ClangBuiltLinux/linux/issues/1343
Signed-off-by: Nathan Chancellor
---
drivers/acpi/cppc_acpi.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 69057fcd2c04..a5e6fd0bafa1 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -119,23 +119,15 @@ static DEFINE_PER_CPU(struct cpc_desc *, cpc_desc_ptr);
*/
#define NUM_RETRIES 500ULL
-struct cppc_attr {
- struct attribute attr;
- ssize_t (*show)(struct kobject *kobj,
- struct attribute *attr, char *buf);
- ssize_t (*store)(struct kobject *kobj,
- struct attribute *attr, const char *c, ssize_t count);
-};
-
#define define_one_cppc_ro(_name) \
-static struct cppc_attr _name =\
+static struct kobj_attribute _name = \
__ATTR(_name, 0444, show_##_name, NULL)
#define to_cpc_desc(a) container_of(a, struct cpc_desc, kobj)
#define show_cppc_data(access_fn, struct_name, member_name)\
static ssize_t show_##member_name(struct kobject *kobj, \
- struct attribute *attr, char *buf) \
+ struct kobj_attribute *attr, char *buf) \
{ \
struct cpc_desc *cpc_ptr = to_cpc_desc(kobj); \
struct struct_name st_name = {0}; \
@@ -161,7 +153,7 @@ show_cppc_data(cppc_get_perf_ctrs, cppc_perf_fb_ctrs,
reference_perf);
show_cppc_data(cppc_get_perf_ctrs, cppc_perf_fb_ctrs, wraparound_time);
static ssize_t show_feedback_ctrs(struct kobject *kobj,
- struct attribute *attr, char *buf)
+ struct kobj_attribute *attr, char *buf)
{
struct cpc_desc *cpc_ptr = to_cpc_desc(kobj);
struct cppc_perf_fb_ctrs fb_ctrs = {0};
base-commit: 454859c552da78b0f587205d308401922b56863e
--
2.31.0
Re: [PATCH 2/2] gcov: re-drop support for clang-10
On Wed, Apr 07, 2021 at 11:54:56AM -0700, Nick Desaulniers wrote:
> LLVM changed the expected function signatures for
> llvm_gcda_emit_function() in the clang-11 release. Drop the older
> implementations and require folks to upgrade their compiler if they're
> interested in GCOV support.
>
> Signed-off-by: Nick Desaulniers
Reviewed-by: Nathan Chancellor
> ---
> kernel/gcov/clang.c | 40
> 1 file changed, 40 deletions(-)
>
> diff --git a/kernel/gcov/clang.c b/kernel/gcov/clang.c
> index 1747204541bf..78c4dc751080 100644
> --- a/kernel/gcov/clang.c
> +++ b/kernel/gcov/clang.c
> @@ -69,9 +69,6 @@ struct gcov_fn_info {
>
> u32 ident;
> u32 checksum;
> -#if CONFIG_CLANG_VERSION < 11
> - u8 use_extra_checksum;
> -#endif
> u32 cfg_checksum;
>
> u32 num_counters;
> @@ -113,23 +110,6 @@ void llvm_gcda_start_file(const char *orig_filename, u32
> version, u32 checksum)
> }
> EXPORT_SYMBOL(llvm_gcda_start_file);
>
> -#if CONFIG_CLANG_VERSION < 11
> -void llvm_gcda_emit_function(u32 ident, u32 func_checksum,
> - u8 use_extra_checksum, u32 cfg_checksum)
> -{
> - struct gcov_fn_info *info = kzalloc(sizeof(*info), GFP_KERNEL);
> -
> - if (!info)
> - return;
> -
> - INIT_LIST_HEAD(>head);
> - info->ident = ident;
> - info->checksum = func_checksum;
> - info->use_extra_checksum = use_extra_checksum;
> - info->cfg_checksum = cfg_checksum;
> - list_add_tail(>head, _info->functions);
> -}
> -#else
> void llvm_gcda_emit_function(u32 ident, u32 func_checksum, u32 cfg_checksum)
> {
> struct gcov_fn_info *info = kzalloc(sizeof(*info), GFP_KERNEL);
> @@ -143,7 +123,6 @@ void llvm_gcda_emit_function(u32 ident, u32
> func_checksum, u32 cfg_checksum)
> info->cfg_checksum = cfg_checksum;
> list_add_tail(>head, _info->functions);
> }
> -#endif
> EXPORT_SYMBOL(llvm_gcda_emit_function);
>
> void llvm_gcda_emit_arcs(u32 num_counters, u64 *counters)
> @@ -274,16 +253,8 @@ int gcov_info_is_compatible(struct gcov_info *info1,
> struct gcov_info *info2)
> !list_is_last(_ptr2->head, >functions)) {
> if (fn_ptr1->checksum != fn_ptr2->checksum)
> return false;
> -#if CONFIG_CLANG_VERSION < 11
> - if (fn_ptr1->use_extra_checksum != fn_ptr2->use_extra_checksum)
> - return false;
> - if (fn_ptr1->use_extra_checksum &&
> - fn_ptr1->cfg_checksum != fn_ptr2->cfg_checksum)
> - return false;
> -#else
> if (fn_ptr1->cfg_checksum != fn_ptr2->cfg_checksum)
> return false;
> -#endif
> fn_ptr1 = list_next_entry(fn_ptr1, head);
> fn_ptr2 = list_next_entry(fn_ptr2, head);
> }
> @@ -403,21 +374,10 @@ size_t convert_to_gcda(char *buffer, struct gcov_info
> *info)
> u32 i;
>
> pos += store_gcov_u32(buffer, pos, GCOV_TAG_FUNCTION);
> -#if CONFIG_CLANG_VERSION < 11
> - pos += store_gcov_u32(buffer, pos,
> - fi_ptr->use_extra_checksum ? 3 : 2);
> -#else
> pos += store_gcov_u32(buffer, pos, 3);
> -#endif
> pos += store_gcov_u32(buffer, pos, fi_ptr->ident);
> pos += store_gcov_u32(buffer, pos, fi_ptr->checksum);
> -#if CONFIG_CLANG_VERSION < 11
> - if (fi_ptr->use_extra_checksum)
> - pos += store_gcov_u32(buffer, pos,
> fi_ptr->cfg_checksum);
> -#else
> pos += store_gcov_u32(buffer, pos, fi_ptr->cfg_checksum);
> -#endif
> -
> pos += store_gcov_u32(buffer, pos, GCOV_TAG_COUNTER_BASE);
> pos += store_gcov_u32(buffer, pos, fi_ptr->num_counters * 2);
> for (i = 0; i < fi_ptr->num_counters; i++)
> --
> 2.31.1.295.g9ea45b61b8-goog
>
Re: [PATCH 1/2] gcov: re-fix clang-11+ support
On Wed, Apr 07, 2021 at 11:54:55AM -0700, Nick Desaulniers wrote:
> LLVM changed the expected function signature for
> llvm_gcda_emit_function() in the clang-11 release. Users of clang-11 or
> newer may have noticed their kernels producing invalid coverage
> information:
>
> $ llvm-cov gcov -a -c -u -f -b .gcda -- gcno=.gcno
> 1 : checksum mismatch, \
> (, ) != (, )
> 2 Invalid .gcda File!
> ...
>
> Fix up the function signatures so calling this function interprets its
> parameters correctly and computes the correct cfg checksum. In
> particular, in clang-11, the additional checksum is no longer optional.
>
> Link: https://reviews.llvm.org/rG25544ce2df0daa4304c07e64b9c8b0f7df60c11d
> Cc: sta...@vger.kernel.org #5.4+
> Reported-by: Prasad Sodagudi
> Tested-by: Prasad Sodagudi
> Signed-off-by: Nick Desaulniers
Reviewed-by: Nathan Chancellor
> ---
> kernel/gcov/clang.c | 38 +-
> 1 file changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/gcov/clang.c b/kernel/gcov/clang.c
> index d41f5ecda9db..1747204541bf 100644
> --- a/kernel/gcov/clang.c
> +++ b/kernel/gcov/clang.c
> @@ -69,7 +69,9 @@ struct gcov_fn_info {
>
> u32 ident;
> u32 checksum;
> +#if CONFIG_CLANG_VERSION < 11
> u8 use_extra_checksum;
> +#endif
> u32 cfg_checksum;
>
> u32 num_counters;
> @@ -111,6 +113,7 @@ void llvm_gcda_start_file(const char *orig_filename, u32
> version, u32 checksum)
> }
> EXPORT_SYMBOL(llvm_gcda_start_file);
>
> +#if CONFIG_CLANG_VERSION < 11
> void llvm_gcda_emit_function(u32 ident, u32 func_checksum,
> u8 use_extra_checksum, u32 cfg_checksum)
> {
> @@ -126,6 +129,21 @@ void llvm_gcda_emit_function(u32 ident, u32
> func_checksum,
> info->cfg_checksum = cfg_checksum;
> list_add_tail(>head, _info->functions);
> }
> +#else
> +void llvm_gcda_emit_function(u32 ident, u32 func_checksum, u32 cfg_checksum)
> +{
> + struct gcov_fn_info *info = kzalloc(sizeof(*info), GFP_KERNEL);
> +
> + if (!info)
> + return;
> +
> + INIT_LIST_HEAD(>head);
> + info->ident = ident;
> + info->checksum = func_checksum;
> + info->cfg_checksum = cfg_checksum;
> + list_add_tail(>head, _info->functions);
> +}
> +#endif
> EXPORT_SYMBOL(llvm_gcda_emit_function);
>
> void llvm_gcda_emit_arcs(u32 num_counters, u64 *counters)
> @@ -256,11 +274,16 @@ int gcov_info_is_compatible(struct gcov_info *info1,
> struct gcov_info *info2)
> !list_is_last(_ptr2->head, >functions)) {
> if (fn_ptr1->checksum != fn_ptr2->checksum)
> return false;
> +#if CONFIG_CLANG_VERSION < 11
> if (fn_ptr1->use_extra_checksum != fn_ptr2->use_extra_checksum)
> return false;
> if (fn_ptr1->use_extra_checksum &&
> fn_ptr1->cfg_checksum != fn_ptr2->cfg_checksum)
> return false;
> +#else
> + if (fn_ptr1->cfg_checksum != fn_ptr2->cfg_checksum)
> + return false;
> +#endif
> fn_ptr1 = list_next_entry(fn_ptr1, head);
> fn_ptr2 = list_next_entry(fn_ptr2, head);
> }
> @@ -378,17 +401,22 @@ size_t convert_to_gcda(char *buffer, struct gcov_info
> *info)
>
> list_for_each_entry(fi_ptr, >functions, head) {
> u32 i;
> - u32 len = 2;
> -
> - if (fi_ptr->use_extra_checksum)
> - len++;
>
> pos += store_gcov_u32(buffer, pos, GCOV_TAG_FUNCTION);
> - pos += store_gcov_u32(buffer, pos, len);
> +#if CONFIG_CLANG_VERSION < 11
> + pos += store_gcov_u32(buffer, pos,
> + fi_ptr->use_extra_checksum ? 3 : 2);
> +#else
> + pos += store_gcov_u32(buffer, pos, 3);
> +#endif
> pos += store_gcov_u32(buffer, pos, fi_ptr->ident);
> pos += store_gcov_u32(buffer, pos, fi_ptr->checksum);
> +#if CONFIG_CLANG_VERSION < 11
> if (fi_ptr->use_extra_checksum)
> pos += store_gcov_u32(buffer, pos,
> fi_ptr->cfg_checksum);
> +#else
> + pos += store_gcov_u32(buffer, pos, fi_ptr->cfg_checksum);
> +#endif
>
> pos += store_gcov_u32(buffer, pos, GCOV_TAG_COUNTER_BASE);
> pos += store_gcov_u32(buffer, pos, fi_ptr->num_counters * 2);
> --
> 2.31.1.295.g9ea45b61b8-goog
>
Re: CFI violation in drivers/infiniband/core/sysfs.c
On Fri, Apr 02, 2021 at 04:03:30PM -0700, Kees Cook wrote: > On Fri, Apr 02, 2021 at 12:52:41PM -0700, Nathan Chancellor wrote: > > Hi all, > > > > I am testing the Clang Control Flow Integrity series that is being > > worked on right now [1] and I encounter a violation in the Infiniband > > sysfs core (drivers/infiniband/core/sysfs.c) on an arm64 server with mlx5: > > > > $ cat /sys/class/infiniband/mlx5_bond_0/ports/1/hw_counters/lifespan > > 12 > > > > $ echo "10" | sudo tee > > /sys/class/infiniband/mlx5_bond_0/ports/1/hw_counters/lifespan > > 10 > > > > $ sudo dmesg > > [64198.670342] [ cut here ] > > [64198.670362] CFI failure (target: show_stats_lifespan+0x0/0x8 [ib_core]): > > [64198.671291] WARNING: CPU: 20 PID: 15786 at kernel/cfi.c:29 > > __ubsan_handle_cfi_check_fail+0x58/0x60 > > [64198.671336] Modules linked in: binfmt_misc nls_iso8859_1 dm_multipath > > scsi_dh_rdac scsi_dh_emc scsi_dh_alua ast drm_vram_helper drm_ttm_helper > > ttm aes_ce_blk crypto_simd drm_kms_helper cryptd cec rc_core > > aes_ce_cipher crct10dif_ce sysimgblt ghash_ce syscopyarea sysfillrect > > acpi_ipmi sha2_ce fb_sys_fops ipmi_ssif sha256_arm64 ipmi_devintf > > sha1_ce drm efi_pstore sbsa_gwdt tcp_westwood evbug ipmi_msghandler > > cppc_cpufreq xgene_hwmon ib_iser rdma_cm iw_cm ib_cm iscsi_tcp > > libiscsi_tcp libiscsi scsi_transport_iscsi bonding ip_tables x_tables > > autofs4 raid10 raid456 libcrc32c async_raid6_recov async_pq raid6_pq > > async_xor xor xor_neon async_memcpy async_tx raid1 raid0 multipath > > linear mlx5_ib ib_uverbs ib_core mlx5_core mlxfw igb i2c_algo_bit tls > > i2c_xgene_slimpro ahci_platform gpio_dwapb > > [64198.671958] CPU: 20 PID: 15786 Comm: cat Tainted: GW > > 5.12.0-rc5+ #5 > > [64198.671980] Hardware name: Lenovo HR330A7X33CTO1WW > > /HR350A , BIOS HVE104D-1.02 03/08/2019 > > [64198.671993] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--) > > [64198.672016] pc : __ubsan_handle_cfi_check_fail+0x58/0x60 > > [64198.672036] lr : __ubsan_handle_cfi_check_fail+0x58/0x60 > > [64198.672054] sp : 800014ea3b50 > > [64198.672065] x29: 800014ea3b50 x28: 80001122da60 > > [64198.672095] x27: 80001122ad80 x26: 800011233088 > > [64198.672122] x25: 000801821a78 x24: 000820cda200 > > [64198.672148] x23: 89aa9f60 x22: 89a66000 > > [64198.672173] x21: 7dac81f92e1d85cf x20: 89abddd0 > > [64198.672198] x19: 89a69fd8 x18: > > [64198.672223] x17: x16: > > [64198.672250] x15: 0004 x14: 1fff > > [64198.672277] x13: 8000121412a8 x12: 0003 > > [64198.672303] x11: x10: 0027 > > [64198.672329] x9 : 4568e3af67e9f000 x8 : 4568e3af67e9f000 > > [64198.672356] x7 : 6e6170736566696c x6 : 8000124699c9 > > [64198.672381] x5 : x4 : 0001 > > [64198.672406] x3 : x2 : > > [64198.672431] x1 : 8000119b905d x0 : 003c > > [64198.672457] Call trace: > > [64198.672469] __ubsan_handle_cfi_check_fail+0x58/0x60 > > [64198.672489] __cfi_check_fail+0x3c/0x44 [ib_core] > > [64198.673362] __cfi_check+0x2e78/0x31b0 [ib_core] > > [64198.674230] port_attr_show+0x88/0x98 [ib_core] > > [64198.675098] sysfs_kf_seq_show+0xc4/0x160 > > [64198.675131] kernfs_seq_show+0x5c/0xa4 > > [64198.675157] seq_read_iter+0x178/0x60c > > [64198.675176] kernfs_fop_read_iter+0x78/0x1fc > > [64198.675202] vfs_read+0x2d0/0x34c > > [64198.675220] ksys_read+0x80/0xec > > [64198.675237] __arm64_sys_read+0x28/0x34 > > [64198.675253] el0_svc_common.llvm.13467398108545334879+0xbc/0x1f0 > > [64198.675277] do_el0_svc+0x30/0xa4 > > [64198.675293] el0_svc+0x30/0xb0 > > [64198.675314] el0_sync_handler+0x84/0xe4 > > [64198.675333] el0_sync+0x174/0x180 > > [64198.675351] ---[ end trace a253e31759778f5c ]--- > > [64216.024673] [ cut here ] > > [64216.024678] CFI failure (target: set_stats_lifespan+0x0/0x8 [ib_core]): > > [64216.024824] WARNING: CPU: 3 PID: 15816 at kernel/cfi.c:29 > > __ubsan_handle_cfi_check_fail+0x58/0x60 > > [64216.024832] Modules linked in: binfmt_misc nls_iso8859_1 dm_multipath > > scsi_dh_rdac scsi_dh_emc scsi_dh_alua ast drm_vram_helper drm_ttm_helper > > ttm aes_ce_blk crypto_simd drm_kms_helper cryptd cec rc_core > > aes_ce_cipher crct10dif_ce sysimgblt ghash_ce syscopyarea sysfillrect > >
Re: [PATCH 3/3] kbuild: fix false-positive modpost warning when all symbols are trimmed
On Fri, Mar 26, 2021 at 03:54:11AM +0900, Masahiro Yamada wrote:
> Nathan reports that the mips defconfig emits the following warning:
>
> WARNING: modpost: Symbol info of vmlinux is missing. Unresolved symbol
> check will be entirely skipped.
>
> This false-positive happens under the following combination:
>
> - CONFIG_TRIM_UNUSED_KSYMS=y
> - CONFIG_MODULES=y
> - No CONFIG option is set to 'm'
>
> Commit a0590473c5e6 ("nfs: fix PNFS_FLEXFILE_LAYOUT Kconfig default")
> turned the last 'm' into 'y' for the mips defconfig, and uncovered
> this issue.
>
> In this case, the module feature itself is enabled, but we have no
> module. As a result, CONFIG_TRIM_UNUSED_KSYMS drops all the instances
> of EXPORT_SYMBOL. Then, modpost wrongly assumes vmlinux is missing
> because vmlinux.symvers is empty. (Or, you can create a module that
> does not use any symbol of vmlinux).
>
> The current behavior is to entirely suppress the unresolved symbol
> warnings when vmlinux is missing just because there are too many.
> I found the origin of this code in the historical git tree. [1]
>
> If this is a matter of noisiness, I think modpost can display the
> first 10 warnings, and the number of suppressed warnings at the end.
>
> You will get a bit noisier logs when you run 'make modules' without
> vmlinux, but such warnings are better to show because you never know
> the resulting modules are actually loadable or not.
>
> This commit changes as follows:
>
> - If any of input *.symver files is missing, pass -w option to let
>the module build keep going with warnings instead of errors.
>
> - If there are too many (10+) unresolved symbol warnings, show only
>the first 10, and also the number of suppressed warnings.
>
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=1cc0e0529569bf6a94f6d49770aa6d4b599d2c46
>
> Reported-by: Nathan Chancellor
> Signed-off-by: Masahiro Yamada
Thank you for the patch, I do not see that warning anymore.
Tested-by: Nathan Chancellor
> ---
>
> scripts/Makefile.modpost | 7 +--
> scripts/mod/modpost.c| 25 -
> 2 files changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
> index b3e08fb1fd56..c383ba33d837 100644
> --- a/scripts/Makefile.modpost
> +++ b/scripts/Makefile.modpost
> @@ -98,9 +98,11 @@ output-symdump := $(KBUILD_EXTMOD)/Module.symvers
>
> endif
>
> +existing-input-symdump := $(wildcard $(input-symdump))
> +
> # modpost options for modules (both in-kernel and external)
> MODPOST += \
> - $(addprefix -i ,$(wildcard $(input-symdump))) \
> + $(addprefix -i ,$(existing-input-symdump)) \
> $(if $(KBUILD_NSDEPS),-d $(MODULES_NSDEPS)) \
> $(if
> $(CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS)$(KBUILD_NSDEPS),-N)
>
> @@ -114,6 +116,7 @@ VPATH :=
> $(input-symdump):
> @echo >&2 'WARNING: Symbol version dump "$@" is missing.'
> @echo >&2 ' Modules may not have dependencies or modversions.'
> + @echo >&2 ' You may get many unresolved symbol warnings.'
>
> ifdef CONFIG_LTO_CLANG
> # With CONFIG_LTO_CLANG, .o files might be LLVM bitcode, so we need to run
> @@ -134,7 +137,7 @@ endif
> modules := $(sort $(shell cat $(MODORDER)))
>
> # KBUILD_MODPOST_WARN can be set to avoid error out in case of undefined
> symbols
> -ifneq ($(KBUILD_MODPOST_WARN),)
> +ifneq ($(KBUILD_MODPOST_WARN)$(filter-out $(existing-input-symdump),
> $(input-symdump)),)
> MODPOST += -w
> endif
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 10c3fba26f03..7c6bec78fa34 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -23,8 +23,6 @@
>
> /* Are we using CONFIG_MODVERSIONS? */
> static int modversions = 0;
> -/* Warn about undefined symbols? (do so if we have vmlinux) */
> -static int have_vmlinux = 0;
> /* Is CONFIG_MODULE_SRCVERSION_ALL set? */
> static int all_versions = 0;
> /* If we are modposting external module set to 1 */
> @@ -41,6 +39,13 @@ static int allow_missing_ns_imports;
>
> static bool error_occurred;
>
> +/*
> + * Cut off the warnings when there are too many. This typically occurs when
> + * vmlinux is missing. ('make modules' without building vmlinux.)
> + */
> +#define MAX_UNRESOLVED_REPORTS 10
> +static unsigned int nr_unresolved;
> +
> enum export {
> export_plain,
> export_gpl,
> @@ -177,9 +182,6 @@ static struct module *new_module(const char *modname)
> mod->next = modules;
> modules =
Re: [PATCH v5 00/18] Add support for Clang CFI
ers/misc/lkdtm/usercopy.c | 2 +- > drivers/misc/sram.c | 4 +- > drivers/nvme/host/core.c | 3 +- > .../controller/cadence/pcie-cadence-host.c| 3 +- > drivers/spi/spi-loopback-test.c | 3 +- > fs/btrfs/raid56.c | 3 +- > fs/btrfs/tree-log.c | 3 +- > fs/btrfs/volumes.c| 3 +- > fs/ext4/fsmap.c | 4 +- > fs/gfs2/glock.c | 3 +- > fs/gfs2/log.c | 2 +- > fs/gfs2/lops.c| 3 +- > fs/iomap/buffered-io.c| 3 +- > fs/ubifs/gc.c | 7 +- > fs/ubifs/replay.c | 4 +- > fs/xfs/scrub/bitmap.c | 4 +- > fs/xfs/xfs_bmap_item.c| 4 +- > fs/xfs/xfs_buf.c | 6 +- > fs/xfs/xfs_extent_busy.c | 4 +- > fs/xfs/xfs_extent_busy.h | 3 +- > fs/xfs/xfs_extfree_item.c | 4 +- > fs/xfs/xfs_refcount_item.c| 4 +- > fs/xfs/xfs_rmap_item.c| 4 +- > include/asm-generic/bug.h | 16 + > include/asm-generic/vmlinux.lds.h | 20 +- > include/linux/bpf.h | 4 +- > include/linux/cfi.h | 41 +++ > include/linux/compiler-clang.h| 3 + > include/linux/compiler_types.h| 8 + > include/linux/init.h | 6 +- > include/linux/list_sort.h | 7 +- > include/linux/mm.h| 10 + > include/linux/module.h| 13 +- > include/linux/pci.h | 4 +- > init/Kconfig | 2 +- > kernel/Makefile | 4 + > kernel/cfi.c | 329 ++ > kernel/kallsyms.c | 55 ++- > kernel/kthread.c | 3 +- > kernel/module.c | 43 +++ > kernel/workqueue.c| 2 +- > lib/list_sort.c | 17 +- > lib/test_list_sort.c | 3 +- > net/tipc/name_table.c | 4 +- > scripts/Makefile.modfinal | 2 +- > scripts/module.lds.S | 19 +- > 75 files changed, 759 insertions(+), 113 deletions(-) > create mode 100644 include/linux/cfi.h > create mode 100644 kernel/cfi.c > > > base-commit: 6905b1dc3c32a094f0da61bd656a740f0a97d592 > -- > 2.31.0.208.g409f899ff0-goog > Hi Sami, I booted this series on Equinix's c1.large.arm (2x Cavium ThunderX CN8890) and c2.large.arm (1x Ampere eMAG 8180) servers [1] and my Raspberry Pi 4B. I ran them through LTP's read_all test case on both /proc and /sys and a few compile workloads, only uncovering one issue [2]. Consider this series: Tested-by: Nathan Chancellor [1]: https://metal.equinix.com/developers/docs/servers/ [2]: https://lore.kernel.org/r/20210402195241.gahc5w25gezluw7p@archlinux-ax161/ Cheers, Nathan
CFI violation in drivers/infiniband/core/sysfs.c
Hi all, I am testing the Clang Control Flow Integrity series that is being worked on right now [1] and I encounter a violation in the Infiniband sysfs core (drivers/infiniband/core/sysfs.c) on an arm64 server with mlx5: $ cat /sys/class/infiniband/mlx5_bond_0/ports/1/hw_counters/lifespan 12 $ echo "10" | sudo tee /sys/class/infiniband/mlx5_bond_0/ports/1/hw_counters/lifespan 10 $ sudo dmesg [64198.670342] [ cut here ] [64198.670362] CFI failure (target: show_stats_lifespan+0x0/0x8 [ib_core]): [64198.671291] WARNING: CPU: 20 PID: 15786 at kernel/cfi.c:29 __ubsan_handle_cfi_check_fail+0x58/0x60 [64198.671336] Modules linked in: binfmt_misc nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ast drm_vram_helper drm_ttm_helper ttm aes_ce_blk crypto_simd drm_kms_helper cryptd cec rc_core aes_ce_cipher crct10dif_ce sysimgblt ghash_ce syscopyarea sysfillrect acpi_ipmi sha2_ce fb_sys_fops ipmi_ssif sha256_arm64 ipmi_devintf sha1_ce drm efi_pstore sbsa_gwdt tcp_westwood evbug ipmi_msghandler cppc_cpufreq xgene_hwmon ib_iser rdma_cm iw_cm ib_cm iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi bonding ip_tables x_tables autofs4 raid10 raid456 libcrc32c async_raid6_recov async_pq raid6_pq async_xor xor xor_neon async_memcpy async_tx raid1 raid0 multipath linear mlx5_ib ib_uverbs ib_core mlx5_core mlxfw igb i2c_algo_bit tls i2c_xgene_slimpro ahci_platform gpio_dwapb [64198.671958] CPU: 20 PID: 15786 Comm: cat Tainted: GW 5.12.0-rc5+ #5 [64198.671980] Hardware name: Lenovo HR330A7X33CTO1WW/HR350A , BIOS HVE104D-1.02 03/08/2019 [64198.671993] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--) [64198.672016] pc : __ubsan_handle_cfi_check_fail+0x58/0x60 [64198.672036] lr : __ubsan_handle_cfi_check_fail+0x58/0x60 [64198.672054] sp : 800014ea3b50 [64198.672065] x29: 800014ea3b50 x28: 80001122da60 [64198.672095] x27: 80001122ad80 x26: 800011233088 [64198.672122] x25: 000801821a78 x24: 000820cda200 [64198.672148] x23: 89aa9f60 x22: 89a66000 [64198.672173] x21: 7dac81f92e1d85cf x20: 89abddd0 [64198.672198] x19: 89a69fd8 x18: [64198.672223] x17: x16: [64198.672250] x15: 0004 x14: 1fff [64198.672277] x13: 8000121412a8 x12: 0003 [64198.672303] x11: x10: 0027 [64198.672329] x9 : 4568e3af67e9f000 x8 : 4568e3af67e9f000 [64198.672356] x7 : 6e6170736566696c x6 : 8000124699c9 [64198.672381] x5 : x4 : 0001 [64198.672406] x3 : x2 : [64198.672431] x1 : 8000119b905d x0 : 003c [64198.672457] Call trace: [64198.672469] __ubsan_handle_cfi_check_fail+0x58/0x60 [64198.672489] __cfi_check_fail+0x3c/0x44 [ib_core] [64198.673362] __cfi_check+0x2e78/0x31b0 [ib_core] [64198.674230] port_attr_show+0x88/0x98 [ib_core] [64198.675098] sysfs_kf_seq_show+0xc4/0x160 [64198.675131] kernfs_seq_show+0x5c/0xa4 [64198.675157] seq_read_iter+0x178/0x60c [64198.675176] kernfs_fop_read_iter+0x78/0x1fc [64198.675202] vfs_read+0x2d0/0x34c [64198.675220] ksys_read+0x80/0xec [64198.675237] __arm64_sys_read+0x28/0x34 [64198.675253] el0_svc_common.llvm.13467398108545334879+0xbc/0x1f0 [64198.675277] do_el0_svc+0x30/0xa4 [64198.675293] el0_svc+0x30/0xb0 [64198.675314] el0_sync_handler+0x84/0xe4 [64198.675333] el0_sync+0x174/0x180 [64198.675351] ---[ end trace a253e31759778f5c ]--- [64216.024673] [ cut here ] [64216.024678] CFI failure (target: set_stats_lifespan+0x0/0x8 [ib_core]): [64216.024824] WARNING: CPU: 3 PID: 15816 at kernel/cfi.c:29 __ubsan_handle_cfi_check_fail+0x58/0x60 [64216.024832] Modules linked in: binfmt_misc nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ast drm_vram_helper drm_ttm_helper ttm aes_ce_blk crypto_simd drm_kms_helper cryptd cec rc_core aes_ce_cipher crct10dif_ce sysimgblt ghash_ce syscopyarea sysfillrect acpi_ipmi sha2_ce fb_sys_fops ipmi_ssif sha256_arm64 ipmi_devintf sha1_ce drm efi_pstore sbsa_gwdt tcp_westwood evbug ipmi_msghandler cppc_cpufreq xgene_hwmon ib_iser rdma_cm iw_cm ib_cm iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi bonding ip_tables x_tables autofs4 raid10 raid456 libcrc32c async_raid6_recov async_pq raid6_pq async_xor xor xor_neon async_memcpy async_tx raid1 raid0 multipath linear mlx5_ib ib_uverbs ib_core mlx5_core mlxfw igb i2c_algo_bit tls i2c_xgene_slimpro ahci_platform gpio_dwapb [64216.024922] CPU: 3 PID: 15816 Comm: tee Tainted: GW 5.12.0-rc5+ #5 [64216.024925] Hardware name: Lenovo HR330A7X33CTO1WW/HR350A , BIOS HVE104D-1.02 03/08/2019 [64216.024927] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--) [64216.024931] pc : __ubsan_handle_cfi_check_fail+0x58/0x60 [64216.024933] lr : __ubsan_handle_cfi_check_fail+0x58/0x60 [64216.024936] sp : 800015433bf0
Re: [PATCH] qemu_fw_cfg: Make fw_cfg_rev_attr a proper kobj_attribute
On Fri, Apr 02, 2021 at 11:25:42AM -0700, Kees Cook wrote: > On Fri, Apr 02, 2021 at 08:42:07AM +0200, Sedat Dilek wrote: > > On Thu, Feb 25, 2021 at 10:25 PM Kees Cook wrote: > > > > > > On Thu, 11 Feb 2021 12:42:58 -0700, Nathan Chancellor wrote: > > > > fw_cfg_showrev() is called by an indirect call in kobj_attr_show(), > > > > which violates clang's CFI checking because fw_cfg_showrev()'s second > > > > parameter is 'struct attribute', whereas the ->show() member of 'struct > > > > kobj_structure' expects the second parameter to be of type 'struct > > > > kobj_attribute'. > > > > > > > > $ cat /sys/firmware/qemu_fw_cfg/rev > > > > 3 > > > > > > > > [...] > > > > > > Applied to kspp/cfi/cleanups, thanks! > > > > > > [1/1] qemu_fw_cfg: Make fw_cfg_rev_attr a proper kobj_attribute > > > https://git.kernel.org/kees/c/f5c4679d6c49 > > > > > > > I have queued this up in my custom patchset > > (for-5.12/kspp-cfi-cleanups-20210225). > > > > What is the plan to get this upstream? > > I haven't sent it to Linus yet -- I was expecting to batch more of these > and send them for v5.13. (But if the kvm folks snag it, that's good > too.) I am going to be putting the CFI series through its paces on both arm64 and x86_64 over the next week or so on several different machines (in fact, I am writing up a report right now) so I will probably have some more of these as I find them. Cheers, Nathan
Re: [PATCH] ARM: OMAP: Fix use of possibly uninitialized irq variable
On Thu, Apr 01, 2021 at 06:11:27PM +0200, Maciej Falkowski wrote:
> The current control flow of IRQ number assignment to `irq` variable
> allows a request of IRQ of unspecified value,
> generating a warning under Clang compilation with omap1_defconfig on
> linux-next:
>
> arch/arm/mach-omap1/pm.c:656:11: warning: variable 'irq' is used
> uninitialized whenever
> 'if' condition is false [-Wsometimes-uninitialized]
> else if (cpu_is_omap16xx())
> ^
> ./arch/arm/mach-omap1/include/mach/soc.h:123:30: note: expanded from macro
> 'cpu_is_omap16xx'
> ^
> arch/arm/mach-omap1/pm.c:658:18: note: uninitialized use occurs here
> if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral wakeup",
> ^~~
> arch/arm/mach-omap1/pm.c:656:7: note: remove the 'if' if its condition is
> always true
> else if (cpu_is_omap16xx())
> ^~
> arch/arm/mach-omap1/pm.c:611:9: note: initialize the variable 'irq' to
> silence this warning
> int irq;
>^
> = 0
> 1 warning generated.
>
> The patch provides a default value to the `irq` variable
> along with a validity check.
>
Might be worth a fixes tag:
Fixes: b75ca5217743 ("ARM: OMAP: replace setup_irq() by request_irq()")
> Signed-off-by: Maciej Falkowski
> Link: https://github.com/ClangBuiltLinux/linux/issues/1324
Reviewed-by: Nathan Chancellor
> ---
> arch/arm/mach-omap1/pm.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
> index 2c1e2b32b9b3..a745d64d4699 100644
> --- a/arch/arm/mach-omap1/pm.c
> +++ b/arch/arm/mach-omap1/pm.c
> @@ -655,9 +655,13 @@ static int __init omap_pm_init(void)
> irq = INT_7XX_WAKE_UP_REQ;
> else if (cpu_is_omap16xx())
> irq = INT_1610_WAKE_UP_REQ;
> - if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral wakeup",
> - NULL))
> - pr_err("Failed to request irq %d (peripheral wakeup)\n", irq);
> + else
> + irq = -1;
> +
> + if (irq >= 0) {
> + if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral
> wakeup", NULL))
> + pr_err("Failed to request irq %d (peripheral
> wakeup)\n", irq);
> + }
>
> /* Program new power ramp-up time
>* (0 for most boards since we don't lower voltage when in deep sleep)
> --
> 2.26.3
>
Re: [PATCH] usb: isp1301-omap: Add missing gpiod_add_lookup_table function
On Thu, Apr 01, 2021 at 06:20:32PM +0200, Maciej Falkowski wrote:
> The gpiod table was added without any usage making it unused
> as reported by Clang compilation from omap1_defconfig on linux-next:
>
> arch/arm/mach-omap1/board-h2.c:347:34: warning: unused variable
> 'isp1301_gpiod_table' [-Wunused-variable]
> static struct gpiod_lookup_table isp1301_gpiod_table = {
> ^
> 1 warning generated.
>
> The patch adds the missing gpiod_add_lookup_table() function.
>
> Signed-off-by: Maciej Falkowski
> Fixes: f3ef38160e3d ("usb: isp1301-omap: Convert to use GPIO descriptors")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1325
Thanks for the patch!
Reviewed-by: Nathan Chancellor
> ---
> arch/arm/mach-omap1/board-h2.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
> index c40cf5ef8607..977b0b744c22 100644
> --- a/arch/arm/mach-omap1/board-h2.c
> +++ b/arch/arm/mach-omap1/board-h2.c
> @@ -320,7 +320,7 @@ static int tps_setup(struct i2c_client *client, void
> *context)
> {
> if (!IS_BUILTIN(CONFIG_TPS65010))
> return -ENOSYS;
> -
> +
> tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
> TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
>
> @@ -394,6 +394,8 @@ static void __init h2_init(void)
> BUG_ON(gpio_request(H2_NAND_RB_GPIO_PIN, "NAND ready") < 0);
> gpio_direction_input(H2_NAND_RB_GPIO_PIN);
>
> + gpiod_add_lookup_table(_gpiod_table);
> +
> omap_cfg_reg(L3_1610_FLASH_CS2B_OE);
> omap_cfg_reg(M8_1610_FLASH_CS2B_WE);
>
> --
> 2.26.3
>
Re: [PATCH] ARM: OMAP1: ams-delta: remove unused function ams_delta_camera_power
On Thu, Apr 01, 2021 at 06:04:34PM +0200, Maciej Falkowski wrote:
> The ams_delta_camera_power() function is unused as reports
> Clang compilation with omap1_defconfig on linux-next:
>
> arch/arm/mach-omap1/board-ams-delta.c:462:12: warning: unused function
> 'ams_delta_camera_power' [-Wunused-function]
> static int ams_delta_camera_power(struct device *dev, int power)
>^
> 1 warning generated.
>
> The soc_camera support was dropped without removing
> ams_delta_camera_power() function, making it unused.
>
> Signed-off-by: Maciej Falkowski
> Fixes: ce548396a433 ("media: mach-omap1: board-ams-delta.c: remove soc_camera
> dependencies")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1326
Thanks for the patch!
Reviewed-by: Nathan Chancellor
> ---
> arch/arm/mach-omap1/board-ams-delta.c | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c
> b/arch/arm/mach-omap1/board-ams-delta.c
> index 2ee527c00284..1026a816dcc0 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -458,20 +458,6 @@ static struct gpiod_lookup_table leds_gpio_table = {
>
> #ifdef CONFIG_LEDS_TRIGGERS
> DEFINE_LED_TRIGGER(ams_delta_camera_led_trigger);
> -
> -static int ams_delta_camera_power(struct device *dev, int power)
> -{
> - /*
> - * turn on camera LED
> - */
> - if (power)
> - led_trigger_event(ams_delta_camera_led_trigger, LED_FULL);
> - else
> - led_trigger_event(ams_delta_camera_led_trigger, LED_OFF);
> - return 0;
> -}
> -#else
> -#define ams_delta_camera_power NULL
> #endif
>
> static struct platform_device ams_delta_audio_device = {
> --
> 2.26.3
>
Re: [PATCH] blk-mq: fix alignment mismatch.
Hi Jian,
On Wed, Mar 31, 2021 at 02:27:03PM -0700, Jian Cai wrote:
> Hi Nathan,
>
> I just realized you already proposed solutions for skipping the check
> in
> https://lore.kernel.org/linux-block/20210310225240.4epj2mdmzt4vurr3@archlinux-ax161/#t.
> Do you have any plans to send them for review?
>
> Thanks,
> Jian
I was hoping to gather some feedback on which option would be preferred
by Jens and the other ClangBuiltLinux folks before I sent them along. I
can send the first just to see what kind of feedback I can gather.
Cheers,
Nathan
> On Tue, Mar 30, 2021 at 6:31 PM Jian Cai wrote:
> >
> > Thanks for all the information. I'll check for similar instances and
> > send an updated version.
> >
> >
> > On Tue, Mar 30, 2021 at 5:26 PM Guenter Roeck wrote:
> > >
> > > On 3/30/21 4:29 PM, Nathan Chancellor wrote:
> > > > Hi Jian,
> > > >
> > > > On Tue, Mar 30, 2021 at 04:02:49PM -0700, Jian Cai wrote:
> > > >> This fixes the mismatch of alignments between csd and its use as an
> > > >> argument to smp_call_function_single_async, which causes build failure
> > > >> when -Walign-mismatch in Clang is used.
> > > >>
> > > >> Link:
> > > >> http://crrev.com/c/1193732
> > > >>
> > > >> Suggested-by: Guenter Roeck
> > > >> Signed-off-by: Jian Cai
> > > >
> > > > Thanks for the patch. This is effectively a revert of commit
> > > > 4ccafe032005 ("block: unalign call_single_data in struct request"),
> > > > which I had brought up in this thread:
> > > >
> > > > https://lore.kernel.org/r/20210310182307.zzcbi5w5jrmveld4@archlinux-ax161/
> > > >
> > > > This is obviously a correct fix, I am not just sure what the impact to
> > > > 'struct request' will be.
> > > >
> > >
> > > As commit 4ccafe032005 states, it increases the request structure size.
> > > Given the exchange referenced above, I think we'll need to disable
> > > the warning in the block code.
> > >
> > > Thanks,
> > > Guenter
> > >
> > > > Cheers,
> > > > Nathan
> > > >
> > > >> ---
> > > >> include/linux/blkdev.h | 2 +-
> > > >> 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> > > >> index bc6bc8383b43..3b92330d95ad 100644
> > > >> --- a/include/linux/blkdev.h
> > > >> +++ b/include/linux/blkdev.h
> > > >> @@ -231,7 +231,7 @@ struct request {
> > > >> unsigned long deadline;
> > > >>
> > > >> union {
> > > >> -struct __call_single_data csd;
> > > >> +call_single_data_t csd;
> > > >> u64 fifo_time;
> > > >> };
> > > >>
> > > >> --
> > > >> 2.31.0.291.g576ba9dcdaf-goog
> > > >>
> > >
Re: [PATCH] blk-mq: fix alignment mismatch.
Hi Jian,
On Tue, Mar 30, 2021 at 04:02:49PM -0700, Jian Cai wrote:
> This fixes the mismatch of alignments between csd and its use as an
> argument to smp_call_function_single_async, which causes build failure
> when -Walign-mismatch in Clang is used.
>
> Link:
> http://crrev.com/c/1193732
>
> Suggested-by: Guenter Roeck
> Signed-off-by: Jian Cai
Thanks for the patch. This is effectively a revert of commit
4ccafe032005 ("block: unalign call_single_data in struct request"),
which I had brought up in this thread:
https://lore.kernel.org/r/20210310182307.zzcbi5w5jrmveld4@archlinux-ax161/
This is obviously a correct fix, I am not just sure what the impact to
'struct request' will be.
Cheers,
Nathan
> ---
> include/linux/blkdev.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index bc6bc8383b43..3b92330d95ad 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -231,7 +231,7 @@ struct request {
> unsigned long deadline;
>
> union {
> - struct __call_single_data csd;
> + call_single_data_t csd;
> u64 fifo_time;
> };
>
> --
> 2.31.0.291.g576ba9dcdaf-goog
>
Re: [PATCH] riscv: Use $(LD) instead of $(CC) to link vDSO
On Sat, Mar 27, 2021 at 12:05:34AM +0800, kernel test robot wrote: > Hi Nathan, > > I love your patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [also build test ERROR on v5.12-rc4 next-20210326] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch] > > url: > https://github.com/0day-ci/linux/commits/Nathan-Chancellor/riscv-Use-LD-instead-of-CC-to-link-vDSO/20210326-055421 > base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > 002322402dafd846c424ffa9240a937f49b48c42 > config: riscv-randconfig-r032-20210326 (attached as .config) > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project > f490a5969bd52c8a48586f134ff8f02ccbb295b3) > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # install riscv cross compiling tool for clang build > # apt-get install binutils-riscv64-linux-gnu > # > https://github.com/0day-ci/linux/commit/dfdcaf93f40f0d15ffc3f25128442c1688e612d6 > git remote add linux-review https://github.com/0day-ci/linux > git fetch --no-tags linux-review > Nathan-Chancellor/riscv-Use-LD-instead-of-CC-to-link-vDSO/20210326-055421 > git checkout dfdcaf93f40f0d15ffc3f25128442c1688e612d6 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv For the record, I tried to use this script to reproduce but it has a couple of bugs: 1. It does not download the right version of clang. This report says that it is clang-13 but the one that the script downloaded is clang-12. 2. It does not download it to the right location. The script expects ~/0day/clang-latest but it is downloaded to ~/0day/clang it seems. I symlinked it to get around it. > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > > >> riscv64-linux-gnu-objcopy: 'arch/riscv/kernel/vdso/vdso.so.dbg': No such > >> file This error only occurs because of errors before it that are not shown due to a denylist: ld.lld: error: arch/riscv/kernel/vdso/rt_sigreturn.o:(.text+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax ld.lld: error: arch/riscv/kernel/vdso/getcpu.o:(.text+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax ld.lld: error: arch/riscv/kernel/vdso/flush_icache.o:(.text+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax My patch only adds another occurrence of this error because we move from $(CC)'s default linker (in clang's case, ld.bfd) to $(LD), which in the case of 0day appears to be ld.lld. ld.lld should not be used with RISC-V in its current form due to errors of this nature, which happen without my patch as well: https://github.com/ClangBuiltLinux/linux/issues/1020 Linker relaxation in ld.lld for RISC-V is an ongoing debate/process. Please give RISC-V the current treatment as s390 with ld.lld for the time being to get meaningful reports. We will reach out once that issue has been resolved. TL;DR: Patch exposes existing issue with LD=ld.lld that would have happened without it in different areas, the report can be ignored. Cheers! Nathan
[tip: x86/build] efi/libstub: Add $(CLANG_FLAGS) to x86 flags
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 58d746c119dfa28e72fc35aacaf3d2a3ac625cd0
Gitweb:
https://git.kernel.org/tip/58d746c119dfa28e72fc35aacaf3d2a3ac625cd0
Author:Nathan Chancellor
AuthorDate:Thu, 25 Mar 2021 17:04:35 -07:00
Committer: Borislav Petkov
CommitterDate: Fri, 26 Mar 2021 11:34:58 +01:00
efi/libstub: Add $(CLANG_FLAGS) to x86 flags
When cross compiling x86 on an ARM machine with clang, there are several
errors along the lines of:
arch/x86/include/asm/page_64.h:52:7: error: invalid output constraint '=D' in
asm
This happens because the x86 flags in the EFI stub are not derived from
KBUILD_CFLAGS like the other architectures are and the clang flags that
set the target architecture ('--target=') and the path to the GNU cross
tools ('--prefix=') are not present, meaning that the host architecture
is targeted.
These flags are available as $(CLANG_FLAGS) from the main Makefile so
add them to the cflags for x86 so that cross compiling works as expected.
Signed-off-by: Nathan Chancellor
Signed-off-by: Borislav Petkov
Acked-by: Ard Biesheuvel
Link: https://lkml.kernel.org/r/20210326000435.4785-4-nat...@kernel.org
---
drivers/firmware/efi/libstub/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/libstub/Makefile
b/drivers/firmware/efi/libstub/Makefile
index c23466e..d053757 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -13,7 +13,8 @@ cflags-$(CONFIG_X86) += -m$(BITS) -D__KERNEL__ \
-Wno-pointer-sign \
$(call cc-disable-warning,
address-of-packed-member) \
$(call cc-disable-warning, gnu) \
- -fno-asynchronous-unwind-tables
+ -fno-asynchronous-unwind-tables \
+ $(CLANG_FLAGS)
# arm64 uses the full KBUILD_CFLAGS so it's necessary to explicitly
# disable the stackleak plugin
[tip: x86/build] x86/boot: Add $(CLANG_FLAGS) to compressed KBUILD_CFLAGS
The following commit has been merged into the x86/build branch of tip:
Commit-ID: d5cbd80e302dfea59726c44c56ab7957f822409f
Gitweb:
https://git.kernel.org/tip/d5cbd80e302dfea59726c44c56ab7957f822409f
Author:Nathan Chancellor
AuthorDate:Thu, 25 Mar 2021 17:04:34 -07:00
Committer: Borislav Petkov
CommitterDate: Fri, 26 Mar 2021 11:32:55 +01:00
x86/boot: Add $(CLANG_FLAGS) to compressed KBUILD_CFLAGS
When cross compiling x86 on an ARM machine with clang, there are several
errors along the lines of:
arch/x86/include/asm/string_64.h:27:10: error: invalid output constraint
'=' in asm
This happens because the compressed boot Makefile reassigns KBUILD_CFLAGS
and drops the clang flags that set the target architecture ('--target=')
and the path to the GNU cross tools ('--prefix='), meaning that the host
architecture is targeted.
These flags are available as $(CLANG_FLAGS) from the main Makefile so
add them to the compressed boot folder's KBUILD_CFLAGS so that cross
compiling works as expected.
Signed-off-by: Nathan Chancellor
Signed-off-by: Borislav Petkov
Acked-by: Ard Biesheuvel
Link: https://lkml.kernel.org/r/20210326000435.4785-3-nat...@kernel.org
---
arch/x86/boot/compressed/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/boot/compressed/Makefile
b/arch/x86/boot/compressed/Makefile
index e0bc398..6e5522a 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -46,6 +46,7 @@ KBUILD_CFLAGS += -D__DISABLE_EXPORTS
# Disable relocation relaxation in case the link is not PIE.
KBUILD_CFLAGS += $(call as-option,-Wa$(comma)-mrelax-relocations=no)
KBUILD_CFLAGS += -include $(srctree)/include/linux/hidden.h
+KBUILD_CFLAGS += $(CLANG_FLAGS)
# sev-es.c indirectly inludes inat-table.h which is generated during
# compilation and stored in $(objtree). Add the directory to the includes so
Re: [PATCH 0/3] Fix CONFIG_FUNCTION_TRACER with clang
On Fri, Mar 26, 2021 at 09:37:55AM +0100, Sedat Dilek wrote: > On Thu, Mar 25, 2021 at 11:38 PM Nathan Chancellor wrote: > > > > Hi all, > > > > This series fixes function tracing with clang. > > > > Patch 1 adjusts the mcount regex in scripts/recordmcount.pl to handle > > the presence of PLT relocations, which happen with clang. Without this, > > the mcount_loc section will not be created properly. > > > > Patch 2 adds a workaround for clang less than 13.0.0 in relation to the > > mcount symbol name, which was "mcount" rather than "_mcount". This was > > written as a separate patch so that it can be reverted when the minimum > > clang version is bumped to clang 13.0.0. > > > > Patch 3 avoids a build error when -fpatchable-function-entry is not > > available, which is the case with clang less than 13.0.0. This will make > > dynamic ftrace unavailable but all of the other function tracing should > > work due to the prescence of the previous patch. > > > > I am hoping this series can go in as fixes for 5.12, due to patch 3, but > > if not, they can always be backported (patches 1 and 2 are already > > marked for stable). > > > > This series has been build tested with gcc-8 through gcc-10 and clang-11 > > through clang-13 with defconfig and nommu_virt_defconfig plus > > CONFIG_FTRACE=y and CONFIG_FUNCTION_TRACER=y then boot tested under > > QEMU. > > > > Cheers, > > Nathan > > > > Nathan Chancellor (3): > > scripts/recordmcount.pl: Fix RISC-V regex for clang > > riscv: Workaround mcount name prior to clang-13 > > riscv: Select HAVE_DYNAMIC_FTRACE when -fpatchable-function-entry is > > available > > > > Does this only fixes stuff for clang + riscv? Yes. > If so, please put a label "riscv" also in the cover-letter. Sure, my apologies for not doing that in the first place, I must have been in a rush with the cover letter. In my defense, I think the titles of my commit messages and the diffstat below make that obvious without the tag :) Cheers, Nathan > - Sedat - > > > arch/riscv/Kconfig | 2 +- > > arch/riscv/include/asm/ftrace.h | 14 -- > > arch/riscv/kernel/mcount.S | 10 +- > > scripts/recordmcount.pl | 2 +- > > 4 files changed, 19 insertions(+), 9 deletions(-) > > > > -- > > 2.31.0 > >
[PATCH 3/3] efi/libstub: Add $(CLANG_FLAGS) to x86 flags
When cross compiling x86 on an ARM machine with clang, there are several
errors along the lines of:
arch/x86/include/asm/page_64.h:52:7: error: invalid output constraint
'=D' in asm
This happens because the x86 flags in the EFI stub are not derived from
KBUILD_CFLAGS like the other architectures are and the clang flags that
set the target architecture ('--target=') and the path to the GNU cross
tools ('--prefix=') are not present, meaning that the host architecture
is targeted.
These flags are available as $(CLANG_FLAGS) from the main Makefile so
add them to the cflags for x86 so that cross compiling works as
expected.
Signed-off-by: Nathan Chancellor
---
drivers/firmware/efi/libstub/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/libstub/Makefile
b/drivers/firmware/efi/libstub/Makefile
index c23466e05e60..d0537573501e 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -13,7 +13,8 @@ cflags-$(CONFIG_X86) += -m$(BITS) -D__KERNEL__ \
-Wno-pointer-sign \
$(call cc-disable-warning,
address-of-packed-member) \
$(call cc-disable-warning, gnu) \
- -fno-asynchronous-unwind-tables
+ -fno-asynchronous-unwind-tables \
+ $(CLANG_FLAGS)
# arm64 uses the full KBUILD_CFLAGS so it's necessary to explicitly
# disable the stackleak plugin
--
2.31.0
[PATCH 2/3] x86/boot: Add $(CLANG_FLAGS) to compressed KBUILD_CFLAGS
When cross compiling x86 on an ARM machine with clang, there are several
errors along the lines of:
arch/x86/include/asm/string_64.h:27:10: error: invalid output constraint
'=' in asm
This happens because the compressed boot Makefile reassigns KBUILD_CFLAGS
and drops the clang flags that set the target architecture ('--target=')
and the path to the GNU cross tools ('--prefix='), meaning that the host
architecture is targeted.
These flags are available as $(CLANG_FLAGS) from the main Makefile so
add them to the compressed boot folder's KBUILD_CFLAGS so that cross
compiling works as expected.
Signed-off-by: Nathan Chancellor
---
arch/x86/boot/compressed/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/boot/compressed/Makefile
b/arch/x86/boot/compressed/Makefile
index e0bc3988c3fa..6e5522aebbbd 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -46,6 +46,7 @@ KBUILD_CFLAGS += -D__DISABLE_EXPORTS
# Disable relocation relaxation in case the link is not PIE.
KBUILD_CFLAGS += $(call as-option,-Wa$(comma)-mrelax-relocations=no)
KBUILD_CFLAGS += -include $(srctree)/include/linux/hidden.h
+KBUILD_CFLAGS += $(CLANG_FLAGS)
# sev-es.c indirectly inludes inat-table.h which is generated during
# compilation and stored in $(objtree). Add the directory to the includes so
--
2.31.0
[PATCH 0/3] Fix cross compiling x86 with clang
Hi all, This series fixes cross compiling x86 with clang, which was initially brought up by John here: https://lore.kernel.org/r/cceb074c-861c-d716-5e19-834a8492f...@gmail.com/ I have picked up that patch and added the same fix in a couple of other places where it is needed. I have tested this on an ARM based server with both defconfig and allmodconfig, where the build now passes. Please let me know if there are any problems. Cheers, Nathan John Millikin (1): x86: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS) Nathan Chancellor (2): x86/boot: Add $(CLANG_FLAGS) to compressed KBUILD_CFLAGS efi/libstub: Add $(CLANG_FLAGS) to x86 flags arch/x86/Makefile | 1 + arch/x86/boot/compressed/Makefile | 1 + drivers/firmware/efi/libstub/Makefile | 3 ++- 3 files changed, 4 insertions(+), 1 deletion(-) base-commit: 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b -- 2.31.0
[PATCH 1/3] x86: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS)
From: John Millikin When cross-compiling with Clang, the `$(CLANG_FLAGS)' variable contains additional flags needed to build C and assembly sources for the target platform. Normally this variable is automatically included in `$(KBUILD_CFLAGS)' by via the top-level Makefile. The x86 real-mode makefile builds `$(REALMODE_CFLAGS)' from a plain assignment and therefore drops the Clang flags. This causes Clang to not recognize x86-specific assembler directives: arch/x86/realmode/rm/header.S:36:1: error: unknown directive .type real_mode_header STT_OBJECT ; .size real_mode_header, .-real_mode_header ^ Explicit propagation of `$(CLANG_FLAGS)' to `$(REALMODE_CFLAGS)', which is inherited by real-mode make rules, fixes cross-compilation with Clang for x86 targets. Relevant flags: * `--target' sets the target architecture when cross-compiling. This flag must be set for both compilation and assembly (`KBUILD_AFLAGS') to support architecture-specific assembler directives. * `-no-integrated-as' tells clang to assemble with GNU Assembler instead of its built-in LLVM assembler. This flag is set by default unless `LLVM_IAS=1' is set, because the LLVM assembler can't yet parse certain GNU extensions. Signed-off-by: John Millikin Tested-by: Sedat Dilek Signed-off-by: Nathan Chancellor --- arch/x86/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 2d6d5a28c3bf..9a73e0cea19c 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -33,6 +33,7 @@ REALMODE_CFLAGS += -ffreestanding REALMODE_CFLAGS += -fno-stack-protector REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -Wno-address-of-packed-member) REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), $(cc_stack_align4)) +REALMODE_CFLAGS += $(CLANG_FLAGS) export REALMODE_CFLAGS # BITS is used as extension for files which are available in a 32 bit -- 2.31.0
[PATCH 3/3] riscv: Select HAVE_DYNAMIC_FTRACE when -fpatchable-function-entry is available
clang prior to 13.0.0 does not support -fpatchable-function-entry for
RISC-V.
clang: error: unsupported option '-fpatchable-function-entry=8' for target
'riscv64-unknown-linux-gnu'
To avoid this error, only select HAVE_DYNAMIC_FTRACE when this option is
not available.
Fixes: afc76b8b8011 ("riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT")
Link: https://github.com/ClangBuiltLinux/linux/issues/1268
Reported-by: kernel test robot
Signed-off-by: Nathan Chancellor
---
arch/riscv/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 87d7b52f278f..ba1d07640b66 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -227,7 +227,7 @@ config ARCH_RV64I
bool "RV64I"
select 64BIT
select ARCH_SUPPORTS_INT128 if CC_HAS_INT128 && GCC_VERSION >= 5
- select HAVE_DYNAMIC_FTRACE if MMU
+ select HAVE_DYNAMIC_FTRACE if MMU &&
$(cc-option,-fpatchable-function-entry=8)
select HAVE_DYNAMIC_FTRACE_WITH_REGS if HAVE_DYNAMIC_FTRACE
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_FUNCTION_GRAPH_TRACER
--
2.31.0
[PATCH 2/3] riscv: Workaround mcount name prior to clang-13
Prior to clang 13.0.0, the RISC-V name for the mcount symbol was
"mcount", which differs from the GCC version of "_mcount", which results
in the following errors:
riscv64-linux-gnu-ld: init/main.o: in function `__traceiter_initcall_level':
main.c:(.text+0xe): undefined reference to `mcount'
riscv64-linux-gnu-ld: init/main.o: in function `__traceiter_initcall_start':
main.c:(.text+0x4e): undefined reference to `mcount'
riscv64-linux-gnu-ld: init/main.o: in function `__traceiter_initcall_finish':
main.c:(.text+0x92): undefined reference to `mcount'
riscv64-linux-gnu-ld: init/main.o: in function `.LBB32_28':
main.c:(.text+0x30c): undefined reference to `mcount'
riscv64-linux-gnu-ld: init/main.o: in function `free_initmem':
main.c:(.text+0x54c): undefined reference to `mcount'
This has been corrected in https://reviews.llvm.org/D98881 but the
minimum supported clang version is 10.0.1. To avoid build errors and to
gain a working function tracer, adjust the name of the mcount symbol for
older versions of clang in mount.S and recordmcount.pl.
Cc: sta...@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1331
Signed-off-by: Nathan Chancellor
---
arch/riscv/include/asm/ftrace.h | 14 --
arch/riscv/kernel/mcount.S | 10 +-
scripts/recordmcount.pl | 2 +-
3 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h
index 845002cc2e57..04dad3380041 100644
--- a/arch/riscv/include/asm/ftrace.h
+++ b/arch/riscv/include/asm/ftrace.h
@@ -13,9 +13,19 @@
#endif
#define HAVE_FUNCTION_GRAPH_RET_ADDR_PTR
+/*
+ * Clang prior to 13 had "mcount" instead of "_mcount":
+ * https://reviews.llvm.org/D98881
+ */
+#if defined(CONFIG_CC_IS_GCC) || CONFIG_CLANG_VERSION >= 13
+#define MCOUNT_NAME _mcount
+#else
+#define MCOUNT_NAME mcount
+#endif
+
#define ARCH_SUPPORTS_FTRACE_OPS 1
#ifndef __ASSEMBLY__
-void _mcount(void);
+void MCOUNT_NAME(void);
static inline unsigned long ftrace_call_adjust(unsigned long addr)
{
return addr;
@@ -36,7 +46,7 @@ struct dyn_arch_ftrace {
* both auipc and jalr at the same time.
*/
-#define MCOUNT_ADDR((unsigned long)_mcount)
+#define MCOUNT_ADDR((unsigned long)MCOUNT_NAME)
#define JALR_SIGN_MASK (0x0800)
#define JALR_OFFSET_MASK (0x0fff)
#define AUIPC_OFFSET_MASK (0xf000)
diff --git a/arch/riscv/kernel/mcount.S b/arch/riscv/kernel/mcount.S
index 8a5593ff9ff3..6d462681c9c0 100644
--- a/arch/riscv/kernel/mcount.S
+++ b/arch/riscv/kernel/mcount.S
@@ -47,8 +47,8 @@
ENTRY(ftrace_stub)
#ifdef CONFIG_DYNAMIC_FTRACE
- .global _mcount
- .set_mcount, ftrace_stub
+ .global MCOUNT_NAME
+ .setMCOUNT_NAME, ftrace_stub
#endif
ret
ENDPROC(ftrace_stub)
@@ -78,7 +78,7 @@ ENDPROC(return_to_handler)
#endif
#ifndef CONFIG_DYNAMIC_FTRACE
-ENTRY(_mcount)
+ENTRY(MCOUNT_NAME)
la t4, ftrace_stub
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
la t0, ftrace_graph_return
@@ -124,6 +124,6 @@ do_trace:
jalrt5
RESTORE_ABI_STATE
ret
-ENDPROC(_mcount)
+ENDPROC(MCOUNT_NAME)
#endif
-EXPORT_SYMBOL(_mcount)
+EXPORT_SYMBOL(MCOUNT_NAME)
diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index a36df04cfa09..7b83a1aaec98 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -392,7 +392,7 @@ if ($arch eq "x86_64") {
$mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\s_mcount\$";
} elsif ($arch eq "riscv") {
$function_regex = "^([0-9a-fA-F]+)\\s+<([^.0-9][0-9a-zA-Z_\\.]+)>:";
-$mcount_regex = "^\\s*([0-9a-fA-F]+):\\sR_RISCV_CALL(_PLT)?\\s_mcount\$";
+$mcount_regex = "^\\s*([0-9a-fA-F]+):\\sR_RISCV_CALL(_PLT)?\\s_?mcount\$";
$type = ".quad";
$alignment = 2;
} elsif ($arch eq "nds32") {
--
2.31.0
[PATCH 1/3] scripts/recordmcount.pl: Fix RISC-V regex for clang
Clang can generate R_RISCV_CALL_PLT relocations to _mcount:
$ llvm-objdump -dr build/riscv/init/main.o | rg mcount
000e: R_RISCV_CALL_PLT _mcount
004e: R_RISCV_CALL_PLT _mcount
After this, the __start_mcount_loc section is properly generated and
function tracing still works.
Cc: sta...@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1331
Signed-off-by: Nathan Chancellor
---
scripts/recordmcount.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index 867860ea57da..a36df04cfa09 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -392,7 +392,7 @@ if ($arch eq "x86_64") {
$mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\s_mcount\$";
} elsif ($arch eq "riscv") {
$function_regex = "^([0-9a-fA-F]+)\\s+<([^.0-9][0-9a-zA-Z_\\.]+)>:";
-$mcount_regex = "^\\s*([0-9a-fA-F]+):\\sR_RISCV_CALL\\s_mcount\$";
+$mcount_regex = "^\\s*([0-9a-fA-F]+):\\sR_RISCV_CALL(_PLT)?\\s_mcount\$";
$type = ".quad";
$alignment = 2;
} elsif ($arch eq "nds32") {
--
2.31.0
[PATCH 0/3] Fix CONFIG_FUNCTION_TRACER with clang
Hi all, This series fixes function tracing with clang. Patch 1 adjusts the mcount regex in scripts/recordmcount.pl to handle the presence of PLT relocations, which happen with clang. Without this, the mcount_loc section will not be created properly. Patch 2 adds a workaround for clang less than 13.0.0 in relation to the mcount symbol name, which was "mcount" rather than "_mcount". This was written as a separate patch so that it can be reverted when the minimum clang version is bumped to clang 13.0.0. Patch 3 avoids a build error when -fpatchable-function-entry is not available, which is the case with clang less than 13.0.0. This will make dynamic ftrace unavailable but all of the other function tracing should work due to the prescence of the previous patch. I am hoping this series can go in as fixes for 5.12, due to patch 3, but if not, they can always be backported (patches 1 and 2 are already marked for stable). This series has been build tested with gcc-8 through gcc-10 and clang-11 through clang-13 with defconfig and nommu_virt_defconfig plus CONFIG_FTRACE=y and CONFIG_FUNCTION_TRACER=y then boot tested under QEMU. Cheers, Nathan Nathan Chancellor (3): scripts/recordmcount.pl: Fix RISC-V regex for clang riscv: Workaround mcount name prior to clang-13 riscv: Select HAVE_DYNAMIC_FTRACE when -fpatchable-function-entry is available arch/riscv/Kconfig | 2 +- arch/riscv/include/asm/ftrace.h | 14 -- arch/riscv/kernel/mcount.S | 10 +- scripts/recordmcount.pl | 2 +- 4 files changed, 19 insertions(+), 9 deletions(-) -- 2.31.0
[PATCH] riscv: Use $(LD) instead of $(CC) to link vDSO
Currently, the VDSO is being linked through $(CC). This does not match
how the rest of the kernel links objects, which is through the $(LD)
variable.
When linking with clang, there are a couple of warnings about flags that
will not be used during the link:
clang-12: warning: argument unused during compilation: '-no-pie'
[-Wunused-command-line-argument]
clang-12: warning: argument unused during compilation: '-pg'
[-Wunused-command-line-argument]
'-no-pie' was added in commit 85602bea297f ("RISC-V: build vdso-dummy.o
with -no-pie") to override '-pie' getting added to the ld command from
distribution versions of GCC that enable PIE by default. It is
technically no longer needed after commit c2c81bb2f691 ("RISC-V: Fix the
VDSO symbol generaton for binutils-2.35+"), which removed vdso-dummy.o
in favor of generating vdso-syms.S from vdso.so with $(NM) but this also
resolves the issue in case it ever comes back due to having full control
over the $(LD) command. '-pg' is for function tracing, it is not used
during linking as clang states.
These flags could be removed/filtered to fix the warnings but it is
easier to just match the rest of the kernel and use $(LD) directly for
linking. See commits
fe00e50b2db8 ("ARM: 8858/1: vdso: use $(LD) instead of $(CC) to link VDSO")
691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO")
2ff906994b6c ("MIPS: VDSO: Use $(LD) instead of $(CC) to link VDSO")
2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO")
for more information.
The flags are converted to linker flags and '--eh-frame-hdr' is added to
match what is added by GCC implicitly, which can be seen by adding '-v'
to GCC's invocation.
Additionally, since this area is being modified, use the $(OBJCOPY)
variable instead of an open coded $(CROSS_COMPILE)objcopy so that the
user's choice of objcopy binary is respected.
Link: https://github.com/ClangBuiltLinux/linux/issues/803
Link: https://github.com/ClangBuiltLinux/linux/issues/970
Signed-off-by: Nathan Chancellor
---
arch/riscv/kernel/vdso/Makefile | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile
index 71a315e73cbe..ca2b40dfd24b 100644
--- a/arch/riscv/kernel/vdso/Makefile
+++ b/arch/riscv/kernel/vdso/Makefile
@@ -41,11 +41,10 @@ KASAN_SANITIZE := n
$(obj)/vdso.o: $(obj)/vdso.so
# link rule for the .so file, .lds has to be first
-SYSCFLAGS_vdso.so.dbg = $(c_flags)
$(obj)/vdso.so.dbg: $(src)/vdso.lds $(obj-vdso) FORCE
$(call if_changed,vdsold)
-SYSCFLAGS_vdso.so.dbg = -shared -s -Wl,-soname=linux-vdso.so.1 \
- -Wl,--build-id=sha1 -Wl,--hash-style=both
+LDFLAGS_vdso.so.dbg = -shared -s -soname=linux-vdso.so.1 \
+ --build-id=sha1 --hash-style=both --eh-frame-hdr
# We also create a special relocatable object that should mirror the symbol
# table and layout of the linked DSO. With ld --just-symbols we can then
@@ -60,13 +59,10 @@ $(obj)/%.so: $(obj)/%.so.dbg FORCE
# actual build commands
# The DSO images are built using a special linker script
-# Add -lgcc so rv32 gets static muldi3 and lshrdi3 definitions.
# Make sure only to export the intended __vdso_xxx symbol offsets.
quiet_cmd_vdsold = VDSOLD $@
- cmd_vdsold = $(CC) $(KBUILD_CFLAGS) $(call cc-option, -no-pie) -nostdlib
-nostartfiles $(SYSCFLAGS_$(@F)) \
- -Wl,-T,$(filter-out FORCE,$^) -o $@.tmp && \
- $(CROSS_COMPILE)objcopy \
- $(patsubst %, -G __vdso_%, $(vdso-syms)) $@.tmp $@
&& \
+ cmd_vdsold = $(LD) $(ld_flags) -T $(filter-out FORCE,$^) -o $@.tmp && \
+ $(OBJCOPY) $(patsubst %, -G __vdso_%, $(vdso-syms)) $@.tmp
$@ && \
rm $@.tmp
# Extracts symbol offsets from the VDSO, converting them into an assembly file
--
2.31.0
Re: [PATCH] arm64: move --fix-cortex-a53-843419 linker test to Kconfig
On Wed, Mar 24, 2021 at 04:11:28PM +0900, Masahiro Yamada wrote: > $(call ld-option, --fix-cortex-a53-843419) in arch/arm64/Makefile is > evaluated every time even for Make targets that do not need the linker, > such as "make ARCH=arm64 install". > > Recently, the Kbuild tree queued up a patch to avoid needless > compiler/linker flag evaluation. I beleive it is a good improvement > itself, but causing a false-positive warning for arm64 installation > in linux-next. (Thanks to Nathan for the report) > > Kconfig can test the linker capability just once, and store it in the > .config file. The build and installation steps that follow do not need > to test the liniker over again. > > Reported-by: Nathan Chancellor > Signed-off-by: Masahiro Yamada Tested-by: Nathan Chancellor Reviewed-by: Nathan Chancellor Thanks for the quick fix! > --- > > I was not sure what the preferred CONFIG option name is. > Please suggest a one if you have a better idea. > > > arch/arm64/Kconfig | 3 +++ > arch/arm64/Makefile | 2 +- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 5656e7aacd69..4a33428de8ac 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -521,6 +521,9 @@ config ARM64_ERRATUM_843419 > > If unsure, say Y. > > +config ARM64_LD_HAS_FIX_ERRATUM_843419 > + def_bool $(ld-option,--fix-cortex-a53-843419) > + > config ARM64_ERRATUM_1024718 > bool "Cortex-A55: 1024718: Update of DBM/AP bits without break before > make might result in incorrect update" > default y > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index 5b84aec31ed3..7ef44478560d 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -21,7 +21,7 @@ LDFLAGS_vmlinux += -shared -Bsymbolic -z notext > \ > endif > > ifeq ($(CONFIG_ARM64_ERRATUM_843419),y) > - ifeq ($(call ld-option, --fix-cortex-a53-843419),) > + ifneq ($(CONFIG_ARM64_LD_HAS_FIX_ERRATUM_843419),y) > $(warning ld does not support --fix-cortex-a53-843419; kernel may be > susceptible to erratum) >else > LDFLAGS_vmlinux += --fix-cortex-a53-843419 > -- > 2.27.0 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v5] x86/Hyper-V: Support for free page reporting
On Tue, Mar 23, 2021 at 06:47:16PM +, Sunil Muthuswamy wrote:
> Linux has support for free page reporting now (36e66c554b5c) for
> virtualized environment. On Hyper-V when virtually backed VMs are
> configured, Hyper-V will advertise cold memory discard capability,
> when supported. This patch adds the support to hook into the free
> page reporting infrastructure and leverage the Hyper-V cold memory
> discard hint hypercall to report/free these pages back to the host.
>
> Signed-off-by: Sunil Muthuswamy
> Tested-by: Matheus Castello
Tested-by: Nathan Chancellor
> ---
> In V2:
> - Addressed feedback comments
> - Added page reporting config option tied to hyper-v balloon config
>
> In V3:
> - Addressed feedback from Vitaly
>
> In V4:
> - Queried and cached the Hyper-V extended capability for the lifetime
> of the VM
> - Addressed feedback from Michael Kelley.
>
> In v5:
> - Added a comment clarifying handling of failed query extended
> capability hypercall to address Michael's feedback.
> ---
> arch/x86/hyperv/hv_init.c | 51 +-
> arch/x86/kernel/cpu/mshyperv.c| 9 ++--
> drivers/hv/Kconfig| 1 +
> drivers/hv/hv_balloon.c | 89 +++
> include/asm-generic/hyperv-tlfs.h | 35 +++-
> include/asm-generic/mshyperv.h| 3 +-
> 6 files changed, 180 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index 9d100257b3af..7c9da3f65afa 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -498,6 +498,8 @@ void __init hyperv_init(void)
> x86_init.irqs.create_pci_msi_domain = hv_create_pci_msi_domain;
> #endif
>
> + /* Query the VMs extended capability once, so that it can be cached. */
> + hv_query_ext_cap(0);
> return;
>
> remove_cpuhp_state:
> @@ -601,7 +603,7 @@ EXPORT_SYMBOL_GPL(hv_is_hibernation_supported);
>
> enum hv_isolation_type hv_get_isolation_type(void)
> {
> - if (!(ms_hyperv.features_b & HV_ISOLATION))
> + if (!(ms_hyperv.priv_high & HV_ISOLATION))
> return HV_ISOLATION_TYPE_NONE;
> return FIELD_GET(HV_ISOLATION_TYPE, ms_hyperv.isolation_config_b);
> }
> @@ -612,3 +614,50 @@ bool hv_is_isolation_supported(void)
> return hv_get_isolation_type() != HV_ISOLATION_TYPE_NONE;
> }
> EXPORT_SYMBOL_GPL(hv_is_isolation_supported);
> +
> +/* Bit mask of the extended capability to query: see HV_EXT_CAPABILITY_xxx */
> +bool hv_query_ext_cap(u64 cap_query)
> +{
> + /*
> + * The address of the 'hv_extended_cap' variable will be used as an
> + * output parameter to the hypercall below and so it should be
> + * compatible with 'virt_to_phys'. Which means, it's address should be
> + * directly mapped. Use 'static' to keep it compatible; stack variables
> + * can be virtually mapped, making them imcompatible with
> + * 'virt_to_phys'.
> + * Hypercall input/output addresses should also be 8-byte aligned.
> + */
> + static u64 hv_extended_cap __aligned(8);
> + static bool hv_extended_cap_queried;
> + u64 status;
> +
> + /*
> + * Querying extended capabilities is an extended hypercall. Check if the
> + * partition supports extended hypercall, first.
> + */
> + if (!(ms_hyperv.priv_high & HV_ENABLE_EXTENDED_HYPERCALLS))
> + return false;
> +
> + /* Extended capabilities do not change at runtime. */
> + if (hv_extended_cap_queried)
> + return hv_extended_cap & cap_query;
> +
> + status = hv_do_hypercall(HV_EXT_CALL_QUERY_CAPABILITIES, NULL,
> + _extended_cap);
> +
> + /*
> + * The query extended capabilities hypercall should not fail under
> + * any normal circumstances. Avoid repeatedly making the hypercall, on
> + * error.
> + */
> + hv_extended_cap_queried = true;
> + status &= HV_HYPERCALL_RESULT_MASK;
> + if (status != HV_STATUS_SUCCESS) {
> + pr_err("Hyper-V: Extended query capabilities hypercall failed
> 0x%llx\n",
> +status);
> + return false;
> + }
> +
> + return hv_extended_cap & cap_query;
> +}
> +EXPORT_SYMBOL_GPL(hv_query_ext_cap);
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index cebed535ec56..3546d3e21787 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -265,12 +265,13 @@ static void __init ms_hyperv_init_platform(void)
>* Extract the features and hints
>
Re: [PATCH] Makefile: fix GDB warning with CONFIG_RELR
On Thu, Mar 18, 2021 at 05:07:06PM -0700, Nick Desaulniers wrote: > GDB produces the following warning when debugging kernels built with > CONFIG_RELR: > > BFD: /android0/linux-next/vmlinux: unknown type [0x13] section `.relr.dyn' > > when loading a kernel built with CONFIG_RELR into GDB. It can also > prevent debugging symbols using such relocations. > > Peter sugguests: > [That flag] means that lld will use dynamic tags and section type > numbers in the OS-specific range rather than the generic range. The > kernel itself doesn't care about these numbers; it determines the > location of the RELR section using symbols defined by a linker script. > > Link: https://github.com/ClangBuiltLinux/linux/issues/1057 > Suggested-by: Peter Collingbourne > Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor > --- > Makefile | 2 +- > scripts/tools-support-relr.sh | 3 ++- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index 5160ff8903c1..47741cb60995 100644 > --- a/Makefile > +++ b/Makefile > @@ -1088,7 +1088,7 @@ LDFLAGS_vmlinux += $(call ld-option, -X,) > endif > > ifeq ($(CONFIG_RELR),y) > -LDFLAGS_vmlinux += --pack-dyn-relocs=relr > +LDFLAGS_vmlinux += --pack-dyn-relocs=relr --use-android-relr-tags > endif > > # We never want expected sections to be placed heuristically by the > diff --git a/scripts/tools-support-relr.sh b/scripts/tools-support-relr.sh > index 45e8aa360b45..cb55878bd5b8 100755 > --- a/scripts/tools-support-relr.sh > +++ b/scripts/tools-support-relr.sh > @@ -7,7 +7,8 @@ trap "rm -f $tmp_file.o $tmp_file $tmp_file.bin" EXIT > cat << "END" | $CC -c -x c - -o $tmp_file.o >/dev/null 2>&1 > void *p = > END > -$LD $tmp_file.o -shared -Bsymbolic --pack-dyn-relocs=relr -o $tmp_file > +$LD $tmp_file.o -shared -Bsymbolic --pack-dyn-relocs=relr \ > + --use-android-relr-tags -o $tmp_file > > # Despite printing an error message, GNU nm still exits with exit code 0 if > it > # sees a relr section. So we need to check that nothing is printed to stderr. > -- > 2.31.0.rc2.261.g7f71774620-goog >
Re: [PATCH] pinctrl: qcom: fix unintentional string concatenation
On Tue, Mar 23, 2021 at 02:17:13PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> clang is clearly correct to point out a typo in a silly
> array of strings:
>
> drivers/pinctrl/qcom/pinctrl-sdx55.c:426:61: error: suspicious concatenation
> of string literals in an array initialization; did you mean to separate the
> elements with a comma? [-Werror,-Wstring-concatenation]
> "gpio14", "gpio15", "gpio16", "gpio17", "gpio18", "gpio19" "gpio20",
> "gpio21", "gpio22",
>^
> Add the missing comma that must have accidentally been removed.
>
> Fixes: ac43c44a7a37 ("pinctrl: qcom: Add SDX55 pincontrol driver")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Nathan Chancellor
> ---
> drivers/pinctrl/qcom/pinctrl-sdx55.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-sdx55.c
> b/drivers/pinctrl/qcom/pinctrl-sdx55.c
> index 2b5b0e2b03ad..5aaf57b40407 100644
> --- a/drivers/pinctrl/qcom/pinctrl-sdx55.c
> +++ b/drivers/pinctrl/qcom/pinctrl-sdx55.c
> @@ -423,7 +423,7 @@ static const char * const gpio_groups[] = {
>
> static const char * const qdss_stm_groups[] = {
> "gpio0", "gpio1", "gpio2", "gpio3", "gpio4", "gpio5", "gpio6", "gpio7",
> "gpio12", "gpio13",
> - "gpio14", "gpio15", "gpio16", "gpio17", "gpio18", "gpio19" "gpio20",
> "gpio21", "gpio22",
> + "gpio14", "gpio15", "gpio16", "gpio17", "gpio18", "gpio19", "gpio20",
> "gpio21", "gpio22",
> "gpio23", "gpio44", "gpio45", "gpio52", "gpio53", "gpio56", "gpio57",
> "gpio61", "gpio62",
> "gpio63", "gpio64", "gpio65", "gpio66",
> };
> --
> 2.29.2
>
Re: [PATCH] clang-format: Update ColumnLimit
On Fri, Mar 19, 2021 at 07:37:14PM +0100, Ansuel Smith wrote: > Update ColumnLimit value, changed from 80 to 100. > > Signed-off-by: Ansuel Smith > --- > .clang-format | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/.clang-format b/.clang-format > index c24b147cac01..3212542df113 100644 > --- a/.clang-format > +++ b/.clang-format > @@ -52,7 +52,7 @@ BreakConstructorInitializersBeforeComma: false > #BreakConstructorInitializers: BeforeComma # Unknown to clang-format-4.0 > BreakAfterJavaFieldAnnotations: false > BreakStringLiterals: false > -ColumnLimit: 80 > +ColumnLimit: 100 > CommentPragmas: '^ IWYU pragma:' > #CompactNamespaces: false # Unknown to clang-format-4.0 > ConstructorInitializerAllOnOneLineOrOnePerLine: false > -- > 2.30.2 > Not sure how opinions have changed since but this has come up before: https://lore.kernel.org/r/20200610125147.2782142-1-christian.brau...@ubuntu.com/ Cheers, Nathan
Re: Clang: powerpc: kvm/book3s_hv_nested.c:264:6: error: stack frame size of 2480 bytes in function 'kvmhv_enter_nested_guest'
Hi Naresh,
Thank you for the testing and report.
On Fri, Mar 19, 2021 at 12:50:42PM +0530, Naresh Kamboju wrote:
> Linux mainline master build breaks for powerpc defconfig.
> There are multiple errors / warnings with clang-12 and clang-11 and 10.
> - powerpc (defconfig) with clang-12
> - powerpc (defconfig) with clang-11
> - powerpc (defconfig) with clang-10
>
> The following build errors / warnings triggered with clang-12.
> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp LLVM=1 ARCH=powerpc
> CROSS_COMPILE=powerpc64le-linux-gnu- 'HOSTCC=sccache clang'
> 'CC=sccache clang'
> /builds/linux/arch/powerpc/kvm/book3s_hv_nested.c:264:6: error: stack
> frame size of 2480 bytes in function 'kvmhv_enter_nested_guest'
> [-Werror,-Wframe-larger-than=]
> long kvmhv_enter_nested_guest(struct kvm_vcpu *vcpu)
> ^
> 1 error generated.
> make[3]: *** [/builds/linux/scripts/Makefile.build:271:
> arch/powerpc/kvm/book3s_hv_nested.o] Error 1
>
> Reported-by: Naresh Kamboju
Yes, unfortunately, this is a clang-12 regression that was exposed by
commit 97e4910232fa ("linux/compiler-clang.h: define HAVE_BUILTIN_BSWAP*")
and it is being tracked on both our GitHub issue tracker and LLVM's
bugzilla:
https://github.com/ClangBuiltLinux/linux/issues/1292
https://bugs.llvm.org/show_bug.cgi?id=49610
Once it has been sorted out, we can potentially work around that by just
raising the limit for that particular file (not sure what the PowerPC
maintainers will want to do).
> The following build errors / warnings triggered with clang-10 and clang-11.
> - powerpc (defconfig) with clang-11
> - powerpc (defconfig) with clang-10
> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp LLVM=1 ARCH=powerpc
> CROSS_COMPILE=powerpc64le-linux-gnu- 'HOSTCC=sccache clang'
> 'CC=sccache clang'
>
> /usr/bin/powerpc64le-linux-gnu-ld:
> arch/powerpc/kernel/vdso32/sigtramp.o: compiled for a little endian
> system and target is big endian
> /usr/bin/powerpc64le-linux-gnu-ld: failed to merge target specific
> data of file arch/powerpc/kernel/vdso32/sigtramp.o
> /usr/bin/powerpc64le-linux-gnu-ld:
> arch/powerpc/kernel/vdso32/gettimeofday.o: compiled for a little
> endian system and target is big endian
> /usr/bin/powerpc64le-linux-gnu-ld: failed to merge target specific
> data of file arch/powerpc/kernel/vdso32/gettimeofday.o
> /usr/bin/powerpc64le-linux-gnu-ld:
> arch/powerpc/kernel/vdso32/datapage.o: compiled for a little endian
> system and target is big endian
> /usr/bin/powerpc64le-linux-gnu-ld: failed to merge target specific
> data of file arch/powerpc/kernel/vdso32/datapage.o
> /usr/bin/powerpc64le-linux-gnu-ld:
> arch/powerpc/kernel/vdso32/cacheflush.o: compiled for a little endian
> system and target is big endian
> /usr/bin/powerpc64le-linux-gnu-ld: failed to merge target specific
> data of file arch/powerpc/kernel/vdso32/cacheflush.o
> /usr/bin/powerpc64le-linux-gnu-ld: arch/powerpc/kernel/vdso32/note.o:
> compiled for a little endian system and target is big endian
> /usr/bin/powerpc64le-linux-gnu-ld: failed to merge target specific
> data of file arch/powerpc/kernel/vdso32/note.o
> /usr/bin/powerpc64le-linux-gnu-ld:
> arch/powerpc/kernel/vdso32/getcpu.o: compiled for a little endian
> system and target is big endian
> /usr/bin/powerpc64le-linux-gnu-ld: failed to merge target specific
> data of file arch/powerpc/kernel/vdso32/getcpu.o
> /usr/bin/powerpc64le-linux-gnu-ld:
> arch/powerpc/kernel/vdso32/vgettimeofday.o: compiled for a little
> endian system and target is big endian
> /usr/bin/powerpc64le-linux-gnu-ld: failed to merge target specific
> data of file arch/powerpc/kernel/vdso32/vgettimeofday.o
> clang: error: unable to execute command: Segmentation fault (core dumped)
> clang: error: linker command failed due to signal (use -v to see invocation)
> make[2]: *** [/builds/linux/arch/powerpc/kernel/vdso32/Makefile:51:
> arch/powerpc/kernel/vdso32/vdso32.so.dbg] Error 254
> make[2]: Target 'include/generated/vdso32-offsets.h' not remade
> because of errors.
>
> Reported-by: Naresh Kamboju
>
> build link,
> https://gitlab.com/Linaro/lkft/mirrors/torvalds/linux-mainline/-/jobs/1110841371#L59
>
This is a deficiency in clang that has been fixed in clang-12:
https://github.com/llvm/llvm-project/commit/0a23fbd28c7509f2f980946091e6055bf27164d2
but tuxmake can resolve it by using a more appropriate CROSS_COMPILE
variable for powerpc64 big-endian (powerpc64-linux-gnu-):
https://gitlab.com/Linaro/tuxmake/-/issues/108
Cheers,
Nathan
Re: [PATCH 4/4] kbuild: include Makefile.compiler only when compiler is required
On Sun, Feb 28, 2021 at 03:10:28PM +0900, Masahiro Yamada wrote:
> Since commit f2f02ebd8f38 ("kbuild: improve cc-option to clean up all
> temporary files"), running 'make kernelversion' in a read-only source
> tree emits a bunch of warnings:
>
> mkdir: cannot create directory '.tmp_12345': Permission denied
>
> Non-build targets such as kernelversion, clean, help, etc. do not
> need to evaluate $(call cc-option,) and friends. Do not include
> Makefile.compiler so $(call cc-option,) becomes no-op.
>
> This not only fix the warnings, but also runs non-build targets much
> faster.
>
> Basically, all installation targets should also be non-build targets.
> Unfortunately, vdso_install requires the compiler because it builds
> vdso before installtion. This is a problem that must be fixed by a
> separate patch.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> I am not adding Reported-by for now because a reporter sent me
> an email privately.
>
> If he allows me to add Reported-by, I will add it to record
> the credit.
>
> (Perhaps, another person might have reported a similar issue
> somewhere, but my memory is obsure. I cannot recall it.)
>
>
> Makefile | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index eec7a94f5c33..20724711dc71 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -263,6 +263,10 @@ no-dot-config-targets := $(clean-targets) \
>$(version_h) headers headers_% archheaders archscripts
> \
>%asm-generic kernelversion %src-pkg dt_binding_check \
>outputmakefile
> +# Installation targets should not require compiler. Unfortunately,
> vdso_install
> +# is an exception where build artifacts may be updated. This must be fixed.
> +no-compiler-targets := $(no-dot-config-targets) install dtbs_install \
> + headers_install modules_install kernelrelease image_name
> no-sync-config-targets := $(no-dot-config-targets) %install kernelrelease \
> image_name
> single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.s %.symtypes %/
> @@ -270,6 +274,7 @@ single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o
> %.s %.symtypes %/
> config-build :=
> mixed-build :=
> need-config := 1
> +need-compiler:= 1
> may-sync-config := 1
> single-build :=
>
> @@ -279,6 +284,12 @@ ifneq ($(filter $(no-dot-config-targets),
> $(MAKECMDGOALS)),)
> endif
> endif
>
> +ifneq ($(filter $(no-compiler-targets), $(MAKECMDGOALS)),)
> + ifeq ($(filter-out $(no-compiler-targets), $(MAKECMDGOALS)),)
> + need-compiler :=
> + endif
> +endif
> +
> ifneq ($(filter $(no-sync-config-targets), $(MAKECMDGOALS)),)
> ifeq ($(filter-out $(no-sync-config-targets), $(MAKECMDGOALS)),)
> may-sync-config :=
> @@ -584,7 +595,9 @@ endif
>
> # Include this also for config targets because some architectures need
> # cc-cross-prefix to determine CROSS_COMPILE.
> +ifdef need-compiler
> include $(srctree)/scripts/Makefile.compiler
> +endif
>
> ifdef config-build
> # ===
> --
> 2.27.0
>
Hi Masahiro,
I see a new warning in my builds on arm64 now when running
'modules_install' or 'dtbs_install' because ld-option evaluates to
nothing, which triggers the warning in arch/arm64/Makefile:
$ make -skj"$(nproc)" \
ARCH=arm64 \
CROSS_COMPILE=aarch64-linux- \
INSTALL_DTBS_PATH=rootfs \
INSTALL_MOD_PATH=rootfs \
O=build/arm64 \
distclean defconfig all modules_install dtbs_install
...
/home/nathan/cbl/src/linux-next/arch/arm64/Makefile:25: ld does not support
--fix-cortex-a53-843419; kernel may be susceptible to erratum
/home/nathan/cbl/src/linux-next/arch/arm64/Makefile:25: ld does not support
--fix-cortex-a53-843419; kernel may be susceptible to erratum
$ sed -n '23,29p' arch/arm64/Makefile
ifeq ($(CONFIG_ARM64_ERRATUM_843419),y)
ifeq ($(call ld-option, --fix-cortex-a53-843419),)
$(warning ld does not support --fix-cortex-a53-843419; kernel may be
susceptible to erratum)
else
LDFLAGS_vmlinux += --fix-cortex-a53-843419
endif
endif
I am not sure how this should be resolved, hence just the report.
Cheers,
Nathan
Re: [PATCH v2 2/2] gcov: clang: drop support for clang-10 and older
On Fri, Mar 12, 2021 at 02:41:32PM -0800, Nick Desaulniers wrote:
> LLVM changed the expected function signatures for llvm_gcda_start_file()
> and llvm_gcda_emit_function() in the clang-11 release. Drop the older
> implementations and require folks to upgrade their compiler if they're
> interested in GCOV support.
>
> Link: https://reviews.llvm.org/rGcdd683b516d147925212724b09ec6fb792a40041
> Link: https://reviews.llvm.org/rG13a633b438b6500ecad9e4f936ebadf3411d0f44
> Suggested-by: Nathan Chancellor
> Signed-off-by: Nick Desaulniers
Reviewed-by: Nathan Chancellor
> ---
> For an easier time reviewing this series, reviewers may want to apply
> these patches, then check the overall diff with `git diff origin/HEAD`.
>
> kernel/gcov/Kconfig | 1 +
> kernel/gcov/clang.c | 85 -
> 2 files changed, 1 insertion(+), 85 deletions(-)
>
> diff --git a/kernel/gcov/Kconfig b/kernel/gcov/Kconfig
> index f62de2dea8a3..58f87a3092f3 100644
> --- a/kernel/gcov/Kconfig
> +++ b/kernel/gcov/Kconfig
> @@ -4,6 +4,7 @@ menu "GCOV-based kernel profiling"
> config GCOV_KERNEL
> bool "Enable gcov-based kernel profiling"
> depends on DEBUG_FS
> + depends on !CC_IS_CLANG || CLANG_VERSION >= 11
> select CONSTRUCTORS
> default n
> help
> diff --git a/kernel/gcov/clang.c b/kernel/gcov/clang.c
> index 8743150db2ac..14de5644b5cc 100644
> --- a/kernel/gcov/clang.c
> +++ b/kernel/gcov/clang.c
> @@ -75,9 +75,6 @@ struct gcov_fn_info {
>
> u32 num_counters;
> u64 *counters;
> -#if CONFIG_CLANG_VERSION < 11
> - const char *function_name;
> -#endif
> };
>
> static struct gcov_info *current_info;
> @@ -107,16 +104,6 @@ void llvm_gcov_init(llvm_gcov_callback writeout,
> llvm_gcov_callback flush)
> }
> EXPORT_SYMBOL(llvm_gcov_init);
>
> -#if CONFIG_CLANG_VERSION < 11
> -void llvm_gcda_start_file(const char *orig_filename, const char version[4],
> - u32 checksum)
> -{
> - current_info->filename = orig_filename;
> - memcpy(_info->version, version, sizeof(current_info->version));
> - current_info->checksum = checksum;
> -}
> -EXPORT_SYMBOL(llvm_gcda_start_file);
> -#else
> void llvm_gcda_start_file(const char *orig_filename, u32 version, u32
> checksum)
> {
> current_info->filename = orig_filename;
> @@ -124,29 +111,7 @@ void llvm_gcda_start_file(const char *orig_filename, u32
> version, u32 checksum)
> current_info->checksum = checksum;
> }
> EXPORT_SYMBOL(llvm_gcda_start_file);
> -#endif
> -
> -#if CONFIG_CLANG_VERSION < 11
> -void llvm_gcda_emit_function(u32 ident, const char *function_name,
> - u32 func_checksum, u8 use_extra_checksum, u32 cfg_checksum)
> -{
> - struct gcov_fn_info *info = kzalloc(sizeof(*info), GFP_KERNEL);
> -
> - if (!info)
> - return;
>
> - INIT_LIST_HEAD(>head);
> - info->ident = ident;
> - info->checksum = func_checksum;
> - info->use_extra_checksum = use_extra_checksum;
> - info->cfg_checksum = cfg_checksum;
> - if (function_name)
> - info->function_name = kstrdup(function_name, GFP_KERNEL);
> -
> - list_add_tail(>head, _info->functions);
> -}
> -EXPORT_SYMBOL(llvm_gcda_emit_function);
> -#else
> void llvm_gcda_emit_function(u32 ident, u32 func_checksum,
> u8 use_extra_checksum, u32 cfg_checksum)
> {
> @@ -163,7 +128,6 @@ void llvm_gcda_emit_function(u32 ident, u32 func_checksum,
> list_add_tail(>head, _info->functions);
> }
> EXPORT_SYMBOL(llvm_gcda_emit_function);
> -#endif
>
> void llvm_gcda_emit_arcs(u32 num_counters, u64 *counters)
> {
> @@ -326,7 +290,6 @@ void gcov_info_add(struct gcov_info *dst, struct
> gcov_info *src)
> }
> }
>
> -#if CONFIG_CLANG_VERSION < 11
> static struct gcov_fn_info *gcov_fn_info_dup(struct gcov_fn_info *fn)
> {
> size_t cv_size; /* counter values size */
> @@ -335,47 +298,15 @@ static struct gcov_fn_info *gcov_fn_info_dup(struct
> gcov_fn_info *fn)
> if (!fn_dup)
> return NULL;
> INIT_LIST_HEAD(_dup->head);
> -
> - fn_dup->function_name = kstrdup(fn->function_name, GFP_KERNEL);
> - if (!fn_dup->function_name)
> - goto err_name;
> -
> - cv_size = fn->num_counters * sizeof(fn->counters[0]);
> - fn_dup->counters = vmalloc(cv_size);
> - if (!fn_dup->counters)
> - goto err_counters;
> - memcpy(fn_dup->counters, fn->counters, cv_size);
> -
Re: [PATCH v2 1/2] gcov: fix clang-11+ support
On Fri, Mar 12, 2021 at 02:41:31PM -0800, Nick Desaulniers wrote:
> LLVM changed the expected function signatures for llvm_gcda_start_file()
> and llvm_gcda_emit_function() in the clang-11 release. Users of clang-11
> or newer may have noticed their kernels failing to boot due to a panic
> when enabling CONFIG_GCOV_KERNEL=y +CONFIG_GCOV_PROFILE_ALL=y. Fix up
> the function signatures so calling these functions doesn't panic the
> kernel.
>
> Link: https://reviews.llvm.org/rGcdd683b516d147925212724b09ec6fb792a40041
> Link: https://reviews.llvm.org/rG13a633b438b6500ecad9e4f936ebadf3411d0f44
> Cc: sta...@vger.kernel.org # 5.4
> Reported-by: Prasad Sodagudi
> Suggested-by: Nathan Chancellor
> Reviewed-by: Fangrui Song
> Signed-off-by: Nick Desaulniers
> Tested-by: Nathan Chancellor
Reviewed-by: Nathan Chancellor
> ---
> Changes V1 -> V2:
> * Use CONFIG_CLANG_VERSION instead of __clang_major__.
> * Pick up and retain Suggested-by, Tested-by, and Reviewed-by tags.
> * Drop note from commit message about `git blame`; I did what was
> sugguested in V1, but it still looks to git like I wrote those
> functions. Oh well.
>
> kernel/gcov/clang.c | 69 +
> 1 file changed, 69 insertions(+)
>
> diff --git a/kernel/gcov/clang.c b/kernel/gcov/clang.c
> index c94b820a1b62..8743150db2ac 100644
> --- a/kernel/gcov/clang.c
> +++ b/kernel/gcov/clang.c
> @@ -75,7 +75,9 @@ struct gcov_fn_info {
>
> u32 num_counters;
> u64 *counters;
> +#if CONFIG_CLANG_VERSION < 11
> const char *function_name;
> +#endif
> };
>
> static struct gcov_info *current_info;
> @@ -105,6 +107,7 @@ void llvm_gcov_init(llvm_gcov_callback writeout,
> llvm_gcov_callback flush)
> }
> EXPORT_SYMBOL(llvm_gcov_init);
>
> +#if CONFIG_CLANG_VERSION < 11
> void llvm_gcda_start_file(const char *orig_filename, const char version[4],
> u32 checksum)
> {
> @@ -113,7 +116,17 @@ void llvm_gcda_start_file(const char *orig_filename,
> const char version[4],
> current_info->checksum = checksum;
> }
> EXPORT_SYMBOL(llvm_gcda_start_file);
> +#else
> +void llvm_gcda_start_file(const char *orig_filename, u32 version, u32
> checksum)
> +{
> + current_info->filename = orig_filename;
> + current_info->version = version;
> + current_info->checksum = checksum;
> +}
> +EXPORT_SYMBOL(llvm_gcda_start_file);
> +#endif
>
> +#if CONFIG_CLANG_VERSION < 11
> void llvm_gcda_emit_function(u32 ident, const char *function_name,
> u32 func_checksum, u8 use_extra_checksum, u32 cfg_checksum)
> {
> @@ -133,6 +146,24 @@ void llvm_gcda_emit_function(u32 ident, const char
> *function_name,
> list_add_tail(>head, _info->functions);
> }
> EXPORT_SYMBOL(llvm_gcda_emit_function);
> +#else
> +void llvm_gcda_emit_function(u32 ident, u32 func_checksum,
> + u8 use_extra_checksum, u32 cfg_checksum)
> +{
> + struct gcov_fn_info *info = kzalloc(sizeof(*info), GFP_KERNEL);
> +
> + if (!info)
> + return;
> +
> + INIT_LIST_HEAD(>head);
> + info->ident = ident;
> + info->checksum = func_checksum;
> + info->use_extra_checksum = use_extra_checksum;
> + info->cfg_checksum = cfg_checksum;
> + list_add_tail(>head, _info->functions);
> +}
> +EXPORT_SYMBOL(llvm_gcda_emit_function);
> +#endif
>
> void llvm_gcda_emit_arcs(u32 num_counters, u64 *counters)
> {
> @@ -295,6 +326,7 @@ void gcov_info_add(struct gcov_info *dst, struct
> gcov_info *src)
> }
> }
>
> +#if CONFIG_CLANG_VERSION < 11
> static struct gcov_fn_info *gcov_fn_info_dup(struct gcov_fn_info *fn)
> {
> size_t cv_size; /* counter values size */
> @@ -322,6 +354,28 @@ static struct gcov_fn_info *gcov_fn_info_dup(struct
> gcov_fn_info *fn)
> kfree(fn_dup);
> return NULL;
> }
> +#else
> +static struct gcov_fn_info *gcov_fn_info_dup(struct gcov_fn_info *fn)
> +{
> + size_t cv_size; /* counter values size */
> + struct gcov_fn_info *fn_dup = kmemdup(fn, sizeof(*fn),
> + GFP_KERNEL);
> + if (!fn_dup)
> + return NULL;
> + INIT_LIST_HEAD(_dup->head);
> +
> + cv_size = fn->num_counters * sizeof(fn->counters[0]);
> + fn_dup->counters = vmalloc(cv_size);
> + if (!fn_dup->counters) {
> + kfree(fn_dup);
> + return NULL;
> + }
> +
> + memcpy(fn_dup->counters, fn->counters, cv_size);
> +
> + return fn_dup;
> +}
> +#endif
>
> /**
> * gcov_info_dup - du
Re: [PATCH v2 2/3] kbuild: check the minimum assembler version in Kconfig
On Tue, Mar 16, 2021 at 01:12:56AM +0900, Masahiro Yamada wrote:
> Documentation/process/changes.rst defines the minimum assembler version
> (binutils version), but we have never checked it in the build time.
>
> Kbuild never invokes 'as' directly because all assembly files in the
> kernel tree are *.S, hence must be preprocessed. I do not expect
> raw assembly source files (*.s) would be added to the kernel tree.
>
> Therefore, we always use $(CC) as the assembler driver, and commit
> aa824e0c962b ("kbuild: remove AS variable") removed 'AS'. However,
> we are still interested in the version of the assembler acting behind.
>
> As usual, the --version option prints the version string.
>
> $ as --version | head -n 1
> GNU assembler (GNU Binutils for Ubuntu) 2.35.1
>
> But, we do not have $(AS). So, we can add the -Wa prefix so that
> $(CC) passes --version down to the backing assembler.
>
> $ gcc -Wa,--version | head -n 1
> gcc: fatal error: no input files
> compilation terminated.
>
> OK, we need to input something to satisfy gcc.
>
> $ gcc -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
> GNU assembler (GNU Binutils for Ubuntu) 2.35.1
>
> The combination of Clang and GNU assembler works in the same way:
>
> $ clang -no-integrated-as -Wa,--version -c -x assembler /dev/null -o
> /dev/null | head -n 1
> GNU assembler (GNU Binutils for Ubuntu) 2.35.1
>
> Clang with the integrated assembler fails like this:
>
> $ clang -integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null
> | head -n 1
> clang: error: unsupported argument '--version' to option 'Wa,'
>
> For the last case, checking the error message is fragile. If the
> proposal for -Wa,--version support [1] is accepted, this may not be
> even an error in the future.
>
> One easy way is to check if -integrated-as is present in the passed
> arguments. We did not pass -integrated-as to CLANG_FLAGS before, but
> we can make it explicit.
>
> Nathan pointed out -integrated-as is the default for all of the
> architectures/targets that the kernel cares about, but it goes
> along with "explicit is better than implicit" policy. [2]
>
> With all this in my mind, I implemented scripts/as-version.sh to
> check the assembler version in Kconfig time.
>
> $ scripts/as-version.sh gcc
> GNU 23501
> $ scripts/as-version.sh clang -no-integrated-as
> GNU 23501
> $ scripts/as-version.sh clang -integrated-as
> LLVM 0
>
> [1]: https://github.com/ClangBuiltLinux/linux/issues/1320
> [2]:
> https://lore.kernel.org/linux-kbuild/20210307044253.v3h47ucq6ng25iay@archlinux-ax161/
>
> Signed-off-by: Masahiro Yamada
Reviewed-by: Nathan Chancellor
> ---
>
> Changes in v2:
> - Check -integrated-as option instead of error message.
> - Add LC_ALL=C just in case.
>
> The Italian locale did not tweak the message from 'as --version'
> but we never know what would happen on locale.
>
> $ LC_MESSAGES=it_IT.UTF-8 ld --version | head -n 1
> ld di GNU (GNU Binutils for Debian) 2.35.2
> $ LC_MESSAGES=it_IT.UTF-8 as --version | head -n 1
> GNU assembler (GNU Binutils for Debian) 2.35.2
>
> Makefile| 4 +-
> arch/Kconfig| 3 +-
> init/Kconfig| 12 ++
> scripts/Kconfig.include | 6 +++
> scripts/as-version.sh | 82 +
> 5 files changed, 104 insertions(+), 3 deletions(-)
> create mode 100755 scripts/as-version.sh
>
> diff --git a/Makefile b/Makefile
> index cc5b7e39fde4..2b161f5a5a66 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -580,7 +580,9 @@ ifneq ($(findstring clang,$(CC_VERSION_TEXT)),)
> ifneq ($(CROSS_COMPILE),)
> CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%))
> endif
> -ifneq ($(LLVM_IAS),1)
> +ifeq ($(LLVM_IAS),1)
> +CLANG_FLAGS += -integrated-as
> +else
> CLANG_FLAGS += -no-integrated-as
> GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
> CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
> diff --git a/arch/Kconfig b/arch/Kconfig
> index ecfd3520b676..555b4f09a9b2 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -631,8 +631,7 @@ config ARCH_SUPPORTS_LTO_CLANG_THIN
> config HAS_LTO_CLANG
> def_bool y
> # Clang >= 11: https://github.com/ClangBuiltLinux/linux/issues/510
> - depends on CC_IS_CLANG && CLANG_VERSION >= 11 && LD_IS_LLD
> - depends on $(success,test $(LLVM_IAS) -eq 1)
> + depends on CC_IS_CLANG && CLANG_VERSION >= 11 && LD_IS_LLD &&
> AS_IS_LLVM
> depends on $(success,$(NM) --
Re: [PATCH] staging: andriod: ashmem: Declared file operation with const keyword
On Sat, Mar 13, 2021 at 10:59:43PM +0530, B K Karthik wrote: > On Sat, Mar 13, 2021 at 10:57 PM namratajanawade > wrote: > > > > Warning found by checkpatch.pl script. > > That doesn't tell what you did or why you did it. Please write an > appropriate commit description and resend the patch. > > karthik This patch will not even build, it has been sent several times before... https://lore.kernel.org/r/2020101605.1947-1-kirank.su...@gmail.com/ https://lore.kernel.org/r/20200328151523.17516-1-sandeshkenjanaas...@gmail.com/ https://lore.kernel.org/r/20201128121627.GA27317@worker-node1/ https://lore.kernel.org/r/20201227112645.256943-1-senguptaangshuma...@gmail.com/ https://lore.kernel.org/r/20201228051301.14983-1-jovin...@gmail.com/ https://lore.kernel.org/r/20210214023136.8916-1-thaiscamac...@gmail.com/ https://lore.kernel.org/r/20210219101338.2670-1-amritkher...@gmail.com/ https://lore.kernel.org/r/20210306063817.674041-1-nabil.ibn.mah...@gmail.com/ I once considered adding a comment above it saying that it should not be marked const but it is a good benchmark for seeing if people compile their patches before sending them out. Cheers, Nathan
Re: [PATCH] gcov: fix clang-11+ support
On Fri, Mar 12, 2021 at 01:57:47PM -0800, 'Nick Desaulniers' via Clang Built
Linux wrote:
> On Fri, Mar 12, 2021 at 12:51 PM Nathan Chancellor wrote:
> >
> > On Fri, Mar 12, 2021 at 12:14:42PM -0800, Nick Desaulniers wrote:
> > > On Fri, Mar 12, 2021 at 11:58 AM Nathan Chancellor
> > > wrote:
> > > >
> > > > On Fri, Mar 12, 2021 at 11:21:39AM -0800, Nick Desaulniers wrote:
> > > > > LLVM changed the expected function signatures for
> > > > > llvm_gcda_start_file()
> > > > > and llvm_gcda_emit_function() in the clang-11 release. Users of
> > > > > clang-11
> > > > > or newer may have noticed their kernels failing to boot due to a panic
> > > > > when enabling CONFIG_GCOV_KERNEL=y +CONFIG_GCOV_PROFILE_ALL=y. Fix up
> > > > > the function signatures so calling these functions doesn't panic the
> > > > > kernel.
> > > > >
> > > > > When we drop clang-10 support from the kernel, we should carefully
> > > > > update the original implementations to try to preserve git blame,
> > > > > deleting these implementations.
> > > > >
> > > > > Link:
> > > > > https://reviews.llvm.org/rGcdd683b516d147925212724b09ec6fb792a40041
> > > > > Link:
> > > > > https://reviews.llvm.org/rG13a633b438b6500ecad9e4f936ebadf3411d0f44
> > > > > Cc: Fangrui Song
> > > > > Reported-by: Prasad Sodagudi
> > > > > Signed-off-by: Nick Desaulniers
> > > >
> > > > I can reproduce the panic (as a boot hang) in QEMU before this patch and
> > > > it is resolved after it so:
> > > >
> > > > Tested-by: Nathan Chancellor
> > > >
> > > > However, the duplication hurts :( would it potentially be better to just
> > > > do the full update to clang-11+ and require it for CONFIG_GCOV_KERNEL?
> > > >
> > > > depends on CC_IS_GCC || CLANG_VERSION >= 11?
> > >
> > > I'm not opposed, and value your input on the matter. Either way, this
> > > will need to be back ported to stable. Should we be concerned with
> > > users of stable's branches before we mandated clang-10 as the minimum
> > > supported version?
> > >
> > > commit 1f7a44f63e6c ("compiler-clang: add build check for clang 10.0.1")
> > >
> > > first landed in v5.10-rc1. Does not exist in v5.4.y. The diff you
> >
> > Hmmm fair point, I did not realize that this support had landed in 5.2
> > meaning that 5.4 needs it as well at 5.10.
> >
> > > suggest is certainly easier to review to observe the differences, and
> > > I we don't have users of the latest Android or CrOS kernels using
> > > older clang, but I suspect there may be older kernel versions where if
> > > they try to upgrade their version of clang, GCOV support will regress
> > > for them. Though, I guess that's fine since either approach will fix
> > > this for them. I guess if they don't want to upgrade from clang-10 say
> > > for example, then this approach can be backported to stable.
> >
> > If people are happy with this approach, it is the more "stable friendly"
> > change because it fixes it for all versions of clang that should have
> > been supported at their respective times. Maybe it is worthwhile to do
> > both? This change gets picked up with a Cc: sta...@vger.kernel.org then
> > in a follow up patch, we remove the #ifdef's and gate GCOV on clang-11?
> > The CLANG_VERSION string is usually what we will search for when
> > removing old workarounds.
>
> Sounds like we're on the same page; will send a v2 with your
> recommendation on top.
>
> > Additionally, your patch could just use
> >
> > #if CLANG_VERSION <= 11
> >
> > to more easily see this. I have no strong opinion one way or the other
> > though. If people are happy with this approach, let's do it.
>
> Err that would be nicer, but:
> kernel/gcov/clang.c:78:5: warning: 'CLANG_VERSION' is not defined,
> evaluates to 0 [-Wundef]
> #if CLANG_VERSION < 11
> ^
> kernel/gcov/clang.c:110:5: warning: 'CLANG_VERSION' is not defined,
> evaluates to 0 [-Wundef]
> #if CLANG_VERSION < 11
> ^
> kernel/gcov/clang.c:130:5: warning: 'CLANG_VERSION' is not defined,
> evaluates to 0 [-Wundef]
> #if CLANG_VERSION < 11
> ^
> kernel/gcov/clang.c:330:5: warning: 'CLANG_VERSION' is not defined,
> evaluates to 0 [-Wundef]
> #if CLA
Re: [PATCH] gcov: fix clang-11+ support
On Fri, Mar 12, 2021 at 12:14:42PM -0800, Nick Desaulniers wrote:
> On Fri, Mar 12, 2021 at 11:58 AM Nathan Chancellor wrote:
> >
> > On Fri, Mar 12, 2021 at 11:21:39AM -0800, Nick Desaulniers wrote:
> > > LLVM changed the expected function signatures for llvm_gcda_start_file()
> > > and llvm_gcda_emit_function() in the clang-11 release. Users of clang-11
> > > or newer may have noticed their kernels failing to boot due to a panic
> > > when enabling CONFIG_GCOV_KERNEL=y +CONFIG_GCOV_PROFILE_ALL=y. Fix up
> > > the function signatures so calling these functions doesn't panic the
> > > kernel.
> > >
> > > When we drop clang-10 support from the kernel, we should carefully
> > > update the original implementations to try to preserve git blame,
> > > deleting these implementations.
> > >
> > > Link: https://reviews.llvm.org/rGcdd683b516d147925212724b09ec6fb792a40041
> > > Link: https://reviews.llvm.org/rG13a633b438b6500ecad9e4f936ebadf3411d0f44
> > > Cc: Fangrui Song
> > > Reported-by: Prasad Sodagudi
> > > Signed-off-by: Nick Desaulniers
> >
> > I can reproduce the panic (as a boot hang) in QEMU before this patch and
> > it is resolved after it so:
> >
> > Tested-by: Nathan Chancellor
> >
> > However, the duplication hurts :( would it potentially be better to just
> > do the full update to clang-11+ and require it for CONFIG_GCOV_KERNEL?
> >
> > depends on CC_IS_GCC || CLANG_VERSION >= 11?
>
> I'm not opposed, and value your input on the matter. Either way, this
> will need to be back ported to stable. Should we be concerned with
> users of stable's branches before we mandated clang-10 as the minimum
> supported version?
>
> commit 1f7a44f63e6c ("compiler-clang: add build check for clang 10.0.1")
>
> first landed in v5.10-rc1. Does not exist in v5.4.y. The diff you
Hmmm fair point, I did not realize that this support had landed in 5.2
meaning that 5.4 needs it as well at 5.10.
> suggest is certainly easier to review to observe the differences, and
> I we don't have users of the latest Android or CrOS kernels using
> older clang, but I suspect there may be older kernel versions where if
> they try to upgrade their version of clang, GCOV support will regress
> for them. Though, I guess that's fine since either approach will fix
> this for them. I guess if they don't want to upgrade from clang-10 say
> for example, then this approach can be backported to stable.
If people are happy with this approach, it is the more "stable friendly"
change because it fixes it for all versions of clang that should have
been supported at their respective times. Maybe it is worthwhile to do
both? This change gets picked up with a Cc: sta...@vger.kernel.org then
in a follow up patch, we remove the #ifdef's and gate GCOV on clang-11?
The CLANG_VERSION string is usually what we will search for when
removing old workarounds. Additionally, your patch could just use
#if CLANG_VERSION <= 11
to more easily see this. I have no strong opinion one way or the other
though. If people are happy with this approach, let's do it.
Cheers,
Nathan
> >
> > > ---
> > > kernel/gcov/clang.c | 69 +
> > > 1 file changed, 69 insertions(+)
> > >
> > > diff --git a/kernel/gcov/clang.c b/kernel/gcov/clang.c
> > > index c94b820a1b62..20e6760ec05d 100644
> > > --- a/kernel/gcov/clang.c
> > > +++ b/kernel/gcov/clang.c
> > > @@ -75,7 +75,9 @@ struct gcov_fn_info {
> > >
> > > u32 num_counters;
> > > u64 *counters;
> > > +#if __clang_major__ < 11
> > > const char *function_name;
> > > +#endif
> > > };
> > >
> > > static struct gcov_info *current_info;
> > > @@ -105,6 +107,7 @@ void llvm_gcov_init(llvm_gcov_callback writeout,
> > > llvm_gcov_callback flush)
> > > }
> > > EXPORT_SYMBOL(llvm_gcov_init);
> > >
> > > +#if __clang_major__ < 11
> > > void llvm_gcda_start_file(const char *orig_filename, const char
> > > version[4],
> > > u32 checksum)
> > > {
> > > @@ -113,7 +116,17 @@ void llvm_gcda_start_file(const char *orig_filename,
> > > const char version[4],
> > > current_info->checksum = checksum;
> > > }
> > > EXPORT_SYMBOL(llvm_gcda_start_file);
> > > +#else
> > > +void llvm_gcda_start_file(const char *orig_filename, u32 version, u32
> > > checksum)
> > > +{
> > > + current_info->filen
Re: [PATCH] gcov: fix clang-11+ support
On Fri, Mar 12, 2021 at 11:21:39AM -0800, Nick Desaulniers wrote:
> LLVM changed the expected function signatures for llvm_gcda_start_file()
> and llvm_gcda_emit_function() in the clang-11 release. Users of clang-11
> or newer may have noticed their kernels failing to boot due to a panic
> when enabling CONFIG_GCOV_KERNEL=y +CONFIG_GCOV_PROFILE_ALL=y. Fix up
> the function signatures so calling these functions doesn't panic the
> kernel.
>
> When we drop clang-10 support from the kernel, we should carefully
> update the original implementations to try to preserve git blame,
> deleting these implementations.
>
> Link: https://reviews.llvm.org/rGcdd683b516d147925212724b09ec6fb792a40041
> Link: https://reviews.llvm.org/rG13a633b438b6500ecad9e4f936ebadf3411d0f44
> Cc: Fangrui Song
> Reported-by: Prasad Sodagudi
> Signed-off-by: Nick Desaulniers
I can reproduce the panic (as a boot hang) in QEMU before this patch and
it is resolved after it so:
Tested-by: Nathan Chancellor
However, the duplication hurts :( would it potentially be better to just
do the full update to clang-11+ and require it for CONFIG_GCOV_KERNEL?
depends on CC_IS_GCC || CLANG_VERSION >= 11?
> ---
> kernel/gcov/clang.c | 69 +
> 1 file changed, 69 insertions(+)
>
> diff --git a/kernel/gcov/clang.c b/kernel/gcov/clang.c
> index c94b820a1b62..20e6760ec05d 100644
> --- a/kernel/gcov/clang.c
> +++ b/kernel/gcov/clang.c
> @@ -75,7 +75,9 @@ struct gcov_fn_info {
>
> u32 num_counters;
> u64 *counters;
> +#if __clang_major__ < 11
> const char *function_name;
> +#endif
> };
>
> static struct gcov_info *current_info;
> @@ -105,6 +107,7 @@ void llvm_gcov_init(llvm_gcov_callback writeout,
> llvm_gcov_callback flush)
> }
> EXPORT_SYMBOL(llvm_gcov_init);
>
> +#if __clang_major__ < 11
> void llvm_gcda_start_file(const char *orig_filename, const char version[4],
> u32 checksum)
> {
> @@ -113,7 +116,17 @@ void llvm_gcda_start_file(const char *orig_filename,
> const char version[4],
> current_info->checksum = checksum;
> }
> EXPORT_SYMBOL(llvm_gcda_start_file);
> +#else
> +void llvm_gcda_start_file(const char *orig_filename, u32 version, u32
> checksum)
> +{
> + current_info->filename = orig_filename;
> + current_info->version = version;
> + current_info->checksum = checksum;
> +}
> +EXPORT_SYMBOL(llvm_gcda_start_file);
> +#endif
>
> +#if __clang_major__ < 11
> void llvm_gcda_emit_function(u32 ident, const char *function_name,
> u32 func_checksum, u8 use_extra_checksum, u32 cfg_checksum)
> {
> @@ -133,6 +146,24 @@ void llvm_gcda_emit_function(u32 ident, const char
> *function_name,
> list_add_tail(>head, _info->functions);
> }
> EXPORT_SYMBOL(llvm_gcda_emit_function);
> +#else
> +void llvm_gcda_emit_function(u32 ident, u32 func_checksum,
> + u8 use_extra_checksum, u32 cfg_checksum)
> +{
> + struct gcov_fn_info *info = kzalloc(sizeof(*info), GFP_KERNEL);
> +
> + if (!info)
> + return;
> +
> + INIT_LIST_HEAD(>head);
> + info->ident = ident;
> + info->checksum = func_checksum;
> + info->use_extra_checksum = use_extra_checksum;
> + info->cfg_checksum = cfg_checksum;
> + list_add_tail(>head, _info->functions);
> +}
> +EXPORT_SYMBOL(llvm_gcda_emit_function);
> +#endif
>
> void llvm_gcda_emit_arcs(u32 num_counters, u64 *counters)
> {
> @@ -295,6 +326,7 @@ void gcov_info_add(struct gcov_info *dst, struct
> gcov_info *src)
> }
> }
>
> +#if __clang_major__ < 11
> static struct gcov_fn_info *gcov_fn_info_dup(struct gcov_fn_info *fn)
> {
> size_t cv_size; /* counter values size */
> @@ -322,6 +354,28 @@ static struct gcov_fn_info *gcov_fn_info_dup(struct
> gcov_fn_info *fn)
> kfree(fn_dup);
> return NULL;
> }
> +#else
> +static struct gcov_fn_info *gcov_fn_info_dup(struct gcov_fn_info *fn)
> +{
> + size_t cv_size; /* counter values size */
> + struct gcov_fn_info *fn_dup = kmemdup(fn, sizeof(*fn),
> + GFP_KERNEL);
> + if (!fn_dup)
> + return NULL;
> + INIT_LIST_HEAD(_dup->head);
> +
> + cv_size = fn->num_counters * sizeof(fn->counters[0]);
> + fn_dup->counters = vmalloc(cv_size);
> + if (!fn_dup->counters) {
> + kfree(fn_dup);
> + return NULL;
> + }
> +
> + memcpy(fn_dup->counters, fn->counters, cv_size);
> +
> + return fn_dup;
> +}
> +#endif
>
> /**
> * gcov_info_dup - duplic
Re: [PATCH] kbuild: fix ld-version.sh to not be affected by locale
On Sat, Mar 13, 2021 at 04:38:14AM +0900, Masahiro Yamada wrote:
> ld-version.sh checks the output from $(LD) --version, but it has a
> problem on some locales.
>
> For example, in Italian:
>
> $ LC_MESSAGES=it_IT.UTF-8 ld --version | head -n 1
> ld di GNU (GNU Binutils for Debian) 2.35.2
>
> This makes ld-version.sh fail because it expects "GNU ld" for the
> BFD linker case.
>
> Add LC_ALL=C to override the user's locale.
>
> BTW, setting LC_MESSAGES=C (or LANG=C) is not enough because it is
> ineffective if LC_ALL is set on the user's environment.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=212105
> Reported-by: Marco Scardovi
> Signed-off-by: Masahiro Yamada
LGTM, this is Debian's recommendation as well:
https://wiki.debian.org/Locale
Reviewed-by: Nathan Chancellor
> ---
>
> scripts/ld-version.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
> index 30debf78aa09..1bf3aadde9de 100755
> --- a/scripts/ld-version.sh
> +++ b/scripts/ld-version.sh
> @@ -29,7 +29,7 @@ orig_args="$@"
> # Get the first line of the --version output.
> IFS='
> '
> -set -- $("$@" --version)
> +set -- $(LC_ALL=C "$@" --version)
>
> # Split the line on spaces.
> IFS=' '
> --
> 2.27.0
>
[PATCH] ARM: Make UNWINDER_ARM depend on ld.bfd or ld.lld 11.0.0+
When linking aspeed_g5_defconfig with ld.lld 10.0.1, the following error occurs: ld.lld: error: .tmp_vmlinux.kallsyms1:(.ARM.exidx+0x34D98): relocation R_ARM_PREL31 out of range: 2135538592 is not in [-1073741824, 1073741823] This was resolved in ld.lld 11.0.0 but the minimum supported version of ld.lld for the kernel is 10.0.1. Prevent CONFIG_UNWINDER_ARM from being selected in this case so that the problematic sections cannot be created. Link: https://github.com/ClangBuiltLinux/linux/issues/732 Link: https://github.com/llvm/llvm-project/commit/48aebfc908ba7b9372aaa478a9c200789491096e Suggested-by: Nick Desaulniers Signed-off-by: Nathan Chancellor --- arch/arm/Kconfig.debug | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 9e0b5e7f12af..64c1f8a46ab5 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -66,6 +66,8 @@ config UNWINDER_FRAME_POINTER config UNWINDER_ARM bool "ARM EABI stack unwinder" depends on AEABI && !FUNCTION_GRAPH_TRACER + # https://github.com/ClangBuiltLinux/linux/issues/732 + depends on !LD_IS_LLD || LLD_VERSION >= 11 select ARM_UNWIND help This option enables stack unwinding support in the kernel base-commit: a38fd8748464831584a19438cbb3082b5a2dab15 -- 2.31.0.rc1
Re: -Walign-mismatch in block/blk-mq.c
On Wed, Mar 10, 2021 at 02:03:56PM -0700, Jens Axboe wrote:
> On 3/10/21 1:52 PM, Nathan Chancellor wrote:
> > On Wed, Mar 10, 2021 at 01:40:25PM -0700, Jens Axboe wrote:
> >> On 3/10/21 1:33 PM, Nathan Chancellor wrote:
> >>> On Wed, Mar 10, 2021 at 01:21:52PM -0700, Jens Axboe wrote:
> >>>> On 3/10/21 11:23 AM, Nathan Chancellor wrote:
> >>>>> Hi Jens,
> >>>>>
> >>>>> There is a new clang warning added in the development branch,
> >>>>> -Walign-mismatch, which shows an instance in block/blk-mq.c:
> >>>>>
> >>>>> block/blk-mq.c:630:39: warning: passing 8-byte aligned argument to
> >>>>> 32-byte aligned parameter 2 of 'smp_call_function_single_async' may
> >>>>> result in an unaligned pointer access [-Walign-mismatch]
> >>>>> smp_call_function_single_async(cpu, >csd);
> >>>>> ^
> >>>>> 1 warning generated.
> >>>>>
> >>>>> There appears to be some history here as I can see that this member was
> >>>>> purposefully unaligned in commit 4ccafe032005 ("block: unalign
> >>>>> call_single_data in struct request"). However, I later see a change in
> >>>>> commit 7c3fb70f0341 ("block: rearrange a few request fields for better
> >>>>> cache layout") that seems somewhat related. Is it possible to get back
> >>>>> the alignment by rearranging the structure again? This seems to be the
> >>>>> only solution for the warning aside from just outright disabling it,
> >>>>> which would be a shame since it seems like it could be useful for
> >>>>> architectures that cannot handle unaligned accesses well, unless I am
> >>>>> missing something obvious :)
> >>>>
> >>>> It should not be hard to ensure that alignment without re-introducing
> >>>> the bloat. Is there some background on why 32-byte alignment is
> >>>> required?
> >>>>
> >>>
> >>> This alignment requirement was introduced in commit 966a967116e6 ("smp:
> >>> Avoid using two cache lines for struct call_single_data") and it looks
> >>> like there was a thread between you and Peter Zijlstra that has some
> >>> more information on this:
> >>> https://lore.kernel.org/r/a9beb452-7344-9e2d-fc80-094d8f5a0...@kernel.dk/
> >>
> >> Ah now I remember - so it's not that it _needs_ to be 32-byte aligned,
> >> it's just a handy way to ensure that it doesn't straddle two cachelines.
> >> In fact, there's no real alignment concern, outside of performance
> >> reasons we don't want it touching two cachelines.
> >>
> >> So... what exactly is your concern? Just silencing that warning? Because
> >
> > Yes, dealing with the warning in some way is my only motivation. My
> > apologies, I should have led with that. I had assumed that this would
> > potentially be an issue due to the warning's text and that rearranging
> > the structure might allow the alignment to be added back but if there is
> > not actually a problem, then the warning should be silenced in some way.
>
> Right, that's what I was getting at, but I needed to page that context
> back in, it had long since been purged :-)
>
> > I am not sure if there is a preferred way to silence it (CFLAGS_... or
> > some of the __diag() infrastructure in include/linux/compiler_types.h).
>
> That's a good question, I'm not sure what the best approach here would
> be. Funnily enough, on my build, it just so happens to be 32-byte
> aligned anyway, but that's by mere chance.
As far as I can tell, there are two options.
1. Objectively smallest option is to just disable -Walign-mismatch for
the whole translation unit. The benefit of this route is one small
and simple patch. The downside is that if there are any more
instances of this added in the future, they won't be caught. May or
may not actually happen or be a big deal.
diff --git a/block/Makefile b/block/Makefile
index 8d841f5f986f..432d0329fb58 100644
--- a/block/Makefile
+++ b/block/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_BLOCK) := bio.o elevator.o blk-core.o blk-sysfs.o \
blk-lib.o blk-mq.o blk-mq-tag.o blk-stat.o \
blk-mq-sysfs.o blk-mq-cpumap.o blk-mq-sched.o ioctl.o \
genhd.o ioprio.o badblocks.o partitions/ blk-rq-qos.o
+CFLAGS_blk-mq.o := $(call cc-disable-warning, align-mismatch)
o
Re: -Walign-mismatch in block/blk-mq.c
On Wed, Mar 10, 2021 at 01:40:25PM -0700, Jens Axboe wrote:
> On 3/10/21 1:33 PM, Nathan Chancellor wrote:
> > On Wed, Mar 10, 2021 at 01:21:52PM -0700, Jens Axboe wrote:
> >> On 3/10/21 11:23 AM, Nathan Chancellor wrote:
> >>> Hi Jens,
> >>>
> >>> There is a new clang warning added in the development branch,
> >>> -Walign-mismatch, which shows an instance in block/blk-mq.c:
> >>>
> >>> block/blk-mq.c:630:39: warning: passing 8-byte aligned argument to
> >>> 32-byte aligned parameter 2 of 'smp_call_function_single_async' may
> >>> result in an unaligned pointer access [-Walign-mismatch]
> >>> smp_call_function_single_async(cpu, >csd);
> >>> ^
> >>> 1 warning generated.
> >>>
> >>> There appears to be some history here as I can see that this member was
> >>> purposefully unaligned in commit 4ccafe032005 ("block: unalign
> >>> call_single_data in struct request"). However, I later see a change in
> >>> commit 7c3fb70f0341 ("block: rearrange a few request fields for better
> >>> cache layout") that seems somewhat related. Is it possible to get back
> >>> the alignment by rearranging the structure again? This seems to be the
> >>> only solution for the warning aside from just outright disabling it,
> >>> which would be a shame since it seems like it could be useful for
> >>> architectures that cannot handle unaligned accesses well, unless I am
> >>> missing something obvious :)
> >>
> >> It should not be hard to ensure that alignment without re-introducing
> >> the bloat. Is there some background on why 32-byte alignment is
> >> required?
> >>
> >
> > This alignment requirement was introduced in commit 966a967116e6 ("smp:
> > Avoid using two cache lines for struct call_single_data") and it looks
> > like there was a thread between you and Peter Zijlstra that has some
> > more information on this:
> > https://lore.kernel.org/r/a9beb452-7344-9e2d-fc80-094d8f5a0...@kernel.dk/
>
> Ah now I remember - so it's not that it _needs_ to be 32-byte aligned,
> it's just a handy way to ensure that it doesn't straddle two cachelines.
> In fact, there's no real alignment concern, outside of performance
> reasons we don't want it touching two cachelines.
>
> So... what exactly is your concern? Just silencing that warning? Because
Yes, dealing with the warning in some way is my only motivation. My
apologies, I should have led with that. I had assumed that this would
potentially be an issue due to the warning's text and that rearranging
the structure might allow the alignment to be added back but if there is
not actually a problem, then the warning should be silenced in some way.
I am not sure if there is a preferred way to silence it (CFLAGS_... or
some of the __diag() infrastructure in include/linux/compiler_types.h).
> there doesn't seem to be an issue with just having it wherever in struct
> request.
>
Cheers,
Nathan
Re: -Walign-mismatch in block/blk-mq.c
On Wed, Mar 10, 2021 at 01:21:52PM -0700, Jens Axboe wrote:
> On 3/10/21 11:23 AM, Nathan Chancellor wrote:
> > Hi Jens,
> >
> > There is a new clang warning added in the development branch,
> > -Walign-mismatch, which shows an instance in block/blk-mq.c:
> >
> > block/blk-mq.c:630:39: warning: passing 8-byte aligned argument to
> > 32-byte aligned parameter 2 of 'smp_call_function_single_async' may
> > result in an unaligned pointer access [-Walign-mismatch]
> > smp_call_function_single_async(cpu, >csd);
> > ^
> > 1 warning generated.
> >
> > There appears to be some history here as I can see that this member was
> > purposefully unaligned in commit 4ccafe032005 ("block: unalign
> > call_single_data in struct request"). However, I later see a change in
> > commit 7c3fb70f0341 ("block: rearrange a few request fields for better
> > cache layout") that seems somewhat related. Is it possible to get back
> > the alignment by rearranging the structure again? This seems to be the
> > only solution for the warning aside from just outright disabling it,
> > which would be a shame since it seems like it could be useful for
> > architectures that cannot handle unaligned accesses well, unless I am
> > missing something obvious :)
>
> It should not be hard to ensure that alignment without re-introducing
> the bloat. Is there some background on why 32-byte alignment is
> required?
>
This alignment requirement was introduced in commit 966a967116e6 ("smp:
Avoid using two cache lines for struct call_single_data") and it looks
like there was a thread between you and Peter Zijlstra that has some
more information on this:
https://lore.kernel.org/r/a9beb452-7344-9e2d-fc80-094d8f5a0...@kernel.dk/
Cheers,
Nathan
-Walign-mismatch in block/blk-mq.c
Hi Jens,
There is a new clang warning added in the development branch,
-Walign-mismatch, which shows an instance in block/blk-mq.c:
block/blk-mq.c:630:39: warning: passing 8-byte aligned argument to
32-byte aligned parameter 2 of 'smp_call_function_single_async' may
result in an unaligned pointer access [-Walign-mismatch]
smp_call_function_single_async(cpu, >csd);
^
1 warning generated.
There appears to be some history here as I can see that this member was
purposefully unaligned in commit 4ccafe032005 ("block: unalign
call_single_data in struct request"). However, I later see a change in
commit 7c3fb70f0341 ("block: rearrange a few request fields for better
cache layout") that seems somewhat related. Is it possible to get back
the alignment by rearranging the structure again? This seems to be the
only solution for the warning aside from just outright disabling it,
which would be a shame since it seems like it could be useful for
architectures that cannot handle unaligned accesses well, unless I am
missing something obvious :)
Cheers,
Nathan
[PATCH v2 2/2] Makefile: Only specify '--prefix=' when building with clang + GNU as
When building with LLVM_IAS=1, there is no point to specifying '--prefix=' because that flag is only used to find GNU cross tools, which will not be used indirectly when using the integrated assembler. All of the tools are invoked directly from PATH or a full path specified via the command line, which does not depend on the value of '--prefix='. Sharing commands to reproduce issues becomes a little bit easier without a '--prefix=' value because that '--prefix=' value is specific to a user's machine due to it being an absolute path. Some further notes from Fangrui Song: clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]). objcopy is only used for GNU as assembled object files. With integrated assembler, the object file streamer creates .o and .dwo simultaneously. With GNU as, two objcopy commands are needed to extract .debug*.dwo to .dwo files && another command to remove .debug*.dwo sections. A small consequence of this change (to keep things simple) is that '--prefix=' will always be specified now, even with a native build, when it was not before. This should not be an issue due to the way that the Makefile searches for the prefix (based on elfedit's location). This ends up improving the experience for host builds because PATH is better respected and matches GCC's behavior more closely. See the below thread for more details: https://lore.kernel.org/r/20210205213651.GA16907@Ryzen-5-4500U.localdomain/ Signed-off-by: Nathan Chancellor --- v1 -> v2: * Fix position of -no-integrated-as flag to fix native build (thanks to Masahiro for catching it and sorry for the breakage). * Add Fangrui's comments about what GNU binaries clang can spawn at Masahiro's request. * Reword commit message. I did not carry tags forward so that people could re-review and test. Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 182e93d91198..15292a6d63f5 100644 --- a/Makefile +++ b/Makefile @@ -566,11 +566,11 @@ CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | head -n 1 | sed 's/\#//g ifneq ($(findstring clang,$(CC_VERSION_TEXT)),) ifneq ($(CROSS_COMPILE),) CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%)) -GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) -CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) endif ifneq ($(LLVM_IAS),1) CLANG_FLAGS+= -no-integrated-as +GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) +CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) endif CLANG_FLAGS+= -Werror=unknown-warning-option KBUILD_CFLAGS += $(CLANG_FLAGS) -- 2.31.0.rc1
[PATCH v2 1/2] Makefile: Remove '--gcc-toolchain' flag
This flag was originally added to allow clang to find the GNU cross
tools in commit 785f11aa595b ("kbuild: Add better clang cross build
support"). This flag was not enough to find the tools at times so
'--prefix' was added to the list in commit ef8c4ed9db80 ("kbuild: allow
to use GCC toolchain not in Clang search path") and improved upon in
commit ca9b31f6bb9c ("Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang
cross compilation"). Now that '--prefix' specifies a full path and
prefix, '--gcc-toolchain' serves no purpose because the kernel builds
with '-nostdinc' and '-nostdlib'.
This has been verified with self compiled LLVM 10.0.1 and LLVM 13.0.0 as
well as a distribution version of LLVM 11.1.0 without binutils in the
LLVM toolchain locations.
Link: https://reviews.llvm.org/D97902
Signed-off-by: Nathan Chancellor
---
v1 -> v2:
* Improve commit message (add history behind flag and link to Fangrui's
documentation improvement).
I did not carry tags forward so that people could re-review and test.
Makefile | 4
1 file changed, 4 deletions(-)
diff --git a/Makefile b/Makefile
index 31dcdb3d61fa..182e93d91198 100644
--- a/Makefile
+++ b/Makefile
@@ -568,10 +568,6 @@ ifneq ($(CROSS_COMPILE),)
CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%))
GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
-GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..)
-endif
-ifneq ($(GCC_TOOLCHAIN),)
-CLANG_FLAGS+= --gcc-toolchain=$(GCC_TOOLCHAIN)
endif
ifneq ($(LLVM_IAS),1)
CLANG_FLAGS+= -no-integrated-as
base-commit: a38fd8748464831584a19438cbb3082b5a2dab15
--
2.31.0.rc1
Re: [PATCH] kbuild: dummy-tools: adjust to scripts/cc-version.sh
On Wed, Mar 10, 2021 at 01:25:45AM +0900, Masahiro Yamada wrote:
> Commit aec6c60a01d3 ("kbuild: check the minimum compiler version in
> Kconfig") changed how the script detects the compiler version.
>
> Get 'make CROSS_COMPILE=scripts/dummy-tools/' back working again.
>
> Fixes: aec6c60a01d3 ("kbuild: check the minimum compiler version in Kconfig")
> Signed-off-by: Masahiro Yamada
Reviewed-by: Nathan Chancellor
Tested-by: Nathan Chancellor
> ---
>
> Perhaps, Jiri may have already noticed this issue, and have a similar patch.
> I just checked ML, but I did not find a patch to fix this.
>
>
> scripts/dummy-tools/gcc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/dummy-tools/gcc b/scripts/dummy-tools/gcc
> index 7b10332b23ba..39e65fee59bd 100755
> --- a/scripts/dummy-tools/gcc
> +++ b/scripts/dummy-tools/gcc
> @@ -57,9 +57,9 @@ if arg_contain --version "$@"; then
> fi
>
> if arg_contain -E "$@"; then
> - # For scripts/gcc-version.sh; This emulates GCC 20.0.0
> + # For scripts/cc-version.sh; This emulates GCC 20.0.0
> if arg_contain - "$@"; then
> - sed 's/^__GNUC__$/20/; s/^__GNUC_MINOR__$/0/;
> s/^__GNUC_PATCHLEVEL__$/0/'
> + sed -n '/^GCC/{s/__GNUC__/20/; s/__GNUC_MINOR__/0/;
> s/__GNUC_PATCHLEVEL__/0/; p;}'
> exit 0
> else
> echo "no input files" >&2
> --
> 2.27.0
>
Re: [PATCH] Fix ld-version.sh script if LLD was built with LLD_VENDOR
On Wed, Mar 10, 2021 at 02:09:02AM +0900, Masahiro Yamada wrote: > On Thu, Mar 4, 2021 at 12:34 PM Masahiro Yamada wrote: > > > > On Thu, Mar 4, 2021 at 9:18 AM Bernhard Rosenkränzer wrote: > > > > > > If LLD was built with -DLLD_VENDOR="xyz", ld.lld --version output > > > will prefix LLD_VENDOR. Since LLD_VENDOR can contain spaces, the > > > LLD identifier isn't guaranteed to be $2 either. > > > > > > Adjust the version checker to handle such versions of lld. > > > > > > Signed-off-by: Bernhard Rosenkränzer > > > --- > > > > > > Bernhard, > > > > Could you senv v2 > > with the suggested code change? > > > > Please make sure to add > > linux-kbu...@vger.kernel.org > > in the To: > > > I did not get v2, but never mind. > I locally modified the code and applied. > > I added Link: to your original patch > just in case I make some mistake in the > code refactoring. > > > The final one looks as follows: > > > > > > commit 0b2813ba7b0f0a9ff273177e85cbc93d92e76212 > Author: Bernhard Rosenkränzer > Date: Tue Mar 2 23:12:11 2021 +0100 > > kbuild: Fix ld-version.sh script if LLD was built with LLD_VENDOR > > If LLD was built with -DLLD_VENDOR="xyz", ld.lld --version output > will prefix LLD_VENDOR. Since LLD_VENDOR can contain spaces, the > LLD identifier isn't guaranteed to be $2 either. > > Adjust the version checker to handle such versions of lld. > > Link: > https://lore.kernel.org/lkml/20210302221211.1620858-1-b...@lindev.ch/ > Signed-off-by: Bernhard Rosenkränzer > [masahiro yamada: refactor the code] If it is not too late: Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor > Signed-off-by: Masahiro Yamada > > diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh > index a463273509b5..30debf78aa09 100755 > --- a/scripts/ld-version.sh > +++ b/scripts/ld-version.sh > @@ -44,14 +44,20 @@ if [ "$1" = GNU -a "$2" = ld ]; then > elif [ "$1" = GNU -a "$2" = gold ]; then > echo "gold linker is not supported as it is not capable of > linking the kernel proper." >&2 > exit 1 > -elif [ "$1" = LLD ]; then > - version=$2 > - min_version=$lld_min_version > - name=LLD > - disp_name=LLD > else > - echo "$orig_args: unknown linker" >&2 > - exit 1 > + while [ $# -gt 1 -a "$1" != "LLD" ]; do > + shift > + done > + > + if [ "$1" = LLD ]; then > + version=$2 > + min_version=$lld_min_version > + name=LLD > + disp_name=LLD > + else > + echo "$orig_args: unknown linker" >&2 > + exit 1 > + fi > fi > > # Some distributions append a package release number, as in 2.34-4.fc32 > > > > > -- > Best Regards > Masahiro Yamada
Re: [PATCH 3/4] kbuild: check the minimum assembler version in Kconfig
On Sat, Mar 06, 2021 at 02:48:38AM +0900, Masahiro Yamada wrote:
> On Fri, Mar 5, 2021 at 10:26 AM Nick Desaulniers
> wrote:
> >
> > On Wed, Mar 3, 2021 at 10:34 AM Masahiro Yamada
> > wrote:
> > >
> > > Documentation/process/changes.rst defines the minimum assembler version
> > > (binutils version), but we have never checked it in the build time.
> > >
> > > Kbuild never invokes 'as' directly because all assembly files in the
> > > kernel tree are *.S, hence must be preprocessed. I do not expect
> > > raw assembly source files (*.s) would be added to the kernel tree.
> > >
> > > Therefore, we always use $(CC) as the assembler driver, and commit
> > > aa824e0c962b ("kbuild: remove AS variable") removed 'AS'. However,
> > > we are still interested in the version of the assembler sitting behind.
> > >
> > > As usual, the --version option prints the version string.
> > >
> > > $ as --version | head -n 1
> > > GNU assembler (GNU Binutils for Ubuntu) 2.35.1
> > >
> > > But, we do not have $(AS). So, we can add the -Wa prefix so that
> > > $(CC) passes --version down to the backing assembler.
> > >
> > > $ gcc -Wa,--version | head -n 1
> > > gcc: fatal error: no input files
> > > compilation terminated.
> > >
> > > OK, we need to input something to satisfy gcc.
> > >
> > > $ gcc -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
> > > GNU assembler (GNU Binutils for Ubuntu) 2.35.1
> > >
> > > The combination of Clang and GNU assembler works in the same way:
> > >
> > > $ clang -no-integrated-as -Wa,--version -c -x assembler /dev/null -o
> > > /dev/null | head -n 1
> > > GNU assembler (GNU Binutils for Ubuntu) 2.35.1
> > >
> > > Clang with the integrated assembler fails like this:
> > >
> > > $ clang -integrated-as -Wa,--version -c -x assembler /dev/null -o
> > > /dev/null | head -n 1
> > > clang: error: unsupported argument '--version' to option 'Wa,'
> >
> > Was this a feature request to "please implement -Wa,--version for clang?"
> > :-P
> > https://github.com/ClangBuiltLinux/linux/issues/1320
> >
> > >
> > > With all this in my mind, I implemented scripts/as-version.sh.
> > >
> > > $ scripts/as-version.sh gcc
> > > GNU 23501
> > > $ scripts/as-version.sh clang -no-integrated-as
> > > GNU 23501
> > > $ scripts/as-version.sh clang -integrated-as
> > > LLVM 0
> > >
> > > Signed-off-by: Masahiro Yamada
> > > ---
> > >
> > > arch/Kconfig| 3 +-
> > > init/Kconfig| 12 +++
> > > scripts/Kconfig.include | 6
> > > scripts/as-version.sh | 77 +
> > > 4 files changed, 96 insertions(+), 2 deletions(-)
> > > create mode 100755 scripts/as-version.sh
> > >
> > > diff --git a/arch/Kconfig b/arch/Kconfig
> > > index 2af10ebe5ed0..d7214f4ae1f7 100644
> > > --- a/arch/Kconfig
> > > +++ b/arch/Kconfig
> > > @@ -631,8 +631,7 @@ config ARCH_SUPPORTS_LTO_CLANG_THIN
> > > config HAS_LTO_CLANG
> > > def_bool y
> > > # Clang >= 11: https://github.com/ClangBuiltLinux/linux/issues/510
> > > - depends on CC_IS_CLANG && CLANG_VERSION >= 11 && LD_IS_LLD
> > > - depends on $(success,test $(LLVM_IAS) -eq 1)
> > > + depends on CC_IS_CLANG && CLANG_VERSION >= 11 && LD_IS_LLD &&
> > > AS_IS_LLVM
> > > depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm)
> > > depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
> > > depends on ARCH_SUPPORTS_LTO_CLANG
> > > diff --git a/init/Kconfig b/init/Kconfig
> > > index 22946fe5ded9..f76e5a44e4fe 100644
> > > --- a/init/Kconfig
> > > +++ b/init/Kconfig
> > > @@ -41,6 +41,18 @@ config CLANG_VERSION
> > > default $(cc-version) if CC_IS_CLANG
> > > default 0
> > >
> > > +config AS_IS_GNU
> > > + def_bool $(success,test "$(as-name)" = GNU)
> > > +
> > > +config AS_IS_LLVM
> > > + def_bool $(success,test "$(as-name)" = LLVM)
> > > +
> > > +config AS_VERSION
> > > + int
> > > + # If it is integrated assembler, the version is the same as
> > > Clang's one.
> > > + default CLANG_VERSION if AS_IS_LLVM
> > > + default $(as-version)
> > > +
> > > config LD_IS_BFD
> > > def_bool $(success,test "$(ld-name)" = BFD)
> > >
> > > diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
> > > index 58fdb5308725..0496efd6e117 100644
> > > --- a/scripts/Kconfig.include
> > > +++ b/scripts/Kconfig.include
> > > @@ -45,6 +45,12 @@ $(error-if,$(success,test -z
> > > "$(cc-info)"),Sorry$(comma) this compiler is not su
> > > cc-name := $(shell,set -- $(cc-info) && echo $1)
> > > cc-version := $(shell,set -- $(cc-info) && echo $2)
> > >
> > > +# Get the assembler name, version, and error out if it is not supported.
> > > +as-info := $(shell,$(srctree)/scripts/as-version.sh $(CC) $(CLANG_FLAGS))
> > > +$(error-if,$(success,test -z "$(as-info)"),Sorry$(comma) this assembler
> > > is not supported.)
> > > +as-name := $(shell,set -- $(as-info)
Re: [PATCH] KVM: arm64: Don't use cbz/adr with external symbols
On Fri, Mar 05, 2021 at 12:21:24PM -0800, Sami Tolvanen wrote: > allmodconfig + CONFIG_LTO_CLANG_THIN=y fails to build due to following > linker errors: > > ld.lld: error: irqbypass.c:(function __guest_enter: .text+0x21CC): > relocation R_AARCH64_CONDBR19 out of range: 2031220 is not in > [-1048576, 1048575]; references hyp_panic > >>> defined in vmlinux.o > > ld.lld: error: irqbypass.c:(function __guest_enter: .text+0x21E0): > relocation R_AARCH64_ADR_PREL_LO21 out of range: 2031200 is not in > [-1048576, 1048575]; references hyp_panic > >>> defined in vmlinux.o > > This is because with LTO, the compiler ends up placing hyp_panic() > more than 1MB away from __guest_enter(). Use an unconditional branch > and adr_l instead to fix the issue. > > Link: https://github.com/ClangBuiltLinux/linux/issues/1317 > Reported-by: Nathan Chancellor > Suggested-by: Marc Zyngier > Suggested-by: Ard Biesheuvel > Signed-off-by: Sami Tolvanen I booted an kernel with this patch in it on my Raspberry Pi 4 and booted a kernel under KVM without any issues. Tested-by: Nathan Chancellor > --- > arch/arm64/kvm/hyp/entry.S | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S > index b0afad7a99c6..c62265951467 100644 > --- a/arch/arm64/kvm/hyp/entry.S > +++ b/arch/arm64/kvm/hyp/entry.S > @@ -85,8 +85,10 @@ SYM_INNER_LABEL(__guest_exit_panic, SYM_L_GLOBAL) > > // If the hyp context is loaded, go straight to hyp_panic > get_loaded_vcpu x0, x1 > - cbz x0, hyp_panic > + cbnzx0, 1f > + b hyp_panic > > +1: > // The hyp context is saved so make sure it is restored to allow > // hyp_panic to run at hyp and, subsequently, panic to run in the host. > // This makes use of __guest_exit to avoid duplication but sets the > @@ -94,7 +96,7 @@ SYM_INNER_LABEL(__guest_exit_panic, SYM_L_GLOBAL) > // current state is saved to the guest context but it will only be > // accurate if the guest had been completely restored. > adr_this_cpu x0, kvm_hyp_ctxt, x1 > - adr x1, hyp_panic > + adr_l x1, hyp_panic > str x1, [x0, #CPU_XREG_OFFSET(30)] > > get_vcpu_ptrx1, x0 > > base-commit: 280d542f6ffac0e6d65dc267f92191d509b13b64 > -- > 2.30.1.766.gb4fecdf3b7-goog > > ___ > kvmarm mailing list > kvm...@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v2] certs: Fix wrong kconfig option used for x509_revocation_list
On Thu, Mar 04, 2021 at 12:50:30PM -0500, Eric Snowberg wrote: > Fix a build issue when x509_revocation_list is not defined. > > $ make ARCH=x86_64 O=build64 all > > EXTRACT_CERTS ../ > At main.c:154: > - SSL error:0909006C:PEM routines:get_name:no start line: > crypto/pem/pem_lib.c:745 > extract-cert: ../: Is a directory > make[2]: [../certs/Makefile:119: certs/x509_revocation_list] Error 1 (ignored) > > When the new CONFIG_SYSTEM_REVOCATION_LIST was added [1], it was not carried > into the code for preloading the revocation certificates [2]. Change from > using the original CONFIG_SYSTEM_BLACKLIST_KEYRING to the new > CONFIG_SYSTEM_REVOCATION_LIST. > > [1] > https://lore.kernel.org/keyrings/eda280f9-f72d-4181-93c7-cdbe95976...@oracle.com/T/#m562c1b27bf402190e7bb573ad20eff5b6310d08f > [2] > https://lore.kernel.org/keyrings/eda280f9-f72d-4181-93c7-cdbe95976...@oracle.com/T/#m07e258bf019ccbac23820fad5192ceffa74fc6ab > > Reported-by: Randy Dunlap > Signed-off-by: Eric Snowberg This seems to fix my build errors. Tested-by: Nathan Chancellor > --- > v2 changes: > Use the new config option for extract-cert > Use the new config option when building revocation_certificates.o > --- > certs/Makefile| 5 +++-- > certs/blacklist.c | 4 > scripts/Makefile | 2 +- > 3 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/certs/Makefile b/certs/Makefile > index e3f4926fd21e..b6db52ebf0be 100644 > --- a/certs/Makefile > +++ b/certs/Makefile > @@ -4,7 +4,8 @@ > # > > obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o > system_certificates.o common.o > -obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist.o > revocation_certificates.o common.o > +obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist.o common.o > +obj-$(CONFIG_SYSTEM_REVOCATION_LIST) += revocation_certificates.o > ifneq ($(CONFIG_SYSTEM_BLACKLIST_HASH_LIST),"") > obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist_hashes.o > else > @@ -105,7 +106,7 @@ $(obj)/signing_key.x509: scripts/extract-cert $(X509_DEP) > FORCE > $(call > if_changed,extract_certs,$(MODULE_SIG_KEY_SRCPREFIX)$(CONFIG_MODULE_SIG_KEY)) > endif # CONFIG_MODULE_SIG > > -ifeq ($(CONFIG_SYSTEM_BLACKLIST_KEYRING),y) > +ifeq ($(CONFIG_SYSTEM_REVOCATION_LIST),y) > > $(eval $(call config_filename,SYSTEM_REVOCATION_KEYS)) > > diff --git a/certs/blacklist.c b/certs/blacklist.c > index 723b19c96256..c9a435b15af4 100644 > --- a/certs/blacklist.c > +++ b/certs/blacklist.c > @@ -21,8 +21,10 @@ > > static struct key *blacklist_keyring; > > +#ifdef CONFIG_SYSTEM_REVOCATION_LIST > extern __initconst const u8 revocation_certificate_list[]; > extern __initconst const unsigned long revocation_certificate_list_size; > +#endif > > /* > * The description must be a type prefix, a colon and then an even number of > @@ -225,6 +227,7 @@ static int __init blacklist_init(void) > */ > device_initcall(blacklist_init); > > +#ifdef CONFIG_SYSTEM_REVOCATION_LIST > /* > * Load the compiled-in list of revocation X.509 certificates. > */ > @@ -237,3 +240,4 @@ static __init int load_revocation_certificate_list(void) >blacklist_keyring); > } > late_initcall(load_revocation_certificate_list); > +#endif > diff --git a/scripts/Makefile b/scripts/Makefile > index 983b785f13cb..bd0718f7c493 100644 > --- a/scripts/Makefile > +++ b/scripts/Makefile > @@ -11,7 +11,7 @@ hostprogs-always-$(CONFIG_ASN1) > += asn1_compiler > hostprogs-always-$(CONFIG_MODULE_SIG_FORMAT) += sign-file > hostprogs-always-$(CONFIG_SYSTEM_TRUSTED_KEYRING)+= extract-cert > hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert > - hostprogs-always-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += extract-cert > +hostprogs-always-$(CONFIG_SYSTEM_REVOCATION_LIST)+= extract-cert > > HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include > HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include > -- > 2.18.4 >
Re: [PATCH v2] MIPS: Make MIPS32_O32 depends on !CC_IS_CLANG
On Thu, Mar 04, 2021 at 02:19:38PM +0800, Tiezhu Yang wrote: > When build kernel with Clang [1]: Sorry I did not catch this in the first revision but I think this would sound better as: When building with Clang [1]: I think the kernel part is obvious :) couple more comments about the commit message inline. > > $ make CC=clang loongson3_defconfig > $ make CC=clang > > there exists the following error: > > Checking missing-syscalls for O32 > CALLscripts/checksyscalls.sh > error: ABI 'o32' is not supported on CPU 'mips64r2' > make[1]: *** [Kbuild:48: missing-syscalls] Error 1 > make: *** [arch/mips/Makefile:419: archprepare] Error 2 > > This is a known bug [2] with Clang, as Simon Atanasyan said, > "There is no plan on support O32 for MIPS64 due to lack of > resources". > > It is not a good idea to remove CONFIG_MIPS32_O32=y directly > in defconfig due to GCC works well, as Nathan said, the config in defconfig because GCC works, as... > should not even be selectable when build kernel with Clang, so building with Clang > just make MIPS32_O32 depends on !CC_IS_CLANG. > > [1] https://www.kernel.org/doc/html/latest/kbuild/llvm.html > [2] https://bugs.llvm.org/show_bug.cgi?id=38063 > > Signed-off-by: Tiezhu Yang I don't know if Nick will have any comments but for me: Acked-by: Nathan Chancellor I have added this patch and the LLVM bug to our issue tracker: https://github.com/ClangBuiltLinux/linux/issues/884 > --- > arch/mips/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index 3a38d27..f6ba59f 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -3318,6 +3318,8 @@ config SYSVIPC_COMPAT > config MIPS32_O32 > bool "Kernel support for o32 binaries" > depends on 64BIT > + # https://bugs.llvm.org/show_bug.cgi?id=38063 > + depends on !CC_IS_CLANG > select ARCH_WANT_OLD_COMPAT_IPC > select COMPAT > select MIPS32_COMPAT > -- > 2.1.0 >
Re: [PATCH] MIPS: Add comment about CONFIG_MIPS32_O32 in loongson3_defconfig when build with Clang
On Thu, Mar 04, 2021 at 11:48:09AM +0800, Tiezhu Yang wrote: > On 03/04/2021 10:02 AM, Nathan Chancellor wrote: > > On Thu, Mar 04, 2021 at 09:15:44AM +0800, Tiezhu Yang wrote: > > > When build kernel with Clang [1]: > > > > > > $ make CC=clang loongson3_defconfig > > > $ make CC=clang > > [snip] > > > I think this might be a better solution. I know that I personally never > > read defconfig files if a build fails. > > > > If CONFIG_MIPS32_O32 is broken with clang and the MIPS backend > > maintainer has said that it will not be supported due to lack of > > resources, then the config should not even be selectable in my opinion. > > > > Cheers, > > Nathan > > > > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > > index d89efba3d8a4..ed35318a759d 100644 > > --- a/arch/mips/Kconfig > > +++ b/arch/mips/Kconfig > > @@ -3315,6 +3315,8 @@ config SYSVIPC_COMPAT > > config MIPS32_O32 > > bool "Kernel support for o32 binaries" > > depends on 64BIT > > + # https://bugs.llvm.org/show_bug.cgi?id=38063 > > + depends on $(success,$(CC) $(CLANG_FLAGS) -march=mips64 -o32 -c -x c > > /dev/null -o /dev/null) > > select ARCH_WANT_OLD_COMPAT_IPC > > select COMPAT > > select MIPS32_COMPAT > > Hi Nathan, > > Thank you very much for your reply and suggestion, maybe the following > change is simple, clear and better? If yes, I will send v2 later. Hi Tiezhu, I think that the change is simpler but better is subjective. I tend to prefer tests like mine so that it is not dependent on someone going "oh hey, this LLVM bug has been fixed so we can turn this config on!". Instead, the config will just turn on automatically as soon as that bug is fixed. However, in this particular case, it does not seem like that will happen unless someone steps but there have been times where an independent party will implement some change that benefits them and nobody notices for a while. Plus, I periodically grep the tree for CC_IS_CLANG to see if there are any configuration options that can be re-enabled.. Regardless, if Thomas is happy with the below change, so am I, as it will allow us to test more 64-bit MIPS configurations. I can add an ack or review at that point in time. Cheers, Nathan > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index 3a38d27..f6ba59f 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -3318,6 +3318,8 @@ config SYSVIPC_COMPAT > config MIPS32_O32 > bool "Kernel support for o32 binaries" > depends on 64BIT > + # https://bugs.llvm.org/show_bug.cgi?id=38063 > + depends on !CC_IS_CLANG > select ARCH_WANT_OLD_COMPAT_IPC > select COMPAT > select MIPS32_COMPAT > > Thanks, > Tiezhu >
Re: [PATCH] MIPS: Add comment about CONFIG_MIPS32_O32 in loongson3_defconfig when build with Clang
On Thu, Mar 04, 2021 at 09:15:44AM +0800, Tiezhu Yang wrote: > When build kernel with Clang [1]: > > $ make CC=clang loongson3_defconfig > $ make CC=clang > > there exists the following error: > > Checking missing-syscalls for O32 > CALLscripts/checksyscalls.sh > error: ABI 'o32' is not supported on CPU 'mips64r2' > make[1]: *** [Kbuild:48: missing-syscalls] Error 1 > make: *** [arch/mips/Makefile:419: archprepare] Error 2 > > This is a known bug [2] with Clang, as Simon Atanasyan said, > "There is no plan on support O32 for MIPS64 due to lack of > resources". > > It is not a good idea to remove this config due to GCC works > well, so add comment to point out this bug and suggest the > users to remove CONFIG_MIPS32_O32=y in defconfig when build > kernel with Clang. > > [1] https://www.kernel.org/doc/html/latest/kbuild/llvm.html > [2] https://bugs.llvm.org/show_bug.cgi?id=38063 > > Signed-off-by: Tiezhu Yang > --- > arch/mips/configs/loongson3_defconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/mips/configs/loongson3_defconfig > b/arch/mips/configs/loongson3_defconfig > index 0e79f81..cacf9dd 100644 > --- a/arch/mips/configs/loongson3_defconfig > +++ b/arch/mips/configs/loongson3_defconfig > @@ -35,6 +35,9 @@ CONFIG_NUMA=y > CONFIG_SMP=y > CONFIG_HZ_256=y > CONFIG_KEXEC=y > +# Please remove CONFIG_MIPS32_O32=y when build with Clang > +# due to "ABI 'o32' is not supported on CPU 'mips64r2'", > +# https://bugs.llvm.org/show_bug.cgi?id=38063 > CONFIG_MIPS32_O32=y > CONFIG_MIPS32_N32=y > CONFIG_VIRTUALIZATION=y > -- > 2.1.0 > I think this might be a better solution. I know that I personally never read defconfig files if a build fails. If CONFIG_MIPS32_O32 is broken with clang and the MIPS backend maintainer has said that it will not be supported due to lack of resources, then the config should not even be selectable in my opinion. Cheers, Nathan diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index d89efba3d8a4..ed35318a759d 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -3315,6 +3315,8 @@ config SYSVIPC_COMPAT config MIPS32_O32 bool "Kernel support for o32 binaries" depends on 64BIT + # https://bugs.llvm.org/show_bug.cgi?id=38063 + depends on $(success,$(CC) $(CLANG_FLAGS) -march=mips64 -o32 -c -x c /dev/null -o /dev/null) select ARCH_WANT_OLD_COMPAT_IPC select COMPAT select MIPS32_COMPAT
Re: [PATCH 4/4] kbuild: dwarf: use AS_VERSION instead of test_dwarf5_support.sh
On Thu, Mar 04, 2021 at 03:33:33AM +0900, Masahiro Yamada wrote: > The test code in scripts/test_dwarf5_support.sh is somewhat difficult > to understand, but after all, we want to check binutils >= 2.35.2 > > >From the former discussion, the requrement for generating DRAWF v5 from > C code is as follows: > > - gcc + binutils as -> requires gcc 5.0+ (but 7.0+ for full support) > - clang + binutils as -> requires binutils 2.35.2+ > - clang + integrated as -> OK > > Signed-off-by: Masahiro Yamada Reviewed-by: Nathan Chancellor > --- > > lib/Kconfig.debug | 3 +-- > scripts/test_dwarf5_support.sh | 8 > 2 files changed, 1 insertion(+), 10 deletions(-) > delete mode 100755 scripts/test_dwarf5_support.sh > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 2779c29d9981..f3337a38925d 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -284,8 +284,7 @@ config DEBUG_INFO_DWARF4 > > config DEBUG_INFO_DWARF5 > bool "Generate DWARF Version 5 debuginfo" > - depends on GCC_VERSION >= 5 || CC_IS_CLANG > - depends on CC_IS_GCC || > $(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC) $(CLANG_FLAGS)) > + depends on GCC_VERSION >= 5 || (CC_IS_CLANG && AS_IS_GNU && > AS_VERSION >= 23502) || (CC_IS_CLANG && AS_IS_LLVM) > depends on !DEBUG_INFO_BTF > help > Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc > diff --git a/scripts/test_dwarf5_support.sh b/scripts/test_dwarf5_support.sh > deleted file mode 100755 > index c46e2456b47a.. > --- a/scripts/test_dwarf5_support.sh > +++ /dev/null > @@ -1,8 +0,0 @@ > -#!/bin/sh > -# SPDX-License-Identifier: GPL-2.0 > - > -# Test that the assembler doesn't need -Wa,-gdwarf-5 when presented with > DWARF > -# v5 input, such as `.file 0` and `md5 0x00`. Should be fixed in GNU binutils > -# 2.35.2. https://sourceware.org/bugzilla/show_bug.cgi?id=25611 > -echo '.file 0 "filename" md5 0x7a0b65214090b6693bd1dc24dd248245' | \ > - $* -gdwarf-5 -Wno-unused-command-line-argument -c -x assembler -o > /dev/null - > -- > 2.27.0 >
Re: [PATCH 3/4] kbuild: check the minimum assembler version in Kconfig
On Thu, Mar 04, 2021 at 03:33:32AM +0900, Masahiro Yamada wrote:
> Documentation/process/changes.rst defines the minimum assembler version
> (binutils version), but we have never checked it in the build time.
>
> Kbuild never invokes 'as' directly because all assembly files in the
> kernel tree are *.S, hence must be preprocessed. I do not expect
> raw assembly source files (*.s) would be added to the kernel tree.
>
> Therefore, we always use $(CC) as the assembler driver, and commit
> aa824e0c962b ("kbuild: remove AS variable") removed 'AS'. However,
> we are still interested in the version of the assembler sitting behind.
>
> As usual, the --version option prints the version string.
>
> $ as --version | head -n 1
> GNU assembler (GNU Binutils for Ubuntu) 2.35.1
>
> But, we do not have $(AS). So, we can add the -Wa prefix so that
> $(CC) passes --version down to the backing assembler.
>
> $ gcc -Wa,--version | head -n 1
> gcc: fatal error: no input files
> compilation terminated.
>
> OK, we need to input something to satisfy gcc.
>
> $ gcc -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
> GNU assembler (GNU Binutils for Ubuntu) 2.35.1
>
> The combination of Clang and GNU assembler works in the same way:
>
> $ clang -no-integrated-as -Wa,--version -c -x assembler /dev/null -o
> /dev/null | head -n 1
> GNU assembler (GNU Binutils for Ubuntu) 2.35.1
>
> Clang with the integrated assembler fails like this:
>
> $ clang -integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null
> | head -n 1
> clang: error: unsupported argument '--version' to option 'Wa,'
>
> With all this in my mind, I implemented scripts/as-version.sh.
>
> $ scripts/as-version.sh gcc
> GNU 23501
> $ scripts/as-version.sh clang -no-integrated-as
> GNU 23501
> $ scripts/as-version.sh clang -integrated-as
> LLVM 0
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/Kconfig| 3 +-
> init/Kconfig| 12 +++
> scripts/Kconfig.include | 6
> scripts/as-version.sh | 77 +
> 4 files changed, 96 insertions(+), 2 deletions(-)
> create mode 100755 scripts/as-version.sh
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 2af10ebe5ed0..d7214f4ae1f7 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -631,8 +631,7 @@ config ARCH_SUPPORTS_LTO_CLANG_THIN
> config HAS_LTO_CLANG
> def_bool y
> # Clang >= 11: https://github.com/ClangBuiltLinux/linux/issues/510
> - depends on CC_IS_CLANG && CLANG_VERSION >= 11 && LD_IS_LLD
> - depends on $(success,test $(LLVM_IAS) -eq 1)
> + depends on CC_IS_CLANG && CLANG_VERSION >= 11 && LD_IS_LLD &&
> AS_IS_LLVM
> depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm)
> depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
> depends on ARCH_SUPPORTS_LTO_CLANG
> diff --git a/init/Kconfig b/init/Kconfig
> index 22946fe5ded9..f76e5a44e4fe 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -41,6 +41,18 @@ config CLANG_VERSION
> default $(cc-version) if CC_IS_CLANG
> default 0
>
> +config AS_IS_GNU
> + def_bool $(success,test "$(as-name)" = GNU)
> +
> +config AS_IS_LLVM
> + def_bool $(success,test "$(as-name)" = LLVM)
> +
> +config AS_VERSION
> + int
> + # If it is integrated assembler, the version is the same as Clang's one.
> + default CLANG_VERSION if AS_IS_LLVM
> + default $(as-version)
> +
> config LD_IS_BFD
> def_bool $(success,test "$(ld-name)" = BFD)
>
> diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
> index 58fdb5308725..0496efd6e117 100644
> --- a/scripts/Kconfig.include
> +++ b/scripts/Kconfig.include
> @@ -45,6 +45,12 @@ $(error-if,$(success,test -z "$(cc-info)"),Sorry$(comma)
> this compiler is not su
> cc-name := $(shell,set -- $(cc-info) && echo $1)
> cc-version := $(shell,set -- $(cc-info) && echo $2)
>
> +# Get the assembler name, version, and error out if it is not supported.
> +as-info := $(shell,$(srctree)/scripts/as-version.sh $(CC) $(CLANG_FLAGS))
> +$(error-if,$(success,test -z "$(as-info)"),Sorry$(comma) this assembler is
> not supported.)
> +as-name := $(shell,set -- $(as-info) && echo $1)
> +as-version := $(shell,set -- $(as-info) && echo $2)
> +
> # Get the linker name, version, and error out if it is not supported.
> ld-info := $(shell,$(srctree)/scripts/ld-version.sh $(LD))
> $(error-if,$(success,test -z "$(ld-info)"),Sorry$(comma) this linker is not
> supported.)
> diff --git a/scripts/as-version.sh b/scripts/as-version.sh
> new file mode 100755
> index ..205d8b9fc4d4
> --- /dev/null
> +++ b/scripts/as-version.sh
> @@ -0,0 +1,77 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Print the assembler name and its version in a 5 or 6-digit form.
> +# Also, perform the minimum version check.
> +# (If it is the integrated assembler, return 0 as the version, and
> +# the version
Re: [PATCH 1/4] kbuild: remove LLVM=1 test from HAS_LTO_CLANG
On Thu, Mar 04, 2021 at 03:33:30AM +0900, Masahiro Yamada wrote:
> This guarding is wrong. As Documentation/kbuild/llvm.rst notes, LLVM=1
> switches the default of tools, but you can still override CC, LD, etc.
> individually.
>
> BTW, LLVM is not 1/0 flag. If LLVM is not passed in, it is empty.
>
> Non-zero return code is all treated as failure anyway.
>
> So, $(success,test $(LLVM) -eq 1) and $(success,test "$(LLVM)" = 1)
> works equivalently in the sense that both are expanded to 'n' if LLVM
> is not given. The difference is that the former internally fails due
> to syntax error.
>
> $ test ${LLVM} -eq 1
> bash: test: -eq: unary operator expected
> $ echo $?
> 2
>
> $ test "${LLVM}" -eq 1
> bash: test: : integer expression expected
> $ echo $?
> 2
>
> $ test "${LLVM}" = 1
> echo $?
> 1
>
> $ test -n "${LLVM}"
> $ echo $?
> 1
>
> Signed-off-by: Masahiro Yamada
Yes, there is not too much point of checking if $(LLVM) is set or not
because we already check for the other tools.
Reviewed-by: Nathan Chancellor
> ---
>
> arch/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 2bb30673d8e6..2af10ebe5ed0 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -632,7 +632,6 @@ config HAS_LTO_CLANG
> def_bool y
> # Clang >= 11: https://github.com/ClangBuiltLinux/linux/issues/510
> depends on CC_IS_CLANG && CLANG_VERSION >= 11 && LD_IS_LLD
> - depends on $(success,test $(LLVM) -eq 1)
> depends on $(success,test $(LLVM_IAS) -eq 1)
> depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm)
> depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
> --
> 2.27.0
>
Re: [PATCH 2/4] kbuild: collect minimum tool versions into scripts/tool-version.sh
On Thu, Mar 04, 2021 at 03:33:31AM +0900, Masahiro Yamada wrote:
> The kernel build uses various tools, many of which are provided by the
> same software suite, for example, LLVM and Binutils.
>
> When we raise the minimal version of Clang/LLVM, we need to update
> clang_min_version in scripts/cc-version.sh and also lld_min_version in
> scripts/ld-version.sh.
>
> In fact, Kbuild can handle CC=clang and LD=ld.lld independently, and we
> could manage their minimal version separately, but it does not make
> much sense.
>
> Make scripts/tool-version.sh a central place of minimum tool versions
> so that we do not need to touch multiple files.
>
> This script prints the minimal version of the given tool.
>
> $ scripts/tool-version.sh gcc
> 4.9.0
> $ scripts/tool-version.sh llvm
> 10.0.1
> $ scripts/tool-version.sh binutils
> 2.23.0
> $ scripts/tool-version.sh foo
> foo: unknown tool
>
> Signed-off-by: Masahiro Yamada
Reviewed-by: Nathan Chancellor
Two comments below.
> ---
>
> scripts/cc-version.sh | 20 +---
> scripts/ld-version.sh | 11 ---
> scripts/tool-version.sh | 27 +++
> 3 files changed, 36 insertions(+), 22 deletions(-)
> create mode 100755 scripts/tool-version.sh
>
> diff --git a/scripts/cc-version.sh b/scripts/cc-version.sh
> index 3f2ee885b116..4772f1ef9cac 100755
> --- a/scripts/cc-version.sh
> +++ b/scripts/cc-version.sh
> @@ -6,18 +6,6 @@
>
> set -e
>
> -# When you raise the minimum compiler version, please update
> -# Documentation/process/changes.rst as well.
> -gcc_min_version=4.9.0
> -clang_min_version=10.0.1
> -icc_min_version=16.0.3 # temporary
> -
> -# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293
> -# https://lore.kernel.org/r/20210107111841.gn1...@shell.armlinux.org.uk
> -if [ "$SRCARCH" = arm64 ]; then
> - gcc_min_version=5.1.0
> -fi
> -
> # Print the compiler name and some version components.
> get_compiler_info()
> {
> @@ -48,18 +36,20 @@ set -- $(get_compiler_info "$@")
>
> name=$1
>
> +tool_version=$(dirname $0)/tool-version.sh
I realize these scripts are currently called by their full path but is
it worth making this '$(dirname "$(readlink -f "$0")")' here and in
ld-version.sh just in case that does not happen?
> case "$name" in
> GCC)
> version=$2.$3.$4
> - min_version=$gcc_min_version
> + min_version=$($tool_version gcc)
> ;;
> Clang)
> version=$2.$3.$4
> - min_version=$clang_min_version
> + min_version=$($tool_version llvm)
> ;;
> ICC)
> version=$(($2 / 100)).$(($2 % 100)).$3
> - min_version=$icc_min_version
> + min_version=$($tool_version icc)
> ;;
> *)
> echo "$orig_args: unknown compiler" >&2
> diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
> index a463273509b5..e824f7675693 100755
> --- a/scripts/ld-version.sh
> +++ b/scripts/ld-version.sh
> @@ -6,11 +6,6 @@
>
> set -e
>
> -# When you raise the minimum linker version, please update
> -# Documentation/process/changes.rst as well.
> -bfd_min_version=2.23.0
> -lld_min_version=10.0.1
> -
> # Convert the version string x.y.z to a canonical 5 or 6-digit form.
> get_canonical_version()
> {
> @@ -35,10 +30,12 @@ set -- $("$@" --version)
> IFS=' '
> set -- $1
>
> +tool_version=$(dirname $0)/tool-version.sh
> +
> if [ "$1" = GNU -a "$2" = ld ]; then
> shift $(($# - 1))
> version=$1
> - min_version=$bfd_min_version
> + min_version=$($tool_version binutils)
> name=BFD
> disp_name="GNU ld"
> elif [ "$1" = GNU -a "$2" = gold ]; then
> @@ -46,7 +43,7 @@ elif [ "$1" = GNU -a "$2" = gold ]; then
> exit 1
> elif [ "$1" = LLD ]; then
> version=$2
> - min_version=$lld_min_version
> + min_version=$($tool_version llvm)
> name=LLD
> disp_name=LLD
> else
> diff --git a/scripts/tool-version.sh b/scripts/tool-version.sh
> new file mode 100755
> index ..b4aa27e2c3d3
> --- /dev/null
> +++ b/scripts/tool-version.sh
> @@ -0,0 +1,27 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Print the minimum supported version of the given tool.
> +
> +set -e
> +
> +# When you raise the minimum version, please update
> +# Documentation/process/changes.rst as well.
> +gcc_min_version=4.9.0
> +llvm_min_version=10.0.1
> +icc_min_version=16.0.3 # temporary
> +binutils_min_version=2.23.0
> +
> +# https://
Re: [PATCH 3/4] certs: Add ability to preload revocation certs
On Thu, Feb 25, 2021 at 08:58:55PM +, David Howells wrote:
> From: Eric Snowberg
>
> Add a new Kconfig option called SYSTEM_REVOCATION_KEYS. If set,
> this option should be the filename of a PEM-formated file containing
> X.509 certificates to be included in the default blacklist keyring.
>
> [DH: Changed this to make the new Kconfig option depend on the option to
> enable the facility.]
>
> Signed-off-by: Eric Snowberg
> Acked-by: Jarkko Sakkinen
> Signed-off-by: David Howells
> Link:
> https://lore.kernel.org/r/20200930201508.35113-3-eric.snowb...@oracle.com/
> Link:
> https://lore.kernel.org/r/20210122181054.32635-4-eric.snowb...@oracle.com/ #
> v5
> ---
>
> certs/Kconfig |8
> certs/Makefile | 18 --
> certs/blacklist.c | 17 +
> certs/revocation_certificates.S | 21 +
> scripts/Makefile|1 +
> 5 files changed, 63 insertions(+), 2 deletions(-)
> create mode 100644 certs/revocation_certificates.S
>
> diff --git a/certs/Kconfig b/certs/Kconfig
> index 76e469b56a77..ab88d2a7f3c7 100644
> --- a/certs/Kconfig
> +++ b/certs/Kconfig
> @@ -92,4 +92,12 @@ config SYSTEM_REVOCATION_LIST
> blacklist keyring and implements a hook whereby a PKCS#7 message can
> be checked to see if it matches such a certificate.
>
> +config SYSTEM_REVOCATION_KEYS
> + string "X.509 certificates to be preloaded into the system blacklist
> keyring"
> + depends on SYSTEM_REVOCATION_LIST
> + help
> + If set, this option should be the filename of a PEM-formatted file
> + containing X.509 certificates to be included in the default blacklist
> + keyring.
> +
> endmenu
> diff --git a/certs/Makefile b/certs/Makefile
> index f4b90bad8690..e3f4926fd21e 100644
> --- a/certs/Makefile
> +++ b/certs/Makefile
> @@ -4,7 +4,7 @@
> #
>
> obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o
> system_certificates.o common.o
> -obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist.o
> +obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist.o
> revocation_certificates.o common.o
> ifneq ($(CONFIG_SYSTEM_BLACKLIST_HASH_LIST),"")
> obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist_hashes.o
> else
> @@ -29,7 +29,7 @@ $(obj)/x509_certificate_list: scripts/extract-cert
> $(SYSTEM_TRUSTED_KEYS_SRCPREF
> $(call
> if_changed,extract_certs,$(SYSTEM_TRUSTED_KEYS_SRCPREFIX)$(CONFIG_SYSTEM_TRUSTED_KEYS))
> endif # CONFIG_SYSTEM_TRUSTED_KEYRING
>
> -clean-files := x509_certificate_list .x509.list
> +clean-files := x509_certificate_list .x509.list x509_revocation_list
>
> ifeq ($(CONFIG_MODULE_SIG),y)
>
> ###
> @@ -104,3 +104,17 @@ targets += signing_key.x509
> $(obj)/signing_key.x509: scripts/extract-cert $(X509_DEP) FORCE
> $(call
> if_changed,extract_certs,$(MODULE_SIG_KEY_SRCPREFIX)$(CONFIG_MODULE_SIG_KEY))
> endif # CONFIG_MODULE_SIG
> +
> +ifeq ($(CONFIG_SYSTEM_BLACKLIST_KEYRING),y)
> +
> +$(eval $(call config_filename,SYSTEM_REVOCATION_KEYS))
> +
> +$(obj)/revocation_certificates.o: $(obj)/x509_revocation_list
> +
> +quiet_cmd_extract_certs = EXTRACT_CERTS $(patsubst "%",%,$(2))
> + cmd_extract_certs = scripts/extract-cert $(2) $@
> +
> +targets += x509_revocation_list
> +$(obj)/x509_revocation_list: scripts/extract-cert
> $(SYSTEM_REVOCATION_KEYS_SRCPREFIX)$(SYSTEM_REVOCATION_KEYS_FILENAME) FORCE
> + $(call
> if_changed,extract_certs,$(SYSTEM_REVOCATION_KEYS_SRCPREFIX)$(CONFIG_SYSTEM_REVOCATION_KEYS))
> +endif
> diff --git a/certs/blacklist.c b/certs/blacklist.c
> index 2b8644123d5f..723b19c96256 100644
> --- a/certs/blacklist.c
> +++ b/certs/blacklist.c
> @@ -17,9 +17,13 @@
> #include
> #include
> #include "blacklist.h"
> +#include "common.h"
>
> static struct key *blacklist_keyring;
>
> +extern __initconst const u8 revocation_certificate_list[];
> +extern __initconst const unsigned long revocation_certificate_list_size;
> +
> /*
> * The description must be a type prefix, a colon and then an even number of
> * hex digits. The hash is kept in the description.
> @@ -220,3 +224,16 @@ static int __init blacklist_init(void)
> * Must be initialised before we try and load the keys into the keyring.
> */
> device_initcall(blacklist_init);
> +
> +/*
> + * Load the compiled-in list of revocation X.509 certificates.
> + */
> +static __init int load_revocation_certificate_list(void)
> +{
> + if (revocation_certificate_list_size)
> + pr_notice("Loading compiled-in revocation X.509
> certificates\n");
> +
> + return load_certificate_list(revocation_certificate_list,
> revocation_certificate_list_size,
> + blacklist_keyring);
> +}
> +late_initcall(load_revocation_certificate_list);
> diff --git a/certs/revocation_certificates.S b/certs/revocation_certificates.S
> new file
Re: [PATCH] Fix ld-version.sh script if LLD was built with LLD_VENDOR
On Wed, Mar 03, 2021 at 08:38:06PM +0900, Masahiro Yamada wrote: > On Wed, Mar 3, 2021 at 1:02 PM Nathan Chancellor wrote: > > > > Hi Bernhard, > > > > I have added the ClangBuiltLinux mailing list, kbuild mailing list, and > > Masahiro and Nick to CC. Maybe ld-version.sh and cc-version.sh should be > > added to a MAINTAINERS entry to make sure we get CC'd (I can send one > > along tomorrow). > > > > On Tue, Mar 02, 2021 at 11:12:11PM +0100, Bernhard Rosenkränzer wrote: > > > If LLD was built with -DLLD_VENDOR="xyz", ld.lld --version output > > > will prefix LLD_VENDOR. Since LLD_VENDOR can contain spaces, the > > > LLD identifier isn't guaranteed to be $2 either. > > > > TIL about LLD_VENDOR... > > > > > Adjust the version checker to handle such versions of lld. > > > > > > Signed-off-by: Bernhard Rosenkränzer > > > --- > > > scripts/ld-version.sh | 12 > > > 1 file changed, 12 insertions(+) > > > > > > diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh > > > index a463273509b5..4c042a306e22 100755 > > > --- a/scripts/ld-version.sh > > > +++ b/scripts/ld-version.sh > > > @@ -49,6 +49,18 @@ elif [ "$1" = LLD ]; then > > > min_version=$lld_min_version > > > name=LLD > > > disp_name=LLD > > > +elif echo "$@" |grep -q ' LLD '; then > > > + # if LLD was built with -DLLD_VENDOR="xyz", it ld.lld --version > > > + # says "xyz LLD [...]". Since LLD_VENDOR may contain spaces, we > > > + # don't know the exact position of "LLD" and the version info > > > + # at this point > > > + while [ "$1" != "LLD" ]; do > > > + shift > > > + done > > > + version=$2 > > > + min_version=$lld_min_version > > > + name=LLD > > > + disp_name=LLD > > > else > > > echo "$orig_args: unknown linker" >&2 > > > exit 1 > > > -- > > > 2.30.1 > > > > > > > I am not sure what a better fix would be of the top of my head but > > wouldn't it be better to avoid the duplication? This diff below works > > for me with or without LLD_VENDOR defined. > > > > diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh > > index a463273509b5..84f9fc741f09 100755 > > --- a/scripts/ld-version.sh > > +++ b/scripts/ld-version.sh > > @@ -44,7 +44,10 @@ if [ "$1" = GNU -a "$2" = ld ]; then > > elif [ "$1" = GNU -a "$2" = gold ]; then > > echo "gold linker is not supported as it is not capable of linking > > the kernel proper." >&2 > > exit 1 > > -elif [ "$1" = LLD ]; then > > +elif echo "$*" | grep -q LLD; then > > + while [ "$1" != "LLD" ]; do > > + shift > > + done > > version=$2 > > min_version=$lld_min_version > > name=LLD > > > > You do not need to use grep. > How about this? > > > > > ... > else > while [ $# -gt 1 -a "$1" != "LLD" ]; do >shift > done > > if [ "$1" = LLD ]; then > version=$2 > min_version=$lld_min_version > name=LLD > disp_name=LLD > else > echo "$orig_args: unknown linker" >&2 > exit 1 > fi > fi > > > > > -- > Best Regards > Masahiro Yamada Yes, that as the following diff works for me. diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh index a463273509b5..30debf78aa09 100755 --- a/scripts/ld-version.sh +++ b/scripts/ld-version.sh @@ -44,14 +44,20 @@ if [ "$1" = GNU -a "$2" = ld ]; then elif [ "$1" = GNU -a "$2" = gold ]; then echo "gold linker is not supported as it is not capable of linking the kernel proper." >&2 exit 1 -elif [ "$1" = LLD ]; then - version=$2 - min_version=$lld_min_version - name=LLD - disp_name=LLD else - echo "$orig_args: unknown linker" >&2 - exit 1 + while [ $# -gt 1 -a "$1" != "LLD" ]; do + shift + done + + if [ "$1" = LLD ]; then + version=$2 + min_version=$lld_min_version + name=LLD + disp_name=LLD + else + echo "$orig_args: unknown linker" >&2 + exit 1 + fi fi # Some distributions append a package release number, as in 2.34-4.fc32
Re: [PATCH] Fix ld-version.sh script if LLD was built with LLD_VENDOR
Hi Bernhard, I have added the ClangBuiltLinux mailing list, kbuild mailing list, and Masahiro and Nick to CC. Maybe ld-version.sh and cc-version.sh should be added to a MAINTAINERS entry to make sure we get CC'd (I can send one along tomorrow). On Tue, Mar 02, 2021 at 11:12:11PM +0100, Bernhard Rosenkränzer wrote: > If LLD was built with -DLLD_VENDOR="xyz", ld.lld --version output > will prefix LLD_VENDOR. Since LLD_VENDOR can contain spaces, the > LLD identifier isn't guaranteed to be $2 either. TIL about LLD_VENDOR... > Adjust the version checker to handle such versions of lld. > > Signed-off-by: Bernhard Rosenkränzer > --- > scripts/ld-version.sh | 12 > 1 file changed, 12 insertions(+) > > diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh > index a463273509b5..4c042a306e22 100755 > --- a/scripts/ld-version.sh > +++ b/scripts/ld-version.sh > @@ -49,6 +49,18 @@ elif [ "$1" = LLD ]; then > min_version=$lld_min_version > name=LLD > disp_name=LLD > +elif echo "$@" |grep -q ' LLD '; then > + # if LLD was built with -DLLD_VENDOR="xyz", it ld.lld --version > + # says "xyz LLD [...]". Since LLD_VENDOR may contain spaces, we > + # don't know the exact position of "LLD" and the version info > + # at this point > + while [ "$1" != "LLD" ]; do > + shift > + done > + version=$2 > + min_version=$lld_min_version > + name=LLD > + disp_name=LLD > else > echo "$orig_args: unknown linker" >&2 > exit 1 > -- > 2.30.1 > I am not sure what a better fix would be of the top of my head but wouldn't it be better to avoid the duplication? This diff below works for me with or without LLD_VENDOR defined. diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh index a463273509b5..84f9fc741f09 100755 --- a/scripts/ld-version.sh +++ b/scripts/ld-version.sh @@ -44,7 +44,10 @@ if [ "$1" = GNU -a "$2" = ld ]; then elif [ "$1" = GNU -a "$2" = gold ]; then echo "gold linker is not supported as it is not capable of linking the kernel proper." >&2 exit 1 -elif [ "$1" = LLD ]; then +elif echo "$*" | grep -q LLD; then + while [ "$1" != "LLD" ]; do + shift + done version=$2 min_version=$lld_min_version name=LLD
[PATCH 1/2] Makefile: Remove '--gcc-toolchain' flag
This is not necessary anymore now that we specify '--prefix=', which tells clang exactly where to find the GNU cross tools. This has been verified with self compiled LLVM 10.0.1 and LLVM 13.0.0 as well as a distribution version of LLVM 11.1.0 without binutils in the LLVM toolchain locations. Signed-off-by: Nathan Chancellor --- Makefile | 4 1 file changed, 4 deletions(-) diff --git a/Makefile b/Makefile index f9b54da2fca0..c20f0ad8be73 100644 --- a/Makefile +++ b/Makefile @@ -568,10 +568,6 @@ ifneq ($(CROSS_COMPILE),) CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%)) GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) -GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..) -endif -ifneq ($(GCC_TOOLCHAIN),) -CLANG_FLAGS+= --gcc-toolchain=$(GCC_TOOLCHAIN) endif ifneq ($(LLVM_IAS),1) CLANG_FLAGS+= -no-integrated-as base-commit: 7a7fd0de4a9804299793e564a555a49c1fc924cb -- 2.31.0.rc0.75.gec125d1bc1
[PATCH 2/2] Makefile: Only specify '--prefix=' when building with clang + GNU as
When building with LLVM_IAS=1, there is no point to specifying '--prefix=' because that flag is only used to find the cross assembler, which is clang itself when building with LLVM_IAS=1. All of the other tools are invoked directly from PATH or a full path specified via the command line, which does not depend on the value of '--prefix='. Sharing commands to reproduce issues becomes a little bit easier without a '--prefix=' value because that '--prefix=' value is specific to a user's machine due to it being an absolute path. Signed-off-by: Nathan Chancellor --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index c20f0ad8be73..0413b8c594cd 100644 --- a/Makefile +++ b/Makefile @@ -566,12 +566,12 @@ CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | head -n 1 | sed 's/\#//g ifneq ($(findstring clang,$(CC_VERSION_TEXT)),) ifneq ($(CROSS_COMPILE),) CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%)) +ifneq ($(LLVM_IAS),1) GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) -endif -ifneq ($(LLVM_IAS),1) CLANG_FLAGS+= -no-integrated-as endif +endif CLANG_FLAGS+= -Werror=unknown-warning-option KBUILD_CFLAGS += $(CLANG_FLAGS) KBUILD_AFLAGS += $(CLANG_FLAGS) -- 2.31.0.rc0.75.gec125d1bc1
[PATCH] powerpc/prom: Mark identical_pvr_fixup as __init
If identical_pvr_fixup() is not inlined, there are two modpost warnings:
WARNING: modpost: vmlinux.o(.text+0x54e8): Section mismatch in reference
from the function identical_pvr_fixup() to the function
.init.text:of_get_flat_dt_prop()
The function identical_pvr_fixup() references
the function __init of_get_flat_dt_prop().
This is often because identical_pvr_fixup lacks a __init
annotation or the annotation of of_get_flat_dt_prop is wrong.
WARNING: modpost: vmlinux.o(.text+0x551c): Section mismatch in reference
from the function identical_pvr_fixup() to the function
.init.text:identify_cpu()
The function identical_pvr_fixup() references
the function __init identify_cpu().
This is often because identical_pvr_fixup lacks a __init
annotation or the annotation of identify_cpu is wrong.
identical_pvr_fixup() calls two functions marked as __init and is only
called by a function marked as __init so it should be marked as __init
as well. At the same time, remove the inline keywork as it is not
necessary to inline this function. The compiler is still free to do so
if it feels it is worthwhile since commit 889b3c1245de ("compiler:
remove CONFIG_OPTIMIZE_INLINING entirely").
Fixes: 14b3d926a22b ("[POWERPC] 4xx: update 440EP(x)/440GR(x) identical PVR
issue workaround")
Link: https://github.com/ClangBuiltLinux/linux/issues/1316
Signed-off-by: Nathan Chancellor
---
arch/powerpc/kernel/prom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 9a4797d1d40d..a8b2d6bfc1ca 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -267,7 +267,7 @@ static struct feature_property {
};
#if defined(CONFIG_44x) && defined(CONFIG_PPC_FPU)
-static inline void identical_pvr_fixup(unsigned long node)
+static __init void identical_pvr_fixup(unsigned long node)
{
unsigned int pvr;
const char *model = of_get_flat_dt_prop(node, "model", NULL);
base-commit: 5c88a17e15795226b56d83f579cbb9b7a4864f79
--
2.31.0.rc0.75.gec125d1bc1
[PATCH] powerpc/fadump: Mark fadump_calculate_reserve_size as __init
If fadump_calculate_reserve_size() is not inlined, there is a modpost
warning:
WARNING: modpost: vmlinux.o(.text+0x5196c): Section mismatch in
reference from the function fadump_calculate_reserve_size() to the
function .init.text:parse_crashkernel()
The function fadump_calculate_reserve_size() references
the function __init parse_crashkernel().
This is often because fadump_calculate_reserve_size lacks a __init
annotation or the annotation of parse_crashkernel is wrong.
fadump_calculate_reserve_size() calls parse_crashkernel(), which is
marked as __init and fadump_calculate_reserve_size() is called from
within fadump_reserve_mem(), which is also marked as __init.
Mark fadump_calculate_reserve_size() as __init to fix the section
mismatch. Additionally, remove the inline keyword as it is not necessary
to inline this function; the compiler is still free to do so if it feels
it is worthwhile since commit 889b3c1245de ("compiler: remove
CONFIG_OPTIMIZE_INLINING entirely").
Fixes: 11550dc0a00b ("powerpc/fadump: reuse crashkernel parameter for fadump
memory reservation")
Link: https://github.com/ClangBuiltLinux/linux/issues/1300
Signed-off-by: Nathan Chancellor
---
Send while streaming at https://www.twitch.tv/nathanchance :P
arch/powerpc/kernel/fadump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 8482739d42f3..eddf362caedc 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -292,7 +292,7 @@ static void fadump_show_config(void)
* that is required for a kernel to boot successfully.
*
*/
-static inline u64 fadump_calculate_reserve_size(void)
+static __init u64 fadump_calculate_reserve_size(void)
{
u64 base, size, bootmem_min;
int ret;
base-commit: 5c88a17e15795226b56d83f579cbb9b7a4864f79
--
2.31.0.rc0.75.gec125d1bc1
Re: [PATCH RFC] x86: remove toolchain check for X32 ABI capability
On Sat, Feb 27, 2021 at 11:49:36PM -0700, Nathan Chancellor wrote:
> On Sun, Feb 28, 2021 at 12:15:16PM +0900, Masahiro Yamada wrote:
> > On Sun, Feb 28, 2021 at 3:41 AM Masahiro Yamada
> > wrote:
> > >
> > > This commit reverts 0bf6276392e9 ("x32: Warn and disable rather than
> > > error if binutils too old").
> > >
> > > The help text in arch/x86/Kconfig says enabling the X32 ABI support
> > > needs binutils 2.22 or later. This is met because the minimal binutils
> > > version is 2.23 according to Documentation/process/changes.rst.
> > >
> > > I would not say I am not familiar with toolchain configuration, but
> >
> > I mean:
> > I would not say I am familiar ...
> > That is why I added RFC.
> >
> > I appreciate comments from people who are familiar
> > with toolchains (binutils, llvm).
> >
> > If this change is not safe,
> > we can move this check to Kconfig at least.
>
> Hi Masahiro,
>
> As Fangrui pointed out, there are two outstanding issues with x32 with
> LLVM=1, both seemingly related to LLVM=1.
^ llvm-objcopy
Sigh, note to self, don't write emails while tired...
Cheers,
Nathan
>
> https://github.com/ClangBuiltLinux/linux/issues/514
> https://github.com/ClangBuiltLinux/linux/issues/1141
>
> Additionally, there appears to be one from Arnd as well but that one has
> received no triage yet.
>
> https://github.com/ClangBuiltLinux/linux/issues/1205
>
> I intend to test this patch as well as a few others at some point in the
> coming week although I am having to play sysadmin due to moving servers
> so I might not be able to get to it until later in the week.
>
> Cheers,
> Nathan
>
> > > I checked the configure.tgt code in binutils. The elf32_x86_64
> > > emulation mode seems to be included when it is configured for the
> > > x86_64-*-linux-* target.
> > >
> > > I also tried lld and llvm-objcopy, and succeeded in building x32 VDSO.
> > >
> > > I removed the compile-time check in arch/x86/Makefile, in the hope of
> > > elf32_x86_64 being always supported.
> > >
> > > With this, CONFIG_X86_X32 and CONFIG_X86_X32_ABI will be equivalent.
> > > Rename the former to the latter.
> > >
> > > Signed-off-by: Masahiro Yamada
> > > ---
> > >
> > > arch/x86/Kconfig | 8 ++--
> > > arch/x86/Makefile | 16
> > > arch/x86/include/asm/syscall_wrapper.h | 6 +++---
> > > arch/x86/include/asm/vdso.h| 2 +-
> > > arch/x86/kernel/process_64.c | 2 +-
> > > fs/fuse/file.c | 2 +-
> > > fs/xfs/xfs_ioctl32.c | 2 +-
> > > sound/core/control_compat.c| 16
> > > sound/core/pcm_compat.c| 20 ++--
> > > 9 files changed, 27 insertions(+), 47 deletions(-)
> > >
> > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > index 2792879d398e..7272cba2744c 100644
> > > --- a/arch/x86/Kconfig
> > > +++ b/arch/x86/Kconfig
> > > @@ -2865,7 +2865,7 @@ config IA32_AOUT
> > > help
> > > Support old a.out binaries in the 32bit emulation.
> > >
> > > -config X86_X32
> > > +config X86_X32_ABI
> > > bool "x32 ABI for 64-bit mode"
> > > depends on X86_64
> > > help
> > > @@ -2874,10 +2874,6 @@ config X86_X32
> > > full 64-bit register file and wide data path while leaving
> > > pointers at 32 bits for smaller memory footprint.
> > >
> > > - You will need a recent binutils (2.22 or later) with
> > > - elf32_x86_64 support enabled to compile a kernel with this
> > > - option set.
> > > -
> > > config COMPAT_32
> > > def_bool y
> > > depends on IA32_EMULATION || X86_32
> > > @@ -2886,7 +2882,7 @@ config COMPAT_32
> > >
> > > config COMPAT
> > > def_bool y
> > > - depends on IA32_EMULATION || X86_X32
> > > + depends on IA32_EMULATION || X86_X32_ABI
> > >
> > > if COMPAT
> > > config COMPAT_FOR_U64_ALIGNMENT
> > > diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> > > index 2d6d5a28c3bf..e163549f5be7 100644
> > > --- a/arch/x86/Makefile
> > > +++ b/arch/x86/Makefile
> > > @
