* Re: [Buildroot] [PATCH 4/4] package/android-tools: add host gcc >= 5 dependency
From: Yann E. MORIN @ 2022-01-05 21:02 UTC (permalink / raw)
To: Fabrice Fontaine
Cc: Marcus Folkesson, Antoine Tenart, Thomas Petazzoni, buildroot,
Clayton Shotwell, Matt Weber
In-Reply-To: <20220105180402.388388-4-fontaine.fabrice@gmail.com>
Fabrice, All,
On 2022-01-05 19:04 +0100, Fabrice Fontaine spake thusly:
> Commit 56d9b887685c86fd4fbadda247cdbe733d499e81 forgot to add host
> gcc >= 5 dependency
>
> Fixes:
> - No autobuilder failures (yet)
>
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> ---
> package/android-tools/Config.in.host | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/package/android-tools/Config.in.host b/package/android-tools/Config.in.host
> index 433f4e384f..576e53e8b5 100644
> --- a/package/android-tools/Config.in.host
> +++ b/package/android-tools/Config.in.host
> @@ -10,12 +10,16 @@ config BR2_PACKAGE_HOST_ANDROID_TOOLS
> if BR2_PACKAGE_HOST_ANDROID_TOOLS
>
> config BR2_PACKAGE_HOST_ANDROID_TOOLS_FASTBOOT
> + depends on BR2_HOST_GCC_AT_LEAST_5 # host-libselinux -> host-libsepol
> bool "fastboot"
> help
> This option will build and install the fastboot utility for
> the host, which can be used to reflash target devices
> implementing the fastboot protocol.
>
> +comment "fastboot needs a toolchain w/ host gcc >= 5"
> + depends on !BR2_HOST_GCC_AT_LEAST_5
> +
> config BR2_PACKAGE_HOST_ANDROID_TOOLS_ADB
> bool "adb"
> help
> @@ -24,10 +28,14 @@ config BR2_PACKAGE_HOST_ANDROID_TOOLS_ADB
> implementing the ADB protocol.
>
> config BR2_PACKAGE_HOST_ANDROID_TOOLS_EXT4_UTILS
> + depends on BR2_HOST_GCC_AT_LEAST_5 # host-libselinux -> host-libsepol
$ make check-package
package/android-tools/Config.in.host:14: attributes order: type, default, depends on, select, help (http://nightly.buildroot.org/#_config_files)
package/android-tools/Config.in.host:32: attributes order: type, default, depends on, select, help (http://nightly.buildroot.org/#_config_files)
Applied to master after fixing this, thanks.
Regards,
Yann E. MORIN.
> bool "ext4 utils"
> help
> This option will build and install the ext4 utils for the
> host, i.e. make_ext4fs, ext4fixup, ext2simg, img2simg,
> simg2img and simg2simg.
>
> +comment "ext4 utils needs a toolchain w/ host gcc >= 5"
> + depends on !BR2_HOST_GCC_AT_LEAST_5
> +
> endif
> --
> 2.34.1
>
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply
* [PATCH] bpf: fix verifier support for validation of async callbacks
From: Kris Van Hees @ 2022-01-05 21:01 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Daniel Borkmann, Andrii Nakryiko,
Network Development, bpf, Kernel Team, Kris Van Hees
Commit bfc6bb74e4 ("bpf: Implement verifier support for validation of
async callbacks.") added support for BPF_FUNC_timer_set_callback to
the __check_func_call() function. The test in __check_func_call() is
flaweed because it can mis-interpret a regular BPF-to-BPF pseudo-call
as a BPF_FUNC_timer_set_callback callback call.
Consider the conditional in the code:
if (insn->code == (BPF_JMP | BPF_CALL) &&
insn->imm == BPF_FUNC_timer_set_callback) {
The BPF_FUNC_timer_set_callback has value 170. This means that if you
have a BPF program that contains a pseudo-call with an instruction delta
of 170, this conditional will be found to be true by the verifier, and
it will interpret the pseudo-call as a callback. This leads to a mess
with the verification of the program because it makes the wrong
assumptions about the nature of this call.
Solution: include an explicit check to ensure that insn->src_reg == 0.
This ensures that calls cannot be mis-interpreted as an async callback
call.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
---
kernel/bpf/verifier.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index b70c66c6db3b..a40ff2efe6be 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -6031,6 +6031,7 @@ static int __check_func_call(struct bpf_verifier_env *env, struct bpf_insn *insn
}
if (insn->code == (BPF_JMP | BPF_CALL) &&
+ insn->src_reg == 0 &&
insn->imm == BPF_FUNC_timer_set_callback) {
struct bpf_verifier_state *async_cb;
--
2.34.1
^ permalink raw reply related
* Re: [Buildroot] [PATCH 1/4] package/libsemanage: add gcc >= 5 dependency
From: Yann E. MORIN @ 2022-01-05 21:00 UTC (permalink / raw)
To: Fabrice Fontaine
Cc: Marcus Folkesson, Antoine Tenart, Thomas Petazzoni, buildroot,
Clayton Shotwell, Matt Weber
In-Reply-To: <20220105180402.388388-1-fontaine.fabrice@gmail.com>
Fabrice, All,
On 2022-01-05 19:03 +0100, Fabrice Fontaine spake thusly:
> Commit 56d9b887685c86fd4fbadda247cdbe733d499e81 forgot to add gcc >= 5
> dependency
>
> Fixes:
> - No autobuilder failures (yet)
>
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Series of 4 patches applied to master, thanks.
I'll further reply to patch 4...
Regards,
Yann E. MORIN.
> ---
> package/libsemanage/Config.in | 6 ++++--
> package/policycoreutils/Config.in | 8 +++++---
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/package/libsemanage/Config.in b/package/libsemanage/Config.in
> index 3c7050ee51..5103df3f15 100644
> --- a/package/libsemanage/Config.in
> +++ b/package/libsemanage/Config.in
> @@ -3,6 +3,7 @@ config BR2_PACKAGE_LIBSEMANAGE
> depends on BR2_PACKAGE_AUDIT_ARCH_SUPPORTS
> depends on BR2_TOOLCHAIN_HAS_THREADS
> depends on !BR2_STATIC_LIBS
> + depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5 # libselinux -> libsepol
> select BR2_PACKAGE_AUDIT
> select BR2_PACKAGE_LIBSELINUX
> select BR2_PACKAGE_BZIP2
> @@ -17,6 +18,7 @@ config BR2_PACKAGE_LIBSEMANAGE
>
> http://selinuxproject.org/page/Main_Page
>
> -comment "libsemanage needs a toolchain w/ threads, dynamic library"
> +comment "libsemanage needs a toolchain w/ threads, dynamic library, gcc >= 5"
> depends on BR2_PACKAGE_AUDIT_ARCH_SUPPORTS
> - depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS
> + depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS || \
> + !BR2_TOOLCHAIN_GCC_AT_LEAST_5
> diff --git a/package/policycoreutils/Config.in b/package/policycoreutils/Config.in
> index 81900b4e41..3201c8fede 100644
> --- a/package/policycoreutils/Config.in
> +++ b/package/policycoreutils/Config.in
> @@ -1,12 +1,14 @@
> -comment "policycoreutils needs a toolchain w/ threads, dynamic library"
> +comment "policycoreutils needs a toolchain w/ threads, dynamic library, gcc >= 5"
> depends on BR2_PACKAGE_AUDIT_ARCH_SUPPORTS
> - depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS
> + depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS || \
> + !BR2_TOOLCHAIN_GCC_AT_LEAST_5
>
> config BR2_PACKAGE_POLICYCOREUTILS
> bool "policycoreutils"
> depends on BR2_PACKAGE_AUDIT_ARCH_SUPPORTS # libsemanage
> depends on BR2_TOOLCHAIN_HAS_THREADS # libsemanage
> - depends on !BR2_STATIC_LIBS #libsemanage
> + depends on !BR2_STATIC_LIBS # libsemanage
> + depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5 # libsemanage -> libselinux -> libsepol
> select BR2_PACKAGE_LIBSEMANAGE
> select BR2_PACKAGE_LIBCAP_NG
> help
> --
> 2.34.1
>
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply
* [Buildroot] [git commit] package/checkpolicy: add host gcc >= 5 dependency
From: Yann E. MORIN @ 2022-01-05 20:59 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=8c0b521987f929ce88ae97ee2bf6f923311061a7
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Commit 56d9b887685c86fd4fbadda247cdbe733d499e81 forgot to add host
gcc >= 5 dependency
Fixes:
- http://autobuild.buildroot.org/results/fc727efc0c658aaae55c83632a91af83701f0c49
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
---
package/checkpolicy/Config.in.host | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/package/checkpolicy/Config.in.host b/package/checkpolicy/Config.in.host
index 240a5b6dc4..38e35e2fc1 100644
--- a/package/checkpolicy/Config.in.host
+++ b/package/checkpolicy/Config.in.host
@@ -1,5 +1,6 @@
config BR2_PACKAGE_HOST_CHECKPOLICY
bool "host checkpolicy"
+ depends on BR2_HOST_GCC_AT_LEAST_5 # host-libselinux -> host-libsepol
help
checkpolicy is the SELinux policy compiler. It uses libsepol
to generate the binary policy. checkpolicy uses the static
@@ -8,3 +9,6 @@ config BR2_PACKAGE_HOST_CHECKPOLICY
shared library interface.
http://selinuxproject.org/page/Main_Page
+
+comment "host checkpolicy needs a toolchain w/ host gcc >= 5"
+ depends on !BR2_HOST_GCC_AT_LEAST_5
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related
* [Buildroot] [git commit] package/libsemanage: add gcc >= 5 dependency
From: Yann E. MORIN @ 2022-01-05 20:58 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=2fb55340ef0781243b18a6f2519c02b5c1d7bf28
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Commit 56d9b887685c86fd4fbadda247cdbe733d499e81 forgot to add gcc >= 5
dependency
Fixes:
- No autobuilder failures (yet)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
---
package/libsemanage/Config.in | 6 ++++--
package/policycoreutils/Config.in | 8 +++++---
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/package/libsemanage/Config.in b/package/libsemanage/Config.in
index 3c7050ee51..5103df3f15 100644
--- a/package/libsemanage/Config.in
+++ b/package/libsemanage/Config.in
@@ -3,6 +3,7 @@ config BR2_PACKAGE_LIBSEMANAGE
depends on BR2_PACKAGE_AUDIT_ARCH_SUPPORTS
depends on BR2_TOOLCHAIN_HAS_THREADS
depends on !BR2_STATIC_LIBS
+ depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5 # libselinux -> libsepol
select BR2_PACKAGE_AUDIT
select BR2_PACKAGE_LIBSELINUX
select BR2_PACKAGE_BZIP2
@@ -17,6 +18,7 @@ config BR2_PACKAGE_LIBSEMANAGE
http://selinuxproject.org/page/Main_Page
-comment "libsemanage needs a toolchain w/ threads, dynamic library"
+comment "libsemanage needs a toolchain w/ threads, dynamic library, gcc >= 5"
depends on BR2_PACKAGE_AUDIT_ARCH_SUPPORTS
- depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS
+ depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS || \
+ !BR2_TOOLCHAIN_GCC_AT_LEAST_5
diff --git a/package/policycoreutils/Config.in b/package/policycoreutils/Config.in
index 81900b4e41..3201c8fede 100644
--- a/package/policycoreutils/Config.in
+++ b/package/policycoreutils/Config.in
@@ -1,12 +1,14 @@
-comment "policycoreutils needs a toolchain w/ threads, dynamic library"
+comment "policycoreutils needs a toolchain w/ threads, dynamic library, gcc >= 5"
depends on BR2_PACKAGE_AUDIT_ARCH_SUPPORTS
- depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS
+ depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS || \
+ !BR2_TOOLCHAIN_GCC_AT_LEAST_5
config BR2_PACKAGE_POLICYCOREUTILS
bool "policycoreutils"
depends on BR2_PACKAGE_AUDIT_ARCH_SUPPORTS # libsemanage
depends on BR2_TOOLCHAIN_HAS_THREADS # libsemanage
- depends on !BR2_STATIC_LIBS #libsemanage
+ depends on !BR2_STATIC_LIBS # libsemanage
+ depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5 # libsemanage -> libselinux -> libsepol
select BR2_PACKAGE_LIBSEMANAGE
select BR2_PACKAGE_LIBCAP_NG
help
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related
* [Buildroot] [git commit] package/android-tools: add host gcc >= 5 dependency
From: Yann E. MORIN @ 2022-01-05 20:59 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=ae2c55df06e2163b6094b72775180c3a3afc4250
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Commit 56d9b887685c86fd4fbadda247cdbe733d499e81 forgot to add host
gcc >= 5 dependency
Fixes:
- No autobuilder failures (yet)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
---
package/android-tools/Config.in.host | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/package/android-tools/Config.in.host b/package/android-tools/Config.in.host
index 433f4e384f..898ddb2199 100644
--- a/package/android-tools/Config.in.host
+++ b/package/android-tools/Config.in.host
@@ -11,11 +11,15 @@ if BR2_PACKAGE_HOST_ANDROID_TOOLS
config BR2_PACKAGE_HOST_ANDROID_TOOLS_FASTBOOT
bool "fastboot"
+ depends on BR2_HOST_GCC_AT_LEAST_5 # host-libselinux -> host-libsepol
help
This option will build and install the fastboot utility for
the host, which can be used to reflash target devices
implementing the fastboot protocol.
+comment "fastboot needs a toolchain w/ host gcc >= 5"
+ depends on !BR2_HOST_GCC_AT_LEAST_5
+
config BR2_PACKAGE_HOST_ANDROID_TOOLS_ADB
bool "adb"
help
@@ -25,9 +29,13 @@ config BR2_PACKAGE_HOST_ANDROID_TOOLS_ADB
config BR2_PACKAGE_HOST_ANDROID_TOOLS_EXT4_UTILS
bool "ext4 utils"
+ depends on BR2_HOST_GCC_AT_LEAST_5 # host-libselinux -> host-libsepol
help
This option will build and install the ext4 utils for the
host, i.e. make_ext4fs, ext4fixup, ext2simg, img2simg,
simg2img and simg2simg.
+comment "ext4 utils needs a toolchain w/ host gcc >= 5"
+ depends on !BR2_HOST_GCC_AT_LEAST_5
+
endif
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related
* [Buildroot] [git commit] package/refpolicy: add host gcc >= 5 dependency
From: Yann E. MORIN @ 2022-01-05 20:59 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=1a087dd17fcfb7df2053cde6286803d6ae326c14
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Commit 56d9b887685c86fd4fbadda247cdbe733d499e81 forgot to add host
gcc >= 5 dependency
Fixes:
- No autobuilder failures (yet)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
---
package/refpolicy/Config.in | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/package/refpolicy/Config.in b/package/refpolicy/Config.in
index 043cc40a72..0e72b895df 100644
--- a/package/refpolicy/Config.in
+++ b/package/refpolicy/Config.in
@@ -2,6 +2,7 @@ config BR2_PACKAGE_REFPOLICY
bool "refpolicy"
depends on BR2_TOOLCHAIN_HAS_THREADS # libsepol
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5 # libsepol
+ depends on BR2_HOST_GCC_AT_LEAST_5 # host-setools -> host-libsepol
# Even though libsepol is not necessary for building, we get
# the policy version from libsepol, so we select it, and treat
# it like a runtime dependency.
@@ -114,6 +115,7 @@ endif
endif
-comment "refpolicy needs a toolchain w/ threads, gcc >= 5"
+comment "refpolicy needs a toolchain w/ threads, gcc >= 5, host gcc >= 5"
depends on !BR2_TOOLCHAIN_HAS_THREADS || \
- !BR2_TOOLCHAIN_GCC_AT_LEAST_5
+ !BR2_TOOLCHAIN_GCC_AT_LEAST_5 || \
+ !BR2_HOST_GCC_AT_LEAST_5
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related
* Re: [PATCH 2/2] sched/core: Uncookied force idle accounting per cpu
From: Josh Don @ 2022-01-05 20:59 UTC (permalink / raw)
To: cruzzhao
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Benjamin Segall, Mel Gorman,
Daniel Bristot de Oliveira, Alexey Dobriyan, Eric Dumazet,
linux-kernel, linux-fsdevel
In-Reply-To: <8be4679f-632b-97e5-9e48-1e1a37727ddf@linux.alibaba.com>
On Wed, Jan 5, 2022 at 3:33 AM cruzzhao <cruzzhao@linux.alibaba.com> wrote:
>
> When we care about capacity loss, we care about all but not some of it.
> The forced idle time from uncookie'd task is actually caused by the
> cookie'd task in runqueue indirectly, and it's more accurate to measure
> the capacity loss with the sum of cookie'd forced idle time and
> uncookie'd forced idle time, as far as I'm concerned.
>
> Assuming cpu x and cpu y are a pair of smt siblings, consider the
> following scenarios:
> 1. There's a cookie'd task A running on cpu x, and there're 4 uncookie'd
> tasks B~E running on cpu y. For cpu x, there will be 80% forced idle
> time(from uncookie'd task); for cpu y, there will be 20% forced idle
> time(from cookie'd task).
> 2. There's a uncookie'd task A running on cpu x, and there're 4 cookie'd
> tasks B~E running on cpu y. For cpu x, there will be 80% forced idle
> time(from cookie'd task); for cpu y, there will be 20% forced idle
> time(from uncookie'd task).
> The scenario1 can recurrent by stress-ng(scenario2 can recurrent similary):
> (cookie'd)taskset -c x stress-ng -c 1 -l 100
> (uncookie'd)taskset -c y stress-ng -c 4 -l 100
>
> In the above two scenarios, the capacity loss is 1 cpu, but in
> scenario1, the cookie'd forced idle time tells us 20%cpu loss, in
> scenario2, the cookie'd forced idle time tells us 80% forced idle time,
> which are not accurate. It'll be more accurate with the sum of cookie'd
> forced idle time and uncookie'd forced idle time.
Why do you need this separated out into two fields then? Could we just
combine the uncookie'd and cookie'd forced idle into a single sum?
IMO it is fine to account the forced idle from uncookie'd tasks, but
we should then also change the task accounting to do the same, for
consistency.
^ permalink raw reply
* Re: [PATCH v2 1/2] t7508: add tests capturing racy timestamp handling
From: Junio C Hamano @ 2022-01-05 20:59 UTC (permalink / raw)
To: Marc Strapetz via GitGitGadget; +Cc: git, Marc Strapetz
In-Reply-To: <7d58f80611193f8696d99e317fe6b1e53ac740f7.1641388523.git.gitgitgadget@gmail.com>
"Marc Strapetz via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Marc Strapetz <marc.strapetz@syntevo.com>
>
> "git status" fixes racy timestamps regardless of the worktree being
> dirty or not. The new test cases capture this behavior.
>
> Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
> ---
> t/t7508-status.sh | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/t/t7508-status.sh b/t/t7508-status.sh
> index 05c6c02435d..652cbb5ed2e 100755
> --- a/t/t7508-status.sh
> +++ b/t/t7508-status.sh
> @@ -1656,4 +1656,32 @@ test_expect_success '--no-optional-locks prevents index update' '
> ! grep ^1234567890 out
> '
>
> +test_expect_success 'racy timestamps will be fixed for clean worktree' '
> + echo content >racy-dirty &&
> + echo content >racy-racy &&
> + git add racy* &&
> + git commit -m "racy test files" &&
> + # let status rewrite the index, if necessary; after that we expect
> + # no more index writes unless caused by racy timestamps; note that
> + # timestamps may already be racy now (depending on previous tests)
> + git status &&
> + test-tool chmtime =1234567890 .git/index &&
> + test-tool chmtime --get .git/index >out &&
> + grep ^1234567890 out &&
If file contents were 1234567890999, this will still hit, but I do
not think that is what you wanted to see. Perhaps
git status &&
echo 1234567890 >expect &&
test-tool chmtime=$(cat expect) .git/index &&
test-tool chmtime --get .git/index >actual &&
test_cmp expect actual
or something? But I think you inherited this bogosity from the
previous test, so I am OK to add a few more copies of the same
bogosity to the test.
Somebody later has to step in and clean them all up, though. When
that happens, we should document how the magic 1234567890 timestamp
was chosen near its first use.
I think it is because it is a timestamp in year 2009, so as long as
your filetime clock is reasonably accurate, a write to the file
would never get such a low timestamp.
> + git status &&
> + test-tool chmtime --get .git/index >out &&
> + ! grep ^1234567890 out
^ permalink raw reply
* Re: [Buildroot] [PATCH] package/opensc: new package
From: Thomas Petazzoni @ 2022-01-05 20:59 UTC (permalink / raw)
To: José Pekkarinen; +Cc: buildroot
In-Reply-To: <20211213061551.4110-1-jose.pekkarinen@unikie.com>
Hello José,
On Mon, 13 Dec 2021 08:15:51 +0200
José Pekkarinen <jose.pekkarinen@unikie.com> wrote:
> The patch will add opensc package.
>
> Signed-off-by: José Pekkarinen <jose.pekkarinen@unikie.com>
I'm afraid that when I read the feedback from upstream in your patches,
saying that they introduce memory leaks (and indeed they do), I'm not
really keen on merging this.
However, I saw you told upstream:
It is a bit of a chiken and egg problem. Buildroot wants me to
upstream the patches before the package would be accesible to you,
you want me to give a testing case that doesn't come easy without
upstreaming the package.
This is not totally correct for two reason:
* we don't require patches to be accepted upstream, except if we have
serious doubts about the patches.
* the package doesn't have to be accepted in Buildroot upstream to
provide an easy way for the opensc developers to reproduce the
issue. You can provide a Buildroot branch on a public Git
repository, with the opensc package, and a very simple
opensc_demo_defconfig in configs/ that uses some external toolchain
and builds just opensc to demonstrate the build failure. Then for
the opensc people, reproducing is as easy as:
git clone -b <yourbranch> git://your.repository.com
cd buildroot/
make opensc_demo_defconfig
make
Could you resolve the remaining issues and send an updated patch? Also,
please remember to add a version to your patches when submitting, it
really makes things easier.
Best regards,
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply
* Re: [PATCH v5 00/11] Factorization of messages with similar meaning
From: Johannes Sixt @ 2022-01-05 20:58 UTC (permalink / raw)
To: Jean-Noël Avila via GitGitGadget, git
Cc: Jeff King, Ævar Arnfjörð Bjarmason,
René Scharfe, Jean-Noël Avila
In-Reply-To: <pull.1088.v5.git.1641412944.gitgitgadget@gmail.com>
Am 05.01.22 um 21:02 schrieb Jean-Noël Avila via GitGitGadget:
> This series is a meager attempt at rationalizing a small fraction of the
> internationalized messages. Sorry in advance for the dull task of reviewing
> these insipide patches.
>
> Doing so has some positive effects:
>
> * non-translatable constant strings are kept out of the way for translators
> * messages with identical meaning are built identically
> * the total number of messages to translate is decreased.
>
> Changes since V1:
>
> * took into account the comments, except for ref-filter.c where the
> proposed refactoring is not obvious.
> * added even more strings to the "cannot be used together" crowd.
>
> Changes since V2:
>
> * fixed change of behaviour in tag.c
> * reverted sam changes as per Johannes Sixt comments
>
> Changes since V3:
>
> * apply Oxford comma where needed
> * switch all options to " '%s' " style where i18n is applied.
>
> Changes since V4:
>
> * Apply changes by René on tag.c
> * cosmetic changes
This round looks good to me, with one caveat: I am not a translator, nor
do I use a translated version of Git. So, I haven't verified the claim
that the number translatable strings was reduced greatly, nor whether
there are any accidential duplicates due to typos. I infer the
correctness only by looking at the changes.
There's one small nit visible in the range-diff; not worth a reroll IMHO:
> 5: a9d8a50d666 ! 5: ad58bc8d8a9 i18n: tag.c factorize i18n strings
> @@ builtin/tag.c: int cmd_tag(int argc, const char **argv, const char *prefix)
> - die(_("--no-contains option is only allowed in list mode"));
> - if (filter.points_at.nr)
> - die(_("--points-at option is only allowed in list mode"));
> +- if (filter.reachable_from || filter.unreachable_from)
> +- die(_("--merged and --no-merged options are only allowed in list mode"));
> + only_in_list = "-n";
> + else if (filter.with_commit)
> + only_in_list = "--contains";
> @@ builtin/tag.c: int cmd_tag(int argc, const char **argv, const char *prefix)
> + only_in_list = "--no-contains";
> + else if (filter.points_at.nr)
> + only_in_list = "--points-at";
> ++ else if (filter.reachable_from)
> ++ only_in_list = "--merged";
> ++ else if (filter.unreachable_from)
An extra blank after the 'if'.
> ++ only_in_list = "--no-merged";
> + if (only_in_list)
> + die(_("the '%s' option is only allowed in list mode"), only_in_list);
> - if (filter.reachable_from || filter.unreachable_from)
> -- die(_("--merged and --no-merged options are only allowed in list mode"));
> -+ die(_("'--merged' and '--no-merged' options are only allowed in list mode"));
> if (cmdmode == 'd') {
> ret = delete_tags(argv);
> goto cleanup;
-- Hannes
^ permalink raw reply
* [PATCH] docs/can: convert to restructuredText
From: oxr463 @ 2022-01-05 20:56 UTC (permalink / raw)
To: qemu-devel; +Cc: peter.maydell, thuth, Lucas Ramage
From: Lucas Ramage <lucas.ramage@infinite-omicron.com>
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/527
Signed-off-by: Lucas Ramage <lucas.ramage@infinite-omicron.com>
---
docs/{can.txt => system/can.rst} | 92 ++++++++++++++------------------
docs/system/index.rst | 1 +
2 files changed, 42 insertions(+), 51 deletions(-)
rename docs/{can.txt => system/can.rst} (68%)
diff --git a/docs/can.txt b/docs/system/can.rst
similarity index 68%
rename from docs/can.txt
rename to docs/system/can.rst
index 0d310237df..198522eaa4 100644
--- a/docs/can.txt
+++ b/docs/system/can.rst
@@ -1,6 +1,5 @@
-QEMU CAN bus emulation support
-==============================
-
+CAN Bus Emulation Support
+=========================
The CAN bus emulation provides mechanism to connect multiple
emulated CAN controller chips together by one or multiple CAN busses
(the controller device "canbus" parameter). The individual busses
@@ -32,34 +31,39 @@ emulated environment for testing and RTEMS GSoC slot has been donated
to work on CAN hardware emulation on QEMU.
Examples how to use CAN emulation for SJA1000 based boards
-==========================================================
-
+----------------------------------------------------------
When QEMU with CAN PCI support is compiled then one of the next
CAN boards can be selected
- (1) CAN bus Kvaser PCI CAN-S (single SJA1000 channel) boad. QEMU startup options
+(1) CAN bus Kvaser PCI CAN-S (single SJA1000 channel) boad. QEMU startup options::
+
-object can-bus,id=canbus0
-device kvaser_pci,canbus=canbus0
- Add "can-host-socketcan" object to connect device to host system CAN bus
+
+Add "can-host-socketcan" object to connect device to host system CAN bus::
+
-object can-host-socketcan,id=canhost0,if=can0,canbus=canbus0
- (2) CAN bus PCM-3680I PCI (dual SJA1000 channel) emulation
+(2) CAN bus PCM-3680I PCI (dual SJA1000 channel) emulation::
+
-object can-bus,id=canbus0
-device pcm3680_pci,canbus0=canbus0,canbus1=canbus0
- another example:
+Another example::
+
-object can-bus,id=canbus0
-object can-bus,id=canbus1
-device pcm3680_pci,canbus0=canbus0,canbus1=canbus1
- (3) CAN bus MIOe-3680 PCI (dual SJA1000 channel) emulation
- -device mioe3680_pci,canbus0=canbus0
+(3) CAN bus MIOe-3680 PCI (dual SJA1000 channel) emulation::
+ -device mioe3680_pci,canbus0=canbus0
The ''kvaser_pci'' board/device model is compatible with and has been tested with
-''kvaser_pci'' driver included in mainline Linux kernel.
+the ''kvaser_pci'' driver included in mainline Linux kernel.
The tested setup was Linux 4.9 kernel on the host and guest side.
-Example for qemu-system-x86_64:
+
+Example for qemu-system-x86_64::
qemu-system-x86_64 -accel kvm -kernel /boot/vmlinuz-4.9.0-4-amd64 \
-initrd ramdisk.cpio \
@@ -69,7 +73,7 @@ Example for qemu-system-x86_64:
-device kvaser_pci,canbus=canbus0 \
-nographic -append "console=ttyS0"
-Example for qemu-system-arm:
+Example for qemu-system-arm::
qemu-system-arm -cpu arm1176 -m 256 -M versatilepb \
-kernel kernel-qemu-arm1176-versatilepb \
@@ -84,24 +88,23 @@ Example for qemu-system-arm:
The CAN interface of the host system has to be configured for proper
bitrate and set up. Configuration is not propagated from emulated
devices through bus to the physical host device. Example configuration
-for 1 Mbit/s
+for 1 Mbit/s::
ip link set can0 type can bitrate 1000000
ip link set can0 up
Virtual (host local only) can interface can be used on the host
-side instead of physical interface
+side instead of physical interface::
ip link add dev can0 type vcan
The CAN interface on the host side can be used to analyze CAN
-traffic with "candump" command which is included in "can-utils".
+traffic with "candump" command which is included in "can-utils"::
candump can0
CTU CAN FD support examples
-===========================
-
+---------------------------
This open-source core provides CAN FD support. CAN FD drames are
delivered even to the host systems when SocketCAN interface is found
CAN FD capable.
@@ -113,7 +116,7 @@ on the board.
Example how to connect the canbus0-bus (virtual wire) to the host
Linux system (SocketCAN used) and to both CTU CAN FD cores emulated
on the corresponding PCI card expects that host system CAN bus
-is setup according to the previous SJA1000 section.
+is setup according to the previous SJA1000 section::
qemu-system-x86_64 -enable-kvm -kernel /boot/vmlinuz-4.19.52+ \
-initrd ramdisk.cpio \
@@ -125,7 +128,7 @@ is setup according to the previous SJA1000 section.
-device ctucan_pci,canbus0=canbus0-bus,canbus1=canbus0-bus \
-nographic
-Setup of CTU CAN FD controller in a guest Linux system
+Setup of CTU CAN FD controller in a guest Linux system::
insmod ctucanfd.ko || modprobe ctucanfd
insmod ctucanfd_pci.ko || modprobe ctucanfd_pci
@@ -150,19 +153,19 @@ Setup of CTU CAN FD controller in a guest Linux system
/bin/ip link set $ifc up
done
-The test can run for example
+The test can run for example::
candump can1
-in the guest system and next commands in the host system for basic CAN
+in the guest system and next commands in the host system for basic CAN::
cangen can0
-for CAN FD without bitrate switch
+for CAN FD without bitrate switch::
cangen can0 -f
-and with bitrate switch
+and with bitrate switch::
cangen can0 -b
@@ -170,29 +173,16 @@ The test can be run viceversa, generate messages in the guest system and capture
in the host one and much more combinations.
Links to other resources
-========================
-
- (1) CAN related projects at Czech Technical University, Faculty of Electrical Engineering
- http://canbus.pages.fel.cvut.cz/
- (2) Repository with development can-pci branch at Czech Technical University
- https://gitlab.fel.cvut.cz/canbus/qemu-canbus
- (3) RTEMS page describing project
- https://devel.rtems.org/wiki/Developer/Simulators/QEMU/CANEmulation
- (4) RTLWS 2015 article about the project and its use with CANopen emulation
- http://cmp.felk.cvut.cz/~pisa/can/doc/rtlws-17-pisa-qemu-can.pdf
- (5) GNU/Linux, CAN and CANopen in Real-time Control Applications
- Slides from LinuxDays 2017 (include updated RTLWS 2015 content)
- https://www.linuxdays.cz/2017/video/Pavel_Pisa-CAN_canopen.pdf
- (6) Linux SocketCAN utilities
- https://github.com/linux-can/can-utils/
- (7) CTU CAN FD project including core VHDL design, Linux driver,
- test utilities etc.
- https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core
- (8) CTU CAN FD Core Datasheet Documentation
- http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/Progdokum.pdf
- (9) CTU CAN FD Core System Architecture Documentation
- http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/ctu_can_fd_architecture.pdf
- (10) CTU CAN FD Driver Documentation
- http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/driver_doc/ctucanfd-driver.html
- (11) Integration with PCIe interfacing for Intel/Altera Cyclone IV based board
- https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd
+------------------------
+
+ (1) `CAN related projects at Czech Technical University, Faculty of Electrical Engineering <http://canbus.pages.fel.cvut.cz>`_
+ (2) `Repository with development can-pci branch at Czech Technical University <https://gitlab.fel.cvut.cz/canbus/qemu-canbus>`_
+ (3) `RTEMS page describing project <https://devel.rtems.org/wiki/Developer/Simulators/QEMU/CANEmulation>`_
+ (4) `RTLWS 2015 article about the project and its use with CANopen emulation <http://cmp.felk.cvut.cz/~pisa/can/doc/rtlws-17-pisa-qemu-can.pdf>`_
+ (5) `GNU/Linux, CAN and CANopen in Real-time Control Applications Slides from LinuxDays 2017 (include updated RTLWS 2015 content) <https://www.linuxdays.cz/2017/video/Pavel_Pisa-CAN_canopen.pdf>`_
+ (6) `Linux SocketCAN utilities <https://github.com/linux-can/can-utils>`_
+ (7) `CTU CAN FD project including core VHDL design, Linux driver, test utilities etc. <https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core>`_
+ (8) `CTU CAN FD Core Datasheet Documentation <http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/Progdokum.pdf>`_
+ (9) `CTU CAN FD Core System Architecture Documentation <http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/ctu_can_fd_architecture.pdf>`_
+ (10) `CTU CAN FD Driver Documentation <http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/driver_doc/ctucanfd-driver.html>`_
+ (11) `Integration with PCIe interfacing for Intel/Altera Cyclone IV based board <https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd>`_
diff --git a/docs/system/index.rst b/docs/system/index.rst
index 73bbedbc22..70bf4863a4 100644
--- a/docs/system/index.rst
+++ b/docs/system/index.rst
@@ -34,3 +34,4 @@ or Hypervisor.Framework.
targets
security
multi-process
+ can
--
2.30.2
^ permalink raw reply related
* Re: [PATCH -next] ieee802154: atusb: move to new USB API
From: Pavel Skripkin @ 2022-01-05 20:58 UTC (permalink / raw)
To: Stefan Schmidt, alex.aring, davem, kuba, linux-wpan, netdev,
linux-kernel
In-Reply-To: <4186d48a-ea7e-39c1-d1fa-1db3f6627a3a@datenfreihafen.org>
Hi Stefan,
On 1/5/22 23:27, Stefan Schmidt wrote:
>> + ret = usb_control_msg_recv(usb_dev, 0, ATUSB_REG_READ, ATUSB_REQ_FROM_DEV,
>> + 0, RG_PART_NUM, &atusb, 1, 1000, GFP_KERNEL);
>
> This needs to be written to &part_num and not &atusb.
>
Oh, stupid copy-paste error :( Thanks for catching this!
> Pretty nice for a first blind try without hardware. Thanks.
>
> Will let you know if I find anything else from testing.
Ok, will wait for test results. Thank you for your time ;)
With regards,
Pavel Skripkin
^ permalink raw reply
* Re: [PATCH] Revert "clk: Detect failure to set defaults"
From: Tom Rini @ 2022-01-05 20:57 UTC (permalink / raw)
To: Marek Vasut
Cc: Sean Anderson, u-boot, Peng Fan, Simon Glass, Mark Kettenis,
lukma
In-Reply-To: <8eeb3c16-10ef-2f06-b211-f34ea7e890ac@denx.de>
[-- Attachment #1: Type: text/plain, Size: 4240 bytes --]
On Wed, Jan 05, 2022 at 08:56:50PM +0100, Marek Vasut wrote:
> On 1/5/22 20:37, Tom Rini wrote:
> > On Wed, Jan 05, 2022 at 08:35:19PM +0100, Marek Vasut wrote:
> > > On 1/1/22 22:41, Sean Anderson wrote:
> > > > Hi Marek,
> > >
> > > Hi,
> > >
> > > > Please CC clock maintainers for future patches.
> > >
> > > btw. I'm surprised the commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646 has
> > > zero reviews/acks from clock maintainers.
> > >
> > > > On 1/1/22 1:51 PM, Marek Vasut wrote:
> > > > > This reverts commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646.
> > > > > The aforementioned patch causes massive breakage on all platforms which
> > > > > have 'assigned-clock' DT property in their DT which references any clock
> > > > > that are not supported by the platform clock driver. That can easily
> > > > > happen either in SPL, or because the clock driver is reduced. Currently
> > > > > it seems all iMX8M are affected and fail to boot altogether.
> > > > >
> > > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > > > Cc: Peng Fan <peng.fan@oss.nxp.com>
> > > > > Cc: Simon Glass <sjg@chromium.org>
> > > > > ---
> > > > > drivers/clk/clk-uclass.c | 6 +-----
> > > > > 1 file changed, 1 insertion(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> > > > > index f2d26427543..094b1abf13c 100644
> > > > > --- a/drivers/clk/clk-uclass.c
> > > > > +++ b/drivers/clk/clk-uclass.c
> > > > > @@ -846,17 +846,13 @@ void devm_clk_put(struct udevice *dev, struct
> > > > > clk *clk)
> > > > > int clk_uclass_post_probe(struct udevice *dev)
> > > > > {
> > > > > - int ret;
> > > > > -
> > > > > /*
> > > > > * when a clock provider is probed. Call clk_set_defaults()
> > > > > * also after the device is probed. This takes care of cases
> > > > > * where the DT is used to setup default parents and rates
> > > > > * using assigned-clocks
> > > > > */
> > > > > - ret = clk_set_defaults(dev, CLK_DEFAULTS_POST);
> > > > > - if (ret)
> > > > > - return log_ret(ret);
> > > > > + clk_set_defaults(dev, CLK_DEFAULTS_POST);
> > > > > return 0;
> > > > > }
> > > > >
> > > >
> > > > See [1] for previous discussion. For more background,
> > > >
> > > > - Device trees for i.MX are sync'd with Linux.
> > > > - General clock assignments may live in the clock-controller node,
> > >
> > > clock assignments can be anywhere, even in non-clock-controller nodes.
> > >
> > > > including those which U-Boot does not implement, but which Linux does.
> > > > It's OK to not set up these clocks, but U-Boot doesn't know that and
> > > > fails.
> > > >
> > > > We don't necessarily need to revert this commit, but we do need a way to
> > > > say "it's OK not to set the defaults, since we can function without
> > > > them". Tom suggested doing this in the clock driver last time. I think a
> > > > Kconfig or a device tree property would work, perhaps something like
> > > > 'u-boot,clock-defaults-optional'.
> > >
> > > We didn't need custom DT properties before, Linux doesn't need them either,
> > > so that approach seems wrong.
> > >
> > > If the clock driver could say "skip unimplemented clock, because I don't
> > > implement them and that is OK", that sounds like the right approach.
> > >
> > > Unless the 2022.01 release should be completely broken for a lot of
> > > platforms, I would propose we revert the clock uclass patch now and re-add
> > > it right after the release, so we would not roll out a completely broken
> > > release and would have more time to fix this properly.
> >
> > It'll be no more broken than v2021.10 was for whatever platforms have
> > problems here, yes? Since that's what has the problematic commit.
>
> So it seems. Does that mean we are OK with releasing such a broken release,
> even though there is an easy way to improve the situation ?
I will defer to the clock maintainer who I see agrees with your patch.
I was just noting that we'd already shipped one release so a last minute
revert is not something I'm happy about either.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply
* Re: [PATCH] net: usb: r8152: Check used MAC passthrough address
From: Henning Schild @ 2022-01-05 20:57 UTC (permalink / raw)
To: Florian Fainelli
Cc: Aaron Ma, kuba, linux-usb, netdev, linux-kernel, davem, hayeswang,
tiwai, Kai-Heng Feng, David Chen, Mario Limonciello
In-Reply-To: <32b9e331-2c1d-6a7d-ca38-57cec50b240c@gmail.com>
Am Wed, 5 Jan 2022 11:55:06 -0800
schrieb Florian Fainelli <f.fainelli@gmail.com>:
> On 1/5/22 12:37 AM, Aaron Ma wrote:
> >
> >
> > On 1/5/22 16:32, Henning Schild wrote:
> >> Am Wed, 5 Jan 2022 16:01:24 +0800
> >> schrieb Aaron Ma <aaron.ma@canonical.com>:
> >>
> >>> On 1/5/22 15:55, Henning Schild wrote:
> >>>> Am Wed, 5 Jan 2022 15:38:51 +0800
> >>>> schrieb Aaron Ma <aaron.ma@canonical.com>:
> >>>>
> >>>>> On 1/5/22 15:32, Henning Schild wrote:
> >>>>>> Am Wed, 5 Jan 2022 08:23:55 +0100
> >>>>>> schrieb Henning Schild <henning.schild@siemens.com>:
> >>>>>>
> >>>>>>> Hi Aaron,
> >>>>>>>
> >>>>>>> if this or something similar goes in, please add another
> >>>>>>> patch to remove the left-over defines.
> >>>>>>>
> >>>>>
> >>>>> Sure, I will do it.
> >>>>>
> >>>>>>> Am Wed, 5 Jan 2022 14:17:47 +0800
> >>>>>>> schrieb Aaron Ma <aaron.ma@canonical.com>:
> >>>>>>>
> >>>>>>>> When plugin multiple r8152 ethernet dongles to Lenovo Docks
> >>>>>>>> or USB hub, MAC passthrough address from BIOS should be
> >>>>>>>> checked if it had been used to avoid using on other dongles.
> >>>>>>>>
> >>>>>>>> Currently builtin r8152 on Dock still can't be identified.
> >>>>>>>> First detected r8152 will use the MAC passthrough address.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
> >>>>>>>> ---
> >>>>>>>> drivers/net/usb/r8152.c | 10 ++++++++++
> >>>>>>>> 1 file changed, 10 insertions(+)
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/net/usb/r8152.c
> >>>>>>>> b/drivers/net/usb/r8152.c index f9877a3e83ac..77f11b3f847b
> >>>>>>>> 100644 --- a/drivers/net/usb/r8152.c
> >>>>>>>> +++ b/drivers/net/usb/r8152.c
> >>>>>>>> @@ -1605,6 +1605,7 @@ static int
> >>>>>>>> vendor_mac_passthru_addr_read(struct r8152 *tp, struct
> >>>>>>>> sockaddr *sa) char *mac_obj_name; acpi_object_type
> >>>>>>>> mac_obj_type; int mac_strlen;
> >>>>>>>> + struct net_device *ndev;
> >>>>>>>> if (tp->lenovo_macpassthru) {
> >>>>>>>> mac_obj_name = "\\MACA";
> >>>>>>>> @@ -1662,6 +1663,15 @@ static int
> >>>>>>>> vendor_mac_passthru_addr_read(struct r8152 *tp, struct
> >>>>>>>> sockaddr *sa) ret = -EINVAL; goto amacout;
> >>>>>>>> }
> >>>>>>>> + rcu_read_lock();
> >>>>>>>> + for_each_netdev_rcu(&init_net, ndev) {
> >>>>>>>> + if (strncmp(buf, ndev->dev_addr, 6) == 0) {
> >>>>>>>> + rcu_read_unlock();
> >>>>>>>> + goto amacout;
> >>>>>>>
> >>>>>>> Since the original PCI netdev will always be there, that would
> >>>>>>> disable inheritance would it not?
> >>>>>>> I guess a strncmp(MODULE_NAME, info->driver,
> >>>>>>> strlen(MODULE_NAME)) is needed as well.
> >>>>>>>
> >>>>>
> >>>>> PCI ethernet could be a builtin one on dock since there will be
> >>>>> TBT4 dock.
> >>>>
> >>>> In my X280 there is a PCI device in the laptop, always there. And
> >>>> its MAC is the one found in ACPI. Did not try but i think for
> >>>> such devices there would never be inheritance even if one wanted
> >>>> and used a Lenovo dock that is supposed to do it.
> >>>>
> >>>
> >>> There will more TBT4 docks in market, the new ethernet is just the
> >>> same as PCI device, connected by thunderbolt.
> >>>
> >>> For exmaple, connect a TBT4 dock which uses i225 pcie base
> >>> ethernet, then connect another TBT3 dock which uses r8152.
> >>> If skip PCI check, then i225 and r8152 will use the same MAC.
> >>
> >> In current 5.15 i have that sort of collision already. All r8152s
> >> will happily grab the MAC of the I219. In fact i have only ever
> >> seen it with one r8152 at a time but while the I219 was actively
> >> in use. While this patch will probably solve that, i bet it would
> >> defeat MAC pass-thru altogether. Even when turned on in the BIOS.
> >> Or does that iterator take "up"/"down" state into consideration?
> >> But even if, the I219 could become "up" any time later.
> >>
> >
> > No, that's different, I219 got MAC from their own space.
> > MAC passthrough got MAC from ACPI "\MACA".
> >
> >> These collisions are simply bound to happen and probably very hard
> >> to avoid once you have set your mind on allowing pass-thru in the
> >> first place. Not sure whether that even has potential to disturb
> >> network equipment like switches.
> >>
> >
> > After check MAC address, it will be more safe.
>
> Sorry to just do a drive by review here, but why is passing through
> the MAC a kernel problem and not something that you punt to
> user-space entirely?
Agreed and several other people seem to feel the same way about
pass-thru not deserving a place in the kernel.
This all dates back to 34ee32c9a5696247be405bb0c21f3d1fc6cb5729
and some other patches that came later
9647722befbedcd6735e00655ffec392c05f0c56
c286909fe5458f69e533c845b757fd2c35064d26
8e29d23e28ee7fb995a00c1ca7e1a4caf5070b12
9c27369f4a1393452c17e8708c1b0beb8ac59501
Maybe other drivers are affected as well.
All of the patches should probably be reverted. If people care enough
they can try and get it into udev.
All patches put policy into the kernel, do weird ACPI lookups and cause
MAC conflicts with NICs that might be up and running. And will claim too
many r8512 devices in case there are multiple.
I propose to revert all of this or maybe add a module param (which
should probably default to "off") just to give people a way to preserve
their hacks.
If the BIOS did spoof we could try to keep that, but spoofing in the OS
(at least in the kernel) sound very wrong and caused me to start the
whole discussion after all my r8521 dongles all of a sudden had the
same (already busy) MAC when moving to v5.15. That was on a Lenovo
laptop but i am pretty sure Dell and HP would be affected as well.
When using another NIC you get another MAC, it is that simple. If that
causes issues with DHCP/PXE deal with it. A MAC does not id a machine,
maybe x509 radius does. Not a kernel story!
Henning
^ permalink raw reply
* Re: [PATCH v8 08/19] ima: Use mac_admin_ns_capable() to check corresponding capability
From: kernel test robot @ 2022-01-05 20:55 UTC (permalink / raw)
To: Stefan Berger, linux-integrity
Cc: llvm, kbuild-all, zohar, serge, christian.brauner, containers,
dmitry.kasatkin, ebiederm, krzysztof.struczynski, roberto.sassu,
mpeters
In-Reply-To: <20220104170416.1923685-9-stefanb@linux.vnet.ibm.com>
Hi Stefan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linux/master]
[also build test WARNING on linus/master v5.16-rc8]
[cannot apply to zohar-integrity/next-integrity jmorris-security/next-testing next-20220105]
[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/Stefan-Berger/ima-Namespace-IMA-with-audit-support-in-IMA-ns/20220105-010946
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 136057256686de39cc3a07c2e39ef6bc43003ff6
config: mips-randconfig-r002-20220105 (https://download.01.org/0day-ci/archive/20220106/202201060430.LHZbFhad-lkp@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project d5b6e30ed3acad794dd0aec400e617daffc6cc3d)
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 mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
# https://github.com/0day-ci/linux/commit/fa09a3da70380ef32e9a644c08a04cc8f4630baf
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Stefan-Berger/ima-Namespace-IMA-with-audit-support-in-IMA-ns/20220105-010946
git checkout fa09a3da70380ef32e9a644c08a04cc8f4630baf
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=mips SHELL=/bin/bash drivers/nvmem/ security/integrity/ima/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> security/integrity/ima/ima_fs.c:380:25: warning: unused variable 'user_ns'
struct user_namespace = ima_user_ns_from_file(filp);
^
fatal error: error in backend: Nested variants found in inline asm string: ' .set push
.set mips64r2
.if ( 0x00 ) != -1)) 0x00 ) != -1)) : ($( static struct ftrace_branch_data __attribute__((__aligned__(4))) __attribute__((__section__("_ftrace_branch"))) __if_trace = $( .func = __func__, .file = "arch/mips/include/asm/bitops.h", .line = 192, $); 0x00 ) != -1)) : $))) ) && ( 0 ); .set push; .set mips64r2; .rept 1; sync 0x00; .endr; .set pop; .else; ; .endif
1: ll $0, $2
or $1, $0, $3
sc $1, $2
beqz $1, 1b
.set pop
'
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: clang -Wp,-MMD,security/integrity/ima/.ima_fs.o.d -nostdinc -Iarch/mips/include -I./arch/mips/include/generated -Iinclude -I./include -Iarch/mips/include/uapi -I./arch/mips/include/generated/uapi -Iinclude/uapi -I./include/generated/uapi -include include/linux/compiler-version.h -include include/linux/kconfig.h -include include/linux/compiler_types.h -D__KERNEL__ -DVMLINUX_LOAD_ADDRESS=0xffffffff84000000 -DLINKER_LOAD_ADDRESS=0x84000000 -DDATAOFFSET=0 -Qunused-arguments -fmacro-prefix-map== -DKBUILD_EXTRA_WARN1 -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 --target=mipsel-linux -fintegrated-as -Werror=unknown-warning-option -Werror=ignored-optimization-argument -mno-check-zero-division -mabi=32 -G 0 -mno-abicalls -fno-pic -pipe -msoft-float -DGAS_HAS_SET_HARDFLOAT -Wa,-msoft-float -ffreestanding -EL -fno-stack-check -march=mips32 -Wa,--trap -DTOOLCHAIN_SUPPORTS_VIRT -Iarch/mips/include/asm/mach-au1x00 -Iarch/mips/include/asm/mach-generic -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-address-of-packed-member -O2 -Wframe-larger-than=1024 -fno-stack-protector -Wimplicit-fallthrough -Wno-gnu -mno-global-merge -Wno-unused-but-set-variable -Wno-unused-const-variable -ftrivial-auto-var-init=pattern -fno-stack-clash-protection -pg -falign-functions=64 -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-array-bounds -fno-strict-overflow -fno-stack-check -Werror=date-time -Werror=incompatible-pointer-types -Wextra -Wunused -Wno-unused-parameter -Wmissing-declarations -Wmissing-format-attribute -Wmissing-prototypes -Wold-style-definition -Wmissing-include-dirs -Wunused-but-set-variable -Wunused-const-variable -Wno-missing-field-initializers -Wno-sign-compare -Wno-type-limits -fsanitize=array-bounds -fsanitize=unreachable -fsanitize=object-size -fsanitize=enum -fsanitize-coverage=trace-pc -I security/integrity/ima -I ./security/integrity/ima -ffunction-sections -fdata-sections -DKBUILD_MODFILE="security/integrity/ima/ima" -DKBUILD_BASENAME="ima_fs" -DKBUILD_MODNAME="ima" -D__KBUILD_MODNAME=kmod_ima -c -o security/integrity/ima/ima_fs.o security/integrity/ima/ima_fs.c
1. <eof> parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'security/integrity/ima/ima_fs.c'.
4. Running pass 'Mips Assembly Printer' on function '@ima_open_policy'
#0 0x0000557a749c4b3f Signals.cpp:0:0
#1 0x0000557a749c2a8c llvm::sys::CleanupOnSignal(unsigned long) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3401a8c)
#2 0x0000557a74906667 llvm::CrashRecoveryContext::HandleExit(int) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3345667)
#3 0x0000557a749bb13e llvm::sys::Process::Exit(int, bool) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x33fa13e)
#4 0x0000557a7264133b (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x108033b)
#5 0x0000557a7490d10c llvm::report_fatal_error(llvm::Twine const&, bool) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x334c10c)
#6 0x0000557a755ef9b8 llvm::AsmPrinter::emitInlineAsm(llvm::MachineInstr const (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x402e9b8)
#7 0x0000557a755eb759 llvm::AsmPrinter::emitFunctionBody() (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x402a759)
#8 0x0000557a7309c82e llvm::MipsAsmPrinter::runOnMachineFunction(llvm::MachineFunction&) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x1adb82e)
#9 0x0000557a73d332fd llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.53) MachineFunctionPass.cpp:0:0
#10 0x0000557a7416b867 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x2baa867)
#11 0x0000557a7416b9e1 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x2baa9e1)
#12 0x0000557a7416ccbf llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x2babcbf)
#13 0x0000557a74cd64fa clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x37154fa)
#14 0x0000557a75903ea3 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x4342ea3)
#15 0x0000557a76407fd9 clang::ParseAST(clang::Sema&, bool, bool) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x4e46fd9)
#16 0x0000557a75902cff clang::CodeGenAction::ExecuteAction() (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x4341cff)
#17 0x0000557a75302001 clang::FrontendAction::Execute() (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3d41001)
#18 0x0000557a75299bda clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3cd8bda)
#19 0x0000557a753cb07b (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3e0a07b)
#20 0x0000557a72642084 cc1_main(llvm::ArrayRef<char char (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x1081084)
#21 0x0000557a7263f5cb ExecuteCC1Tool(llvm::SmallVectorImpl<char driver.cpp:0:0
#22 0x0000557a75136b15 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> const::'lambda'()>(long) Job.cpp:0:0
#23 0x0000557a74906523 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3345523)
#24 0x0000557a7513740e clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> const (.part.216) Job.cpp:0:0
#25 0x0000557a7510dee7 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3b4cee7)
#26 0x0000557a7510e8c7 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command >&) const (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3b4d8c7)
#27 0x0000557a75118139 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command >&) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3b57139)
#28 0x0000557a7256a19f main (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0xfa919f)
#29 0x00007fc0e7a42d0a __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26d0a)
#30 0x0000557a7263f0ea _start (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x107e0ea)
clang-14: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 14.0.0 (git://gitmirror/llvm_project d5b6e30ed3acad794dd0aec400e617daffc6cc3d)
Target: mipsel-unknown-linux
Thread model: posix
InstalledDir: /opt/cross/clang-d5b6e30ed3/bin
clang-14: note: diagnostic msg:
Makefile arch drivers include kernel nr_bisected scripts security source usr
vim +/user_ns +380 security/integrity/ima/ima_fs.c
374
375 /*
376 * ima_open_policy: sequentialize access to the policy file
377 */
378 static int ima_open_policy(struct inode *inode, struct file *filp)
379 {
> 380 struct user_namespace *user_ns = ima_user_ns_from_file(filp);
381 struct ima_namespace *ns = &init_ima_ns;
382
383 if (!(filp->f_flags & O_WRONLY)) {
384 #ifndef CONFIG_IMA_READ_POLICY
385 return -EACCES;
386 #else
387 if ((filp->f_flags & O_ACCMODE) != O_RDONLY)
388 return -EACCES;
389 if (!mac_admin_ns_capable(user_ns))
390 return -EPERM;
391 return seq_open(filp, &ima_policy_seqops);
392 #endif
393 }
394 if (test_and_set_bit(IMA_FS_BUSY, &ns->ima_fs_flags))
395 return -EBUSY;
396 return 0;
397 }
398
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [net-next 12/18] net: mac802154: Handle scan requests
From: Miquel Raynal @ 2022-01-05 20:55 UTC (permalink / raw)
To: Alexander Aring
Cc: Nicolas Schodet, David S. Miller, Jakub Kicinski,
open list:NETWORKING [GENERAL], Stefan Schmidt, linux-wpan - ML,
David Girault, Romuald Despres, Frederic Blain, Thomas Petazzoni,
kernel list
In-Reply-To: <CAB_54W5quZz8rVrbdx+cotTRZZpJ4ouRDZkxeW6S1L775Si=cw@mail.gmail.com>
Hi Alexander,
alex.aring@gmail.com wrote on Tue, 4 Jan 2022 20:16:30 -0500:
> Hi.
>
> On Tue, 4 Jan 2022 at 13:18, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Alexander,
> >
> ...
> > >
> > > I see now why promiscuous mode is necessary here. The actual
> > > promiscuous mode setting for the driver is not the same as promiscuous
> > > mode in 802.15.4 spec. For until now it was there for running a
> > > sniffer device only.
> > > As the 802.15.4 spec defines some "filtering levels" I came up with a
> > > draft so we can define which filtering level should be done on the
> > > hardware.
> >
> > I like the idea but I'm not sure on what side you want to tackle the
> > problem first. Is it the phy drivers which should advertise the mac
> > about the promiscuous mode they support (which matches the description
> > below but does not fit the purpose of an enum very well)? Or is it the
> > MAC that requests a particular filtering mode? In this case what a phy
> > driver should do if:
> > - the requested mode is more constrained than its usual promiscuous
> > capabilities?
>
> Then, the driver needs to go one level lower and tell mac802154 to
> filter more out.
>
> > - the requested mode is less constrained than its usual promiscuous
> > capabilities?
> >
>
> Then mac802154 needs to filter more out.
>
> I am more worried at the point the transceiver will shut off automatic
> acknowledge handling which we probably can't do in software in cases
> where it's required. Some transceivers will shut that off if they turn
> off address filtering and if they don't have a detailed setting for
> that they will ack every frame what they see, which is... not so good.
>
> Future work would be to warn about mismatch of seeing frames, what the
> hardware would filter out vs what mac802154 sees. More further work
> could be to use a monitor interface and raw sockets and verify
> transceivers how they act to frames.
>
> > >
> > > diff --git a/include/net/mac802154.h b/include/net/mac802154.h
> > > index 72978fb72a3a..3839ed3f8f0d 100644
> > > --- a/include/net/mac802154.h
> > > +++ b/include/net/mac802154.h
> > > @@ -130,6 +130,48 @@ enum ieee802154_hw_flags {
> > > #define IEEE802154_HW_OMIT_CKSUM (IEEE802154_HW_TX_OMIT_CKSUM | \
> > > IEEE802154_HW_RX_OMIT_CKSUM)
> > >
> > > +/**
> > > + * enum ieee802154_filter_mode - hardware filter mode that a driver
> > > will pass to
> > > + * pass to mac802154.
> >
> > Isn't it the opposite: The filtering level the mac is requesting? Here
> > it looks like we are describing driver capabilities (ie what drivers
> > advertise supporting).
> >
>
> I am sorry. I meant what the transceiver "should" deliver or "level
> less" to mac802154.
>
> I think the filtering when not much resources are required can also be
> done in a hardirq context. There exists a tasklet which is there to
> switch to a softirq context [0], currently we do all parsing there.
>
> > > + *
> > > + * @IEEE802154_FILTER_MODE_0: No MFR filtering at all.
> >
> > I suppose this would be for a sniffer accepting all frames, including
> > the bad ones.
> >
>
> yes.
>
> > > + *
> > > + * @IEEE802154_FILTER_MODE_1: IEEE802154_FILTER_MODE_1 with a bad FCS filter.
> >
> > This means that the driver should only discard bad frames and propagate
> > all the remaining frames, right? So this typically is a regular sniffer
> > mode.
> >
>
> I think this depends on what you want to filter out, so far I know in
> wireless this is configurable. Wireshark always expects the FCS in
> their payload for a linux 802.15.4 monitor interface and I think this
> is because of some historical reason to support the first 802.15.4
> sniffers in wireshark.
> There is a difference between filter bad FCS and cutoff FCS. I need to
> look it up but I think wireless would cut off the checksum if FCS is
> filtered on hardware (may even some transceivers will not deliver FCS
> to you if you enable filtering).
>
> > > + *
> > > + * @IEEE802154_FILTER_MODE_2: Same as IEEE802154_FILTER_MODE_1, known as
> > > + * 802.15.4 promiscuous mode, sets
> > > + * mib.PromiscuousMode.
> >
> > I believe what you call mib.PromiscuousMode is the mode that is
> > referred in the spec, ie. being in the official promiscuous mode? So
> > that is the mode that should be used "by default" when really asking
> > for a 802154 promiscuous mode.
> >
>
> then we don't call it in driver level promiscuous mode, we call it
> "filtering level". And this is the filtering for cases when the
> standard says set "mib.PromiscuousMode".
>
> > Is there really a need for a different mode than mode_1 ?
> >
>
> I think so, I am not sure what they or will define if PromiscuousMode
> is set or not and might the transceiver need to get notice about it?
> It's not needed now, but we might keep it in mind then.
>
> > > + *
> > > + * @IEEE802154_FILTER_MODE_3_SCAN: Same as IEEE802154_FILTER_MODE_2 without
> > > + * set mib.PromiscuousMode.
> >
> > And here what is the difference between MODE_1 and MODE_3 ?
> >
> > I suppose here we should as well drop all non-beacon frames?
>
> Yes, additionally there could be a transceiver doing this filtering on
> hardware and tell that it's in scan and this is the difference.
>
> >
> > > + *
> > > + * @IEEE802154_FILTER_MODE_3_NO_SCAN:
> > > + * IEEE802154_FILTER_MODE_3_SCAN with MFR additional filter on:
> > > + *
>
> should be IEEE802154_FILTER_MODE_2. Maybe we can also get some better
> names for that but the standard describes it with numbers as well.
>
> > > + * - No reserved value in frame type
> > > + * - No reserved value in frame version
> > > + * - Match mib.PanId or broadcast
> > > + * - Destination address field:
> > > + * - Match mib.ShortAddress or broadcast
> > > + * - Match mib.ExtendedAddress or GroupRxMode is true
> > > + * - ImplicitBroadcast is true and destination address field/destination
> > > + * panid is not included.
> > > + * - Device is coordinator only source address present in data
> > > + * frame/command frame and source panid matches mib.PanId
> > > + * - Device is coordinator only source address present in multipurpose
> > > + * frame and destination panid matches macPanId
> > > + * - Beacon frames source panid matches mib.PanId. If mib.PanId is
> > > + * broadcast it should always be accepted.
> >
> > This is a bit counter intuitive, but do we agree on the fact that the
> > higher level of filtering should refer to promiscuous = false?
> >
>
> Yes, it's a lot of filter rules at this level.
> Yes, promiscuous is false in this case. That is what currently what
> wpan "node" interface should filter at mac802154 [1] (for cases device
> coordinator is false).
>
> I might mention a lot of future work here. I think we can live for now
> to make a difference between those levels and be sure that we drop
> everything else in the scan operation (inclusive check fcs in
> software). Moving stuff that we can do in hardware to hardware and the
> rest in software is a bigger task here...
On the symbol duration side I feel I'm close to a working PoC.
So there is 'only' this item left in my mind. Could you please clarify
what you expect from me exactly in terms of support for the promiscuous
filters we discussed so far?
Also, just for the record,
- should I keep copying the netdev list for v2?
- should I monitor if net-next is open before sending or do you have
your own set of rules?
> [0] https://elixir.bootlin.com/linux/v5.16-rc8/source/net/mac802154/rx.c#L294
> [1] https://elixir.bootlin.com/linux/v5.16-rc8/source/net/mac802154/rx.c#L132
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH bpf-next v2 3/4] ice: xsk: improve AF_XDP ZC Tx and use batching API
From: Alexei Starovoitov @ 2022-01-05 20:55 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Maciej Fijalkowski, bpf, Alexei Starovoitov, Daniel Borkmann,
Network Development, Karlsson, Magnus, Jakub Kicinski,
David S. Miller
In-Reply-To: <20211230160755.26019-1-alexandr.lobakin@intel.com>
On Thu, Dec 30, 2021 at 8:09 AM Alexander Lobakin
<alexandr.lobakin@intel.com> wrote:
>
> From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Date: Thu, 30 Dec 2021 14:13:10 +0100
>
> > On Wed, Dec 29, 2021 at 02:11:31PM +0100, Alexander Lobakin wrote:
> > > From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> > > Date: Thu, 16 Dec 2021 14:59:57 +0100
> > >
> > > > Follow mostly the logic from commit 9610bd988df9 ("ice: optimize XDP_TX
> > > > workloads") that has been done in order to address the massive tx_busy
> > > > statistic bump and improve the performance as well.
> > > >
> > > > Increase the ICE_TX_THRESH to 64 as it seems to work out better for both
> > > > XDP and AF_XDP. Also, separating the stats structs onto separate cache
> > > > lines seemed to improve the performance. Batching approach is inspired
> > > > by i40e's implementation with adjustments to the cleaning logic.
> > > >
> > > > One difference from 'xdpdrv' XDP_TX is when ring has less than
> > > > ICE_TX_THRESH free entries, the cleaning routine will not stop after
> > > > cleaning a single ICE_TX_THRESH amount of descs but rather will forward
> > > > the next_dd pointer and check the DD bit and for this bit being set the
> > > > cleaning will be repeated. IOW clean until there are descs that can be
> > > > cleaned.
> > > >
> > > > It takes three separate xdpsock instances in txonly mode to achieve the
> > > > line rate and this was not previously possible.
> > > >
> > > > Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> > > > ---
> > > > drivers/net/ethernet/intel/ice/ice_txrx.c | 2 +-
> > > > drivers/net/ethernet/intel/ice/ice_txrx.h | 4 +-
> > > > drivers/net/ethernet/intel/ice/ice_xsk.c | 249 ++++++++++++++--------
> > > > drivers/net/ethernet/intel/ice/ice_xsk.h | 26 ++-
> > > > 4 files changed, 182 insertions(+), 99 deletions(-)
> > > >
> > >
> > > -- 8< --
> > >
> > > > diff --git a/drivers/net/ethernet/intel/ice/ice_xsk.h b/drivers/net/ethernet/intel/ice/ice_xsk.h
> > > > index 4c7bd8e9dfc4..f2eb99063c1f 100644
> > > > --- a/drivers/net/ethernet/intel/ice/ice_xsk.h
> > > > +++ b/drivers/net/ethernet/intel/ice/ice_xsk.h
> > > > @@ -6,19 +6,36 @@
> > > > #include "ice_txrx.h"
> > > > #include "ice.h"
> > > >
> > > > +#define PKTS_PER_BATCH 8
> > > > +
> > > > +#ifdef __clang__
> > > > +#define loop_unrolled_for _Pragma("clang loop unroll_count(8)") for
> > > > +#elif __GNUC__ >= 4
> > > > +#define loop_unrolled_for _Pragma("GCC unroll 8") for
> > > > +#else
> > > > +#define loop_unrolled_for for
> > > > +#endif
> > >
> > > It's used in a bunch more places across the tree, what about
> > > defining that in linux/compiler{,_clang,_gcc}.h?
> > > Is it possible to pass '8' as an argument? Like
> >
> > Like where besides i40e? I might currently suck at grepping, let's blame
> > christmas break for that.
>
> Ah okay, I confused it with a work around this pragma here: [0]
>
> >
> > If there are actually other callsites besides i40e then this is a good
> > idea to me, maybe as a follow-up?
>
> I think there are more potential call sites for that to come, I'd
> make linux/unroll.h in the future I guess. But not as a part of
> this series, right.
Please don't, since loop unroll pragma is a hint.
The compilers don't have to actually do the unroll.
Both gcc and clang try to do it when it looks ok-ish from
compiler perspective, but they don't have to.
Try large unroll values and check the code.
Ideally add compiler debug flags, so it can tell what it's actually doing.
It's hard to figure out loop unroll factor looking at the assembly.
^ permalink raw reply
* Re: [PATCH v8 08/19] ima: Use mac_admin_ns_capable() to check corresponding capability
From: kernel test robot @ 2022-01-05 20:55 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20220104170416.1923685-9-stefanb@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 11107 bytes --]
Hi Stefan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linux/master]
[also build test WARNING on linus/master v5.16-rc8]
[cannot apply to zohar-integrity/next-integrity jmorris-security/next-testing next-20220105]
[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/Stefan-Berger/ima-Namespace-IMA-with-audit-support-in-IMA-ns/20220105-010946
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 136057256686de39cc3a07c2e39ef6bc43003ff6
config: mips-randconfig-r002-20220105 (https://download.01.org/0day-ci/archive/20220106/202201060430.LHZbFhad-lkp(a)intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project d5b6e30ed3acad794dd0aec400e617daffc6cc3d)
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 mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
# https://github.com/0day-ci/linux/commit/fa09a3da70380ef32e9a644c08a04cc8f4630baf
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Stefan-Berger/ima-Namespace-IMA-with-audit-support-in-IMA-ns/20220105-010946
git checkout fa09a3da70380ef32e9a644c08a04cc8f4630baf
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=mips SHELL=/bin/bash drivers/nvmem/ security/integrity/ima/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> security/integrity/ima/ima_fs.c:380:25: warning: unused variable 'user_ns'
struct user_namespace = ima_user_ns_from_file(filp);
^
fatal error: error in backend: Nested variants found in inline asm string: ' .set push
.set mips64r2
.if ( 0x00 ) != -1)) 0x00 ) != -1)) : ($( static struct ftrace_branch_data __attribute__((__aligned__(4))) __attribute__((__section__("_ftrace_branch"))) __if_trace = $( .func = __func__, .file = "arch/mips/include/asm/bitops.h", .line = 192, $); 0x00 ) != -1)) : $))) ) && ( 0 ); .set push; .set mips64r2; .rept 1; sync 0x00; .endr; .set pop; .else; ; .endif
1: ll $0, $2
or $1, $0, $3
sc $1, $2
beqz $1, 1b
.set pop
'
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: clang -Wp,-MMD,security/integrity/ima/.ima_fs.o.d -nostdinc -Iarch/mips/include -I./arch/mips/include/generated -Iinclude -I./include -Iarch/mips/include/uapi -I./arch/mips/include/generated/uapi -Iinclude/uapi -I./include/generated/uapi -include include/linux/compiler-version.h -include include/linux/kconfig.h -include include/linux/compiler_types.h -D__KERNEL__ -DVMLINUX_LOAD_ADDRESS=0xffffffff84000000 -DLINKER_LOAD_ADDRESS=0x84000000 -DDATAOFFSET=0 -Qunused-arguments -fmacro-prefix-map== -DKBUILD_EXTRA_WARN1 -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 --target=mipsel-linux -fintegrated-as -Werror=unknown-warning-option -Werror=ignored-optimization-argument -mno-check-zero-division -mabi=32 -G 0 -mno-abicalls -fno-pic -pipe -msoft-float -DGAS_HAS_SET_HARDFLOAT -Wa,-msoft-float -ffreestanding -EL -fno-stack-check -march=mips32 -Wa,--trap -DTOOLCHAIN_SUPPORTS_VIRT -Iarch/mips/include/asm/mach-au1x00 -Iarch/mips/include/asm/mach-generic -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-address-of-packed-member -O2 -Wframe-larger-than=1024 -fno-stack-protector -Wimplicit-fallthrough -Wno-gnu -mno-global-merge -Wno-unused-but-set-variable -Wno-unused-const-variable -ftrivial-auto-var-init=pattern -fno-stack-clash-protection -pg -falign-functions=64 -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-array-bounds -fno-strict-overflow -fno-stack-check -Werror=date-time -Werror=incompatible-pointer-types -Wextra -Wunused -Wno-unused-parameter -Wmissing-declarations -Wmissing-format-attribute -Wmissing-prototypes -Wold-style-definition -Wmissing-include-dirs -Wunused-but-set-variable -Wunused-const-variable -Wno-missing-field-initializers -Wno-sign-compare -Wno-type-limits -fsanitize=array-bounds -fsanitize=unreachable -fsanitize=object-size -fsanitize=enum -fsanitize-coverage=trace-pc -I security/integrity/ima -I ./security/integrity/ima -ffunction-sections -fdata-sections -DKBUILD_MODFILE="security/integrity/ima/ima" -DKBUILD_BASENAME="ima_fs" -DKBUILD_MODNAME="ima" -D__KBUILD_MODNAME=kmod_ima -c -o security/integrity/ima/ima_fs.o security/integrity/ima/ima_fs.c
1. <eof> parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'security/integrity/ima/ima_fs.c'.
4. Running pass 'Mips Assembly Printer' on function '@ima_open_policy'
#0 0x0000557a749c4b3f Signals.cpp:0:0
#1 0x0000557a749c2a8c llvm::sys::CleanupOnSignal(unsigned long) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3401a8c)
#2 0x0000557a74906667 llvm::CrashRecoveryContext::HandleExit(int) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3345667)
#3 0x0000557a749bb13e llvm::sys::Process::Exit(int, bool) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x33fa13e)
#4 0x0000557a7264133b (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x108033b)
#5 0x0000557a7490d10c llvm::report_fatal_error(llvm::Twine const&, bool) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x334c10c)
#6 0x0000557a755ef9b8 llvm::AsmPrinter::emitInlineAsm(llvm::MachineInstr const (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x402e9b8)
#7 0x0000557a755eb759 llvm::AsmPrinter::emitFunctionBody() (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x402a759)
#8 0x0000557a7309c82e llvm::MipsAsmPrinter::runOnMachineFunction(llvm::MachineFunction&) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x1adb82e)
#9 0x0000557a73d332fd llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.53) MachineFunctionPass.cpp:0:0
#10 0x0000557a7416b867 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x2baa867)
#11 0x0000557a7416b9e1 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x2baa9e1)
#12 0x0000557a7416ccbf llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x2babcbf)
#13 0x0000557a74cd64fa clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x37154fa)
#14 0x0000557a75903ea3 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x4342ea3)
#15 0x0000557a76407fd9 clang::ParseAST(clang::Sema&, bool, bool) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x4e46fd9)
#16 0x0000557a75902cff clang::CodeGenAction::ExecuteAction() (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x4341cff)
#17 0x0000557a75302001 clang::FrontendAction::Execute() (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3d41001)
#18 0x0000557a75299bda clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3cd8bda)
#19 0x0000557a753cb07b (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3e0a07b)
#20 0x0000557a72642084 cc1_main(llvm::ArrayRef<char char (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x1081084)
#21 0x0000557a7263f5cb ExecuteCC1Tool(llvm::SmallVectorImpl<char driver.cpp:0:0
#22 0x0000557a75136b15 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> const::'lambda'()>(long) Job.cpp:0:0
#23 0x0000557a74906523 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3345523)
#24 0x0000557a7513740e clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> const (.part.216) Job.cpp:0:0
#25 0x0000557a7510dee7 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3b4cee7)
#26 0x0000557a7510e8c7 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command >&) const (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3b4d8c7)
#27 0x0000557a75118139 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command >&) (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x3b57139)
#28 0x0000557a7256a19f main (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0xfa919f)
#29 0x00007fc0e7a42d0a __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26d0a)
#30 0x0000557a7263f0ea _start (/opt/cross/clang-d5b6e30ed3/bin/clang-14+0x107e0ea)
clang-14: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 14.0.0 (git://gitmirror/llvm_project d5b6e30ed3acad794dd0aec400e617daffc6cc3d)
Target: mipsel-unknown-linux
Thread model: posix
InstalledDir: /opt/cross/clang-d5b6e30ed3/bin
clang-14: note: diagnostic msg:
Makefile arch drivers include kernel nr_bisected scripts security source usr
vim +/user_ns +380 security/integrity/ima/ima_fs.c
374
375 /*
376 * ima_open_policy: sequentialize access to the policy file
377 */
378 static int ima_open_policy(struct inode *inode, struct file *filp)
379 {
> 380 struct user_namespace *user_ns = ima_user_ns_from_file(filp);
381 struct ima_namespace *ns = &init_ima_ns;
382
383 if (!(filp->f_flags & O_WRONLY)) {
384 #ifndef CONFIG_IMA_READ_POLICY
385 return -EACCES;
386 #else
387 if ((filp->f_flags & O_ACCMODE) != O_RDONLY)
388 return -EACCES;
389 if (!mac_admin_ns_capable(user_ns))
390 return -EPERM;
391 return seq_open(filp, &ima_policy_seqops);
392 #endif
393 }
394 if (test_and_set_bit(IMA_FS_BUSY, &ns->ima_fs_flags))
395 return -EBUSY;
396 return 0;
397 }
398
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply
* [PATCH net 2/2] can: isotp: convert struct tpcon::{idx,len} to unsigned int
From: Marc Kleine-Budde @ 2022-01-05 20:54 UTC (permalink / raw)
To: netdev
Cc: davem, kuba, linux-can, kernel, Marc Kleine-Budde, stable,
Oliver Hartkopp, syzbot+4c63f36709a642f801c5
In-Reply-To: <20220105205443.1274709-1-mkl@pengutronix.de>
In isotp_rcv_ff() 32 bit of data received over the network is assigned
to struct tpcon::len. Later in that function the length is checked for
the maximal supported length against MAX_MSG_LENGTH.
As struct tpcon::len is an "int" this check does not work, if the
provided length overflows the "int".
Later on struct tpcon::idx is compared against struct tpcon::len.
To fix this problem this patch converts both struct tpcon::{idx,len}
to unsigned int.
Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol")
Link: https://lore.kernel.org/all/20220105132429.1170627-1-mkl@pengutronix.de
Cc: stable@vger.kernel.org
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Reported-by: syzbot+4c63f36709a642f801c5@syzkaller.appspotmail.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
net/can/isotp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/can/isotp.c b/net/can/isotp.c
index df6968b28bf4..02cbcb2ecf0d 100644
--- a/net/can/isotp.c
+++ b/net/can/isotp.c
@@ -119,8 +119,8 @@ enum {
};
struct tpcon {
- int idx;
- int len;
+ unsigned int idx;
+ unsigned int len;
u32 state;
u8 bs;
u8 sn;
--
2.34.1
^ permalink raw reply related
* [PATCH net 1/2] can: gs_usb: fix use of uninitialized variable, detach device on reception of invalid USB data
From: Marc Kleine-Budde @ 2022-01-05 20:54 UTC (permalink / raw)
To: netdev; +Cc: davem, kuba, linux-can, kernel, Marc Kleine-Budde, stable
In-Reply-To: <20220105205443.1274709-1-mkl@pengutronix.de>
The received data contains the channel the received data is associated
with. If the channel number is bigger than the actual number of
channels assume broken or malicious USB device and shut it down.
This fixes the error found by clang:
| drivers/net/can/usb/gs_usb.c:386:6: error: variable 'dev' is used
| uninitialized whenever 'if' condition is true
| if (hf->channel >= GS_MAX_INTF)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
| drivers/net/can/usb/gs_usb.c:474:10: note: uninitialized use occurs here
| hf, dev->gs_hf_size, gs_usb_receive_bulk_callback,
| ^~~
Link: https://lore.kernel.org/all/20211210091158.408326-1-mkl@pengutronix.de
Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices")
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/gs_usb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c
index 1b400de00f51..d7ce2c5956f4 100644
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -321,7 +321,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb)
/* device reports out of range channel id */
if (hf->channel >= GS_MAX_INTF)
- goto resubmit_urb;
+ goto device_detach;
dev = usbcan->canch[hf->channel];
@@ -406,6 +406,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb)
/* USB failure take down all interfaces */
if (rc == -ENODEV) {
+ device_detach:
for (rc = 0; rc < GS_MAX_INTF; rc++) {
if (usbcan->canch[rc])
netif_device_detach(usbcan->canch[rc]->netdev);
base-commit: 1d5a474240407c38ca8c7484a656ee39f585399c
--
2.34.1
^ permalink raw reply related
* [PATCH net 0/2] pull-request: can 2022-01-05
From: Marc Kleine-Budde @ 2022-01-05 20:54 UTC (permalink / raw)
To: netdev; +Cc: davem, kuba, linux-can, kernel
Hello Jakub, hello David,
this is a pull request of 2 patches for net/master.
It consists of 2 patches, both by me. The first one fixes the use of
an uninitialized variable in the gs_usb driver the other one a
skb_over_panic in the ISOTP stack in case of reception of too large
ISOTP messages.
regards,
Marc
---
The following changes since commit 1d5a474240407c38ca8c7484a656ee39f585399c:
sfc: The RX page_ring is optional (2022-01-04 18:14:21 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-5.16-20220105
for you to fetch changes up to 5f33a09e769a9da0482f20a6770a342842443776:
can: isotp: convert struct tpcon::{idx,len} to unsigned int (2022-01-05 21:49:47 +0100)
----------------------------------------------------------------
linux-can-fixes-for-5.16-20220105
----------------------------------------------------------------
Marc Kleine-Budde (2):
can: gs_usb: fix use of uninitialized variable, detach device on reception of invalid USB data
can: isotp: convert struct tpcon::{idx,len} to unsigned int
drivers/net/can/usb/gs_usb.c | 3 ++-
net/can/isotp.c | 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 kvm/queue 14/16] KVM: Handle page fault for private memory
From: Sean Christopherson @ 2022-01-05 20:52 UTC (permalink / raw)
To: Yan Zhao
Cc: Chao Peng, kvm, linux-kernel, linux-mm, linux-fsdevel, qemu-devel,
Paolo Bonzini, Jonathan Corbet, Vitaly Kuznetsov, Wanpeng Li,
Jim Mattson, Joerg Roedel, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, x86, H . Peter Anvin, Hugh Dickins, Jeff Layton,
J . Bruce Fields, Andrew Morton, Yu Zhang, Kirill A . Shutemov,
luto, john.ji, susie.li, jun.nakajima, dave.hansen, ak, david
In-Reply-To: <20220105075356.GB19947@yzhao56-desk.sh.intel.com>
On Wed, Jan 05, 2022, Yan Zhao wrote:
> Sorry, maybe I didn't express it clearly.
>
> As in the kvm_faultin_pfn_private(),
> static bool kvm_faultin_pfn_private(struct kvm_vcpu *vcpu,
> struct kvm_page_fault *fault,
> bool *is_private_pfn, int *r)
> {
> int order;
> int mem_convert_type;
> struct kvm_memory_slot *slot = fault->slot;
> long pfn = kvm_memfd_get_pfn(slot, fault->gfn, &order);
> ...
> }
> Currently, kvm_memfd_get_pfn() is called unconditionally.
> However, if the backend of a private memslot is not memfd, and is device
> fd for example, a different xxx_get_pfn() is required here.
Ya, I've complained about this in a different thread[*]. This should really be
something like kvm_private_fd_get_pfn(), where the underlying ops struct can point
at any compatible backing store.
https://lore.kernel.org/all/YcuMUemyBXFYyxCC@google.com/
> Further, though mapped to a private gfn, it might be ok for QEMU to
> access the device fd in hva-based way (or call it MMU access way, e.g.
> read/write/mmap), it's desired that it could use the traditional to get
> pfn without convert the range to a shared one.
No, this is expressly forbidden. The backing store for a private gfn must not
be accessible by userspace. It's possible a backing store could support both, but
not concurrently, and any conversion must be done without KVM being involved.
In other words, resolving a private gfn must either succeed or fail (exit to
userspace), KVM cannot initiate any conversions.
> pfn = __gfn_to_pfn_memslot(slot, fault->gfn, ...)
> |->addr = __gfn_to_hva_many (slot, gfn,...)
> | pfn = hva_to_pfn (addr,...)
>
>
> So, is it possible to recognize such kind of backends in KVM, and to get
> the pfn in traditional way without converting them to shared?
> e.g.
> - specify KVM_MEM_PRIVATE_NONPROTECT to memory regions with such kind
> of backends, or
> - detect the fd type and check if get_pfn is provided. if no, go the
> traditional way.
No, because the whole point of this is to make guest private memory inaccessible
to host userspace. Or did I misinterpret your questions?
^ permalink raw reply
* Re: [PATCH 2/2] udoo: neo: Do not print the Model information
From: Fabio Estevam @ 2022-01-05 20:52 UTC (permalink / raw)
To: Tommaso Merciai; +Cc: Stefano Babic, U-Boot-Denx, Peter Robinson
In-Reply-To: <20220105204752.GA2177@tom-desktop>
Hi Tommaso,
On Wed, Jan 5, 2022 at 5:47 PM Tommaso Merciai <tomm.merciai@gmail.com> wrote:
> Hi Fabio,
> Thanks, I test your patch on basic and extended model. Below some logs
> seems all work properly. I hope I helped the cause :)
Yes, thanks a lot!
> - BASIC log:
> -------------------------------------------------------------------------
> U-Boot 2022.01-rc4-00034-g19f31e718f-dirty (Jan 05 2022 - 21:38:32 +0100)
>
> CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
> CPU: Extended Commercial temperature grade (-20C to 105C) at 32C
> Reset cause: POR
> Model: UDOO Neo Basic
I assume you have only applied 1/2 and not 2/2.
With 2/2 applied the Model line should not be printed.
Thanks
^ permalink raw reply
* stable-rc/queue/4.14 build: 196 builds: 3 failed, 193 passed, 2 errors, 32 warnings (v4.14.261)
From: kernelci.org bot @ 2022-01-05 20:52 UTC (permalink / raw)
To: stable, kernel-build-reports, kernelci-results
stable-rc/queue/4.14 build: 196 builds: 3 failed, 193 passed, 2 errors, 32 warnings (v4.14.261)
Full Build Summary: https://kernelci.org/build/stable-rc/branch/queue%2F4.14/kernel/v4.14.261/
Tree: stable-rc
Branch: queue/4.14
Git Describe: v4.14.261
Git Commit: bfdef05c8da46b022172695aa493cff7ac667a4b
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Built: 6 unique architectures
Build Failures Detected:
arm:
rpc_defconfig: (gcc-10) FAIL
mips:
ip27_defconfig: (gcc-10) FAIL
ip28_defconfig: (gcc-10) FAIL
Errors and Warnings Detected:
arc:
arm64:
arm:
mini2440_defconfig (gcc-10): 1 warning
omap1_defconfig (gcc-10): 1 warning
rpc_defconfig (gcc-10): 2 errors
s3c2410_defconfig (gcc-10): 1 warning
i386:
allnoconfig (gcc-10): 3 warnings
i386_defconfig (gcc-10): 3 warnings
tinyconfig (gcc-10): 3 warnings
mips:
malta_qemu_32r6_defconfig (gcc-10): 1 warning
mtx1_defconfig (gcc-10): 3 warnings
x86_64:
allnoconfig (gcc-10): 4 warnings
tinyconfig (gcc-10): 4 warnings
x86_64_defconfig (gcc-10): 4 warnings
x86_64_defconfig+x86-chromebook (gcc-10): 4 warnings
Errors summary:
1 arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv3
1 arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’
Warnings summary:
7 ld: warning: creating DT_TEXTREL in a PIE
4 ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
4 arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
4 Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
3 ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
3 arch/x86/entry/entry_32.S:482: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
2 sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
2 drivers/tty/serial/samsung.c:1794:34: warning: array ‘s3c24xx_uart_dt_match’ assumed to have one element
1 {standard input}:30: Warning: macro instruction expanded into multiple instructions
1 sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
1 drivers/gpio/gpio-omap.c:1152:34: warning: array ‘omap_gpio_match’ assumed to have one element
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
32r2el_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
acs5k_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
acs5k_tiny_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (x86_64, gcc-10) — PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
allnoconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (i386, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_32.S:482: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
am200epdkit_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ar7_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
aspeed_g4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
aspeed_g5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
assabet_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
at91_dt_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ath25_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ath79_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axm55xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axs103_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axs103_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
badge4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm2835_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm47xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm63xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bigsur_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bmips_be_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bmips_stb_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
capcella_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cavium_octeon_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cerfcube_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ci20_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cm_x2xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cm_x300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cobalt_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
collie_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
corgi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
davinci_all_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
db1xxx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
decstation_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig+arm64-chromebook (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
dove_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
e55_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ebsa110_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
efm32_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
em_x270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ep93xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
eseries_pxa_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
exynos_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ezx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
footbridge_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
fuloong2e_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gemini_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gpr_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h3600_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h5000_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hackkit_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
haps_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
haps_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hisi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hsdk_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
i386_defconfig (i386, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_32.S:482: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
imote2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imx_v4_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imx_v6_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
integrator_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop13xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop32x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop33x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip22_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip27_defconfig (mips, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip28_defconfig (mips, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip32_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ixp4xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jazz_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jmr3927_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jornada720_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
keystone_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ks8695_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lart_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lasat_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lemote2f_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson1b_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson1c_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson3_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc18xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc32xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpd270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lubbock_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
magician_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mainstone_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_guest_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_qemu_32r6_defconfig (mips, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
{standard input}:30: Warning: macro instruction expanded into multiple instructions
--------------------------------------------------------------------------------
maltaaprp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_eva_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_xpa_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
markeins_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mini2440_defconfig (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/tty/serial/samsung.c:1794:34: warning: array ‘s3c24xx_uart_dt_match’ assumed to have one element
--------------------------------------------------------------------------------
mips_paravirt_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mmp2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
moxart_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mpc30x_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mps2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
msp71xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mtx1_defconfig (mips, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
--------------------------------------------------------------------------------
multi_v4t_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mvebu_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mvebu_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mxs_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
neponset_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
netwinder_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
netx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nhk8815_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlr_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsimosci_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsimosci_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc910_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc950_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc960_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
omap1_defconfig (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/gpio/gpio-omap.c:1152:34: warning: array ‘omap_gpio_match’ assumed to have one element
--------------------------------------------------------------------------------
omap2plus_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
omega2p_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
orion5x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
palmz72_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pcm027_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pic32mzda_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pistachio_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pleb_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pnx8335_stb225_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
prima2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa168_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa255-idp_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa3xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa910_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
qcom_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
qi_lb60_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
raumfeld_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rb532_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rbtx49xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
realview_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rm200_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rpc_defconfig (arm, gcc-10) — FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv3
arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’
--------------------------------------------------------------------------------
rt305x_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s3c2410_defconfig (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/tty/serial/samsung.c:1794:34: warning: array ‘s3c24xx_uart_dt_match’ assumed to have one element
--------------------------------------------------------------------------------
s3c6400_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s5pv210_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sama5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sb1250_swarm_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shannon_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shmobile_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
simpad_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
socfpga_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear13xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear3xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear6xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spitz_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
stm32_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sunxi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tango4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0219_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0226_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0287_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tct_hammer_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tegra_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (x86_64, gcc-10) — PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
tinyconfig (i386, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_32.S:482: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
tinyconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
trizeps4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
u300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
u8500_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vdk_hs38_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vdk_hs38_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
versatile_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vexpress_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
viper_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vocore2_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vt8500_v6_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
workpad_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-10) — PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
x86_64_defconfig+x86-chromebook (x86_64, gcc-10) — PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
xcep_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
xilfpga_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zeus_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.