Re: [PATCH 5/8] arm64: dts: mt8183: Add kukui-jacuzzi-kappa board
Hi Hsin-Yi,
Thank you for your patch.
Missatge de Hsin-Yi Wang del dia dj., 15 d’abr.
2021 a les 11:36:
>
> Kappa is known as HP Chromebook 11a
>
> Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
> ---
> arch/arm64/boot/dts/mediatek/Makefile| 1 +
> .../dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts | 16
> 2 files changed, 17 insertions(+)
> create mode 100644
> arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile
> b/arch/arm64/boot/dts/mediatek/Makefile
> index a1c50adc98fa..df70674949ce 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -15,6 +15,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku16.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku272.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
> new file mode 100644
> index ..b3f46c16e5d7
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
> @@ -0,0 +1,16 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-jacuzzi.dtsi"
> +
> +/ {
> + model = "Google kappa board";
> + compatible = "google,kappa", "mediatek,mt8183";
> +};
> +
> + {
> + mediatek,dmic-mode = <1>; /* one-wire */
> +};
> --
> 2.31.1.295.g9ea45b61b8-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 4/8] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-kenzo
Hi Hsin-Yi, Thank you for your patch. Missatge de Hsin-Yi Wang del dia dj., 15 d’abr. 2021 a les 11:36: > > Kenzo is known as Acer Chromebook 311. > > Signed-off-by: Hsin-Yi Wang Reviewed-by: Enric Balletbo i Serra > --- > Documentation/devicetree/bindings/arm/mediatek.yaml | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml > b/Documentation/devicetree/bindings/arm/mediatek.yaml > index 0870490aa350..39e4a99ebb37 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek.yaml > +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml > @@ -137,9 +137,11 @@ properties: > items: >- const: google,damu >- const: mediatek,mt8183 > - - description: Google Juniper (Acer Chromebook Spin 311) > + - description: Google Juniper (Acer Chromebook Spin 311) / Kenzo (Acer > Crhomebook 311) > items: > - - const: google,juniper-sku16 > + - enum: > + - google,juniper-sku16 > + - google,juniper-sku17 >- const: google,juniper >- const: mediatek,mt8183 >- description: Google Kakadu (ASUS Chromebook Detachable CM3) > -- > 2.31.1.295.g9ea45b61b8-goog > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v2] kconfig: redo fake deps at include/config/*.h
On Fri, Apr 16, 2021 at 2:36 AM Alexey Dobriyan wrote:
>
> Make include/config/foo/bar.h fake deps files generation simpler.
>
> * delete .h suffix
> those aren't header files, shorten filenames,
>
> * delete tolower()
> Linux filesystems can deal with both upper and lowercase
> filenames very well,
>
> * put everything in 1 directory
> Presumably 'mkdir -p' split is from dark times when filesystems
> handled huge directories badly, disks were round adding to
> seek times.
>
> x86_64 allmodconfig lists 12364 files in include/config.
>
> ../obj/include/config/
> ├── 104_QUAD_8
> ├── 60XX_WDT
> ├── 64BIT
> ...
> ├── ZSWAP_DEFAULT_ON
> ├── ZSWAP_ZPOOL_DEFAULT
> └── ZSWAP_ZPOOL_DEFAULT_ZBUD
>
> 0 directories, 12364 files
>
> Signed-off-by: Alexey Dobriyan
> ---
>
> include/linux/compiler-version.h |2 +-
> init/Kconfig |2 +-
> kernel/gen_kheaders.sh |2 +-
> scripts/Makefile.build |4 ++--
> scripts/basic/fixdep.c | 39
> ---
> scripts/kconfig/confdata.c | 15 +--
> 6 files changed, 14 insertions(+), 50 deletions(-)
>
> --- a/include/linux/compiler-version.h
> +++ b/include/linux/compiler-version.h
> @@ -9,6 +9,6 @@
> * This header exists to force full rebuild when the compiler is upgraded.
> *
> * When fixdep scans this, it will find this string "CONFIG_CC_VERSION_TEXT"
> - * and add dependency on include/config/cc/version/text.h, which is touched
> + * and add dependency on include/config/CC_VERSION_TEXT, which is touched
> * by Kconfig when the version string from the compiler changes.
> */
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -21,7 +21,7 @@ config CC_VERSION_TEXT
>
> - Ensure full rebuild when the compiler is updated
> include/linux/compiler-version.h contains this option in the
> comment
> - line so fixdep adds include/config/cc/version/text.h into the
> + line so fixdep adds include/config/CC_VERSION_TEXT into the
> auto-generated dependency. When the compiler is updated,
> syncconfig
> will touch it and then every file will be rebuilt.
>
> --- a/kernel/gen_kheaders.sh
> +++ b/kernel/gen_kheaders.sh
> @@ -36,7 +36,7 @@ all_dirs="$all_dirs $dir_list"
> #
> # When Kconfig regenerates include/generated/autoconf.h, its timestamp is
> # updated, but the contents might be still the same. When any CONFIG option
> is
> -# changed, Kconfig touches the corresponding timestamp file
> include/config/*.h.
> +# changed, Kconfig touches the corresponding timestamp file include/config/*.
> # Hence, the md5sum detects the configuration change anyway. We do not need
> to
> # check include/generated/autoconf.h explicitly.
> #
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -238,8 +238,8 @@ endif # CONFIG_STACK_VALIDATION
>
> # Rebuild all objects when objtool changes, or is enabled/disabled.
> objtool_dep = $(objtool_obj) \
> - $(wildcard include/config/orc/unwinder.h \
> -include/config/stack/validation.h)
> + $(wildcard include/config/ORC_UNWINDER\
> +include/config/STACK_VALIDATION)
>
> ifdef CONFIG_TRIM_UNUSED_KSYMS
> cmd_gen_ksymdeps = \
> --- a/scripts/basic/fixdep.c
> +++ b/scripts/basic/fixdep.c
> @@ -34,7 +34,7 @@
> * the config symbols are rebuilt.
> *
> * So if the user changes his CONFIG_HIS_DRIVER option, only the objects
> - * which depend on "include/config/his/driver.h" will be rebuilt,
> + * which depend on "include/config/HIS_DRIVER" will be rebuilt,
> * so most likely only his driver ;-)
> *
> * The idea above dates, by the way, back to Michael E Chastain, AFAIK.
> @@ -74,7 +74,7 @@
> *
> * and then basically copies the ..d file to stdout, in the
> * process filtering out the dependency on autoconf.h and adding
> - * dependencies on include/config/my/option.h for every
> + * dependencies on include/config/MY_OPTION for every
> * CONFIG_MY_OPTION encountered in any of the prerequisites.
> *
> * We don't even try to really parse the header files, but
> @@ -124,38 +124,6 @@ static void xprintf(const char *format, ...)
> va_end(ap);
> }
>
> -static void xputchar(int c)
> -{
> - int ret;
> -
> - ret = putchar(c);
> - if (ret == EOF) {
> - perror("fixdep");
> - exit(1);
> - }
> -}
> -
Applied to linux-kbuild.
I just found one more minor thing to fix up.
fixdep no longer calls putchar(), so I squashed the following:
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index 5bee6a80992f..44e887cff49b 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -107,8 +107,8 @@ static void usage(void)
Re: [PATCH 3/8] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-burnet
Hi Hsin-Yi, Thank you for your patch. Missatge de Hsin-Yi Wang del dia dj., 15 d’abr. 2021 a les 11:36: > > Burnet is known as HP Chromebook x360 11MK G3 EE. > > Signed-off-by: Hsin-Yi Wang Reviewed-by: Enric Balletbo i Serra > --- > Documentation/devicetree/bindings/arm/mediatek.yaml | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml > b/Documentation/devicetree/bindings/arm/mediatek.yaml > index 96c401597bd8..0870490aa350 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek.yaml > +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml > @@ -122,6 +122,10 @@ properties: >- enum: >- mediatek,mt8195-evb >- const: mediatek,mt8195 > + - description: Google Burnet (HP Chromebook x360 11MK G3 EE) > +items: > + - const: google,burnet > + - const: mediatek,mt8183 >- description: Google Krane (Lenovo IdeaPad Duet, 10e,...) > items: >- enum: > -- > 2.31.1.295.g9ea45b61b8-goog > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 2/2] tools: do not include scripts/Kbuild.include
On 15.04.21 10:06, Christian Borntraeger wrote:
On 15.04.21 09:27, Masahiro Yamada wrote:
Since commit d9f4ff50d2aa ("kbuild: spilt cc-option and friends to
scripts/Makefile.compiler"), some kselftests fail to build.
The tools/ directory opted out Kbuild, and went in a different
direction. They copy any kind of files to the tools/ directory
in order to do whatever they want to do in their world.
tools/build/Build.include mimics scripts/Kbuild.include, but some
tool Makefiles included the Kbuild one to import a feature that is
missing in tools/build/Build.include:
- Commit ec04aa3ae87b ("tools/thermal: tmon: use "-fstack-protector"
only if supported") included scripts/Kbuild.include from
tools/thermal/tmon/Makefile to import the cc-option macro.
- Commit c2390f16fc5b ("selftests: kvm: fix for compilers that do
not support -no-pie") included scripts/Kbuild.include from
tools/testing/selftests/kvm/Makefile to import the try-run macro.
- Commit 9cae4ace80ef ("selftests/bpf: do not ignore clang
failures") included scripts/Kbuild.include from
tools/testing/selftests/bpf/Makefile to import the .DELETE_ON_ERROR
target.
- Commit 0695f8bca93e ("selftests/powerpc: Handle Makefile for
unrecognized option") included scripts/Kbuild.include from
tools/testing/selftests/powerpc/pmu/ebb/Makefile to import the
try-run macro.
Copy what they want there, and stop including scripts/Kbuild.include
from the tool Makefiles.
Link:
https://lore.kernel.org/lkml/86dadf33-70f7-a5ac-cb8c-64966d2f4...@linux.ibm.com/
Fixes: d9f4ff50d2aa ("kbuild: spilt cc-option and friends to
scripts/Makefile.compiler")
Reported-by: Janosch Frank
Reported-by: Christian Borntraeger
Signed-off-by: Masahiro Yamada
When applying this on top of d9f4ff50d2aa ("kbuild: spilt cc-option and friends to
scripts/Makefile.compiler")
I still do get
# Test Assertion Failure
# lib/kvm_util.c:142: vm->fd >= 0
# pid=315635 tid=315635 - Invalid argument
# 1 0x01002f4b: vm_open at kvm_util.c:142
# 2 (inlined by) vm_create at kvm_util.c:258
# 3 0x010015ef: test_add_max_memory_regions at
set_memory_region_test.c:351
# 4 (inlined by) main at set_memory_region_test.c:397
# 5 0x03ff971abb89: ?? ??:0
# 6 0x010017ad: .annobin_abi_note.c.hot at crt1.o:?
# KVM_CREATE_VM ioctl failed, rc: -1 errno: 22
not ok 7 selftests: kvm: set_memory_region_test # exit=254
and the testcase compilation does not pickup the pgste option.
What does work is the following:
diff --git a/tools/testing/selftests/kvm/Makefile
b/tools/testing/selftests/kvm/Makefile
index a6d61f451f88..d9c6d9c2069e 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
include ../../../../scripts/Kbuild.include
+include ../../../../scripts/Makefile.compiler
all:
as it does pickup the linker option handling.
Re: [PATCH 2/8] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-willow
Hi Hsin-Yi. Thank you for your patch. Missatge de Hsin-Yi Wang del dia dj., 15 d’abr. 2021 a les 11:36: > > Willow is known as Acer Chromebook 311 (C722/C722T). > > Signed-off-by: Hsin-Yi Wang Reviewed-by: Enric Balletbo i Serra > --- > Documentation/devicetree/bindings/arm/mediatek.yaml | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml > b/Documentation/devicetree/bindings/arm/mediatek.yaml > index 81b86b189a8d..96c401597bd8 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek.yaml > +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml > @@ -157,6 +157,13 @@ properties: >- google,kodama-sku32 >- const: google,kodama >- const: mediatek,mt8183 > + - description: Google Willow (Acer Chromebook 311 C722/C722T) > +items: > + - enum: > + - google,willow-sku0 > + - google,willow-sku1 > + - const: google,willow > + - const: mediatek,mt8183 >- items: >- enum: >- mediatek,mt8183-pumpkin > -- > 2.31.1.295.g9ea45b61b8-goog > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 1/8] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-kappa
Hi Hsin-Yi, Thank you for your patch. Missatge de Hsin-Yi Wang del dia dj., 15 d’abr. 2021 a les 11:36: > > Kappa is known as HP Chromebook 11a. > > Signed-off-by: Hsin-Yi Wang Reviewed-by: Enric Balletbo i Serra > --- > Documentation/devicetree/bindings/arm/mediatek.yaml | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml > b/Documentation/devicetree/bindings/arm/mediatek.yaml > index aff57a8c8c30..81b86b189a8d 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek.yaml > +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml > @@ -144,6 +144,10 @@ properties: >- const: google,kakadu-rev2 >- const: google,kakadu >- const: mediatek,mt8183 > + - description: Google Kappa (HP Chromebook 11a) > +items: > + - const: google,kappa > + - const: mediatek,mt8183 >- description: Google Kodama (Lenovo 10e Chromebook Tablet) > items: >- enum: > -- > 2.31.1.295.g9ea45b61b8-goog > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 2/3] arm64: dts: mt8183: fix dtbs_check warning
Hi Matthias,
Thank you for your patch.
Missatge de l'adreça del dia dc., 14 d’abr.
2021 a les 16:48:
>
> From: Matthias Brugger
>
> Fix unit names to make dtbs_check happy.
>
> Signed-off-by: Matthias Brugger
> ---
>
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 0ff7b67a6806..c5e822b6b77a 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -681,13 +681,13 @@ cpu_thermal: cpu_thermal {
> sustainable-power = <5000>;
>
> trips {
> - threshold: trip-point@0 {
> + threshold: trip-point0 {
> temperature = <68000>;
> hysteresis = <2000>;
> type = "passive";
> };
>
> - target: trip-point@1 {
> + target: trip-point1 {
> temperature = <8>;
> hysteresis = <2000>;
> type = "passive";
> @@ -1103,7 +1103,7 @@ u2port0: usb-phy@0 {
> status = "okay";
> };
>
> - u3port0: usb-phy@0700 {
> + u3port0: usb-phy@700 {
> reg = <0x0700 0x900>;
> clocks = <>;
> clock-names = "ref";
> --
> 2.30.2
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Reviewed-by: Enric Balletbo i Serra
Re: [PATCH v2] uml: fix W=1 missing-include-dirs warnings
On Fri, Apr 16, 2021 at 4:14 AM Masahiro Yamada wrote: > > On Fri, Apr 16, 2021 at 2:14 AM Randy Dunlap wrote: > > > > Currently when using "W=1" with UML builds, there are over 700 warnings > > like so: > > > > CC arch/um/drivers/stderr_console.o > > cc1: warning: ./arch/um/include/uapi: No such file or directory > > [-Wmissing-include-dirs] > > > > but arch/um/ does not have include/uapi/ at all, so add that > > subdir and put one Kbuild file into it (since git does not track > > empty subdirs). > > > > Signed-off-by: Randy Dunlap > > Cc: Masahiro Yamada > > Cc: Michal Marek > > Cc: linux-kbu...@vger.kernel.org > > Cc: Jeff Dike > > Cc: Richard Weinberger > > Cc: Anton Ivanov > > Cc: linux...@lists.infradead.org > > --- > > v2: use Option 4 from v1: add arch/um/include/uapi so that 'make' is > > placated -- and just like all other arch's have. > > > > Assuming the UML maintainer will pick up this: > > Reviewed-by: Masahiro Yamada Now I see this patch queued up to UML repository. Thanks. -- Best Regards Masahiro Yamada
Re: [PATCH 1/3] arm64: dts: mt8183-pumpkin: fix dtbs_check warning
Hi Matthias,
Thank you for your patch.
Missatge de l'adreça del dia dc., 14 d’abr.
2021 a les 16:48:
>
> From: Matthias Brugger
>
> Fix unit names to make dtbs_check happy.
>
> Signed-off-by: Matthias Brugger
> ---
>
> arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
> b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
> index eb6e595c2975..0aff5eb52e88 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
> @@ -32,7 +32,7 @@ reserved-memory {
> #size-cells = <2>;
> ranges;
>
> - scp_mem_reserved: scp_mem_region {
> + scp_mem_reserved: scp_mem_region@5000 {
> compatible = "shared-dma-pool";
> reg = <0 0x5000 0 0x290>;
> no-map;
> @@ -55,7 +55,7 @@ led-green {
> };
> };
>
> - ntc@0 {
> + ntc {
> compatible = "murata,ncp03wf104";
> pullup-uv = <180>;
> pullup-ohm = <39>;
> --
> 2.30.2
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Reviewed-by: Enric Balletbo i Serra
Re: linux-next: build warning after merge of the amdgpu tree
On Fri, Apr 16, 2021 at 1:47 AM Liang, Prike wrote: > > [AMD Public Use] > > > From: Stephen Rothwell > > Sent: Friday, April 16, 2021 12:09 PM > > To: Liang, Prike > > Cc: Alex Deucher ; S-k, Shyam-sundar > sundar@amd.com>; Linux Kernel Mailing List > ker...@vger.kernel.org>; Linux Next Mailing List > > > > Subject: Re: linux-next: build warning after merge of the amdgpu tree > > > > Hi, > > > > On Fri, 16 Apr 2021 03:12:12 + "Liang, Prike" > > wrote: > > > > > > Hi, Rothwell > > > > (Stephen, actually :-)) > > > > > This fix solution hasn't locked down and still being discussed and roll- > > updated in the NVMe mail group. > > > Will update the patch once it refined done. > > > > In which case, this patch should not be in linux-next (or any branch that is > > included by linux-next). > > > How about revert the patch temporally ? Once lock down the solution and will > land in the final latest patch. I'll drop it for now. I just have it in there temporarily while it makes its way upstream because a lot of people use this branch and it fixes an important bug. Alex
Re: [Outreachy kernel] [PATCH v2] staging: media: atomisp: pci: Change line break to avoid an open parenthesis at the end of the line
On Fri, Apr 16, 2021 at 12:21:58AM +0300, Sakari Ailus wrote: > On Thu, Apr 15, 2021 at 08:59:41PM +0100, Matthew Wilcox wrote: > > On Thu, Apr 15, 2021 at 08:57:04PM +0100, Matthew Wilcox wrote: > > > On Thu, Apr 15, 2021 at 10:49:55PM +0300, Sakari Ailus wrote: > > > > On Thu, Apr 15, 2021 at 06:14:09PM +0100, Matthew Wilcox wrote: > > > > > On Thu, Apr 15, 2021 at 02:08:19PM -0300, Aline Santana Cordeiro > > > > > wrote: > > > > > > -const struct atomisp_format_bridge > > > > > > *get_atomisp_format_bridge_from_mbus( > > > > > > -u32 mbus_code); > > > > > > +const struct atomisp_format_bridge* > > > > > > +get_atomisp_format_bridge_from_mbus(u32 mbus_code); > > > > > > > > > > No, this does not match coding style. Probably best to break the > > > > > 80-column guideline in this instance. Best would be to have a > > > > > function > > > > > > > > Having the return type on the previous line is perfectly fine. There > > > > should > > > > be a space before the asterisk though. > > > > > > No, it's not. Linus has ranted about that before. > > > > Found it. > > https://lore.kernel.org/lkml/1054519757.161...@palladium.transmeta.com/ > > Two decades ago, really? > > This is simply one of the practical means how you split long function > declarations and avoid overly long lines. Not my favourite though, but > still better than those long lines. I've always thought we allow either style, but it has to be done consistently within the file. I was pretty sure that was policy but it's another thing that goes back decades so I don't have a reference. It shouldn't be about breaking up long lines. > > My personal preference would be to wrap at the opening parenthesis and > indent by just a tab, but I know many people who disagree with that... If you're running into the 80 character limit, then it's fine to use two tabs. I think we have been rejecting patches that push align the parameters but push past the 80 character limit. Using one tab is confusing because it makes the decalarations line up with the code. regards, dan carpenter
Re: [PATCH v1 1/5] mm: pagewalk: Fix walk for hugepage tables
Le 16/04/2021 à 00:43, Daniel Axtens a écrit :
Hi Christophe,
Pagewalk ignores hugepd entries and walk down the tables
as if it was traditionnal entries, leading to crazy result.
Add walk_hugepd_range() and use it to walk hugepage tables.
Signed-off-by: Christophe Leroy
---
mm/pagewalk.c | 54 +--
1 file changed, 48 insertions(+), 6 deletions(-)
diff --git a/mm/pagewalk.c b/mm/pagewalk.c
index e81640d9f177..410a9d8f7572 100644
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -58,6 +58,32 @@ static int walk_pte_range(pmd_t *pmd, unsigned long addr,
unsigned long end,
return err;
}
+static int walk_hugepd_range(hugepd_t *phpd, unsigned long addr,
+unsigned long end, struct mm_walk *walk, int
pdshift)
+{
+ int err = 0;
+#ifdef CONFIG_ARCH_HAS_HUGEPD
+ const struct mm_walk_ops *ops = walk->ops;
+ int shift = hugepd_shift(*phpd);
+ int page_size = 1 << shift;
+
+ if (addr & (page_size - 1))
+ return 0;
+
+ for (;;) {
+ pte_t *pte = hugepte_offset(*phpd, addr, pdshift);
+
+ err = ops->pte_entry(pte, addr, addr + page_size, walk);
+ if (err)
+ break;
+ if (addr >= end - page_size)
+ break;
+ addr += page_size;
+ }
Initially I thought this was a somewhat unintuitive way to structure
this loop, but I see it parallels the structure of walk_pte_range_inner,
so I think the consistency is worth it.
I notice the pte walking code potentially takes some locks: does this
code need to do that?
arch/powerpc/mm/hugetlbpage.c says that hugepds are protected by the
mm->page_table_lock, but I don't think we're taking it in this code.
I'll add it, thanks.
+#endif
+ return err;
+}
+
static int walk_pmd_range(pud_t *pud, unsigned long addr, unsigned long end,
struct mm_walk *walk)
{
@@ -108,7 +134,10 @@ static int walk_pmd_range(pud_t *pud, unsigned long addr,
unsigned long end,
goto again;
}
- err = walk_pte_range(pmd, addr, next, walk);
+ if (is_hugepd(__hugepd(pmd_val(*pmd
+ err = walk_hugepd_range((hugepd_t *)pmd, addr, next,
walk, PMD_SHIFT);
+ else
+ err = walk_pte_range(pmd, addr, next, walk);
if (err)
break;
} while (pmd++, addr = next, addr != end);
@@ -157,7 +186,10 @@ static int walk_pud_range(p4d_t *p4d, unsigned long addr,
unsigned long end,
if (pud_none(*pud))
goto again;
- err = walk_pmd_range(pud, addr, next, walk);
+ if (is_hugepd(__hugepd(pud_val(*pud
+ err = walk_hugepd_range((hugepd_t *)pud, addr, next,
walk, PUD_SHIFT);
+ else
+ err = walk_pmd_range(pud, addr, next, walk);
I'm a bit worried you might end up calling into walk_hugepd_range with
ops->pte_entry == NULL, and then jumping to 0.
You are right, I missed it.
I'll bail out of walk_hugepd_range() when ops->pte_entry is NULL.
static int walk_pud_range(p4d_t *p4d, unsigned long addr, unsigned long end,
struct mm_walk *walk)
{
...
pud = pud_offset(p4d, addr);
do {
...
if ((!walk->vma && (pud_leaf(*pud) || !pud_present(*pud))) ||
walk->action == ACTION_CONTINUE ||
!(ops->pmd_entry || ops->pte_entry)) <<< THIS CHECK
continue;
...
if (is_hugepd(__hugepd(pud_val(*pud
err = walk_hugepd_range((hugepd_t *)pud, addr, next,
walk, PUD_SHIFT);
else
err = walk_pmd_range(pud, addr, next, walk);
if (err)
break;
} while (pud++, addr = next, addr != end);
walk_pud_range will proceed if there is _either_ an ops->pmd_entry _or_
an ops->pte_entry, but walk_hugepd_range will call ops->pte_entry
unconditionally.
The same issue applies to walk_{p4d,pgd}_range...
Kind regards,
Daniel
Thanks
Christophe
RE: linux-next: build warning after merge of the amdgpu tree
[AMD Public Use] > From: Stephen Rothwell > Sent: Friday, April 16, 2021 12:09 PM > To: Liang, Prike > Cc: Alex Deucher ; S-k, Shyam-sundar sundar@amd.com>; Linux Kernel Mailing List ker...@vger.kernel.org>; Linux Next Mailing List > Subject: Re: linux-next: build warning after merge of the amdgpu tree > > Hi, > > On Fri, 16 Apr 2021 03:12:12 + "Liang, Prike" > wrote: > > > > Hi, Rothwell > > (Stephen, actually :-)) > > > This fix solution hasn't locked down and still being discussed and roll- > updated in the NVMe mail group. > > Will update the patch once it refined done. > > In which case, this patch should not be in linux-next (or any branch that is > included by linux-next). > How about revert the patch temporally ? Once lock down the solution and will land in the final latest patch. > -- > Cheers, > Stephen Rothwell
Re: [PATCH 13/15] usb: dwc2: Add exit hibernation mode before removing drive
Hi Sergei,
On 4/15/2021 13:24, Sergei Shtylyov wrote:
> On 15.04.2021 8:41, Artur Petrosyan wrote:
>
>> When dwc2 core is in hibernation mode loading
>> driver again causes driver fail. Because in
>> that mode registers are not accessible.
>>
>> In order to exit from hibernation checking
>> dwc2 core power saving state in "dwc2_driver_remove()"
>> function. If core is in hibernation, then checking the
>> operational mode of the driver. To check whether dwc2 core
>> is operating in host mode or device mode there is one way
>> which is retrieving the backup value of "gotgctl" and compare
>> the "CurMod" value. If previously core entered hibernation
>> in host mode then the exit is performed for host if not then
>> exit is performed for device mode. The introduced checking
>> is because in hibernation state all registers are not
>> accessible.
>>
>> Signed-off-by: Artur Petrosyan
>> ---
>>drivers/usb/dwc2/platform.c | 16
>>1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
>> index f8b819cfa80e..2ae4748ed5ec 100644
>> --- a/drivers/usb/dwc2/platform.c
>> +++ b/drivers/usb/dwc2/platform.c
>> @@ -316,8 +316,24 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg
>> *hsotg)
>>static int dwc2_driver_remove(struct platform_device *dev)
>>{
>> struct dwc2_hsotg *hsotg = platform_get_drvdata(dev);
>> +struct dwc2_gregs_backup *gr;
>> int ret = 0;
>>
>> +/* Exit Hibernation when driver is removed. */
>> +if (hsotg->hibernated) {
>> +if (gr->gotgctl & GOTGCTL_CURMODE_HOST) {
>> +ret = dwc2_exit_hibernation(hsotg, 0, 0, 1);
>> +if (ret)
>> +dev_err(hsotg->dev,
>> +"exit hibernation failed.\n");
>> +} else {
>> +ret = dwc2_exit_hibernation(hsotg, 0, 0, 0);
>> +if (ret)
>> +dev_err(hsotg->dev,
>> +"exit hibernation failed.\n");
>
> Again, why duplicate the innermost *if*?
Again the reason is that combination of inner and outside ifs would give
as a situation when core would not be hibernated but driver would try to
exit from host or device hibernation.
>
>> + }
>> +}
>> +
>> /* Exit Partial Power Down when driver is removed. */
>> if (hsotg->in_ppd) {
>> ret = dwc2_exit_partial_power_down(hsotg, 0, true);
>
> MBR, Sergei
>
Regards,
Artur
Re: [PATCH 10/15] usb: dwc2: Allow exit hibernation in urb enqueue
Hi Sergei,
On 4/15/2021 13:12, Sergei Shtylyov wrote:
> On 15.04.2021 8:40, Artur Petrosyan wrote:
>
>> When core is in hibernation state and an external
>> hub is connected, upper layer sends URB enqueue request,
>> which results in port reset issue.
>>
>> - Added exit from hibernation state to avoid port
>> reset issue and process upper layer request properly.
>>
>> Signed-off-by: Artur Petrosyan
>> ---
>>drivers/usb/dwc2/hcd.c | 17 +
>>1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
>> index cc9ad6cf02d9..3b03b2d73aaa 100644
>> --- a/drivers/usb/dwc2/hcd.c
>> +++ b/drivers/usb/dwc2/hcd.c
>> @@ -4631,12 +4631,29 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd
>> *hcd, struct urb *urb,
>> struct dwc2_qh *qh;
>> bool qh_allocated = false;
>> struct dwc2_qtd *qtd;
>> +struct dwc2_gregs_backup *gr;
>> +
>> +gr = >gr_backup;
>>
>> if (dbg_urb(urb)) {
>> dev_vdbg(hsotg->dev, "DWC OTG HCD URB Enqueue\n");
>> dwc2_dump_urb_info(hcd, urb, "urb_enqueue");
>> }
>>
>> +if (hsotg->hibernated) {
>> +if (gr->gotgctl & GOTGCTL_CURMODE_HOST) {
>> +retval = dwc2_exit_hibernation(hsotg, 0, 0, 1);
>> +if (retval)
>> +dev_err(hsotg->dev,
>> +"exit hibernation failed.\n");
>> +} else {
>> +retval = dwc2_exit_hibernation(hsotg, 0, 0, 0);
>> +if (retval)
>> +dev_err(hsotg->dev,
>> +"exit hibernation failed.\n");
>
> Why not put these identical *if*s outside the the outer *if*?
>
Well the reason that the conditions are implemented like they are, is
that the inner if checks whether core operates in host mode or device
mode and the outside if checks if the core is hibernated or not.
So now imagine that the ifs are combined and core is not hibernated but
the operational mode of the driver is let's say gadget. If the case is
such then the driver will try to exit from gadget hibernation because of
the else condition as the if condition will be false again because core
is not hibernated. As a result if we combine the outside and inner ifs
then it will try to exit from gadget hibernation but core is not
hibernated and that would be an issue.
>
>> +}
>> +}
>> +
>> if (hsotg->in_ppd) {
>> retval = dwc2_exit_partial_power_down(hsotg, 0, true);
>> if (retval)
>
> MBR, Sergei
>
Regards,
Artur
Re: [PATCH v3] kconfig: nconf: stop endless search loops
On Thu, Apr 15, 2021 at 4:28 PM Mihai Moldovan wrote:
>
> If the user selects the very first entry in a page and performs a
> search-up operation, or selects the very last entry in a page and
> performs a search-down operation that will not succeed (e.g., via
> [/]asdfzzz[Up Arrow]), nconf will never terminate searching the page.
>
> The reason is that in this case, the starting point will be set to -1
> or n, which is then translated into (n - 1) (i.e., the last entry of
> the page) or 0 (i.e., the first entry of the page) and finally the
> search begins. This continues to work fine until the index reaches 0 or
> (n - 1), at which point it will be decremented to -1 or incremented to
> n, but not checked against the starting point right away. Instead, it's
> wrapped around to the bottom or top again, after which the starting
> point check occurs... and naturally fails.
>
> My original implementation added another check for -1 before wrapping
> the running index variable around, but Masahiro Yamada pointed out that
> the actual issue is that the comparison point (starting point) exceeds
> bounds (i.e., the [0,n-1] interval) in the first place and that,
> instead, the starting point should be fixed.
>
> This has the welcome side-effect of also fixing the case where the
> starting point was n while searching down, which also lead to an
> infinite loop.
>
> OTOH, this code is now essentially all his work.
>
> Amazingly, nobody seems to have been hit by this for 11 years - or at
> the very least nobody bothered to debug and fix this.
>
> Signed-off-by: Mihai Moldovan
> ---
Applied to linux-kbuild. Thanks.
> v2: swap constant in comparison to right side, as requested by
> Randy Dunlap
> v3: reimplement as suggested by Masahiro Yamada ,
> which has the side-effect of also fixing endless looping in the
> symmetric down-direction
>
> scripts/kconfig/nconf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
> index e0f965529166..af814b39b876 100644
> --- a/scripts/kconfig/nconf.c
> +++ b/scripts/kconfig/nconf.c
> @@ -504,8 +504,8 @@ static int get_mext_match(const char *match_str, match_f
> flag)
> else if (flag == FIND_NEXT_MATCH_UP)
> --match_start;
>
> + match_start = (match_start + items_num) % items_num;
> index = match_start;
> - index = (index + items_num) % items_num;
> while (true) {
> char *str = k_menu_items[index].str;
> if (strcasestr(str, match_str) != NULL)
> --
> 2.30.1
>
--
Best Regards
Masahiro Yamada
Re: [syzbot] general protection fault in gadget_setup
On Tue, Apr 13, 2021 at 12:13:11PM -0400, Alan Stern wrote:
> On Tue, Apr 13, 2021 at 10:12:05AM +0200, Dmitry Vyukov wrote:
> > On Tue, Apr 13, 2021 at 10:08 AM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:0f4498ce Merge tag 'for-5.12/dm-fixes-2' of
> > > git://git.kern..
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=124adbf6d0
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=daeff30c2474a60f
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=eb4674092e6cc8d9e0bd
> > > userspace arch: i386
> > >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the
> > > commit:
> > > Reported-by: syzbot+eb4674092e6cc8d9e...@syzkaller.appspotmail.com
> >
> > I suspect that the raw gadget_unbind() can be called while the timer
> > is still active. gadget_unbind() sets gadget data to NULL.
> > But I am not sure which unbind call this is:
> > usb_gadget_remove_driver() or right in udc_bind_to_driver() due to a
> > start error.
>
> This certainly looks like a race between gadget_unbind and gadget_setup
> in raw_gadget.
>
> In theory, this race shouldn't matter. The gadget core is supposed to
> guarantee that there won't be any more callbacks to the gadget driver
> once the driver's unbind routine is called. That guarantee is enforced
> in usb_gadget_remove_driver as follows:
>
> usb_gadget_disconnect(udc->gadget);
> if (udc->gadget->irq)
> synchronize_irq(udc->gadget->irq);
> udc->driver->unbind(udc->gadget);
> usb_gadget_udc_stop(udc);
>
> usb_gadget_disconnect turns off the pullup resistor, telling the host
> that the gadget is no longer connected and preventing the transmission
> of any more USB packets. Any packets that have already been received
> are sure to processed by the UDC driver's interrupt handler by the time
> synchronize_irq returns.
>
> But this doesn't work with dummy_hcd, because dummy_hcd doesn't use
> interrupts; it uses a timer instead. It does have code to emulate the
> effect of synchronize_irq, but that code doesn't get invoked at the
> right time -- it currently runs in usb_gadget_udc_stop, after the unbind
> callback instead of before. Indeed, there's no way for
> usb_gadget_remove_driver to invoke this code before the unbind
> callback,.
>
> I thought the synchronize_irq emulation problem had been completely
> solved, but evidently it hasn't. It looks like the best solution is to
> add a call of the synchronize_irq emulation code in dummy_pullup.
>
> Maybe we can test this reasoning by putting a delay just before the call
> to dum->driver->setup. That runs in the timer handler, so it's not a
> good place to delay, but it may be okay just for testing purposes.
>
> Hopefully this patch will make the race a lot more likely to occur. Is
Hi Alan,
Indeed, I was able to reproduce this bug easily on my machine with your
delay patch applied and using this syzkaller program:
syz_usb_connect$cdc_ncm(0x1, 0x6e, &(0x7f40)={{0x12, 0x1, 0x0, 0x2,
0x0, 0x0, 0x8, 0x525, 0xa4a1, 0x40, 0x1, 0x2, 0x3, 0x1, [{{0x9, 0x2, 0x5c, 0x2,
0x1, 0x0, 0x0, 0x0, {{0x9, 0x4, 0x0, 0x0, 0x1, 0x2, 0xd, 0x0, 0x0, {{0x5},
{0x5}, {0xd}, {0x6}}, {{0x9, 0x5, 0x81, 0x3, 0x200}}]}},
&(0x7f000480)={0x0, 0x0, 0x0, 0x0, 0x3, [{0x0, 0x0}, {0x0, 0x0}, {0x0,
0x0}]})
I also tested doing the synchronize_irq emulation in dummy_pullup and it
fixed the issue. The patch is below.
Thanks!
- Anirudh.
diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
b/drivers/usb/gadget/udc/dummy_hcd.c
index ce24d4f28f2a..931d4612d859 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -903,6 +903,12 @@ static int dummy_pullup(struct usb_gadget *_gadget, int
value)
spin_lock_irqsave(>lock, flags);
dum->pullup = (value != 0);
set_link_state(dum_hcd);
+ /* emulate synchronize_irq(): wait for callbacks to finish */
+ while (dum->callback_usage > 0) {
+ spin_unlock_irqrestore(>lock, flags);
+ usleep_range(1000, 2000);
+ spin_lock_irqsave(>lock, flags);
+ }
spin_unlock_irqrestore(>lock, flags);
usb_hcd_poll_rh_status(dummy_hcd_to_hcd(dum_hcd));
@@ -1005,13 +1011,6 @@ static int dummy_udc_stop(struct usb_gadget *g)
dum->ints_enabled = 0;
stop_activity(dum);
- /* emulate synchronize_irq(): wait for callbacks to finish */
- while (dum->callback_usage > 0) {
- spin_unlock_irq(>lock);
- usleep_range(1000, 2000);
- spin_lock_irq(>lock);
- }
-
dum->driver = NULL;
spin_unlock_irq(>lock);
@@ -1900,6 +1899,7 @@ static void dummy_timer(struct timer_list *t)
if (value >
[PATCH v2] X86: Makefile: Replace -pg with CC_FLAGS_FTRACE
In preparation for x86 supporting ftrace built on other compiler options, let's have the x86 Makefiles remove the $(CC_FLAGS_FTRACE) flags, whatever these may be, rather than assuming '-pg'. There should be no functional change as a result of this patch. Signed-off-by: zhaoxiao --- v2: add the same change for the other Makefile in arch/x86 directory. arch/x86/entry/vdso/Makefile | 8 arch/x86/kernel/Makefile | 16 arch/x86/kernel/cpu/Makefile | 4 ++-- arch/x86/lib/Makefile| 2 +- arch/x86/mm/Makefile | 4 ++-- arch/x86/xen/Makefile| 6 +++--- 6 files changed, 20 insertions(+), 20 deletions(-) diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile index 05c4abc2fdfd..c5bd91bf9f93 100644 --- a/arch/x86/entry/vdso/Makefile +++ b/arch/x86/entry/vdso/Makefile @@ -96,10 +96,10 @@ $(vobjs): KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_LTO) $(GCC_PLUGINS_CFLAGS) $( # # vDSO code runs in userspace and -pg doesn't help with profiling anyway. # -CFLAGS_REMOVE_vclock_gettime.o = -pg -CFLAGS_REMOVE_vdso32/vclock_gettime.o = -pg -CFLAGS_REMOVE_vgetcpu.o = -pg -CFLAGS_REMOVE_vsgx.o = -pg +CFLAGS_REMOVE_vclock_gettime.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_vdso32/vclock_gettime.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_vgetcpu.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_vsgx.o = $(CC_FLAGS_FTRACE) # # X32 processes use x32 vDSO to access 64bit kernel data. diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 2ddf08351f0b..2811fc6a17ba 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -13,14 +13,14 @@ CPPFLAGS_vmlinux.lds += -U$(UTS_MACHINE) ifdef CONFIG_FUNCTION_TRACER # Do not profile debug and lowlevel utilities -CFLAGS_REMOVE_tsc.o = -pg -CFLAGS_REMOVE_paravirt-spinlocks.o = -pg -CFLAGS_REMOVE_pvclock.o = -pg -CFLAGS_REMOVE_kvmclock.o = -pg -CFLAGS_REMOVE_ftrace.o = -pg -CFLAGS_REMOVE_early_printk.o = -pg -CFLAGS_REMOVE_head64.o = -pg -CFLAGS_REMOVE_sev-es.o = -pg +CFLAGS_REMOVE_tsc.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_paravirt-spinlocks.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_pvclock.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_kvmclock.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_early_printk.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_head64.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_sev-es.o = $(CC_FLAGS_FTRACE) endif KASAN_SANITIZE_head$(BITS).o := n diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile index 637b499450d1..4435c6de9145 100644 --- a/arch/x86/kernel/cpu/Makefile +++ b/arch/x86/kernel/cpu/Makefile @@ -5,8 +5,8 @@ # Don't trace early stages of a secondary CPU boot ifdef CONFIG_FUNCTION_TRACER -CFLAGS_REMOVE_common.o = -pg -CFLAGS_REMOVE_perf_event.o = -pg +CFLAGS_REMOVE_common.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_perf_event.o = $(CC_FLAGS_FTRACE) endif # If these files are instrumented, boot hangs during the first second. diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index bad4dee4f0e4..0aa71b8a5bc1 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -21,7 +21,7 @@ KASAN_SANITIZE_cmdline.o := n KCSAN_SANITIZE_cmdline.o := n ifdef CONFIG_FUNCTION_TRACER -CFLAGS_REMOVE_cmdline.o = -pg +CFLAGS_REMOVE_cmdline.o = $(CC_FLAGS_FTRACE) endif CFLAGS_cmdline.o := -fno-stack-protector -fno-jump-tables diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile index 5864219221ca..91883d5a0293 100644 --- a/arch/x86/mm/Makefile +++ b/arch/x86/mm/Makefile @@ -12,8 +12,8 @@ KASAN_SANITIZE_mem_encrypt_identity.o := n KCSAN_SANITIZE := n ifdef CONFIG_FUNCTION_TRACER -CFLAGS_REMOVE_mem_encrypt.o= -pg -CFLAGS_REMOVE_mem_encrypt_identity.o = -pg +CFLAGS_REMOVE_mem_encrypt.o= $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_mem_encrypt_identity.o = $(CC_FLAGS_FTRACE) endif obj-y := init.o init_$(BITS).o fault.o ioremap.o extable.o mmap.o \ diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile index 40b5779fce21..179dfc124c94 100644 --- a/arch/x86/xen/Makefile +++ b/arch/x86/xen/Makefile @@ -2,9 +2,9 @@ ifdef CONFIG_FUNCTION_TRACER # Do not profile debug and lowlevel utilities -CFLAGS_REMOVE_spinlock.o = -pg -CFLAGS_REMOVE_time.o = -pg -CFLAGS_REMOVE_irq.o = -pg +CFLAGS_REMOVE_spinlock.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_time.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_irq.o = $(CC_FLAGS_FTRACE) endif # Make sure early boot has no stackprotector -- 2.20.1
Re: [PATCH 00/13] [RFC] Rust support
On Fri, Apr 16, 2021 at 06:02:33 +0100, Wedson Almeida Filho wrote: > On Fri, Apr 16, 2021 at 04:25:34AM +, Al Viro wrote: > >>> Are you stating [what you perceive as] a fact or just venting? If the >>> former, >>> would you mind enlightening us with some evidence? >> >> How about "not everyone uses a browser as a part of their workflow"? > > The documentation is available in markdown alongside the code. You don't need > a > browser to see it. I, for one, use neovim and a rust LSP, so I can see the > documentation by pressing shift+k. > >> I realize that it might sound ridiculous for folks who spent a while >> around Mozilla, but it's really true and kernel community actually >> has quite a few of such freaks. > > I haven't spent any time around Mozilla myself (not that there's anything > wrong > with it), so I can't really comment on this. > >> And as one of those freaks I can tell >> you where exactly I would like you to go and what I would like you to do >> with implicit suggestions to start a browser when I need to read some >> in-tree documentation. > > I could be mistaken but you seem angry. Perhaps it wouldn't be a bad idea to > read your own code of conduct, I don't think you need a browser for that > either. Haven't you folks ever head of lynx? Good old-fashioned command-line tool that opens html files in a terminal window, supports following links within the file, good stuff like that. I don't see how the dinosaurs^W traditional folks could object to that! -- Paul
Re: [PATCH] platform/chrome: cros_ec_typec: Handle hard reset
Hi Prashant,
Thank you for your patch.
Missatge de Prashant Malani del dia dj., 15
d’abr. 2021 a les 4:15:
>
> The Chrome Embedded Controller (EC) generates a hard reset type C event
> when a USB Power Delivery (PD) hard reset is encountered. Handle this
> event by unregistering the partner and cable on the associated port and
> clearing the event flag.
>
> Also update the EC command header to include the new event bit. This bit
> is included in the latest version of the Chrome EC headers[1].
>
> [1]
> https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/main/include/ec_commands.h
>
> Cc: Benson Leung
> Signed-off-by: Prashant Malani
> ---
> drivers/platform/chrome/cros_ec_typec.c| 13 +
> include/linux/platform_data/cros_ec_commands.h | 1 +
Could this be a separate patch?
Thank you.
Enric
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c
> b/drivers/platform/chrome/cros_ec_typec.c
> index d3df1717a5fd..22052f569f2a 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -905,6 +905,19 @@ static void cros_typec_handle_status(struct
> cros_typec_data *typec, int port_num
> return;
> }
>
> + /* If we got a hard reset, unregister everything and return. */
> + if (resp.events & PD_STATUS_EVENT_HARD_RESET) {
> + cros_typec_remove_partner(typec, port_num);
> + cros_typec_remove_cable(typec, port_num);
> +
> + ret = cros_typec_send_clear_event(typec, port_num,
> + PD_STATUS_EVENT_HARD_RESET);
> + if (ret < 0)
> + dev_warn(typec->dev,
> +"Failed hard reset event clear, port: %d\n",
> port_num);
> + return;
> + }
> +
> /* Handle any events appropriately. */
> if (resp.events & PD_STATUS_EVENT_SOP_DISC_DONE &&
> !typec->ports[port_num]->sop_disc_done) {
> u16 sop_revision;
> diff --git a/include/linux/platform_data/cros_ec_commands.h
> b/include/linux/platform_data/cros_ec_commands.h
> index 5ff8597ceabd..9156078c6fc6 100644
> --- a/include/linux/platform_data/cros_ec_commands.h
> +++ b/include/linux/platform_data/cros_ec_commands.h
> @@ -5678,6 +5678,7 @@ enum tcpc_cc_polarity {
>
> #define PD_STATUS_EVENT_SOP_DISC_DONE BIT(0)
> #define PD_STATUS_EVENT_SOP_PRIME_DISC_DONEBIT(1)
> +#define PD_STATUS_EVENT_HARD_RESET BIT(2)
>
> struct ec_params_typec_status {
> uint8_t port;
> --
> 2.31.1.295.g9ea45b61b8-goog
>
Re: [PATCH v5 1/2] mfd: google,cros-ec: add DT bindings for a baseboard's switch device
Hi Ikjoon,
Thank you for your patch.
Missatge de Ikjoon Jang del dia dj., 15 d’abr.
2021 a les 5:32:
>
> This is for ChromeOS tablets which have a 'cros_cbas' switch device
> in the "Whiskers" base board. This device can be instantiated only by
> device tree on ARM platforms. ChromeOS EC doesn't provide a way to
> probe the device.
>
> Signed-off-by: Ikjoon Jang
>
> ---
>
> Changes in v5:
> - Add missing blank lines and change the description property's position.
> - Add a note to description: "this device cannot be detected at runtime."
>
> Changes in v4:
> Define cros-cbase bindings inside google,cros-ec.yaml instead of
> a separated binding document.
>
> .../bindings/mfd/google,cros-ec.yaml | 20 +++
> 1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> index 76bf16ee27ec..8dcce176b72e 100644
> --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> @@ -114,6 +114,22 @@ properties:
>- "#address-cells"
>- "#size-cells"
>
> + cbas:
> +type: object
> +
> +description:
> + This device is used to signal when a detachable base is attached
> + to a Chrome OS tablet. This device cannot be detected at runtime.
> +
> +properties:
> + compatible:
> +const: google,cros-cbas
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> patternProperties:
>"^i2c-tunnel[0-9]*$":
> type: object
> @@ -180,6 +196,10 @@ examples:
> interrupts = <99 0>;
> interrupt-parent = <>;
> spi-max-frequency = <500>;
> +
> +base_detection: cbas {
nit: Rob, shouldn't this be just cbas?
> +compatible = "google,cros-cbas";
> +};
> };
> };
>
> --
> 2.31.1.295.g9ea45b61b8-goog
>
Acked-by: Enric Balletbo i Serra
Re: [Regression] amdgpu driver broken on AMD HD7770 GHz edition.
On Fri, Apr 16, 2021 at 12:48 AM David Niklas wrote: > > Hey, > > I forgot to give you a bug tracker in case you want one. > Here: https://bugzilla.kernel.org/show_bug.cgi?id=212691 I've followed up on the bug report. Please take a look there. Alex > > Thanks, > David > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v3 0/4] CAN TRANSCEIVER: Add support for CAN transceivers
Hi all, On 15/04/21 8:19 pm, Aswath Govindraju wrote: > The following series of patches add support for CAN transceivers. > > TCAN1042 has a standby signal that needs to be pulled high for > sending/receiving messages[1]. TCAN1043 has a enable signal along with > standby signal that needs to be pulled up for sending/receiving > messages[2], and other combinations of the two lines can be used to put the > transceiver in different states to reduce power consumption. On boards > like the AM654-idk and J721e-evm these signals are controlled using gpios. > > Patch 1 rewords the comment that restricts max_link_rate attribute to have > units of Mbps. > > Patch 2 adds an API for devm_of_phy_optional_get_by_index > > Patch 3 models the transceiver as a phy device tree node with properties > for max bit rate supported, gpio properties for indicating gpio pin numbers > to which standby and enable signals are connected. > > Patch 4 adds a generic driver to support CAN transceivers. > > changes since v2: > - dropped 5 and 6 patches and to be sent via linux-can-next > - added static keyword for can_transceiver_phy_probe() > - changed enable gpio example to active high in patch 3 > - Rearranged the file names in alphabetical order in Makefile > and MAINTAINERS file > > changes since v1: > - Added patch 1 (in v2) that rewords the comment that restrict > max_link_rate attribute to have units of Mbps. > - Added patch 2 (in v2) that adds an API for > devm_of_phy_optional_get_by_index > - Patch 1 (in v1) > - updated MAINTAINERS file > - Patch 2 (in v1) > - replaced m_can with CAN to make the driver independent of CAN driver > - Added prefix CAN_TRANSCEIVER for EN_PRESENT and STB_PRESENT > - Added new line before return statements in power_on() and power_off > - Added error handling patch for devm_kzalloc() > - used the max_link_rate attribute directly instead of dividing it by > 100 > - removed the spaces before GPIOD_OUT_LOW in devm_gpiod_get() > - Corrected requested value for standby-gpios to GPIOD_OUT_HIGH > - Updated MAINTAINERS file > - Patch 3 (in v1) > - replaced minItems with maxItems > - Removed phy-names property as there is only one phy > - Patch 4 (in v1) > - replaced dev_warn with dev_info when no transceiver is found > - Added struct phy * field in m_can_classdev struct > - moved phy_power_on and phy_power_off to m_can_open and m_can_close > respectively > - Moved the check for max_bit_rate to generice transceiver driver > > [1] - https://www.ti.com/lit/ds/symlink/tcan1042h.pdf > [2] - https://www.ti.com/lit/ds/symlink/tcan1043-q1.pdf > Posted v4 for this series. Thanks, Aswath > Aswath Govindraju (4): > phy: core: Reword the comment specifying the units of max_link_rate to > be Mbps > phy: Add API for devm_of_phy_optional_get_by_index > dt-bindings: phy: Add binding for TI TCAN104x CAN transceivers > phy: phy-can-transceiver: Add support for generic CAN transceiver > driver > > .../bindings/phy/ti,tcan104x-can.yaml | 56 +++ > MAINTAINERS | 2 + > drivers/phy/Kconfig | 9 ++ > drivers/phy/Makefile | 1 + > drivers/phy/phy-can-transceiver.c | 146 ++ > drivers/phy/phy-core.c| 26 > include/linux/phy/phy.h | 4 +- > 7 files changed, 243 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml > create mode 100644 drivers/phy/phy-can-transceiver.c >
[PATCH v4 3/3] phy: phy-can-transceiver: Add support for generic CAN transceiver driver
The driver adds support for generic CAN transceivers. Currently
the modes supported by this driver are standby and normal modes for TI
TCAN1042 and TCAN1043 CAN transceivers.
The transceiver is modelled as a phy with pins controlled by gpios, to put
the transceiver in various device functional modes. It also gets the phy
attribute max_link_rate for the usage of CAN drivers.
Signed-off-by: Aswath Govindraju
---
MAINTAINERS | 1 +
drivers/phy/Kconfig | 9 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-can-transceiver.c | 146 ++
4 files changed, 157 insertions(+)
create mode 100644 drivers/phy/phy-can-transceiver.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e666d33af10d..4e868f2a97c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4048,6 +4048,7 @@ T:git
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
F: Documentation/devicetree/bindings/net/can/
F: Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
F: drivers/net/can/
+F: drivers/phy/phy-can-transceiver.c
F: include/linux/can/bittiming.h
F: include/linux/can/dev.h
F: include/linux/can/led.h
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 54c1f2f0985f..51902b629fc6 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -61,6 +61,15 @@ config USB_LGM_PHY
interface to interact with USB GEN-II and USB 3.x PHY that is part
of the Intel network SOC.
+config PHY_CAN_TRANSCEIVER
+ tristate "CAN transceiver PHY"
+ select GENERIC_PHY
+ help
+ This option enables support for CAN transceivers as a PHY. This
+ driver provides function for putting the transceivers in various
+ functional modes using gpios and sets the attribute max link
+ rate, for mcan drivers.
+
source "drivers/phy/allwinner/Kconfig"
source "drivers/phy/amlogic/Kconfig"
source "drivers/phy/broadcom/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index adac1b1a39d1..01e9efffc726 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -5,6 +5,7 @@
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_GENERIC_PHY_MIPI_DPHY)+= phy-core-mipi-dphy.o
+obj-$(CONFIG_PHY_CAN_TRANSCEIVER) += phy-can-transceiver.o
obj-$(CONFIG_PHY_LPC18XX_USB_OTG) += phy-lpc18xx-usb-otg.o
obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
diff --git a/drivers/phy/phy-can-transceiver.c
b/drivers/phy/phy-can-transceiver.c
new file mode 100644
index ..c24aa2eab9e4
--- /dev/null
+++ b/drivers/phy/phy-can-transceiver.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * phy-can-transceiver.c - phy driver for CAN transceivers
+ *
+ * Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+
+struct can_transceiver_data {
+ u32 flags;
+#define CAN_TRANSCEIVER_STB_PRESENTBIT(0)
+#define CAN_TRANSCEIVER_EN_PRESENT BIT(1)
+};
+
+struct can_transceiver_phy {
+ struct phy *generic_phy;
+ struct gpio_desc *standby_gpio;
+ struct gpio_desc *enable_gpio;
+};
+
+/* Power on function */
+static int can_transceiver_phy_power_on(struct phy *phy)
+{
+ struct can_transceiver_phy *can_transceiver_phy = phy_get_drvdata(phy);
+
+ if (can_transceiver_phy->standby_gpio)
+ gpiod_set_value_cansleep(can_transceiver_phy->standby_gpio, 0);
+ if (can_transceiver_phy->enable_gpio)
+ gpiod_set_value_cansleep(can_transceiver_phy->enable_gpio, 1);
+
+ return 0;
+}
+
+/* Power off function */
+static int can_transceiver_phy_power_off(struct phy *phy)
+{
+ struct can_transceiver_phy *can_transceiver_phy = phy_get_drvdata(phy);
+
+ if (can_transceiver_phy->standby_gpio)
+ gpiod_set_value_cansleep(can_transceiver_phy->standby_gpio, 1);
+ if (can_transceiver_phy->enable_gpio)
+ gpiod_set_value_cansleep(can_transceiver_phy->enable_gpio, 0);
+
+ return 0;
+}
+
+static const struct phy_ops can_transceiver_phy_ops = {
+ .power_on = can_transceiver_phy_power_on,
+ .power_off = can_transceiver_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static const struct can_transceiver_data tcan1042_drvdata = {
+ .flags = CAN_TRANSCEIVER_STB_PRESENT,
+};
+
+static const struct can_transceiver_data tcan1043_drvdata = {
+ .flags = CAN_TRANSCEIVER_STB_PRESENT | CAN_TRANSCEIVER_EN_PRESENT,
+};
+
+static const struct of_device_id can_transceiver_phy_ids[] = {
+ {
+ .compatible = "ti,tcan1042",
+ .data = _drvdata
+ },
+ {
+ .compatible = "ti,tcan1043",
+ .data = _drvdata
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, can_transceiver_phy_ids);
+
[PATCH v4 0/3] CAN TRANSCEIVER: Add support for CAN transceivers
The following series of patches add support for CAN transceivers. TCAN1042 has a standby signal that needs to be pulled high for sending/receiving messages[1]. TCAN1043 has a enable signal along with standby signal that needs to be pulled up for sending/receiving messages[2], and other combinations of the two lines can be used to put the transceiver in different states to reduce power consumption. On boards like the AM654-idk and J721e-evm these signals are controlled using gpios. Patch 1 rewords the comment that restricts max_link_rate attribute to have units of Mbps. Patch 2 models the transceiver as a phy device tree node with properties for max bit rate supported, gpio properties for indicating gpio pin numbers to which standby and enable signals are connected. Patch 2 adds a generic driver to support CAN transceivers. changes since v3: - dropped patch 2(in v3) - changed the node name property in patch 3(in v3) - picked up Rob Herring's reviewed-by for patch 3(in v3) changes since v2: - dropped 5 and 6 patches and to be sent via linux-can-next - added static keyword for can_transceiver_phy_probe() - changed enable gpio example to active high in patch 3 - Rearranged the file names in alphabetical order in Makefile and MAINTAINERS file changes since v1: - Added patch 1 (in v2) that rewords the comment that restrict max_link_rate attribute to have units of Mbps. - Added patch 2 (in v2) that adds an API for devm_of_phy_optional_get_by_index - Patch 1 (in v1) - updated MAINTAINERS file - Patch 2 (in v1) - replaced m_can with CAN to make the driver independent of CAN driver - Added prefix CAN_TRANSCEIVER for EN_PRESENT and STB_PRESENT - Added new line before return statements in power_on() and power_off - Added error handling patch for devm_kzalloc() - used the max_link_rate attribute directly instead of dividing it by 100 - removed the spaces before GPIOD_OUT_LOW in devm_gpiod_get() - Corrected requested value for standby-gpios to GPIOD_OUT_HIGH - Updated MAINTAINERS file - Patch 3 (in v1) - replaced minItems with maxItems - Removed phy-names property as there is only one phy - Patch 4 (in v1) - replaced dev_warn with dev_info when no transceiver is found - Added struct phy * field in m_can_classdev struct - moved phy_power_on and phy_power_off to m_can_open and m_can_close respectively - Moved the check for max_bit_rate to generice transceiver driver [1] - https://www.ti.com/lit/ds/symlink/tcan1042h.pdf [2] - https://www.ti.com/lit/ds/symlink/tcan1043-q1.pdf Aswath Govindraju (3): phy: core: Reword the comment specifying the units of max_link_rate to be Mbps dt-bindings: phy: Add binding for TI TCAN104x CAN transceivers phy: phy-can-transceiver: Add support for generic CAN transceiver driver .../bindings/phy/ti,tcan104x-can.yaml | 56 +++ MAINTAINERS | 2 + drivers/phy/Kconfig | 9 ++ drivers/phy/Makefile | 1 + drivers/phy/phy-can-transceiver.c | 146 ++ include/linux/phy/phy.h | 2 +- 6 files changed, 215 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml create mode 100644 drivers/phy/phy-can-transceiver.c -- 2.17.1
[PATCH v4 2/3] dt-bindings: phy: Add binding for TI TCAN104x CAN transceivers
Add binding documentation for TI TCAN104x CAN transceivers.
Signed-off-by: Aswath Govindraju
Reviewed-by: Rob Herring
---
.../bindings/phy/ti,tcan104x-can.yaml | 56 +++
MAINTAINERS | 1 +
2 files changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
new file mode 100644
index ..6107880e5246
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/ti,tcan104x-can.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: TCAN104x CAN TRANSCEIVER PHY
+
+maintainers:
+ - Aswath Govindraju
+
+properties:
+ $nodename:
+pattern: "^can-phy"
+
+ compatible:
+enum:
+ - ti,tcan1042
+ - ti,tcan1043
+
+ '#phy-cells':
+const: 0
+
+ standby-gpios:
+description:
+ gpio node to toggle standby signal on transceiver
+maxItems: 1
+
+ enable-gpios:
+description:
+ gpio node to toggle enable signal on transceiver
+maxItems: 1
+
+ max-bitrate:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+ max bit rate supported in bps
+minimum: 1
+
+required:
+ - compatible
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+transceiver1: can-phy {
+ compatible = "ti,tcan1043";
+ #phy-cells = <0>;
+ max-bitrate = <500>;
+ standby-gpios = <_gpio1 16 GPIO_ACTIVE_LOW>;
+ enable-gpios = <_gpio1 67 GPIO_ACTIVE_HIGH>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 84ef96a444c3..e666d33af10d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4046,6 +4046,7 @@ W:https://github.com/linux-can
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
F: Documentation/devicetree/bindings/net/can/
+F: Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
F: drivers/net/can/
F: include/linux/can/bittiming.h
F: include/linux/can/dev.h
--
2.17.1
[PATCH v4 1/3] phy: core: Reword the comment specifying the units of max_link_rate to be Mbps
In some subsystems (eg. CAN, SPI), the max link rate supported can be less
than 1 Mbps and if the unit for max_link_rate is Mbps then it can't be
used. Therefore, leave the decision of units to be used, to the producer
and consumer.
Signed-off-by: Aswath Govindraju
---
include/linux/phy/phy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 0ed434d02196..f3286f4cd306 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -125,7 +125,7 @@ struct phy_ops {
/**
* struct phy_attrs - represents phy attributes
* @bus_width: Data path width implemented by PHY
- * @max_link_rate: Maximum link rate supported by PHY (in Mbps)
+ * @max_link_rate: Maximum link rate supported by PHY (units to be decided by
producer and consumer)
* @mode: PHY mode
*/
struct phy_attrs {
--
2.17.1
Re: [PATCH v1 4/5] mm: ptdump: Support hugepd table entries
Hi Daniel,
Le 16/04/2021 à 01:29, Daniel Axtens a écrit :
Hi Christophe,
Which hugepd, page table entries can be at any level
and can be of any size.
Add support for them.
Signed-off-by: Christophe Leroy
---
mm/ptdump.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/mm/ptdump.c b/mm/ptdump.c
index 61cd16afb1c8..6efdb8c15a7d 100644
--- a/mm/ptdump.c
+++ b/mm/ptdump.c
@@ -112,11 +112,24 @@ static int ptdump_pte_entry(pte_t *pte, unsigned long
addr,
{
struct ptdump_state *st = walk->private;
pte_t val = ptep_get(pte);
+ unsigned long page_size = next - addr;
+ int level;
+
+ if (page_size >= PGDIR_SIZE)
+ level = 0;
+ else if (page_size >= P4D_SIZE)
+ level = 1;
+ else if (page_size >= PUD_SIZE)
+ level = 2;
+ else if (page_size >= PMD_SIZE)
+ level = 3;
+ else
+ level = 4;
if (st->effective_prot)
- st->effective_prot(st, 4, pte_val(val));
+ st->effective_prot(st, level, pte_val(val));
- st->note_page(st, addr, 4, pte_val(val), PAGE_SIZE);
+ st->note_page(st, addr, level, pte_val(val), page_size);
It seems to me that passing both level and page_size is a bit redundant,
but I guess it does reduce the impact on each arch's code?
Exactly, as shown above, the level can be re-calculated based on the page size, but it would be a
unnecessary impact on all architectures and would duplicate the re-calculation of the level whereas
in most cases we get it for free from the caller.
Kind regards,
Daniel
return 0;
}
--
2.25.0
Re: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
Le 16/04/2021 à 01:12, Daniel Axtens a écrit :
Hi Christophe,
static void note_page(struct ptdump_state *pt_st, unsigned long addr, int
level,
- u64 val)
+ u64 val, unsigned long page_size)
Compilers can warn about unused parameters at -Wextra level. However,
reading scripts/Makefile.extrawarn it looks like the warning is
explicitly _disabled_ in the kernel at W=1 and not reenabled at W=2 or
W=3. So I guess this is fine...
There are a lot lot lot functions having unused parameters in the kernel , especially the ones that
are re-implemented by each architecture.
@@ -126,7 +126,7 @@ static int ptdump_hole(unsigned long addr, unsigned long
next,
{
struct ptdump_state *st = walk->private;
- st->note_page(st, addr, depth, 0);
+ st->note_page(st, addr, depth, 0, 0);
I know it doesn't matter at this point, but I'm not really thrilled by
the idea of passing 0 as the size here. Doesn't the hole have a known
page size?
The hole has a size for sure, I don't think we can call it a page size:
On powerpc 8xx, we have 4 page sizes: 8M, 512k, 16k and 4k.
A page table will cover 4M areas and will contain pages of size 512k, 16k and
4k.
A PGD table contains either entries which points to a page table (covering 4M), or two identical
consecutive entries pointing to the same hugepd which contains a single PTE for an 8M page.
So, if a PGD entry is empty, the hole is 4M, it corresponds to none of the page sizes the
architecture supports.
But looking at what is done with that size, it can make sense to pass it to notepage() anyway. Let's
do that.
return 0;
}
@@ -153,5 +153,5 @@ void ptdump_walk_pgd(struct ptdump_state *st, struct
mm_struct *mm, pgd_t *pgd)
mmap_read_unlock(mm);
/* Flush out the last page */
- st->note_page(st, 0, -1, 0);
+ st->note_page(st, 0, -1, 0, 0);
I'm more OK with the idea of passing 0 as the size when the depth is -1
(don't know): if we don't know the depth we conceptually can't know the
page size.
Regards,
Daniel
Re: [PATCH v1 1/1] ACPI: NFIT: Import GUID before use
On Thu, Apr 15, 2021 at 6:59 AM Andy Shevchenko
wrote:
>
> Strictly speaking the comparison between guid_t and raw buffer
> is not correct. Import GUID to variable of guid_t type and then
> compare.
Hmm, what about something like the following instead, because it adds
safety. Any concerns about evaluating x twice in a macro should be
alleviated by the fact that ARRAY_SIZE() will fail the build if (x) is
not an array.
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 8c5dde628405..bac01eec07a6 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -681,7 +681,7 @@ int nfit_spa_type(struct acpi_nfit_system_address *spa)
int i;
for (i = 0; i < NFIT_UUID_MAX; i++)
- if (guid_equal(to_nfit_uuid(i), (guid_t *)>range_guid))
+ if (guid_equal(to_nfit_uuid(i), cast_guid(spa->range_guid)))
return i;
return -1;
}
diff --git a/include/linux/uuid.h b/include/linux/uuid.h
index 8cdc0d3567cd..cec1dc2ab994 100644
--- a/include/linux/uuid.h
+++ b/include/linux/uuid.h
@@ -33,6 +33,9 @@ typedef struct {
extern const guid_t guid_null;
extern const uuid_t uuid_null;
+#define cast_guid(x) ({ BUILD_BUG_ON(ARRAY_SIZE(x) != 16); (guid_t *)&(x); })
+#define cast_uuid(x) ({ BUILD_BUG_ON(ARRAY_SIZE(x) != 16); (uuid_t *)&(x); })
+
static inline bool guid_equal(const guid_t *u1, const guid_t *u2)
{
return memcmp(u1, u2, sizeof(guid_t)) == 0;
[PATCH V2] mm: Define default value for FIRST_USER_ADDRESS
Currently most platforms define FIRST_USER_ADDRESS as 0UL duplication the same code all over. Instead just define a generic default value (i.e 0UL) for FIRST_USER_ADDRESS and let the platforms override when required. This makes it much cleaner with reduced code. The default FIRST_USER_ADDRESS here would be skipped in when the given platform overrides its value via . Cc: Richard Henderson Cc: Vineet Gupta Cc: Catalin Marinas Cc: Will Deacon Cc: Guo Ren Cc: Brian Cain Cc: Geert Uytterhoeven Cc: Michal Simek Cc: Thomas Bogendoerfer Cc: Ley Foon Tan Cc: Jonas Bonn Cc: Stefan Kristiansson Cc: Stafford Horne Cc: "James E.J. Bottomley" Cc: Michael Ellerman Cc: Christophe Leroy Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Heiko Carstens Cc: Yoshinori Sato Cc: "David S. Miller" Cc: Jeff Dike Cc: Thomas Gleixner Cc: Chris Zankel Cc: Andrew Morton Cc: linux-a...@vger.kernel.org Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual --- This applies on v5.12-rc7 and has been boot tested on arm64 platform. But has been cross compiled on multiple other platforms. Changes in V2: - Dropped ARCH_HAS_FIRST_USER_ADDRESS construct Changes in V1: https://patchwork.kernel.org/project/linux-mm/patch/1618368899-20311-1-git-send-email-anshuman.khand...@arm.com/ arch/alpha/include/asm/pgtable.h | 1 - arch/arc/include/asm/pgtable.h | 6 -- arch/arm64/include/asm/pgtable.h | 2 -- arch/csky/include/asm/pgtable.h | 1 - arch/hexagon/include/asm/pgtable.h | 3 --- arch/ia64/include/asm/pgtable.h | 1 - arch/m68k/include/asm/pgtable_mm.h | 1 - arch/microblaze/include/asm/pgtable.h| 2 -- arch/mips/include/asm/pgtable-32.h | 1 - arch/mips/include/asm/pgtable-64.h | 1 - arch/nios2/include/asm/pgtable.h | 2 -- arch/openrisc/include/asm/pgtable.h | 1 - arch/parisc/include/asm/pgtable.h| 2 -- arch/powerpc/include/asm/book3s/pgtable.h| 1 - arch/powerpc/include/asm/nohash/32/pgtable.h | 1 - arch/powerpc/include/asm/nohash/64/pgtable.h | 2 -- arch/riscv/include/asm/pgtable.h | 2 -- arch/s390/include/asm/pgtable.h | 2 -- arch/sh/include/asm/pgtable.h| 2 -- arch/sparc/include/asm/pgtable_32.h | 1 - arch/sparc/include/asm/pgtable_64.h | 3 --- arch/um/include/asm/pgtable-2level.h | 1 - arch/um/include/asm/pgtable-3level.h | 1 - arch/x86/include/asm/pgtable_types.h | 2 -- arch/xtensa/include/asm/pgtable.h| 1 - include/linux/pgtable.h | 9 + 26 files changed, 9 insertions(+), 43 deletions(-) diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h index 8d856c62e22a..1a2fb0dc905b 100644 --- a/arch/alpha/include/asm/pgtable.h +++ b/arch/alpha/include/asm/pgtable.h @@ -46,7 +46,6 @@ struct vm_area_struct; #define PTRS_PER_PMD (1UL << (PAGE_SHIFT-3)) #define PTRS_PER_PGD (1UL << (PAGE_SHIFT-3)) #define USER_PTRS_PER_PGD (TASK_SIZE / PGDIR_SIZE) -#define FIRST_USER_ADDRESS 0UL /* Number of pointers that fit on a page: this will go away. */ #define PTRS_PER_PAGE (1UL << (PAGE_SHIFT-3)) diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h index 163641726a2b..a9fabfb70664 100644 --- a/arch/arc/include/asm/pgtable.h +++ b/arch/arc/include/asm/pgtable.h @@ -228,12 +228,6 @@ */ #defineUSER_PTRS_PER_PGD (TASK_SIZE / PGDIR_SIZE) -/* - * No special requirements for lowest virtual address we permit any user space - * mapping to be mapped at. - */ -#define FIRST_USER_ADDRESS 0UL - / * Bucket load of VM Helpers diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h index 47027796c2f9..f6ab8b64967e 100644 --- a/arch/arm64/include/asm/pgtable.h +++ b/arch/arm64/include/asm/pgtable.h @@ -26,8 +26,6 @@ #define vmemmap((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT)) -#define FIRST_USER_ADDRESS 0UL - #ifndef __ASSEMBLY__ #include diff --git a/arch/csky/include/asm/pgtable.h b/arch/csky/include/asm/pgtable.h index 0d60367b6bfa..151607ed5158 100644 --- a/arch/csky/include/asm/pgtable.h +++ b/arch/csky/include/asm/pgtable.h @@ -14,7 +14,6 @@ #define PGDIR_MASK (~(PGDIR_SIZE-1)) #define USER_PTRS_PER_PGD (PAGE_OFFSET/PGDIR_SIZE) -#define FIRST_USER_ADDRESS 0UL /* * C-SKY is two-level paging structure: diff --git a/arch/hexagon/include/asm/pgtable.h b/arch/hexagon/include/asm/pgtable.h index dbb22b80b8c4..e4979508cddf 100644 --- a/arch/hexagon/include/asm/pgtable.h +++ b/arch/hexagon/include/asm/pgtable.h @@ -155,9 +155,6 @@ extern unsigned long _dflt_cache_att; extern pgd_t swapper_pg_dir[PTRS_PER_PGD]; /* located in head.S */ -/* Seems to be
Re: [RFC PATCH] USB:XHCI:skip hub registration
On Fri, Apr 16, 2021 at 10:43:34AM +0800, liulongfang wrote:
> On 2021/4/15 20:34, Greg KH wrote:
> > On Thu, Apr 15, 2021 at 08:22:38PM +0800, Longfang Liu wrote:
> >> When the number of ports on the USB hub is 0, skip the registration
> >> operation of the USB hub.
> >
> > That's crazy. Why not fix the hardware? How has this hub passed the
> > USB certification process?
> >
> >> The current Kunpeng930's XHCI hardware controller is defective. The number
> >> of ports on its USB3.0 bus controller is 0, and the number of ports on
> >> the USB2.0 bus controller is 1.
> >>
> >> In order to solve this problem that the USB3.0 controller does not have
> >> a port which causes the registration of the hub to fail, this patch passes
> >> the defect information by adding flags in the quirks of xhci and usb_hcd,
> >> and finally skips the registration process of the hub directly according
> >> to the results of these flags when the hub is initialized.
> >>
> >> Signed-off-by: Longfang Liu
> >> ---
> >> drivers/usb/core/hub.c | 6 ++
> >> drivers/usb/host/xhci-pci.c | 4
> >> drivers/usb/host/xhci.c | 5 +
> >> drivers/usb/host/xhci.h | 1 +
> >> include/linux/usb/hcd.h | 1 +
> >> 5 files changed, 17 insertions(+)
> >>
> >> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> >> index b1e14be..2d6869d 100644
> >> --- a/drivers/usb/core/hub.c
> >> +++ b/drivers/usb/core/hub.c
> >> @@ -1769,9 +1769,15 @@ static int hub_probe(struct usb_interface *intf,
> >> const struct usb_device_id *id)
> >>struct usb_host_interface *desc;
> >>struct usb_device *hdev;
> >>struct usb_hub *hub;
> >> + struct usb_hcd *hcd;
> >>
> >>desc = intf->cur_altsetting;
> >>hdev = interface_to_usbdev(intf);
> >> + hcd = bus_to_hcd(hdev->bus);
> >> + if (hcd->usb3_no_port) {
> >> + dev_warn(>dev, "USB hub has no port\n");
> >> + return -ENODEV;
> >> + }
> >>
> >>/*
> >> * Set default autosuspend delay as 0 to speedup bus suspend,
> >> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> >> index ef513c2..63b89a4 100644
> >> --- a/drivers/usb/host/xhci-pci.c
> >> +++ b/drivers/usb/host/xhci-pci.c
> >> @@ -281,6 +281,10 @@ static void xhci_pci_quirks(struct device *dev,
> >> struct xhci_hcd *xhci)
> >>if (xhci->quirks & XHCI_RESET_ON_RESUME)
> >>xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
> >>"QUIRK: Resetting on resume");
> >> +
> >> + if (pdev->vendor == PCI_VENDOR_ID_HUAWEI &&
> >> + pdev->device == 0xa23c)
> >> + xhci->quirks |= XHCI_USB3_NOPORT;
> >
> > Can't we just detect this normally that there are no ports for this
> > device? Why is the device lying about how many ports it has such that
> > we have to "override" this?
> >
>
> The hub driver will check the port number in prob(). If there is no port,
> the driver will report an error log. But we hope this defective device
> does not print error log.
Defective devices deserve to have errors sent to the error log,
otherwise how will people know to tell the companies to fix them?
Again, this device can not pass USB certification, so there's not much
we should do to work around that, right?
thanks,
greg k-h
[PATCH v2 8/8] mm: vmscan: remove noinline_for_stack
The noinline_for_stack is introduced by commit 666356297ec4 ("vmscan:
set up pagevec as late as possible in shrink_inactive_list()"), its
purpose is to delay the allocation of pagevec as late as possible to
save stack memory. But the commit 2bcf88796381 ("mm: take pagevecs off
reclaim stack") replace pagevecs by lists of pages_to_free. So we do
not need noinline_for_stack, just remove it (let the compiler decide
whether to inline).
Signed-off-by: Muchun Song
Acked-by: Johannes Weiner
Acked-by: Roman Gushchin
Reviewed-by: Shakeel Butt
Acked-by: Michal Hocko
---
mm/vmscan.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 2bc5cf409958..2d2727b78df9 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2014,8 +2014,8 @@ static int too_many_isolated(struct pglist_data *pgdat,
int file,
*
* Returns the number of pages moved to the given lruvec.
*/
-static unsigned noinline_for_stack move_pages_to_lru(struct lruvec *lruvec,
-struct list_head *list)
+static unsigned int move_pages_to_lru(struct lruvec *lruvec,
+ struct list_head *list)
{
int nr_pages, nr_moved = 0;
LIST_HEAD(pages_to_free);
@@ -2095,7 +2095,7 @@ static int current_may_throttle(void)
* shrink_inactive_list() is a helper for shrink_node(). It returns the number
* of reclaimed pages
*/
-static noinline_for_stack unsigned long
+static unsigned long
shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
struct scan_control *sc, enum lru_list lru)
{
--
2.11.0
[PATCH v2 7/8] mm: memcontrol: move obj_cgroup_uncharge_pages() out of css_set_lock
The css_set_lock is used to guard the list of inherited objcgs. So there is no need to uncharge kernel memory under css_set_lock. Just move it out of the lock. Signed-off-by: Muchun Song Reviewed-by: Shakeel Butt Acked-by: Roman Gushchin Acked-by: Johannes Weiner --- mm/memcontrol.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index c4eebe2a2914..e0c398fe7443 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -289,9 +289,10 @@ static void obj_cgroup_release(struct percpu_ref *ref) WARN_ON_ONCE(nr_bytes & (PAGE_SIZE - 1)); nr_pages = nr_bytes >> PAGE_SHIFT; - spin_lock_irqsave(_set_lock, flags); if (nr_pages) obj_cgroup_uncharge_pages(objcg, nr_pages); + + spin_lock_irqsave(_set_lock, flags); list_del(>list); spin_unlock_irqrestore(_set_lock, flags); -- 2.11.0
[PATCH v2 6/8] mm: memcontrol: simplify the logic of objcg pinning memcg
The obj_cgroup_release() and memcg_reparent_objcgs() are serialized by
the css_set_lock. We do not need to care about objcg->memcg being
released in the process of obj_cgroup_release(). So there is no need
to pin memcg before releasing objcg. Remove those pinning logic to
simplfy the code.
There are only two places that modifies the objcg->memcg. One is the
initialization to objcg->memcg in the memcg_online_kmem(), another
is objcgs reparenting in the memcg_reparent_objcgs(). It is also
impossible for the two to run in parallel. So xchg() is unnecessary
and it is enough to use WRITE_ONCE().
Signed-off-by: Muchun Song
Acked-by: Johannes Weiner
Reviewed-by: Shakeel Butt
Acked-by: Roman Gushchin
---
mm/memcontrol.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index caf193088beb..c4eebe2a2914 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -261,7 +261,6 @@ static void obj_cgroup_uncharge_pages(struct obj_cgroup
*objcg,
static void obj_cgroup_release(struct percpu_ref *ref)
{
struct obj_cgroup *objcg = container_of(ref, struct obj_cgroup, refcnt);
- struct mem_cgroup *memcg;
unsigned int nr_bytes;
unsigned int nr_pages;
unsigned long flags;
@@ -291,11 +290,9 @@ static void obj_cgroup_release(struct percpu_ref *ref)
nr_pages = nr_bytes >> PAGE_SHIFT;
spin_lock_irqsave(_set_lock, flags);
- memcg = obj_cgroup_memcg(objcg);
if (nr_pages)
obj_cgroup_uncharge_pages(objcg, nr_pages);
list_del(>list);
- mem_cgroup_put(memcg);
spin_unlock_irqrestore(_set_lock, flags);
percpu_ref_exit(ref);
@@ -330,17 +327,12 @@ static void memcg_reparent_objcgs(struct mem_cgroup
*memcg,
spin_lock_irq(_set_lock);
- /* Move active objcg to the parent's list */
- xchg(>memcg, parent);
- css_get(>css);
- list_add(>list, >objcg_list);
-
- /* Move already reparented objcgs to the parent's list */
- list_for_each_entry(iter, >objcg_list, list) {
- css_get(>css);
- xchg(>memcg, parent);
- css_put(>css);
- }
+ /* 1) Ready to reparent active objcg. */
+ list_add(>list, >objcg_list);
+ /* 2) Reparent active objcg and already reparented objcgs to parent. */
+ list_for_each_entry(iter, >objcg_list, list)
+ WRITE_ONCE(iter->memcg, parent);
+ /* 3) Move already reparented objcgs to the parent's list */
list_splice(>objcg_list, >objcg_list);
spin_unlock_irq(_set_lock);
--
2.11.0
[PATCH v2 5/8] mm: memcontrol: rename lruvec_holds_page_lru_lock to page_matches_lruvec
lruvec_holds_page_lru_lock() doesn't check anything about locking and is
used to check whether the page belongs to the lruvec. So rename it to
page_matches_lruvec().
Signed-off-by: Muchun Song
---
include/linux/memcontrol.h | 7 +++
mm/vmscan.c| 2 +-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 2fc728492c9b..40b0c31ea4ba 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -1492,8 +1492,7 @@ static inline void unlock_page_lruvec_irqrestore(struct
lruvec *lruvec,
spin_unlock_irqrestore(>lru_lock, flags);
}
-static inline bool lruvec_holds_page_lru_lock(struct page *page,
- struct lruvec *lruvec)
+static inline bool page_matches_lruvec(struct page *page, struct lruvec
*lruvec)
{
return lruvec_pgdat(lruvec) == page_pgdat(page) &&
lruvec_memcg(lruvec) == page_memcg(page);
@@ -1504,7 +1503,7 @@ static inline struct lruvec
*relock_page_lruvec_irq(struct page *page,
struct lruvec *locked_lruvec)
{
if (locked_lruvec) {
- if (lruvec_holds_page_lru_lock(page, locked_lruvec))
+ if (page_matches_lruvec(page, locked_lruvec))
return locked_lruvec;
unlock_page_lruvec_irq(locked_lruvec);
@@ -1518,7 +1517,7 @@ static inline struct lruvec
*relock_page_lruvec_irqsave(struct page *page,
struct lruvec *locked_lruvec, unsigned long *flags)
{
if (locked_lruvec) {
- if (lruvec_holds_page_lru_lock(page, locked_lruvec))
+ if (page_matches_lruvec(page, locked_lruvec))
return locked_lruvec;
unlock_page_lruvec_irqrestore(locked_lruvec, *flags);
diff --git a/mm/vmscan.c b/mm/vmscan.c
index bb8321026c0c..2bc5cf409958 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2062,7 +2062,7 @@ static unsigned noinline_for_stack
move_pages_to_lru(struct lruvec *lruvec,
* All pages were isolated from the same lruvec (and isolation
* inhibits memcg migration).
*/
- VM_BUG_ON_PAGE(!lruvec_holds_page_lru_lock(page, lruvec), page);
+ VM_BUG_ON_PAGE(!page_matches_lruvec(page, lruvec), page);
add_page_to_lru_list(page, lruvec);
nr_pages = thp_nr_pages(page);
nr_moved += nr_pages;
--
2.11.0
[PATCH v2 4/8] mm: memcontrol: simplify lruvec_holds_page_lru_lock
We already have a helper lruvec_memcg() to get the memcg from lruvec, we
do not need to do it ourselves in the lruvec_holds_page_lru_lock(). So use
lruvec_memcg() instead. And if mem_cgroup_disabled() returns false, the
page_memcg(page) (the LRU pages) cannot be NULL. So remove the odd logic
of "memcg = page_memcg(page) ? : root_mem_cgroup". And use lruvec_pgdat
to simplify the code. We can have a single definition for this function
that works for !CONFIG_MEMCG, CONFIG_MEMCG + mem_cgroup_disabled() and
CONFIG_MEMCG.
Signed-off-by: Muchun Song
Acked-by: Johannes Weiner
Reviewed-by: Shakeel Butt
Acked-by: Roman Gushchin
Acked-by: Michal Hocko
---
include/linux/memcontrol.h | 31 +++
1 file changed, 7 insertions(+), 24 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index f2a5aaba3577..2fc728492c9b 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -755,22 +755,6 @@ static inline struct lruvec *mem_cgroup_page_lruvec(struct
page *page)
return mem_cgroup_lruvec(memcg, pgdat);
}
-static inline bool lruvec_holds_page_lru_lock(struct page *page,
- struct lruvec *lruvec)
-{
- pg_data_t *pgdat = page_pgdat(page);
- const struct mem_cgroup *memcg;
- struct mem_cgroup_per_node *mz;
-
- if (mem_cgroup_disabled())
- return lruvec == >__lruvec;
-
- mz = container_of(lruvec, struct mem_cgroup_per_node, lruvec);
- memcg = page_memcg(page) ? : root_mem_cgroup;
-
- return lruvec->pgdat == pgdat && mz->memcg == memcg;
-}
-
struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p);
struct mem_cgroup *get_mem_cgroup_from_mm(struct mm_struct *mm);
@@ -1227,14 +1211,6 @@ static inline struct lruvec
*mem_cgroup_page_lruvec(struct page *page)
return >__lruvec;
}
-static inline bool lruvec_holds_page_lru_lock(struct page *page,
- struct lruvec *lruvec)
-{
- pg_data_t *pgdat = page_pgdat(page);
-
- return lruvec == >__lruvec;
-}
-
static inline void lruvec_memcg_debug(struct lruvec *lruvec, struct page *page)
{
}
@@ -1516,6 +1492,13 @@ static inline void unlock_page_lruvec_irqrestore(struct
lruvec *lruvec,
spin_unlock_irqrestore(>lru_lock, flags);
}
+static inline bool lruvec_holds_page_lru_lock(struct page *page,
+ struct lruvec *lruvec)
+{
+ return lruvec_pgdat(lruvec) == page_pgdat(page) &&
+ lruvec_memcg(lruvec) == page_memcg(page);
+}
+
/* Don't lock again iff page's lruvec locked */
static inline struct lruvec *relock_page_lruvec_irq(struct page *page,
struct lruvec *locked_lruvec)
--
2.11.0
[PATCH v2 3/8] mm: memcontrol: remove the pgdata parameter of mem_cgroup_page_lruvec
All the callers of mem_cgroup_page_lruvec() just pass page_pgdat(page)
as the 2nd parameter to it (except isolate_migratepages_block()). But
for isolate_migratepages_block(), the page_pgdat(page) is also equal
to the local variable of @pgdat. So mem_cgroup_page_lruvec() do not
need the pgdat parameter. Just remove it to simplify the code.
Signed-off-by: Muchun Song
Acked-by: Johannes Weiner
Reviewed-by: Shakeel Butt
Acked-by: Roman Gushchin
Acked-by: Michal Hocko
---
include/linux/memcontrol.h | 10 +-
mm/compaction.c| 2 +-
mm/memcontrol.c| 9 +++--
mm/swap.c | 2 +-
mm/workingset.c| 2 +-
5 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index c193be760709..f2a5aaba3577 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -743,13 +743,12 @@ static inline struct lruvec *mem_cgroup_lruvec(struct
mem_cgroup *memcg,
/**
* mem_cgroup_page_lruvec - return lruvec for isolating/putting an LRU page
* @page: the page
- * @pgdat: pgdat of the page
*
* This function relies on page->mem_cgroup being stable.
*/
-static inline struct lruvec *mem_cgroup_page_lruvec(struct page *page,
- struct pglist_data *pgdat)
+static inline struct lruvec *mem_cgroup_page_lruvec(struct page *page)
{
+ pg_data_t *pgdat = page_pgdat(page);
struct mem_cgroup *memcg = page_memcg(page);
VM_WARN_ON_ONCE_PAGE(!memcg && !mem_cgroup_disabled(), page);
@@ -1221,9 +1220,10 @@ static inline struct lruvec *mem_cgroup_lruvec(struct
mem_cgroup *memcg,
return >__lruvec;
}
-static inline struct lruvec *mem_cgroup_page_lruvec(struct page *page,
- struct pglist_data *pgdat)
+static inline struct lruvec *mem_cgroup_page_lruvec(struct page *page)
{
+ pg_data_t *pgdat = page_pgdat(page);
+
return >__lruvec;
}
diff --git a/mm/compaction.c b/mm/compaction.c
index 8c5028bfbd56..1c500e697c88 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -994,7 +994,7 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
if (!TestClearPageLRU(page))
goto isolate_fail_put;
- lruvec = mem_cgroup_page_lruvec(page, pgdat);
+ lruvec = mem_cgroup_page_lruvec(page);
/* If we already hold the lock, we can skip some rechecking */
if (lruvec != locked) {
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 50e3cf1e263e..caf193088beb 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1181,9 +1181,8 @@ void lruvec_memcg_debug(struct lruvec *lruvec, struct
page *page)
struct lruvec *lock_page_lruvec(struct page *page)
{
struct lruvec *lruvec;
- struct pglist_data *pgdat = page_pgdat(page);
- lruvec = mem_cgroup_page_lruvec(page, pgdat);
+ lruvec = mem_cgroup_page_lruvec(page);
spin_lock(>lru_lock);
lruvec_memcg_debug(lruvec, page);
@@ -1194,9 +1193,8 @@ struct lruvec *lock_page_lruvec(struct page *page)
struct lruvec *lock_page_lruvec_irq(struct page *page)
{
struct lruvec *lruvec;
- struct pglist_data *pgdat = page_pgdat(page);
- lruvec = mem_cgroup_page_lruvec(page, pgdat);
+ lruvec = mem_cgroup_page_lruvec(page);
spin_lock_irq(>lru_lock);
lruvec_memcg_debug(lruvec, page);
@@ -1207,9 +1205,8 @@ struct lruvec *lock_page_lruvec_irq(struct page *page)
struct lruvec *lock_page_lruvec_irqsave(struct page *page, unsigned long
*flags)
{
struct lruvec *lruvec;
- struct pglist_data *pgdat = page_pgdat(page);
- lruvec = mem_cgroup_page_lruvec(page, pgdat);
+ lruvec = mem_cgroup_page_lruvec(page);
spin_lock_irqsave(>lru_lock, *flags);
lruvec_memcg_debug(lruvec, page);
diff --git a/mm/swap.c b/mm/swap.c
index a75a8265302b..e0d5699213cc 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -313,7 +313,7 @@ void lru_note_cost(struct lruvec *lruvec, bool file,
unsigned int nr_pages)
void lru_note_cost_page(struct page *page)
{
- lru_note_cost(mem_cgroup_page_lruvec(page, page_pgdat(page)),
+ lru_note_cost(mem_cgroup_page_lruvec(page),
page_is_file_lru(page), thp_nr_pages(page));
}
diff --git a/mm/workingset.c b/mm/workingset.c
index b7cdeca5a76d..4f7a306ce75a 100644
--- a/mm/workingset.c
+++ b/mm/workingset.c
@@ -408,7 +408,7 @@ void workingset_activation(struct page *page)
memcg = page_memcg_rcu(page);
if (!mem_cgroup_disabled() && !memcg)
goto out;
- lruvec = mem_cgroup_page_lruvec(page, page_pgdat(page));
+ lruvec = mem_cgroup_page_lruvec(page);
workingset_age_nonresident(lruvec, thp_nr_pages(page));
out:
rcu_read_unlock();
--
2.11.0
[PATCH v2 2/8] mm: memcontrol: bail out early when !mm in get_mem_cgroup_from_mm
When mm is NULL, we do not need to hold rcu lock and call css_tryget for
the root memcg. And we also do not need to check !mm in every loop of
while. So bail out early when !mm.
Signed-off-by: Muchun Song
Acked-by: Johannes Weiner
Reviewed-by: Shakeel Butt
Acked-by: Roman Gushchin
Acked-by: Michal Hocko
---
mm/memcontrol.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index f229de925aa5..50e3cf1e263e 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -901,20 +901,23 @@ struct mem_cgroup *get_mem_cgroup_from_mm(struct
mm_struct *mm)
if (mem_cgroup_disabled())
return NULL;
+ /*
+* Page cache insertions can happen without an
+* actual mm context, e.g. during disk probing
+* on boot, loopback IO, acct() writes etc.
+*
+* No need to css_get on root memcg as the reference
+* counting is disabled on the root level in the
+* cgroup core. See CSS_NO_REF.
+*/
+ if (unlikely(!mm))
+ return root_mem_cgroup;
+
rcu_read_lock();
do {
- /*
-* Page cache insertions can happen without an
-* actual mm context, e.g. during disk probing
-* on boot, loopback IO, acct() writes etc.
-*/
- if (unlikely(!mm))
+ memcg = mem_cgroup_from_task(rcu_dereference(mm->owner));
+ if (unlikely(!memcg))
memcg = root_mem_cgroup;
- else {
- memcg =
mem_cgroup_from_task(rcu_dereference(mm->owner));
- if (unlikely(!memcg))
- memcg = root_mem_cgroup;
- }
} while (!css_tryget(>css));
rcu_read_unlock();
return memcg;
--
2.11.0
[PATCH v2 0/8] memcontrol code cleanup and simplification
This patch series is part of [1] patch series. Because those patches are code cleanup or simplification. I gather those patches into a separate series to make it easier to review. [1] https://lore.kernel.org/linux-mm/20210409122959.82264-1-songmuc...@bytedance.com/ Changlogs in v2: 1. Collect Acked-by and Review-by tags. 2. Add a new patch to rename lruvec_holds_page_lru_lock to page_matches_lruvec. 3. Add a comment to patch 2. Thanks to Roman, Johannes, Shakeel and Michal's review. Muchun Song (8): mm: memcontrol: fix page charging in page replacement mm: memcontrol: bail out early when !mm in get_mem_cgroup_from_mm mm: memcontrol: remove the pgdata parameter of mem_cgroup_page_lruvec mm: memcontrol: simplify lruvec_holds_page_lru_lock mm: memcontrol: rename lruvec_holds_page_lru_lock to page_matches_lruvec mm: memcontrol: simplify the logic of objcg pinning memcg mm: memcontrol: move obj_cgroup_uncharge_pages() out of css_set_lock mm: vmscan: remove noinline_for_stack include/linux/memcontrol.h | 42 +- mm/compaction.c| 2 +- mm/memcontrol.c| 65 +- mm/swap.c | 2 +- mm/vmscan.c| 8 +++--- mm/workingset.c| 2 +- 6 files changed, 49 insertions(+), 72 deletions(-) -- 2.11.0
[PATCH v2 1/8] mm: memcontrol: fix page charging in page replacement
The pages aren't accounted at the root level, so do not charge the page
to the root memcg in page replacement. Although we do not display the
value (mem_cgroup_usage) so there shouldn't be any actual problem, but
there is a WARN_ON_ONCE in the page_counter_cancel(). Who knows if it
will trigger? So it is better to fix it.
Signed-off-by: Muchun Song
Acked-by: Johannes Weiner
Reviewed-by: Shakeel Butt
Acked-by: Roman Gushchin
Acked-by: Michal Hocko
---
mm/memcontrol.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 64ada9e650a5..f229de925aa5 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6806,9 +6806,11 @@ void mem_cgroup_migrate(struct page *oldpage, struct
page *newpage)
/* Force-charge the new page. The old one will be freed soon */
nr_pages = thp_nr_pages(newpage);
- page_counter_charge(>memory, nr_pages);
- if (do_memsw_account())
- page_counter_charge(>memsw, nr_pages);
+ if (!mem_cgroup_is_root(memcg)) {
+ page_counter_charge(>memory, nr_pages);
+ if (do_memsw_account())
+ page_counter_charge(>memsw, nr_pages);
+ }
css_get(>css);
commit_charge(newpage, memcg);
--
2.11.0
Re: [PATCH v2] watchdog: aspeed: fix integer overflow in set_timeout handler
On 4/15/21 7:13 PM, rentao.b...@gmail.com wrote:
> From: Tao Ren
>
> Fix the time comparison (timeout vs. max_hw_heartbeat_ms) in set_timeout
> handler to avoid potential integer overflow when the supplied timeout is
> greater than aspeed's maximum allowed timeout (4294 seconds).
>
I think this is the wrong focus: What this fixes is the wrong hardware
timeout calculation. Again, I think that the wrong calculation leads to
the overflow should not be the focus of this patch, though it can of
course be mentioned.
I'll leave it up to Wim to decide if he wants to apply the patch with the
current explanation.
Thanks,
Guenter
> Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
> Reported-by: Amithash Prasad
> Signed-off-by: Tao Ren
> ---
> Changes in v2:
>- do not touch "wdd->timeout": only "max_hw_heartbeat_ms * 1000" is
> updated to "max_hw_heartbeat_ms / 1000".
>
> drivers/watchdog/aspeed_wdt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
> index 7e00960651fa..507fd815d767 100644
> --- a/drivers/watchdog/aspeed_wdt.c
> +++ b/drivers/watchdog/aspeed_wdt.c
> @@ -147,7 +147,7 @@ static int aspeed_wdt_set_timeout(struct watchdog_device
> *wdd,
>
> wdd->timeout = timeout;
>
> - actual = min(timeout, wdd->max_hw_heartbeat_ms * 1000);
> + actual = min(timeout, wdd->max_hw_heartbeat_ms / 1000);
>
> writel(actual * WDT_RATE_1MHZ, wdt->base + WDT_RELOAD_VALUE);
> writel(WDT_RESTART_MAGIC, wdt->base + WDT_RESTART);
>
Re: [PATCH 00/13] [RFC] Rust support
On Fri, Apr 16, 2021 at 04:25:34AM +, Al Viro wrote: > > Are you stating [what you perceive as] a fact or just venting? If the > > former, > > would you mind enlightening us with some evidence? > > How about "not everyone uses a browser as a part of their workflow"? The documentation is available in markdown alongside the code. You don't need a browser to see it. I, for one, use neovim and a rust LSP, so I can see the documentation by pressing shift+k. > I realize that it might sound ridiculous for folks who spent a while > around Mozilla, but it's really true and kernel community actually > has quite a few of such freaks. I haven't spent any time around Mozilla myself (not that there's anything wrong with it), so I can't really comment on this. > And as one of those freaks I can tell > you where exactly I would like you to go and what I would like you to do > with implicit suggestions to start a browser when I need to read some > in-tree documentation. I could be mistaken but you seem angry. Perhaps it wouldn't be a bad idea to read your own code of conduct, I don't think you need a browser for that either.
Re: [RFC PATCH] percpu_ref: Make percpu_ref_tryget*() ACQUIRE operations
On Thu, Apr 15, 2021 at 09:42:56PM -0700, Paul E. McKenney wrote:
> On Tue, Apr 13, 2021 at 10:47:03AM +0800, Huang Ying wrote:
> > One typical use case of percpu_ref_tryget() family functions is as
> > follows,
> >
> > if (percpu_ref_tryget(>ref)) {
> > /* Operate on the other fields of *p */
> > }
> >
> > The refcount needs to be checked before operating on the other fields
> > of the data structure (*p), otherwise, the values gotten from the
> > other fields may be invalid or inconsistent. To guarantee the correct
> > memory ordering, percpu_ref_tryget*() needs to be the ACQUIRE
> > operations.
>
> I am not seeing the need for this.
>
> If __ref_is_percpu() returns true, then the overall count must be non-zero
> and there will be an RCU grace period between now and the time that this
> count becomes zero. For the calls to __ref_is_percpu() enclosed within
> rcu_read_lock() and rcu_read_unlock(), the grace period will provide
> the needed ordering. (See the comment header for the synchronize_rcu()
> function.)
>
> Otherwise, when __ref_is_percpu() returns false, its caller does a
> value-returning atomic read-modify-write operation, which provides
> full ordering.
>
> Either way, the required acquire semantics (and more) are already
> provided, and in particular, this analysis covers the percpu_ref_tryget()
> you call out above.
>
> Or am I missing something subtle here?
I think you're right, but some details about the race we're concerned about
would be helpful. Are we concerned about seeing values from after the ref has
hit 0? In that case I agree with Paul. Or is the concern about seeing values
from before a transition from 0 to nonzero? That wasn't a concern when I wrote
the code for the patterns of use I had in mind, but Tejun's done some stuff with
the code since.
Huang, can you elaborate?
[RFC PATCH] capabilities: require CAP_SETFCAP to map uid 0 (v3)
(Eric - this patch (v3) is a cleaned up version of the previous approach.
v4 is at
https://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux.git/log/?h=2021-04-15/setfcap-nsfscaps-v4
and is the approach you suggested. I can send it also as a separate patch
if you like)
A process running as uid 0 but without cap_setfcap currently can simply
unshare a new user namespace with uid 0 mapped to 0. While this task
will not have new capabilities against the parent namespace, there is
a loophole due to the way namespaced file capabilities work. File
capabilities valid in userns 1 are distinguised from file capabilities
valid in userns 2 by the kuid which underlies uid 0. Therefore
the restricted root process can unshare a new self-mapping namespace,
add a namespaced file capability onto a file, then use that file
capability in the parent namespace.
To prevent that, do not allow mapping uid 0 if the process which
opened the uid_map file does not have CAP_SETFCAP, which is the capability
for setting file capabilities.
A further wrinkle: a task can unshare its user namespace, then
open its uid_map file itself, and map (only) its own uid. In this
case we do not have the credential from before unshare, which was
potentially more restricted. So, when creating a user namespace, we
record whether the creator had CAP_SETFCAP. Then we can use that
during map_write().
With this patch:
1. unprivileged user can still unshare -Ur
ubuntu@caps:~$ unshare -Ur
root@caps:~# logout
2. root user can still unshare -Ur
ubuntu@caps:~$ sudo bash
root@caps:/home/ubuntu# unshare -Ur
root@caps:/home/ubuntu# logout
3. root user without CAP_SETFCAP cannot unshare -Ur:
root@caps:/home/ubuntu# /sbin/capsh --drop=cap_setfcap --
root@caps:/home/ubuntu# /sbin/setcap cap_setfcap=p /sbin/setcap
unable to set CAP_SETFCAP effective capability: Operation not permitted
root@caps:/home/ubuntu# unshare -Ur
unshare: write failed /proc/self/uid_map: Operation not permitted
Signed-off-by: Serge Hallyn
Changelog:
* fix logic in the case of writing to another task's uid_map
* rename 'ns' to 'map_ns', and make a file_ns local variable
* use /* comments */
* update the CAP_SETFCAP comment in capability.h
* rename parent_unpriv to parent_can_setfcap (and reverse the
logic)
* remove printks
* clarify (i hope) the code comments
* update capability.h comment
* renamed parent_can_setfcap to parent_could_setfcap
* made the check its own disallowed_0_mapping() fn
* moved the check into new_idmap_permitted
---
include/linux/user_namespace.h | 3 ++
include/uapi/linux/capability.h | 3 +-
kernel/user_namespace.c | 61 +++--
3 files changed, 63 insertions(+), 4 deletions(-)
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index 64cf8ebdc4ec..f6c5f784be5a 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -63,6 +63,9 @@ struct user_namespace {
kgid_t group;
struct ns_commonns;
unsigned long flags;
+ /* parent_could_setfcap: true if the creator if this ns had CAP_SETFCAP
+* in its effective capability set at the child ns creation time. */
+ boolparent_could_setfcap;
#ifdef CONFIG_KEYS
/* List of joinable keyrings in this namespace. Modification access of
diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index c6ca33034147..2ddb4226cd23 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -335,7 +335,8 @@ struct vfs_ns_cap_data {
#define CAP_AUDIT_CONTROL30
-/* Set or remove capabilities on files */
+/* Set or remove capabilities on files.
+ Map uid=0 into a child user namespace. */
#define CAP_SETFCAP 31
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index af612945a4d0..8c75028a9aae 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -106,6 +106,7 @@ int create_user_ns(struct cred *new)
if (!ns)
goto fail_dec;
+ ns->parent_could_setfcap = cap_raised(new->cap_effective, CAP_SETFCAP);
ret = ns_alloc_inum(>ns);
if (ret)
goto fail_free;
@@ -841,6 +842,56 @@ static int sort_idmaps(struct uid_gid_map *map)
return 0;
}
+/*
+ * If mapping uid 0, then file capabilities created by the new namespace will
+ * be effective in the parent namespace. Adding file capabilities requires
+ * CAP_SETFCAP, which the child namespace will have, so creating such a
+ * mapping requires CAP_SETFCAP in the parent namespace.
+ */
+static bool disallowed_0_mapping(const struct file *file,
+struct user_namespace *map_ns,
+struct uid_gid_map *new_map)
+{
+ int idx;
+ bool zeromapping = false;
+ const struct user_namespace *file_ns = file->f_cred->user_ns;
+
+
Re: [PATCH] kernel:irq:manage: request threaded irq with a specified priority
On 2021/4/13 下午4:39, Thomas Gleixner wrote: On Tue, Apr 13 2021 at 14:19, Song Chen wrote: In general, irq handler thread will be assigned a default priority which is MAX_RT_PRIO/2, as a result, no one can preempt others. Here is the case I found in a real project, an interrupt int_a is coming, wakes up its handler handler_a and handler_a wakes up a userspace RT process task_a. However, if another irq handler handler_b which has nothing to do with any RT tasks is running when int_a is coming, handler_a can't preempt handler_b, as a result, task_a can't be waken up immediately as expected until handler_b gives up cpu voluntarily. In this case, determinism breaks. It breaks because the system designer failed to assign proper priorities to the irq threads int_a, int_b and to the user space process task_a. yes, it's designers' responsibility to assign proper priorities, but kernel is also obliged to provide interfaces for those designers. chrt can help designers in this case, however, the truth is lot of customers are not familiar with it. what's more, chrt can also apply to userspace rt task, but userspace also has sched_setscheduler to assgin proper priority inside code like cyclictest, why can't driver writers have another choice? Further, what if irq handlear thread has to run on the expected priority at the very beginning? This patch helps. BR Song That's not solvable at the kernel level. Thanks, tglx
Re: High kmalloc-32 slab cache consumption with 10k containers
On Wed, Apr 07, 2021 at 08:28:07AM +1000, Dave Chinner wrote: > On Mon, Apr 05, 2021 at 11:18:48AM +0530, Bharata B Rao wrote: > > > As an alternative approach, I have this below hack that does lazy > > list_lru creation. The memcg-specific list is created and initialized > > only when there is a request to add an element to that particular > > list. Though I am not sure about the full impact of this change > > on the owners of the lists and also the performance impact of this, > > the overall savings look good. > > Avoiding memory allocation in list_lru_add() was one of the main > reasons for up-front static allocation of memcg lists. We cannot do > memory allocation while callers are holding multiple spinlocks in > core system algorithms (e.g. dentry_kill -> retain_dentry -> > d_lru_add -> list_lru_add), let alone while holding an internal > spinlock. > > Putting a GFP_ATOMIC allocation inside 3-4 nested spinlocks in a > path we know might have memory demand in the *hundreds of GB* range > gets an NACK from me. It's a great idea, but it's just not a I do understand that GFP_ATOMIC allocations are really not preferrable but want to point out that the allocations in the range of hundreds of GBs get reduced to tens of MBs when we do lazy list_lru head allocations under GFP_ATOMIC. As shown earlier, this is what I see in my experimental setup with 10k containers: Number of kmalloc-32 allocations Before During After W/o patch 178176 3442409472 388933632 W/ patch 190464 468992 468992 So 3442409472*32=102GB upfront list_lru creation-time GFP_KERNEL allocations get reduced to 468992*32=14MB dynamic list_lru addtion-time GFP_ATOMIC allocations. This does really depend and vary on the type of the container and the number of mounts it does, but I suspect we are looking at GFP_ATOMIC allocations in the MB range. Also the number of GFP_ATOMIC slab allocation requests matter I suppose. There are other users of list_lru, but I was just looking at dentry and inode list_lru usecase. It appears to me that for both dentry and inode, we can tolerate the failure from list_lru_add due to GFP_ATOMIC allocation failure. The failure to add dentry or inode to the lru list means that they won't be retained in the lru list, but would be freed immediately. Is this understanding correct? If so, would that likely impact the subsequent lookups adversely? We failed to retain a dentry or inode in the lru list because we failed to allocate memory, presumably under memory pressure. Even in such a scenario, is failure to add dentry or inode to lru list so bad and not tolerable? Regards, Bharata.
Re: [RFC PATCH] percpu_ref: Make percpu_ref_tryget*() ACQUIRE operations
On Tue, Apr 13, 2021 at 10:47:03AM +0800, Huang Ying wrote:
> One typical use case of percpu_ref_tryget() family functions is as
> follows,
>
> if (percpu_ref_tryget(>ref)) {
> /* Operate on the other fields of *p */
> }
>
> The refcount needs to be checked before operating on the other fields
> of the data structure (*p), otherwise, the values gotten from the
> other fields may be invalid or inconsistent. To guarantee the correct
> memory ordering, percpu_ref_tryget*() needs to be the ACQUIRE
> operations.
I am not seeing the need for this.
If __ref_is_percpu() returns true, then the overall count must be non-zero
and there will be an RCU grace period between now and the time that this
count becomes zero. For the calls to __ref_is_percpu() enclosed within
rcu_read_lock() and rcu_read_unlock(), the grace period will provide
the needed ordering. (See the comment header for the synchronize_rcu()
function.)
Otherwise, when __ref_is_percpu() returns false, its caller does a
value-returning atomic read-modify-write operation, which provides
full ordering.
Either way, the required acquire semantics (and more) are already
provided, and in particular, this analysis covers the percpu_ref_tryget()
you call out above.
Or am I missing something subtle here?
Thanx, Paul
> This function implements that via using smp_load_acquire() in
> __ref_is_percpu() to read the percpu pointer.
>
> Signed-off-by: "Huang, Ying"
> Cc: Tejun Heo
> Cc: Kent Overstreet
> Cc: "Paul E. McKenney"
> Cc: Roman Gushchin
> Cc: Ming Lei
> Cc: Al Viro
> Cc: Miaohe Lin
> ---
> include/linux/percpu-refcount.h | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
> index 16c35a728b4c..9838f7ea4bf1 100644
> --- a/include/linux/percpu-refcount.h
> +++ b/include/linux/percpu-refcount.h
> @@ -165,13 +165,13 @@ static inline bool __ref_is_percpu(struct percpu_ref
> *ref,
>* !__PERCPU_REF_ATOMIC, which may be set asynchronously, and then
>* used as a pointer. If the compiler generates a separate fetch
>* when using it as a pointer, __PERCPU_REF_ATOMIC may be set in
> - * between contaminating the pointer value, meaning that
> - * READ_ONCE() is required when fetching it.
> + * between contaminating the pointer value, smp_load_acquire()
> + * will prevent this.
>*
> - * The dependency ordering from the READ_ONCE() pairs
> + * The dependency ordering from the smp_load_acquire() pairs
>* with smp_store_release() in __percpu_ref_switch_to_percpu().
>*/
> - percpu_ptr = READ_ONCE(ref->percpu_count_ptr);
> + percpu_ptr = smp_load_acquire(>percpu_count_ptr);
>
> /*
>* Theoretically, the following could test just ATOMIC; however,
> @@ -231,6 +231,9 @@ static inline void percpu_ref_get(struct percpu_ref *ref)
> * Returns %true on success; %false on failure.
> *
> * This function is safe to call as long as @ref is between init and exit.
> + *
> + * This function is an ACQUIRE operation, that is, all memory operations
> + * after will appear to happen after checking the refcount.
> */
> static inline bool percpu_ref_tryget_many(struct percpu_ref *ref,
> unsigned long nr)
> @@ -260,6 +263,9 @@ static inline bool percpu_ref_tryget_many(struct
> percpu_ref *ref,
> * Returns %true on success; %false on failure.
> *
> * This function is safe to call as long as @ref is between init and exit.
> + *
> + * This function is an ACQUIRE operation, that is, all memory operations
> + * after will appear to happen after checking the refcount.
> */
> static inline bool percpu_ref_tryget(struct percpu_ref *ref)
> {
> @@ -280,6 +286,9 @@ static inline bool percpu_ref_tryget(struct percpu_ref
> *ref)
> * percpu_ref_tryget_live().
> *
> * This function is safe to call as long as @ref is between init and exit.
> + *
> + * This function is an ACQUIRE operation, that is, all memory operations
> + * after will appear to happen after checking the refcount.
> */
> static inline bool percpu_ref_tryget_live(struct percpu_ref *ref)
> {
> --
> 2.30.2
>
Re: [PATCH v1 1/1] powerpc/papr_scm: Properly handle UUID types and API
On 4/15/21 7:16 PM, Andy Shevchenko wrote:
Parse to and export from UUID own type, before dereferencing.
This also fixes wrong comment (Little Endian UUID is something else)
and should fix Sparse warnings about assigning strict types to POD.
I am wondering whether this will break older namespace created. IIRC
that cpu_to_le64 was done to be backward compatible with namespaces
created before 259a948c4ba1.
What we need to test is create a namespace in little endian kernel and
read it back in via big endian and vice versa. Also we need to make sure
we can read the already created namespace before this patch.
Fixes: 43001c52b603 ("powerpc/papr_scm: Use ibm,unit-guid as the iset cookie")
Fixes: 259a948c4ba1 ("powerpc/pseries/scm: Use a specific endian format for storing
uuid from the device tree")
Cc: Oliver O'Halloran
Cc: Aneesh Kumar K.V
Signed-off-by: Andy Shevchenko
---
Not tested
arch/powerpc/platforms/pseries/papr_scm.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c
b/arch/powerpc/platforms/pseries/papr_scm.c
index ae6f5d80d5ce..4366e1902890 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -1085,8 +1085,9 @@ static int papr_scm_probe(struct platform_device *pdev)
u32 drc_index, metadata_size;
u64 blocks, block_size;
struct papr_scm_priv *p;
+ u8 uuid_raw[UUID_SIZE];
const char *uuid_str;
- u64 uuid[2];
+ uuid_t uuid;
int rc;
/* check we have all the required DT properties */
@@ -1129,16 +1130,18 @@ static int papr_scm_probe(struct platform_device *pdev)
p->hcall_flush_required = of_property_read_bool(dn,
"ibm,hcall-flush-required");
/* We just need to ensure that set cookies are unique across */
- uuid_parse(uuid_str, (uuid_t *) uuid);
+ uuid_parse(uuid_str, );
+
/*
* cookie1 and cookie2 are not really little endian
-* we store a little endian representation of the
+* we store a raw buffer representation of the
* uuid str so that we can compare this with the label
* area cookie irrespective of the endian config with which
* the kernel is built.
*/
- p->nd_set.cookie1 = cpu_to_le64(uuid[0]);
- p->nd_set.cookie2 = cpu_to_le64(uuid[1]);
+ export_uuid(uuid_raw, );
+ p->nd_set.cookie1 = get_unaligned_le64(_raw[0]);
+ p->nd_set.cookie2 = get_unaligned_le64(_raw[8]);
/* might be zero */
p->metadata_size = metadata_size;
[syzbot] WARNING in ctx_sched_in
Hello, syzbot found the following issue on: HEAD commit:79c338ab riscv: keep interrupts disabled for BREAKPOINT ex.. git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes console output: https://syzkaller.appspot.com/x/log.txt?x=10fb93f9d0 kernel config: https://syzkaller.appspot.com/x/.config?x=f8af20e245283c9a dashboard link: https://syzkaller.appspot.com/bug?extid=50d41b514809f6f4f326 userspace arch: riscv64 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+50d41b514809f6f4f...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 1 PID: 4475 at kernel/events/core.c:3752 ctx_sched_in+0x12e/0x3ee kernel/events/core.c:3752 Modules linked in: CPU: 1 PID: 4475 Comm: syz-executor.1 Not tainted 5.12.0-rc6-syzkaller-00183-g79c338ab575e #0 Hardware name: riscv-virtio,qemu (DT) epc : ctx_sched_in+0x12e/0x3ee kernel/events/core.c:3752 ra : ctx_sched_in+0x12e/0x3ee kernel/events/core.c:3752 epc : ffe000279fe8 ra : ffe000279fe8 sp : ffe009e17680 gp : ffe004588ad0 tp : ffe006398000 t0 : t1 : 0001 t2 : 000f4240 s0 : ffe009e176f0 s1 : ffe0077edc00 a0 : ffe067d79118 a1 : 000f a2 : 0002 a3 : ffe000279fe8 a4 : ffe006399000 a5 : 4000 a6 : 00f0 a7 : ffe000280cc8 s2 : 0007 s3 : ffe0077edd40 s4 : ffe006398000 s5 : 0002 s6 : ffe00458c0d0 s7 : ffe067d78f70 s8 : 0007 s9 : ffe067d79118 s10: ffe0077edc00 s11: ffe0077edc08 t3 : e189d98bb4bfb900 t4 : ffc4042c47b2 t5 : ffc4042c47ba t6 : 0004 status: 0100 badaddr: cause: 0003 Call Trace: [] ctx_sched_in+0x12e/0x3ee kernel/events/core.c:3752 [] perf_event_sched_in+0x38/0x74 kernel/events/core.c:2680 [] perf_event_context_sched_in kernel/events/core.c:3817 [inline] [] __perf_event_task_sched_in+0x4ea/0x680 kernel/events/core.c:3860 [] perf_event_task_sched_in include/linux/perf_event.h:1210 [inline] [] finish_task_switch.isra.0+0x284/0x318 kernel/sched/core.c:4189 [] context_switch kernel/sched/core.c:4325 [inline] [] __schedule+0x484/0xe8c kernel/sched/core.c:5073 [] preempt_schedule_notrace+0x9c/0x19a kernel/sched/core.c:5312 [] rcu_read_unlock_sched_notrace include/linux/rcupdate.h:794 [inline] [] trace_lock_acquire+0xf0/0x20e include/trace/events/lock.h:13 [] lock_acquire+0x28/0x5a kernel/locking/lockdep.c:5481 [] rcu_lock_acquire include/linux/rcupdate.h:267 [inline] [] rcu_read_lock include/linux/rcupdate.h:656 [inline] [] percpu_ref_put_many.constprop.0+0x38/0x148 include/linux/percpu-refcount.h:317 [] percpu_ref_put include/linux/percpu-refcount.h:338 [inline] [] obj_cgroup_put include/linux/memcontrol.h:713 [inline] [] memcg_slab_free_hook mm/slab.h:372 [inline] [] memcg_slab_free_hook mm/slab.h:336 [inline] [] do_slab_free mm/slub.c:3117 [inline] [] ___cache_free+0x2bc/0x3dc mm/slub.c:3168 [] qlink_free mm/kasan/quarantine.c:146 [inline] [] qlist_free_all+0x56/0xac mm/kasan/quarantine.c:165 [] kasan_quarantine_reduce+0x14c/0x1c8 mm/kasan/quarantine.c:272 [] __kasan_slab_alloc+0x60/0x62 mm/kasan/common.c:437 [] kasan_slab_alloc include/linux/kasan.h:223 [inline] [] slab_post_alloc_hook mm/slab.h:516 [inline] [] slab_alloc_node mm/slub.c:2907 [inline] [] slab_alloc mm/slub.c:2915 [inline] [] kmem_cache_alloc+0x168/0x3ca mm/slub.c:2920 [] kmem_cache_zalloc include/linux/slab.h:674 [inline] [] taskstats_tgid_alloc kernel/taskstats.c:561 [inline] [] taskstats_exit+0x3ce/0x5fe kernel/taskstats.c:600 [] do_exit+0x3b2/0x1846 kernel/exit.c:810 [] do_group_exit+0xa0/0x198 kernel/exit.c:922 [] get_signal+0x31e/0x14ba kernel/signal.c:2781 [] do_signal arch/riscv/kernel/signal.c:271 [inline] [] do_notify_resume+0xa8/0x930 arch/riscv/kernel/signal.c:317 [] ret_from_exception+0x0/0x14 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH v3] powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h
Hello Michael, The latest version of this patch addressed all feedback I'm aware of when submitted last September, and I've seen no further comments from reviewers since then. Could you please let me know where this stands and if anything further is needed? Kind regards, Tony On Thu, 17 Sept 2020 at 06:54, Tony Ambardar wrote: > > A few archs like powerpc have different errno.h values for macros > EDEADLOCK and EDEADLK. In code including both libc and linux versions of > errno.h, this can result in multiple definitions of EDEADLOCK in the > include chain. Definitions to the same value (e.g. seen with mips) do > not raise warnings, but on powerpc there are redefinitions changing the > value, which raise warnings and errors (if using "-Werror"). > > Guard against these redefinitions to avoid build errors like the following, > first seen cross-compiling libbpf v5.8.9 for powerpc using GCC 8.4.0 with > musl 1.1.24: > > In file included from ../../arch/powerpc/include/uapi/asm/errno.h:5, >from ../../include/linux/err.h:8, >from libbpf.c:29: > ../../include/uapi/asm-generic/errno.h:40: error: "EDEADLOCK" redefined > [-Werror] >#define EDEADLOCK EDEADLK > > In file included from > toolchain-powerpc_8540_gcc-8.4.0_musl/include/errno.h:10, >from libbpf.c:26: > toolchain-powerpc_8540_gcc-8.4.0_musl/include/bits/errno.h:58: note: this > is the location of the previous definition >#define EDEADLOCK 58 > > cc1: all warnings being treated as errors > > CC: Stable > Reported-by: Rosen Penev > Signed-off-by: Tony Ambardar > --- > v1 -> v2: > * clean up commit description formatting > > v2 -> v3: (per Michael Ellerman) > * drop indeterminate 'Fixes' tags, request stable backports instead > --- > arch/powerpc/include/uapi/asm/errno.h | 1 + > tools/arch/powerpc/include/uapi/asm/errno.h | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/arch/powerpc/include/uapi/asm/errno.h > b/arch/powerpc/include/uapi/asm/errno.h > index cc79856896a1..4ba87de32be0 100644 > --- a/arch/powerpc/include/uapi/asm/errno.h > +++ b/arch/powerpc/include/uapi/asm/errno.h > @@ -2,6 +2,7 @@ > #ifndef _ASM_POWERPC_ERRNO_H > #define _ASM_POWERPC_ERRNO_H > > +#undef EDEADLOCK > #include > > #undef EDEADLOCK > diff --git a/tools/arch/powerpc/include/uapi/asm/errno.h > b/tools/arch/powerpc/include/uapi/asm/errno.h > index cc79856896a1..4ba87de32be0 100644 > --- a/tools/arch/powerpc/include/uapi/asm/errno.h > +++ b/tools/arch/powerpc/include/uapi/asm/errno.h > @@ -2,6 +2,7 @@ > #ifndef _ASM_POWERPC_ERRNO_H > #define _ASM_POWERPC_ERRNO_H > > +#undef EDEADLOCK > #include > > #undef EDEADLOCK > -- > 2.25.1 >
Re: [kbuild] drivers/gpu/drm/msm/adreno/a3xx_gpu.c:600 a3xx_gpu_init() error: passing non negative 1 to ERR_PTR
On Thu, Apr 15, 2021 at 04:21:01PM -0700, Rob Clark wrote:
> > > 5785dd7a8ef0de Akhil P Oommen 2020-10-28 571 icc_path =
> > > devm_of_icc_get(>dev, "gfx-mem");
> > > 5785dd7a8ef0de Akhil P Oommen 2020-10-28 572 ret =
> > > IS_ERR(icc_path);
> > > 5785dd7a8ef0de Akhil P Oommen 2020-10-28 573 if (ret)
> > > 5785dd7a8ef0de Akhil P Oommen 2020-10-28 574 goto fail;
> > >
> > > IS_ERR() returns/true false so this will lead to an Oops in the caller.
> > >
> > > icc_path = devm_of_icc_get(>dev, "gfx-mem");
> > > if (IS_ERR(icc_path)) {
> > > ret = PTR_ERR(icc_path);
> > > goto fail;
> > > }
> > Agree.
> >
> > >
> > > 5785dd7a8ef0de Akhil P Oommen 2020-10-28 575
> > > 5785dd7a8ef0de Akhil P Oommen 2020-10-28 576 ocmem_icc_path =
> > > devm_of_icc_get(>dev, "ocmem");
> > > 5785dd7a8ef0de Akhil P Oommen 2020-10-28 577 ret =
> > > IS_ERR(ocmem_icc_path);
> > > 5785dd7a8ef0de Akhil P Oommen 2020-10-28 578 if (ret) {
> > > 5785dd7a8ef0de Akhil P Oommen 2020-10-28 579 /* allow
> > > -ENODATA, ocmem icc is optional */
> > > 5785dd7a8ef0de Akhil P Oommen 2020-10-28 580 if (ret !=
> > > -ENODATA)
> > > 5785dd7a8ef0de Akhil P Oommen 2020-10-28 581
> > > goto fail;
> > >
> > > Same. ret is true/false so it can't be equal to -ENODATA, plus the
> > > caller will Oops.
> > >
> > > Btw, this patch removed the assignments:
> > >
> > > gpu->icc_path = of_icc_get(dev, "gfx-mem");
> > > gpu->ocmem_icc_path = of_icc_get(dev, "ocmem");
> > >
> > > So I think "gpu->icc_path" and "gpu->ocmem_icc_path" are always
> > > NULL/unused and they should be removed.
> > >
> > Agree. Will share a fix.
> > Thanks, Dan.
>
> gpu->ocmem_icc_path/icc_path is used on older devices.. it sounds like
> we broke some older devices and no one has noticed yet?
This is error paths and dead code. Probably no one is affected in
real life.
regards,
dan carpenter
Re: [PATCH] bonding: 3ad: update slave arr after initialize
jinyiting wrote:
>From: jin yiting
>
>The bond works in mode 4, and performs down/up operations on the bond
>that is normally negotiated. The probability of bond-> slave_arr is NULL
>
>Test commands:
>ifconfig bond1 down
>ifconfig bond1 up
>
>The conflict occurs in the following process：
>
>__dev_open (CPU A)
> --bond_open
> --queue_delayed_work(bond->wq,>ad_work,0);
> --bond_update_slave_arr
> --bond_3ad_get_active_agg_info
>
>ad_work(CPU B)
> --bond_3ad_state_machine_handler
> --ad_agg_selection_logic
>
>ad_work runs on cpu B. In the function ad_agg_selection_logic, all
>agg->is_active will be cleared. Before the new active aggregator is
>selected on CPU B, bond_3ad_get_active_agg_info failed on CPU A,
>bond->slave_arr will be set to NULL. The best aggregator in
>ad_agg_selection_logic has not changed, no need to update slave arr.
>
>Signed-off-by: jin yiting
>---
> drivers/net/bonding/bond_3ad.c | 6 ++
> 1 file changed, 6 insertions(+)
>
>diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
>index 6908822..d100079 100644
>--- a/drivers/net/bonding/bond_3ad.c
>+++ b/drivers/net/bonding/bond_3ad.c
>@@ -2327,6 +2327,12 @@ void bond_3ad_state_machine_handler(struct work_struct
>*work)
>
> aggregator = __get_first_agg(port);
> ad_agg_selection_logic(aggregator, _slave_arr);
>+ if (!update_slave_arr) {
>+ struct aggregator *active =
>__get_active_agg(aggregator);
>+
>+ if (active && active->is_active)
>+ update_slave_arr = true;
>+ }
> }
> bond_3ad_set_carrier(bond);
> }
The described issue is a race condition (in that
ad_agg_selection_logic clears agg->is_active under mode_lock, but
bond_open -> bond_update_slave_arr is inspecting agg->is_active outside
the lock). I don't see how the above change will reliably manage this;
the real issue looks to be that bond_update_slave_arr is committing
changes to the array (via bond_reset_slave_arr) based on a racy
inspection of the active aggregator state while it is in flux.
Also, the description of the issue says "The best aggregator in
ad_agg_selection_logic has not changed, no need to update slave arr,"
but the change above does the opposite, and will set update_slave_arr
when the aggregator has not changed (update_slave_arr remains false at
return of ad_agg_selection_logic).
I believe I understand the described problem, but I don't see
how the patch fixes it. I suspect (but haven't tested) that the proper
fix is to acquire mode_lock in bond_update_slave_arr while calling
bond_3ad_get_active_agg_info to avoid conflict with the state machine.
-J
---
-Jay Vosburgh, jay.vosbu...@canonical.com
Re: [PATCH 00/13] [RFC] Rust support
[Copy LKMM people, Josh, Nick and Wedson] On Thu, Apr 15, 2021 at 08:58:16PM +0200, Peter Zijlstra wrote: > On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote: > > > Rust is a systems programming language that brings several key > > advantages over C in the context of the Linux kernel: > > > > - No undefined behavior in the safe subset (when unsafe code is > > sound), including memory safety and the absence of data races. > > And yet I see not a single mention of the Rust Memory Model and how it > aligns (or not) with the LKMM. The C11 memory model for example is a > really poor fit for LKMM. > I think Rust currently uses C11 memory model as per: https://doc.rust-lang.org/nomicon/atomics.html , also I guess another reason that they pick C11 memory model is because LLVM has the support by default. But I think the Rust Community still wants to have a good memory model, and they are open to any kind of suggestion and input. I think we (LKMM people) should really get involved, because the recent discussion on RISC-V's atomics shows that if we didn't people might get a "broken" design because they thought C11 memory model is good enough: https://lore.kernel.org/lkml/YGyZPCxJYGOvqYZQ@boqun-archlinux/ And the benefits are mutual: a) Linux Kernel Memory Model (LKMM) is defined by combining the requirements of developers and the behavior of hardwares, it's pratical and can be a very good input for memory model designing in Rust; b) Once Rust has a better memory model, the compiler technologies whatever Rust compilers use to suppor the memory model can be adopted to C compilers and we can get that part for free. At least I personally is very intereted to help Rust on a complete and pratical memory model ;-) Josh, I think it's good if we can connect to the people working on Rust memoryg model, I think the right person is Ralf Jung and the right place is https://github.com/rust-lang/unsafe-code-guidelines, but you cerntainly know better than me ;-) Or maybe we can use Rust-for-Linux or linux-toolchains list to discuss. [...] > > - Boqun Feng is working hard on the different options for > > threading abstractions and has reviewed most of the `sync` PRs. > > Boqun, I know you're familiar with LKMM, can you please talk about how > Rust does things and how it interacts? As Wedson said in the other email, currently there is no code requiring synchronization between C side and Rust side, so we are currently fine. But in the longer term, we need to teach Rust memory model about the "design patterns" used in Linux kernel for parallel programming. What I have been doing so far is reviewing patches which have memory orderings in Rust-for-Linux project, try to make sure we don't include memory ordering bugs for the beginning. Regards, Boqun
Re: [PATCH 00/13] [RFC] Rust support
On Fri, Apr 16, 2021 at 03:22:16AM +0100, Wedson Almeida Filho wrote: > > HTML is not a valid documentation format. Heck, markdown itself is > > barely readable. > > Are you stating [what you perceive as] a fact or just venting? If the former, > would you mind enlightening us with some evidence? How about "not everyone uses a browser as a part of their workflow"? I realize that it might sound ridiculous for folks who spent a while around Mozilla, but it's really true and kernel community actually has quite a few of such freaks. And as one of those freaks I can tell you where exactly I would like you to go and what I would like you to do with implicit suggestions to start a browser when I need to read some in-tree documentation. Linus might have different reasons, obviously.
Re: [PATCH v4] kernel/resource: Fix locking in request_free_mem_region
On Thu, Apr 15, 2021 at 7:58 PM Alistair Popple wrote:
>
> request_free_mem_region() is used to find an empty range of physical
> addresses for hotplugging ZONE_DEVICE memory. It does this by iterating
> over the range of possible addresses using region_intersects() to see if
> the range is free.
>
> region_intersects() obtains a read lock before walking the resource tree
> to protect against concurrent changes. However it drops the lock prior
> to returning. This means by the time request_mem_region() is called in
> request_free_mem_region() another thread may have already reserved the
> requested region resulting in unexpected failures and a message in the
> kernel log from hitting this condition:
>
> /*
> * mm/hmm.c reserves physical addresses which then
> * become unavailable to other users. Conflicts are
> * not expected. Warn to aid debugging if encountered.
> */
> if (conflict->desc == IORES_DESC_DEVICE_PRIVATE_MEMORY) {
> pr_warn("Unaddressable device %s %pR conflicts with %pR",
> conflict->name, conflict, res);
>
> To fix this create versions of region_intersects() and
> request_mem_region() that allow the caller to take the appropriate lock
> such that it may be held over the required calls.
>
> Instead of creating another version of devm_request_mem_region() that
> doesn't take the lock open-code it to allow the caller to pre-allocate
> the required memory prior to taking the lock.
>
> On some architectures and kernel configurations revoke_iomem() also
> calls resource code so cannot be called with the resource lock held.
> Therefore call it only after dropping the lock.
The patch is difficult to read because too many things are being
changed at once, and the changelog seems to confirm that. Can you try
breaking this down into a set of incremental changes? Not only will
this ease review it will distribute any regressions over multiple
bisection targets.
Something like:
* Refactor region_intersects() to allow external locking
* Refactor __request_region() to allow external locking
* Push revoke_iomem() down into...
* Fix resource_lock usage in [devm_]request_free_mem_region()
The revoke_iomem() change seems like something that should be moved
into a leaf helper and not called by __request_free_mem_region()
directly.
Re: [PATCH] fs: split receive_fd_replace from __receive_fd
On Fri, Apr 02, 2021 at 12:01:05PM -0700, Kees Cook wrote:
> On Thu, Mar 25, 2021 at 09:22:09AM +0100, Christoph Hellwig wrote:
> > receive_fd_replace shares almost no code with the general case, so split
> > it out. Also remove the "Bump the sock usage counts" comment from
> > both copies, as that is now what __receive_sock actually does.
> >
> > Signed-off-by: Christoph Hellwig
>
> I'm okay with repeating code in fs/file.c. What I wanted to avoid was
> open coded combinations in various callers.
... and that got you a lovely userland ABI, where you have
(1) newfd >= 0, SECCOMP_ADDFD_FLAG_SETFD is present => replace
(2) newfd < 0, SECCOMP_ADDFD_FLAG_SETFD is present => insert
(3) newfd == 0, SECCOMP_ADDFD_FLAG_SETFD not present => insert
(4) newfd != 0, SECCOMP_ADDFD_FLAG_SETFD not present => -EINVAL
IMO (2) is a bug. Whether we still can fix it or not... no idea, depends
on whether the actual userland has come to depend upon it.
I suggest turning (2) into an error (-EBADF is what you'd get from
attempt to set something at such descriptor) and seeing if anything
breaks. And having SECCOMP_ADDFD_FLAG_SETFD status passed into kaddfd
explicitly, with explicit check in seccomp_handle_addfd(). As in
commit 42eb0d54c08a0331d6d295420f602237968d792b
Author: Christoph Hellwig
Date: Thu Mar 25 09:22:09 2021 +0100
fs: split receive_fd_replace from __receive_fd
receive_fd_replace shares almost no code with the general case, so split
it out. Also remove the "Bump the sock usage counts" comment from
both copies, as that is now what __receive_sock actually does.
[AV: ... and make the only user of receive_fd_replace() choose between
it and receive_fd() according to what userland had passed to it in
flags]
Signed-off-by: Christoph Hellwig
Signed-off-by: Al Viro
diff --git a/fs/file.c b/fs/file.c
index f3a4bac2cbe9..d8ccb95a7f41 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -1068,8 +1068,6 @@ int replace_fd(unsigned fd, struct file *file, unsigned
flags)
/**
* __receive_fd() - Install received file into file descriptor table
- *
- * @fd: fd to install into (if negative, a new fd will be allocated)
* @file: struct file that was received from another process
* @ufd: __user pointer to write new fd number to
* @o_flags: the O_* flags to apply to the new fd entry
@@ -1083,7 +1081,7 @@ int replace_fd(unsigned fd, struct file *file, unsigned
flags)
*
* Returns newly install fd or -ve on error.
*/
-int __receive_fd(int fd, struct file *file, int __user *ufd, unsigned int
o_flags)
+int __receive_fd(struct file *file, int __user *ufd, unsigned int o_flags)
{
int new_fd;
int error;
@@ -1092,32 +1090,33 @@ int __receive_fd(int fd, struct file *file, int __user
*ufd, unsigned int o_flag
if (error)
return error;
- if (fd < 0) {
- new_fd = get_unused_fd_flags(o_flags);
- if (new_fd < 0)
- return new_fd;
- } else {
- new_fd = fd;
- }
+ new_fd = get_unused_fd_flags(o_flags);
+ if (new_fd < 0)
+ return new_fd;
if (ufd) {
error = put_user(new_fd, ufd);
if (error) {
- if (fd < 0)
- put_unused_fd(new_fd);
+ put_unused_fd(new_fd);
return error;
}
}
- if (fd < 0) {
- fd_install(new_fd, get_file(file));
- } else {
- error = replace_fd(new_fd, file, o_flags);
- if (error)
- return error;
- }
+ fd_install(new_fd, get_file(file));
+ __receive_sock(file);
+ return new_fd;
+}
- /* Bump the sock usage counts, if any. */
+int receive_fd_replace(int new_fd, struct file *file, unsigned int o_flags)
+{
+ int error;
+
+ error = security_file_receive(file);
+ if (error)
+ return error;
+ error = replace_fd(new_fd, file, o_flags);
+ if (error)
+ return error;
__receive_sock(file);
return new_fd;
}
diff --git a/include/linux/file.h b/include/linux/file.h
index 225982792fa2..2de2e4613d7b 100644
--- a/include/linux/file.h
+++ b/include/linux/file.h
@@ -92,23 +92,20 @@ extern void put_unused_fd(unsigned int fd);
extern void fd_install(unsigned int fd, struct file *file);
-extern int __receive_fd(int fd, struct file *file, int __user *ufd,
+extern int __receive_fd(struct file *file, int __user *ufd,
unsigned int o_flags);
static inline int receive_fd_user(struct file *file, int __user *ufd,
unsigned int o_flags)
{
if (ufd == NULL)
return -EFAULT;
- return __receive_fd(-1, file, ufd, o_flags);
+ return __receive_fd(file, ufd, o_flags);
}
static inline int
[PATCH 7/8] of: allow sending a NULL value to early_init_dt_scan_chosen
It's possible that an architecture may want to populate
boot_command_line before calling the device tree code.
Currently, early_init_dt_scan_chosen won't accept a NULL
in the data parameter and it returns immediately if you
send one.
I changed early_init_dt_scan_nodes() to send a NULL into
early_init_dt_scan_chosen() , then I made
early_init_dt_scan_chosen() to do the initrd checking, and
the rng-seed checking and skip all the command line related
code.
Given lots of changes to the command line, I think it makes sense
to allow the initrd code and rng-seed code to be run without
forcing the command line handling. I'm also submitting changes
to arm64 which populate boot_command_line much early and this
device tree code overwrites boot_command_line in that case.
This code depends on all architecture to have a NULL
boot_command_line at boot up when this function runs, unless
it's already populated.
This code was boot tested on powerpc 32bit, x86, and arm64.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Daniel Walker
---
drivers/of/fdt.c | 44 +---
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index adb26aff481d..a1fda952ce60 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1052,36 +1052,38 @@ int __init early_init_dt_scan_chosen(unsigned long
node, const char *uname,
pr_debug("search \"chosen\", depth: %d, uname: %s\n", depth, uname);
- if (depth != 1 || !data ||
- (strcmp(uname, "chosen") != 0 && strcmp(uname, "chosen@0") != 0))
+ if (depth != 1 || (strcmp(uname, "chosen") != 0
+ && strcmp(uname, "chosen@0") != 0))
return 0;
early_init_dt_check_for_initrd(node);
- /* Retrieve command line */
- p = of_get_flat_dt_prop(node, "bootargs", );
- if (p != NULL && l > 0)
- strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
+ if (data) {
+ /* Retrieve command line */
+ p = of_get_flat_dt_prop(node, "bootargs", );
+ if (p != NULL && l > 0)
+ strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
- /*
-* CONFIG_CMDLINE is meant to be a default in case nothing else
-* managed to set the command line, unless CONFIG_CMDLINE_FORCE
-* is set in which case we override whatever was found earlier.
-*/
+ /*
+* CONFIG_CMDLINE is meant to be a default in case nothing else
+* managed to set the command line, unless CONFIG_CMDLINE_FORCE
+* is set in which case we override whatever was found earlier.
+*/
#ifdef CONFIG_CMDLINE
#if defined(CONFIG_CMDLINE_EXTEND)
- strlcat(data, " ", COMMAND_LINE_SIZE);
- strlcat(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+ strlcat(data, " ", COMMAND_LINE_SIZE);
+ strlcat(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
#elif defined(CONFIG_CMDLINE_FORCE)
- strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#else
- /* No arguments from boot loader, use kernel's cmdl*/
- if (!((char *)data)[0])
strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+#else
+ /* No arguments from boot loader, use kernel's cmdl*/
+ if (!((char *)data)[0])
+ strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
#endif
#endif /* CONFIG_CMDLINE */
- pr_debug("Command line is: %s\n", (char *)data);
+ pr_debug("Command line is: %s\n", (char *)data);
+ }
rng_seed = of_get_flat_dt_prop(node, "rng-seed", );
if (rng_seed && l > 0) {
@@ -1202,7 +1204,11 @@ void __init early_init_dt_scan_nodes(void)
int rc = 0;
/* Retrieve various information from the /chosen node */
- rc = of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
+ if (boot_command_line[0])
+ rc = of_scan_flat_dt(early_init_dt_scan_chosen, NULL);
+ else
+ rc = of_scan_flat_dt(early_init_dt_scan_chosen,
+ boot_command_line);
if (!rc)
pr_warn("No chosen node found, continuing without\n");
--
2.25.1
[PATCH 5/8] drivers: firmware: efi: libstub: enable generic commandline
This adds code to handle the generic command line changes.
The efi code appears that it doesn't benefit as much from this design
as it could.
For example, if you had a prepend command line with "nokaslr" then
you might be helpful to re-enable it in the boot loader or dts,
but there appears to be no way to re-enable kaslr or some of the
other options.
The efi command line handling is incorrect. x86 and arm have an append
system however the efi code prepends the command line.
For example, you could have a non-upgradable bios which sends
efi=disable_early_pci_dma
This hypothetically could have been set because early pci dma caused
issues on early versions of the product.
Then later the early pci dma was made to work and the company desired
to start using it. To override the bios you could set the CONFIG_CMDLINE
to,
efi=no_disable_early_pci_dma
then parsing would normally start with the bios command line, then move
to the CONFIG_CMDLINE and you would end up with early pci dma turned on.
however, current efi code keeps early pci dma off because the bios
arguments always override the built in.
Per my reading this is different from the main body of x86, arm, and
arm64.
The generic command line provides both append and prepend, so it
alleviates this issue if it's used. However not all architectures use
it.
It would be desirable to allow the efi stub to have it's builtin command
line to be modified after compile, but I don't see a feasible way to do
that currently.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Daniel Walker
---
.../firmware/efi/libstub/efi-stub-helper.c| 29 +++
drivers/firmware/efi/libstub/efi-stub.c | 9 ++
drivers/firmware/efi/libstub/efistub.h| 1 +
drivers/firmware/efi/libstub/x86-stub.c | 13 +++--
4 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index aa8da0a49829..16318f55f187 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -13,6 +13,7 @@
#include
#include
#include /* For CONSOLE_LOGLEVEL_* */
+#include
#include
#include
@@ -172,6 +173,34 @@ int efi_printk(const char *fmt, ...)
return printed;
}
+/**
+ * efi_handle_cmdline() - handle adding in building parts of the command line
+ * @cmdline: kernel command line
+ *
+ * Add in the generic parts of the commandline and start the parsing of the
+ * command line.
+ *
+ * Return: status code
+ */
+efi_status_t efi_handle_cmdline(char const *cmdline)
+{
+ efi_status_t status = EFI_SUCCESS;
+
+ if (sizeof(CMDLINE_STATIC_PREPEND) > 1)
+ status |= efi_parse_options(CMDLINE_STATIC_PREPEND);
+
+ if (!IS_ENABLED(CONFIG_CMDLINE_OVERRIDE))
+ status |= efi_parse_options(cmdline);
+
+ if (sizeof(CMDLINE_STATIC_APPEND) > 1)
+ status |= efi_parse_options(CMDLINE_STATIC_APPEND);
+
+ if (status != EFI_SUCCESS)
+ efi_err("Failed to parse options\n");
+
+ return status;
+}
+
/**
* efi_parse_options() - Parse EFI command line options
* @cmdline: kernel command line
diff --git a/drivers/firmware/efi/libstub/efi-stub.c
b/drivers/firmware/efi/libstub/efi-stub.c
index 26e69788f27a..baa69b24cfdd 100644
--- a/drivers/firmware/efi/libstub/efi-stub.c
+++ b/drivers/firmware/efi/libstub/efi-stub.c
@@ -172,6 +172,14 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
goto fail;
}
+#ifdef CONFIG_GENERIC_CMDLINE
+ status = efi_handle_cmdline(cmdline_ptr);
+ if (status != EFI_SUCCESS) {
+ goto fail_free_cmdline;
+ }
+#endif
+
+#ifdef CONFIG_CMDLINE
if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
cmdline_size == 0) {
@@ -189,6 +197,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
goto fail_free_cmdline;
}
}
+#endif
efi_info("Booting Linux Kernel...\n");
diff --git a/drivers/firmware/efi/libstub/efistub.h
b/drivers/firmware/efi/libstub/efistub.h
index cde0a2ef507d..07c7f9fdfffc 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -800,6 +800,7 @@ efi_status_t efi_relocate_kernel(unsigned long *image_addr,
unsigned long alignment,
unsigned long min_addr);
+efi_status_t efi_handle_cmdline(char const *cmdline);
efi_status_t efi_parse_options(char const *cmdline);
void efi_parse_option_graphics(char *option);
diff --git a/drivers/firmware/efi/libstub/x86-stub.c
b/drivers/firmware/efi/libstub/x86-stub.c
index f14c4ff5839f..30ad8fb7122d 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -673,6 +673,8 @@ unsigned long efi_main(efi_handle_t handle,
[PATCH 8/8] CMDLINE: arm64: convert to generic builtin command line
This removes arm64 from the device tree handling of the
command line arguments.
The boot_command_line variable is populated inside the earliest
user of the command line, which is in idreg-override.c.
The device tree should not be needed to do any further handling
of the boot command line options.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Daniel Walker
---
arch/arm64/Kconfig | 33 +-
arch/arm64/include/asm/setup.h | 2 ++
arch/arm64/kernel/idreg-override.c | 9
3 files changed, 8 insertions(+), 36 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..9781ba3758b1 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -105,6 +105,7 @@ config ARM64
select GENERIC_ALLOCATOR
select GENERIC_ARCH_TOPOLOGY
select GENERIC_CLOCKEVENTS_BROADCAST
+ select GENERIC_CMDLINE
select GENERIC_CPU_AUTOPROBE
select GENERIC_CPU_VULNERABILITIES
select GENERIC_EARLY_IOREMAP
@@ -1841,38 +1842,6 @@ config ARM64_ACPI_PARKING_PROTOCOL
protocol even if the corresponding data is present in the ACPI
MADT table.
-config CMDLINE
- string "Default kernel command string"
- default ""
- help
- Provide a set of default command-line options at build time by
- entering them here. As a minimum, you should specify the the
- root device (e.g. root=/dev/nfs).
-
-choice
- prompt "Kernel command line type" if CMDLINE != ""
- default CMDLINE_FROM_BOOTLOADER
- help
- Choose how the kernel will handle the provided default kernel
- command line string.
-
-config CMDLINE_FROM_BOOTLOADER
- bool "Use bootloader kernel arguments if available"
- help
- Uses the command-line options passed by the boot loader. If
- the boot loader doesn't provide any, the default kernel command
- string provided in CMDLINE will be used.
-
-config CMDLINE_FORCE
- bool "Always use the default kernel command string"
- help
- Always use the default kernel command string, even if the boot
- loader passes other arguments to the kernel.
- This is useful if you cannot or don't want to change the
- command-line options your boot loader passes to the kernel.
-
-endchoice
-
config EFI_STUB
bool
diff --git a/arch/arm64/include/asm/setup.h b/arch/arm64/include/asm/setup.h
index d3320618ed14..1f5b6d8f2433 100644
--- a/arch/arm64/include/asm/setup.h
+++ b/arch/arm64/include/asm/setup.h
@@ -5,7 +5,9 @@
#include
+#ifndef __ASSEMBLY__
void *get_early_fdt_ptr(void);
void early_fdt_map(u64 dt_phys);
+#endif /* __ASSEMBLY__ */
#endif
diff --git a/arch/arm64/kernel/idreg-override.c
b/arch/arm64/kernel/idreg-override.c
index 83f1c4b92095..0a3fcae13043 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -188,11 +189,11 @@ static __init void parse_cmdline(void)
{
const u8 *prop = get_bootargs_cmdline();
- if (IS_ENABLED(CONFIG_CMDLINE_FORCE) || !prop)
- __parse_cmdline(CONFIG_CMDLINE, true);
+ strscpy(boot_command_line, prop, COMMAND_LINE_SIZE);
+ cmdline_add_builtin(boot_command_line);
+
+ __parse_cmdline(boot_command_line, true);
- if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && prop)
- __parse_cmdline(prop, true);
}
/* Keep checkers quiet */
--
2.25.1
[PATCH 6/8] CMDLINE: x86: convert to generic builtin command line
This updates the x86 code to use the CONFIG_GENERIC_CMDLINE
option.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko
Signed-off-by: Ruslan Bilovol
Signed-off-by: Daniel Walker
---
arch/x86/Kconfig| 44 +
arch/x86/kernel/setup.c | 18 ++---
2 files changed, 3 insertions(+), 59 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2792879d398e..73ea9589e50d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -118,6 +118,7 @@ config X86
select EDAC_SUPPORT
select GENERIC_CLOCKEVENTS_BROADCASTif X86_64 || (X86_32 &&
X86_LOCAL_APIC)
select GENERIC_CLOCKEVENTS_MIN_ADJUST
+ select GENERIC_CMDLINE
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
select GENERIC_CPU_VULNERABILITIES
@@ -2358,49 +2359,6 @@ choice
endchoice
-config CMDLINE_BOOL
- bool "Built-in kernel command line"
- help
- Allow for specifying boot arguments to the kernel at
- build time. On some systems (e.g. embedded ones), it is
- necessary or convenient to provide some or all of the
- kernel boot arguments with the kernel itself (that is,
- to not rely on the boot loader to provide them.)
-
- To compile command line arguments into the kernel,
- set this option to 'Y', then fill in the
- boot arguments in CONFIG_CMDLINE.
-
- Systems with fully functional boot loaders (i.e. non-embedded)
- should leave this option set to 'N'.
-
-config CMDLINE
- string "Built-in kernel command string"
- depends on CMDLINE_BOOL
- default ""
- help
- Enter arguments here that should be compiled into the kernel
- image and used at boot time. If the boot loader provides a
- command line at boot time, it is appended to this string to
- form the full kernel command line, when the system boots.
-
- However, you can use the CONFIG_CMDLINE_OVERRIDE option to
- change this behavior.
-
- In most cases, the command line (whether built-in or provided
- by the boot loader) should specify the device for the root
- file system.
-
-config CMDLINE_OVERRIDE
- bool "Built-in command line overrides boot loader arguments"
- depends on CMDLINE_BOOL && CMDLINE != ""
- help
- Set this option to 'Y' to have the kernel ignore the boot loader
- command line, and use ONLY the built-in command line.
-
- This is used to work around broken boot loaders. This should
- be set to 'N' under normal conditions.
-
config MODIFY_LDT_SYSCALL
bool "Enable the LDT (local descriptor table)" if EXPERT
default y
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 5ecd69a48393..cd2aa33c44d7 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
/*
* max_low_pfn_mapped: highest directly mapped pfn < 4 GB
@@ -161,9 +162,6 @@ unsigned long saved_video_mode;
#define RAMDISK_LOAD_FLAG 0x4000
static char __initdata command_line[COMMAND_LINE_SIZE];
-#ifdef CONFIG_CMDLINE_BOOL
-static char __initdata builtin_cmdline[COMMAND_LINE_SIZE] = CONFIG_CMDLINE;
-#endif
#if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
struct edd edd;
@@ -883,19 +881,7 @@ void __init setup_arch(char **cmdline_p)
bss_resource.start = __pa_symbol(__bss_start);
bss_resource.end = __pa_symbol(__bss_stop)-1;
-#ifdef CONFIG_CMDLINE_BOOL
-#ifdef CONFIG_CMDLINE_OVERRIDE
- strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-#else
- if (builtin_cmdline[0]) {
- /* append boot loader cmdline to builtin */
- strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
- strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
- strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
- }
-#endif
-#endif
-
+ cmdline_add_builtin(boot_command_line);
strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
--
2.25.1
[PATCH 4/8] CMDLINE: mips: convert to generic builtin command line
This updates the mips code to use the CONFIG_GENERIC_CMDLINE option. This deletes the option for MIPS_CMDLINE_BUILTIN_EXTEND and replaces the functionality with generic code. Of note, the pic32 has some strange handling of the current built in command line. It was converted to use the static variant which can't be updated after compilation. It should eventually be updated to use to append and prepend symbols. This includes a scripted mass convert of the config files to use the new generic cmdline. There is a bit of a trim effect here. It would seems that some of the config haven't been trimmed in a while. The script used is as follows, if [[ -z "$1" || -z "$2" ]]; then echo "Two arguments are needed." exit 1 fi mkdir $1 cp $2 $1/.config sed -i 's/CONFIG_CMDLINE=/CONFIG_CMDLINE_BOOL=y\nCONFIG_CMDLINE_PREPEND=/g' $1/.config make ARCH=$1 O=$1 olddefconfig make ARCH=$1 O=$1 savedefconfig cp $1/defconfig $2 rm -Rf $1 Cc: xe-linux-exter...@cisco.com Signed-off-by: Ruslan Ruslichenko Signed-off-by: Ruslan Bilovol Signed-off-by: Daniel Walker --- arch/mips/Kconfig | 4 +-- arch/mips/Kconfig.debug | 44 --- arch/mips/configs/ar7_defconfig | 9 ++--- arch/mips/configs/bcm47xx_defconfig | 8 ++--- arch/mips/configs/bcm63xx_defconfig | 15 +++- arch/mips/configs/bmips_be_defconfig | 11 +++--- arch/mips/configs/bmips_stb_defconfig | 11 +++--- arch/mips/configs/capcella_defconfig | 11 ++ arch/mips/configs/ci20_defconfig | 10 +++--- arch/mips/configs/cu1000-neo_defconfig| 10 +++--- arch/mips/configs/cu1830-neo_defconfig| 10 +++--- arch/mips/configs/e55_defconfig | 4 +-- arch/mips/configs/generic_defconfig | 6 ++-- arch/mips/configs/gpr_defconfig | 18 ++ arch/mips/configs/loongson3_defconfig | 13 ++- arch/mips/configs/mpc30x_defconfig| 7 ++-- arch/mips/configs/tb0219_defconfig| 7 ++-- arch/mips/configs/tb0226_defconfig| 7 ++-- arch/mips/configs/tb0287_defconfig| 7 ++-- arch/mips/configs/workpad_defconfig | 11 +++--- arch/mips/include/asm/setup.h | 2 ++ arch/mips/kernel/relocate.c | 17 +++-- arch/mips/kernel/setup.c | 36 +++ arch/mips/pic32/pic32mzda/early_console.c | 2 +- arch/mips/pic32/pic32mzda/init.c | 3 +- 25 files changed, 78 insertions(+), 205 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index d89efba3d8a4..0e753894d28d 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -24,6 +24,7 @@ config MIPS select CPU_NO_EFFICIENT_FFS if (TARGET_ISA_REV < 1) select CPU_PM if CPU_IDLE select GENERIC_ATOMIC64 if !64BIT + select GENERIC_CMDLINE select GENERIC_CMOS_UPDATE select GENERIC_CPU_AUTOPROBE select GENERIC_GETTIMEOFDAY @@ -3212,9 +3213,6 @@ choice config MIPS_CMDLINE_FROM_BOOTLOADER bool "Bootloader kernel arguments if available" - config MIPS_CMDLINE_BUILTIN_EXTEND - depends on CMDLINE_BOOL - bool "Extend builtin kernel arguments with bootloader arguments" endchoice endmenu diff --git a/arch/mips/Kconfig.debug b/arch/mips/Kconfig.debug index 7a8d94cdd493..b5a099c74eb6 100644 --- a/arch/mips/Kconfig.debug +++ b/arch/mips/Kconfig.debug @@ -30,50 +30,6 @@ config EARLY_PRINTK_8250 config USE_GENERIC_EARLY_PRINTK_8250 bool -config CMDLINE_BOOL - bool "Built-in kernel command line" - help - For most systems, it is firmware or second stage bootloader that - by default specifies the kernel command line options. However, - it might be necessary or advantageous to either override the - default kernel command line or add a few extra options to it. - For such cases, this option allows you to hardcode your own - command line options directly into the kernel. For that, you - should choose 'Y' here, and fill in the extra boot arguments - in CONFIG_CMDLINE. - - The built-in options will be concatenated to the default command - line if CMDLINE_OVERRIDE is set to 'N'. Otherwise, the default - command line will be ignored and replaced by the built-in string. - - Most MIPS systems will normally expect 'N' here and rely upon - the command line from the firmware or the second-stage bootloader. - -config CMDLINE - string "Default kernel command string" - depends on CMDLINE_BOOL - help - On some platforms, there is currently no way for the boot loader to - pass arguments to the kernel. For these platforms, and for the cases - when you want to add some extra options to the command line or ignore - the default command line, you can supply some command-line options at - build time by
[PATCH 1/8] CMDLINE: add generic builtin command line
This code allows architectures to use a generic builtin command line.
The state of the builtin command line options across architecture is
diverse. MIPS and X86 once has similar systems, then mips added some
options to allow extending the command line. Powerpc did something
simiar in adding the ability to extend. Even with mips and powerpc
enhancement the needs of Cisco are not met on these platforms.
The code in this commit unifies the code into a generic
header file under the CONFIG_GENERIC_CMDLINE option. When this
option is enabled the architecture can call the cmdline_add_builtin()
to add the builtin command line. The generic code provides both
append and/or prepend options and provides a way to redefine these
option after the kernel is compiled.
This code also includes test's which are meant to confirm
functionality.
This unified implementation offers the same functionality needed by
Cisco on all platform which we enable it on.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Bilovol
Signed-off-by: Daniel Walker
---
include/linux/cmdline.h | 103 +
init/Kconfig| 78 ++
lib/Kconfig | 4 ++
lib/Makefile| 3 +
lib/generic_cmdline.S | 53 +++
lib/test_cmdline1.c | 139
6 files changed, 380 insertions(+)
create mode 100644 include/linux/cmdline.h
create mode 100644 lib/generic_cmdline.S
create mode 100644 lib/test_cmdline1.c
diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
new file mode 100644
index ..34d9d8d14672
--- /dev/null
+++ b/include/linux/cmdline.h
@@ -0,0 +1,103 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_CMDLINE_H
+#define _LINUX_CMDLINE_H
+/*
+ *
+ * Copyright (C) 2006,2021. Cisco Systems, Inc.
+ *
+ * Generic Append/Prepend cmdline support.
+ */
+
+
+#include
+#include
+
+#ifdef CONFIG_CMDLINE_BOOL
+extern char cmdline_prepend[];
+extern char cmdline_append[];
+extern char cmdline_tmp[];
+#define CMDLINE_PREPEND cmdline_prepend
+#define CMDLINE_APPEND cmdline_append
+#define CMDLINE_TMP cmdline_tmp
+#define CMDLINE_STATIC_PREPEND CONFIG_CMDLINE_PREPEND
+#define CMDLINE_STATIC_APPEND CONFIG_CMDLINE_APPEND
+#else
+#define CMDLINE_PREPEND ""
+#define CMDLINE_APPEND ""
+#define CMDLINE_TMP ""
+#define CMDLINE_STATIC_PREPEND ""
+#define CMDLINE_STATIC_APPEND ""
+#endif
+
+#ifndef CMDLINE_STRLCAT
+#define CMDLINE_STRLCAT strlcat
+#endif
+
+#ifndef CMDLINE_STRLEN
+#define CMDLINE_STRLEN strlen
+#endif
+
+/*
+ * This function will append or prepend a builtin command line to the command
+ * line provided by the bootloader. Kconfig options can be used to alter
+ * the behavior of this builtin command line.
+ * @dest: The destination of the final appended/prepended string
+ * @tmp: temporary space used for prepending
+ * @prepend: string to prepend to @dest
+ * @append: string to append to @dest
+ * @length: the maximum length of the strings above.
+ * @cmdline_strlen: point to a compatible strlen
+ * @cmdline_strlcat: point to a compatible strlcat
+ * This function returns true when the builtin command line was copied
successfully
+ * and false when there was not enough room to copy all parts of the command
line.
+ */
+static inline bool
+__cmdline_add_builtin(
+ char *dest,
+ char *tmp,
+ char *prepend,
+ char *append,
+ unsigned long length,
+ size_t (*cmdline_strlen)(const char *s),
+ size_t (*cmdline_strlcat)(char *dest, const char *src, size_t
count))
+{
+ size_t total_length = 0, tmp_length;
+
+ if (!IS_ENABLED(CONFIG_GENERIC_CMDLINE))
+ return true;
+
+ if (!IS_ENABLED(CONFIG_CMDLINE_BOOL))
+ return true;
+
+ if (IS_ENABLED(CONFIG_CMDLINE_OVERRIDE))
+ dest[0] = '\0';
+ else
+ total_length += cmdline_strlen(dest);
+
+ tmp_length = cmdline_strlen(append);
+ if (tmp_length > 0) {
+ cmdline_strlcat(dest, append, length);
+ total_length += tmp_length;
+ }
+
+ tmp_length = cmdline_strlen(prepend);
+ if (tmp_length > 0) {
+ cmdline_strlcat(tmp, prepend, length);
+ cmdline_strlcat(tmp, dest, length);
+ dest[0] = '\0';
+ cmdline_strlcat(dest, tmp, length);
+ total_length += tmp_length;
+ }
+
+ tmp[0] = '\0';
+
+ if (total_length > length)
+ return false;
+
+ return true;
+}
+
+#define cmdline_add_builtin(dest) \
+ __cmdline_add_builtin(dest, CMDLINE_TMP, CMDLINE_PREPEND,
CMDLINE_APPEND, COMMAND_LINE_SIZE, CMDLINE_STRLEN, CMDLINE_STRLCAT)
+
+#endif
diff --git a/init/Kconfig b/init/Kconfig
index 5f5c776ef192..d72eb5a804c6 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2034,6 +2034,84 @@ config PROFILING
config TRACEPOINTS
bool
+config
[PATCH 3/8] scripts: insert-sys-cert: change name to insert-symbol
Since the tool is used to update the command line and/or
to update the certificates, I think it makes sense to
changes the name of this tool.
Update the name of the tool to better reflect it's new use.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Daniel Walker
---
scripts/Makefile | 2 +-
scripts/{insert-sys-cert.c => insert-symbol.c} | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
rename scripts/{insert-sys-cert.c => insert-symbol.c} (99%)
diff --git a/scripts/Makefile b/scripts/Makefile
index c36106bce80e..ed6b9f8f91fa 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -13,7 +13,7 @@ hostprogs-always-$(CONFIG_BUILDTIME_TABLE_SORT)
+= sorttable
hostprogs-always-$(CONFIG_ASN1)+= asn1_compiler
hostprogs-always-$(CONFIG_MODULE_SIG_FORMAT) += sign-file
hostprogs-always-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += extract-cert
-hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE)+= insert-sys-cert
+hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE)+= insert-symbol
HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include
HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
diff --git a/scripts/insert-sys-cert.c b/scripts/insert-symbol.c
similarity index 99%
rename from scripts/insert-sys-cert.c
rename to scripts/insert-symbol.c
index 77d3306cfbfb..6866e3a84974 100644
--- a/scripts/insert-sys-cert.c
+++ b/scripts/insert-symbol.c
@@ -7,7 +7,7 @@
* This software may be used and distributed according to the terms
* of the GNU General Public License, incorporated herein by reference.
*
- * Usage: insert-sys-cert [-s -b -c
+ * Usage: insert-symbol [-s -b -c
*/
#define _GNU_SOURCE
--
2.25.1
[PATCH 2/8] scripts: insert-sys-cert: add command line insert capability
This adds changes to the insert-sys-cert tool to allow updating
the cmdline_prepend and cmdline_append symbols in addition to
adding certificates.
Updating the cmdline symbols was tested on a PVH virtual machine
with a vmlinux, and with a bzImage which was repackaged on x86.
This commit intentionally keeps the tool filename the same to allow
the changes to be seen more easily. The next commit will change
the name of the tool.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Daniel Walker
---
scripts/insert-sys-cert.c | 241 +++---
1 file changed, 170 insertions(+), 71 deletions(-)
diff --git a/scripts/insert-sys-cert.c b/scripts/insert-sys-cert.c
index 8902836c2342..77d3306cfbfb 100644
--- a/scripts/insert-sys-cert.c
+++ b/scripts/insert-sys-cert.c
@@ -30,6 +30,9 @@
#define USED_SYM "system_extra_cert_used"
#define LSIZE_SYM "system_certificate_list_size"
+#define CMDLINE_APPEND "cmdline_append"
+#define CMDLINE_PREPEND "cmdline_prepend"
+
#define info(format, args...) fprintf(stderr, "INFO:" format, ## args)
#define warn(format, args...) fprintf(stdout, "WARNING: " format, ## args)
#define err(format, args...) fprintf(stderr, "ERROR: " format, ## args)
@@ -267,95 +270,46 @@ static void print_sym(Elf_Ehdr *hdr, struct sym *s)
static void print_usage(char *e)
{
- printf("Usage %s [-s ] -b -c \n", e);
+ printf("Usage %s [-s ] -b [ -c | -p
| -a ]-\n", e);
}
-int main(int argc, char **argv)
+static char *cmdline_prepend, *cmdline_append;
+static char *system_map_file;
+static char *cert_file;
+static char *cli_name;
+
+static int insert_certificate(Elf_Ehdr *hdr)
{
- char *system_map_file = NULL;
- char *vmlinux_file = NULL;
- char *cert_file = NULL;
- int vmlinux_size;
+ struct sym cert_sym, lsize_sym, used_sym;
+ Elf_Shdr *symtab = NULL;
+ unsigned long *lsize;
+ FILE *system_map;
int cert_size;
- Elf_Ehdr *hdr;
char *cert;
- FILE *system_map;
- unsigned long *lsize;
int *used;
- int opt;
- Elf_Shdr *symtab = NULL;
- struct sym cert_sym, lsize_sym, used_sym;
-
- while ((opt = getopt(argc, argv, "b:c:s:")) != -1) {
- switch (opt) {
- case 's':
- system_map_file = optarg;
- break;
- case 'b':
- vmlinux_file = optarg;
- break;
- case 'c':
- cert_file = optarg;
- break;
- default:
- break;
- }
- }
- if (!vmlinux_file || !cert_file) {
- print_usage(argv[0]);
- exit(EXIT_FAILURE);
+ if (!cert_file) {
+ print_usage(cli_name);
+ return EXIT_FAILURE;
}
cert = read_file(cert_file, _size);
if (!cert)
- exit(EXIT_FAILURE);
-
- hdr = map_file(vmlinux_file, _size);
- if (!hdr)
- exit(EXIT_FAILURE);
-
- if (vmlinux_size < sizeof(*hdr)) {
- err("Invalid ELF file.\n");
- exit(EXIT_FAILURE);
- }
-
- if ((hdr->e_ident[EI_MAG0] != ELFMAG0) ||
- (hdr->e_ident[EI_MAG1] != ELFMAG1) ||
- (hdr->e_ident[EI_MAG2] != ELFMAG2) ||
- (hdr->e_ident[EI_MAG3] != ELFMAG3)) {
- err("Invalid ELF magic.\n");
- exit(EXIT_FAILURE);
- }
-
- if (hdr->e_ident[EI_CLASS] != CURRENT_ELFCLASS) {
- err("ELF class mismatch.\n");
- exit(EXIT_FAILURE);
- }
-
- if (hdr->e_ident[EI_DATA] != endianness()) {
- err("ELF endian mismatch.\n");
- exit(EXIT_FAILURE);
- }
-
- if (hdr->e_shoff > vmlinux_size) {
- err("Could not find section header.\n");
- exit(EXIT_FAILURE);
- }
+ return EXIT_FAILURE;
symtab = get_symbol_table(hdr);
if (!symtab) {
warn("Could not find the symbol table.\n");
if (!system_map_file) {
err("Please provide a System.map file.\n");
- print_usage(argv[0]);
- exit(EXIT_FAILURE);
+ print_usage(cli_name);
+ return EXIT_FAILURE;
}
system_map = fopen(system_map_file, "r");
if (!system_map) {
perror(system_map_file);
- exit(EXIT_FAILURE);
+ return EXIT_FAILURE;
}
get_symbol_from_map(hdr, system_map, CERT_SYM, _sym);
get_symbol_from_map(hdr, system_map, USED_SYM, _sym);
@@ -371,7 +325,7 @@ int main(int argc, char **argv)
}
if (!cert_sym.offset || !lsize_sym.offset || !used_sym.offset)
-
[PATCH 0/8] generic command line v4
v4 release changes
* Updated insert-sys-cert tool to change command line symbols after
compilation.
This tool is used to release binary kernels internally to companies
and then later insert certificates for each product by consumers of
the binary kernel. Cisco uses this tool for this purpose.
Cisco has a similar need for the command line to be modified on a
binary released kernels similar to how certificates are setup.
* Added global symbols to hold append and prepend values.
These changes follow the system certificate code to allow the
insert-sys-cert tool to be used.
* Added a test case to confirm functionality.
Seemed sensible to add this to make sure everything is working.
* Dropped powerpc changes
Christophe Leroy has reservations about the features for powerpc. I
don't think his reservations are founded, and these changes should
fully work on powerpc. However, I dropped these changes so Christophe
can have more time to get comfortable with the changes.
Enjoy!
Daniel Walker (8):
CMDLINE: add generic builtin command line
scripts: insert-sys-cert: add command line insert capability
scripts: insert-sys-cert: change name to insert-symbol
CMDLINE: mips: convert to generic builtin command line
drivers: firmware: efi: libstub: enable generic commandline
CMDLINE: x86: convert to generic builtin command line
of: allow sending a NULL value to early_init_dt_scan_chosen
CMDLINE: arm64: convert to generic builtin command line
arch/arm64/Kconfig| 33 +--
arch/arm64/include/asm/setup.h| 2 +
arch/arm64/kernel/idreg-override.c| 9 +-
arch/mips/Kconfig | 4 +-
arch/mips/Kconfig.debug | 44
arch/mips/configs/ar7_defconfig | 9 +-
arch/mips/configs/bcm47xx_defconfig | 8 +-
arch/mips/configs/bcm63xx_defconfig | 15 +-
arch/mips/configs/bmips_be_defconfig | 11 +-
arch/mips/configs/bmips_stb_defconfig | 11 +-
arch/mips/configs/capcella_defconfig | 11 +-
arch/mips/configs/ci20_defconfig | 10 +-
arch/mips/configs/cu1000-neo_defconfig| 10 +-
arch/mips/configs/cu1830-neo_defconfig| 10 +-
arch/mips/configs/e55_defconfig | 4 +-
arch/mips/configs/generic_defconfig | 6 +-
arch/mips/configs/gpr_defconfig | 18 +-
arch/mips/configs/loongson3_defconfig | 13 +-
arch/mips/configs/mpc30x_defconfig| 7 +-
arch/mips/configs/tb0219_defconfig| 7 +-
arch/mips/configs/tb0226_defconfig| 7 +-
arch/mips/configs/tb0287_defconfig| 7 +-
arch/mips/configs/workpad_defconfig | 11 +-
arch/mips/include/asm/setup.h | 2 +
arch/mips/kernel/relocate.c | 17 +-
arch/mips/kernel/setup.c | 36 +--
arch/mips/pic32/pic32mzda/early_console.c | 2 +-
arch/mips/pic32/pic32mzda/init.c | 3 +-
arch/x86/Kconfig | 44 +---
arch/x86/kernel/setup.c | 18 +-
.../firmware/efi/libstub/efi-stub-helper.c| 29 +++
drivers/firmware/efi/libstub/efi-stub.c | 9 +
drivers/firmware/efi/libstub/efistub.h| 1 +
drivers/firmware/efi/libstub/x86-stub.c | 13 +-
drivers/of/fdt.c | 44 ++--
include/linux/cmdline.h | 103
init/Kconfig | 78 ++
lib/Kconfig | 4 +
lib/Makefile | 3 +
lib/generic_cmdline.S | 53
lib/test_cmdline1.c | 139 ++
scripts/Makefile | 2 +-
.../{insert-sys-cert.c => insert-symbol.c}| 243 --
43 files changed, 716 insertions(+), 394 deletions(-)
create mode 100644 include/linux/cmdline.h
create mode 100644 lib/generic_cmdline.S
create mode 100644 lib/test_cmdline1.c
rename scripts/{insert-sys-cert.c => insert-symbol.c} (72%)
--
2.25.1
Re: linux-next: build warning after merge of the amdgpu tree
Hi, On Fri, 16 Apr 2021 03:12:12 + "Liang, Prike" wrote: > > Hi, Rothwell (Stephen, actually :-)) > This fix solution hasn't locked down and still being discussed and > roll-updated in the NVMe mail group. > Will update the patch once it refined done. In which case, this patch should not be in linux-next (or any branch that is included by linux-next). -- Cheers, Stephen Rothwell pgpe8OeiFcmwZ.pgp Description: OpenPGP digital signature
[PATCH 2/2] scsi: arcmsr: update driver version to v1.50.00.04-20210414
From: ching Huang Update driver version to v1.50.00.04-20210414. Signed-off-by: ching Huang --- diff --git a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h index 0f6abd2..eb0ef73 100644 --- a/drivers/scsi/arcmsr/arcmsr.h +++ b/drivers/scsi/arcmsr/arcmsr.h @@ -49,7 +49,7 @@ struct device_attribute; #define ARCMSR_MAX_OUTSTANDING_CMD 1024 #define ARCMSR_DEFAULT_OUTSTANDING_CMD 128 #define ARCMSR_MIN_OUTSTANDING_CMD 32 -#define ARCMSR_DRIVER_VERSION "v1.50.00.02-20200819" +#define ARCMSR_DRIVER_VERSION "v1.50.00.04-20210414" #define ARCMSR_SCSI_INITIATOR_ID 255 #define ARCMSR_MAX_XFER_SECTORS512 #define ARCMSR_MAX_XFER_SECTORS_B 4096
Re: [PATCH v2 4/7] dt-bindings: soc: mediatek: apusys: Add new document for APU power domain
On Thu, 2021-04-15 at 10:25 -0500, Rob Herring wrote:
> On Thu, Apr 15, 2021 at 01:52:37PM +0800, Flora Fu wrote:
> > Document the bindings for APU power domain on MediaTek SoC.
> >
> > Signed-off-by: Flora Fu
> > ---
> > Note:
> > This patch depends on MT8192 clock[1] patches which haven't yet been
> > accepted.
> > [1]
> > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20210324104110.13383-7-chun-jie.c...@mediatek.com/__;!!CTRNKA9wMg0ARbw!zINTC3jweo4_C2yxqf9kHaxAXhO-k-I_JplIY4OQ390IeSfk5QCR4ojmFz2gPbBV$
> >
> > ---
> > .../soc/mediatek/mediatek,apu-pm.yaml | 145 ++
> > 1 file changed, 145 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
> > b/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
> > new file mode 100644
> > index ..6ff966920917
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
> > @@ -0,0 +1,145 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
> > https://urldefense.com/v3/__http://devicetree.org/schemas/soc/mediatek/mediatek,apu-pm.yaml*__;Iw!!CTRNKA9wMg0ARbw!zINTC3jweo4_C2yxqf9kHaxAXhO-k-I_JplIY4OQ390IeSfk5QCR4ojmF_yHpQUx$
> >
> > +$schema:
> > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!zINTC3jweo4_C2yxqf9kHaxAXhO-k-I_JplIY4OQ390IeSfk5QCR4ojmFy1L2FzU$
> >
> > +
> > +title: Mediatek APU Power Domains
> > +
> > +maintainers:
> > + - Flora Fu
> > +
> > +description: |
> > + Mediatek AI Process Unit (APU) include support for power domains which
> > can be
> > + powered up/down by software.
> > + APU subsys belonging to a power domain should contain a 'power-domains'
> > + property that is a phandle for apuspm node representing the domain.
> > +
> > +properties:
> > + compatible:
> > +items:
> > + - enum:
> > + - mediatek,mt8192-apu-pm
> > + - const: syscon
> > +
> > + reg:
> > +description: Address range of the APU power domain controller.
> > +maxItems: 1
> > +
> > + '#address-cells':
> > +const: 1
> > +
> > + '#size-cells':
> > +const: 0
> > +
> > + '#power-domain-cells':
> > +const: 1
> > +
> > + vsram-supply:
> > +description: apu sram regulator supply.
> > +
> > + mediatek,scpsys:
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +description: |
> > + phandle to the device containing the scpsys register range.
> > +
> > + mediatek,apu-conn:
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +description: |
> > + phandle to the device containing the scpsys apu conn register range.
> > +
> > + mediatek,apu-conn1:
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +description: |
> > + phandle to the device containing the scpsys apu conn1 register range.
> > +
> > + mediatek,apu-vcore:
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +description: |
> > + phandle to the device containing the scpsys apu vcore register range.
> > +
> > +patternProperties:
> > + "^power-domain@[0-9a-f]+$":
> > +type: object
> > +description: |
> > + Represents the power domains within the power controller node as
> > + documented in
> > Documentation/devicetree/bindings/power/power-domain.yaml.
> > +
> > +properties:
> > + reg:
> > +description: |
> > + Power domain index. Valid values are defined in:
> > + "include/dt-bindings/power/mt8182-apu-power.h"
> > +maxItems: 1
> > +
> > + '#power-domain-cells':
> > +description: |
> > + Must be 0 for nodes representing a single PM domain and 1 for
> > nodes
> > + providing multiple PM.
> > +
> > + clocks:
> > +description: |
> > + List of phandles of clocks list. Specify by order according to
> > + power-up sequence.
> > +
> > + clock-names:
> > +description: |
> > + List of names of clocks. Specify by order according to power-up
> > + sequence.
> > +
> > + assigned-clocks:
> > +maxItems: 2
> > +
> > + assigned-clock-parents:
> > +maxItems: 2
> > +
> > + domain-supply:
> > +description: domain regulator supply.
> > +
> > +required:
> > + - reg
> > + - '#power-domain-cells'
> > +
> > +additionalProperties: false
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - '#power-domain-cells'
> > + - vsram-supply
> > + - mediatek,scpsys
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +apuspm: power-domain@190f {
> > +compatible = "mediatek,mt8192-apu-pm", "syscon";
> > +reg = <0x190f 0x1000>;
> > +#address-cells = <1>;
> > +
[PATH 2/2] scsi: arcmsr: update driver version to v1.50.00.04-20210414
From: ching Huang Update driver version to v1.50.00.04-20210414. Signed-off-by: ching Huang --- diff --git a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h index 0f6abd2..eb0ef73 100644 --- a/drivers/scsi/arcmsr/arcmsr.h +++ b/drivers/scsi/arcmsr/arcmsr.h @@ -49,7 +49,7 @@ struct device_attribute; #define ARCMSR_MAX_OUTSTANDING_CMD 1024 #define ARCMSR_DEFAULT_OUTSTANDING_CMD 128 #define ARCMSR_MIN_OUTSTANDING_CMD 32 -#define ARCMSR_DRIVER_VERSION "v1.50.00.02-20200819" +#define ARCMSR_DRIVER_VERSION "v1.50.00.04-20210414" #define ARCMSR_SCSI_INITIATOR_ID 255 #define ARCMSR_MAX_XFER_SECTORS512 #define ARCMSR_MAX_XFER_SECTORS_B 4096
Re: linux-next: build failure after merge of the mmc tree
Hi all,
This is actually just a warning.
On Fri, 16 Apr 2021 13:48:27 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the mmc tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from drivers/memstick/host/r592.h:13,
> from drivers/memstick/host/r592.c:21:
> drivers/memstick/host/r592.c: In function 'r592_flush_fifo_write':
> include/linux/kfifo.h:588:1: warning: ignoring return value of
> '__kfifo_uint_must_check_helper' declared with attribute 'warn_unused_result'
> [-Wunused-result]
> 588 | __kfifo_uint_must_check_helper( \
> | ^
> 589 | ({ \
> |
> 590 | typeof((fifo) + 1) __tmp = (fifo); \
> |
> 591 | typeof(__tmp->ptr) __buf = (buf); \
> | ~~~
> 592 | unsigned long __n = (n); \
> | ~~
> 593 | const size_t __recsize = sizeof(*__tmp->rectype); \
> | ~~~
> 594 | struct __kfifo *__kfifo = &__tmp->kfifo; \
> | ~~
> 595 | (__recsize) ?\
> | ~~
> 596 | __kfifo_out_r(__kfifo, __buf, __n, __recsize) : \
> | ~
> 597 | __kfifo_out(__kfifo, __buf, __n); \
> | ~~~
> 598 | }) \
> |
> 599 | )
> | ~
> drivers/memstick/host/r592.c:367:2: note: in expansion of macro 'kfifo_out'
> 367 | kfifo_out(>pio_fifo, buffer, 4);
> | ^
>
> Caused by commit
>
> 4b00ed3c5072 ("memstick: r592: remove unused variable")
--
Cheers,
Stephen Rothwell
pgpuShvUS9tYz.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the mmc tree
Hi all,
After merging the mmc tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from drivers/memstick/host/r592.h:13,
from drivers/memstick/host/r592.c:21:
drivers/memstick/host/r592.c: In function 'r592_flush_fifo_write':
include/linux/kfifo.h:588:1: warning: ignoring return value of
'__kfifo_uint_must_check_helper' declared with attribute 'warn_unused_result'
[-Wunused-result]
588 | __kfifo_uint_must_check_helper( \
| ^
589 | ({ \
|
590 | typeof((fifo) + 1) __tmp = (fifo); \
|
591 | typeof(__tmp->ptr) __buf = (buf); \
| ~~~
592 | unsigned long __n = (n); \
| ~~
593 | const size_t __recsize = sizeof(*__tmp->rectype); \
| ~~~
594 | struct __kfifo *__kfifo = &__tmp->kfifo; \
| ~~
595 | (__recsize) ?\
| ~~
596 | __kfifo_out_r(__kfifo, __buf, __n, __recsize) : \
| ~
597 | __kfifo_out(__kfifo, __buf, __n); \
| ~~~
598 | }) \
|
599 | )
| ~
drivers/memstick/host/r592.c:367:2: note: in expansion of macro 'kfifo_out'
367 | kfifo_out(>pio_fifo, buffer, 4);
| ^
Caused by commit
4b00ed3c5072 ("memstick: r592: remove unused variable")
Please check the fixes for "simple, robot reported" warnings :-(
--
Cheers,
Stephen Rothwell
pgp9fZLWkh9zV.pgp
Description: OpenPGP digital signature
[PATCH] regulator: mt6360: Fix missing IRQF_ONESHOT as only threaded handler
From: Guangqing Zhu
Coccinelle noticed:
drivers/regulator/mt6360-regulator.c:386:8-33: ERROR: Threaded IRQ with no
primary handler requested without IRQF_ONESHOT
Signed-off-by: Guangqing Zhu
---
drivers/regulator/mt6360-regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/mt6360-regulator.c
b/drivers/regulator/mt6360-regulator.c
index 4d34be94d166..34c354721ef0 100644
--- a/drivers/regulator/mt6360-regulator.c
+++ b/drivers/regulator/mt6360-regulator.c
@@ -383,8 +383,8 @@ static int mt6360_regulator_irq_register(struct
platform_device *pdev,
if (irq < 0)
return irq;
- ret = devm_request_threaded_irq(>dev, irq, NULL,
irq_desc->handler, 0,
- irq_desc->name, rdev);
+ ret = devm_request_threaded_irq(>dev, irq, NULL,
irq_desc->handler,
+ IRQF_ONESHOT, irq_desc->name,
rdev);
if (ret) {
dev_err(>dev, "Fail to request %s irq\n",
irq_desc->name);
return ret;
--
2.17.1
Re: [PATCH net-next v4 2/2] of: net: fix of_get_mac_addr_nvmem() for non-platform devices
On Mon, 2021-04-12 at 19:47 +0200, Michael Walle wrote:
>
> /**
> * of_get_phy_mode - Get phy mode for given device_node
> @@ -59,15 +60,39 @@ static int of_get_mac_addr(struct device_node *np, const
> char *name, u8 *addr)
> static int of_get_mac_addr_nvmem(struct device_node *np, u8 *addr)
> {
> struct platform_device *pdev = of_find_device_by_node(np);
> + struct nvmem_cell *cell;
> + const void *mac;
> + size_t len;
> int ret;
>
> - if (!pdev)
> - return -ENODEV;
> + /* Try lookup by device first, there might be a nvmem_cell_lookup
> +* associated with a given device.
> +*/
> + if (pdev) {
> + ret = nvmem_get_mac_address(>dev, addr);
> + put_device(>dev);
> + return ret;
> + }
> +
This smells like the wrong band aid :)
Any struct device can contain an OF node pointer these days.
This seems all backwards. I think we are dealing with bad evolution.
We need to do a lookup for the device because we get passed an of_node.
We should just get passed a device here... or rather stop calling
of_get_mac_addr() from all those drivers and instead call
eth_platform_get_mac_address() which in turns calls of_get_mac_addr().
Then the nvmem stuff gets put in eth_platform_get_mac_address().
of_get_mac_addr() becomes a low-level thingy that most drivers don't
care about.
Cheers,
Ben.
[PATCH 1/2] scsi: arcmsr: fixed the wrong cdb payload report to IOP
From: ching Huang
This patch fixed the wrong cdb payload report to IOP.
Signed-off-by: ching Huang
---
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index 4b79661..930972c 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -1923,8 +1923,12 @@ static void arcmsr_post_ccb(struct AdapterControlBlock
*acb, struct CommandContr
if (ccb->arc_cdb_size <= 0x300)
arc_cdb_size = (ccb->arc_cdb_size - 1) >> 6 | 1;
- else
- arc_cdb_size = (((ccb->arc_cdb_size + 0xff) >> 8) + 2)
<< 1 | 1;
+ else {
+ arc_cdb_size = ((ccb->arc_cdb_size + 0xff) >> 8) + 2;
+ if (arc_cdb_size > 0xF)
+ arc_cdb_size = 0xF;
+ arc_cdb_size = (arc_cdb_size << 1) | 1;
+ }
ccb_post_stamp = (ccb->smid | arc_cdb_size);
writel(0, >inbound_queueport_high);
writel(ccb_post_stamp, >inbound_queueport_low);
[PATCH] Documentation: kunit: Update kunit_tool page
The kunit_tool documentation page was pretty minimal, and a bit outdated. Update it and flesh it out a bit. In particular, - Mention that .kunitconfig is now in the build directory - Describe the use of --kunitconfig to specify a different config framgent - Mention the split functionality (i.e., commands other than 'run') - Describe --raw_output and kunit.py parse - Mention the globbing support - Provide a quick overview of other options, including --build_dir and --alltests Note that this does overlap a little with the new running_tips page. I don't think it's a problem having both: this page is supposed to be a bit more of a reference, rather than a list of useful tips, so the fact that they both describe the same features isn't a problem. Signed-off-by: David Gow --- Documentation/dev-tools/kunit/kunit-tool.rst | 132 ++- 1 file changed, 128 insertions(+), 4 deletions(-) diff --git a/Documentation/dev-tools/kunit/kunit-tool.rst b/Documentation/dev-tools/kunit/kunit-tool.rst index 29ae2fee8123..0b45affcd65c 100644 --- a/Documentation/dev-tools/kunit/kunit-tool.rst +++ b/Documentation/dev-tools/kunit/kunit-tool.rst @@ -22,14 +22,19 @@ not require any virtualization support: it is just a regular program. What is a .kunitconfig? === -It's just a defconfig that kunit_tool looks for in the base directory. +It's just a defconfig that kunit_tool looks for in the build directory. kunit_tool uses it to generate a .config as you might expect. In addition, it verifies that the generated .config contains the CONFIG options in the .kunitconfig; the reason it does this is so that it is easy to be sure that a CONFIG that enables a test actually ends up in the .config. -How do I use kunit_tool? - +It's also possible to pass a separate .kunitconfig fragment to kunit_tool, +which is useful if you have several different groups of tests you wish +to run independently, or if you want to use pre-defined test configs for +certain subsystems. + +Getting Started with kunit_tool +=== If a kunitconfig is present at the root directory, all you have to do is: @@ -48,10 +53,129 @@ However, you most likely want to use it with the following options: .. note:: This command will work even without a .kunitconfig file: if no -.kunitconfig is present, a default one will be used instead. + .kunitconfig is present, a default one will be used instead. + +If you wish to use a different .kunitconfig file (such as one provided for +testing a particular subsystem), you can pass it as an option. + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run --kunitconfig=fs/ext4/.kunitconfig For a list of all the flags supported by kunit_tool, you can run: .. code-block:: bash ./tools/testing/kunit/kunit.py run --help + +Configuring, Building, and Running Tests + + +It's also possible to run just parts of the KUnit build process independently, +which is useful if you want to make manual changes to part of the process. + +A .config can be generated from a .kunitconfig by using the ``config`` argument +when running kunit_tool: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py config + +Similarly, if you just want to build a KUnit kernel from the current .config, +you can use the ``build`` argument: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py build + +And, if you already have a built UML kernel with built-in KUnit tests, you can +run the kernel and display the test results with the ``exec`` argument: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py exec + +The ``run`` command which is discussed above is equivalent to running all three +of these in sequence. + +All of these commands accept a number of optional command-line arguments. The +``--help`` flag will give a complete list of these, or keep reading this page +for a guide to some of the more useful ones. + +Parsing Test Results + + +KUnit tests output their results in TAP (Test Anything Protocol) format. +kunit_tool will, when running tests, parse this output and print a summary +which is much more pleasant to read. If you wish to look at the raw test +results in TAP format, you can pass the ``--raw_output`` argument. + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run --raw_output + +.. note:: + The raw output from test runs may contain other, non-KUnit kernel log + lines. + +If you have KUnit results in their raw TAP format, you can parse them and print +the human-readable summary with the ``parse`` command for kunit_tool. This +accepts a filename for an argument, or will read from standard input. + +.. code-block:: bash + + # Reading from a file + ./tools/testing/kunit/kunit.py parse /var/log/dmesg + # Reading from stdin + dmesg | ./tools/testing/kunit/kunit.py parse +
Re: [PATCH 5.4 00/18] 5.4.113-rc1 review
On 2021/4/15 22:47, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.4.113 release. There are 18 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat, 17 Apr 2021 14:44:01 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.113-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y and the diffstat can be found below. thanks, greg k-h Tested on arm64 and x86 for 5.4.113-rc1, Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Branch: linux-5.4.y Version: 5.4.113-rc1 Commit: 0d80f6c61d6ba21b3cb64eae72b8485dd96b5a94 Compiler: gcc version 7.3.0 (GCC) arm64: Testcase Result Summary: total: 5764 passed: 5764 failed: 0 timeout: 0 x86: Testcase Result Summary: total: 5764 passed: 5764 failed: 0 timeout: 0 Tested-by: Hulk Robot
[PATCH] drivers: ipa: Fix missing IRQF_ONESHOT as only threaded handler
From: Guangqing Zhu
Coccinelle noticed:
drivers/net/ipa/ipa_smp2p.c:186:7-27: ERROR: Threaded IRQ with no primary
handler requested without IRQF_ONESHOT
Signed-off-by: Guangqing Zhu
---
drivers/net/ipa/ipa_smp2p.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ipa/ipa_smp2p.c b/drivers/net/ipa/ipa_smp2p.c
index a5f7a79a1923..74e04427a711 100644
--- a/drivers/net/ipa/ipa_smp2p.c
+++ b/drivers/net/ipa/ipa_smp2p.c
@@ -183,7 +183,8 @@ static int ipa_smp2p_irq_init(struct ipa_smp2p *smp2p,
const char *name,
}
irq = ret;
- ret = request_threaded_irq(irq, NULL, handler, 0, name, smp2p);
+ ret = request_threaded_irq(irq, NULL, handler, IRQF_ONESHOT,
+ name, smp2p);
if (ret) {
dev_err(dev, "error %d requesting \"%s\" IRQ\n", ret, name);
return ret;
--
2.17.1
[PATCH 0/2] scsi: arcmsr: fix SCSI command timeout on ARC-1886
This patch is against to mkp's 5.13/scsi-staging. This patch fixed the wrong cdb payload report to IOP, that cause scsi command timeout when scatter-gather count is large than some number. ---
Re: [PATCH] fs: split receive_fd_replace from __receive_fd
On Thu, Mar 25, 2021 at 09:22:09AM +0100, Christoph Hellwig wrote:
> receive_fd_replace shares almost no code with the general case, so split
> it out. Also remove the "Bump the sock usage counts" comment from
> both copies, as that is now what __receive_sock actually does.
Nice, except that you've misread that, er, lovely API. This
> -static inline int receive_fd_replace(int fd, struct file *file, unsigned int
> o_flags)
> -{
> - return __receive_fd(fd, file, NULL, o_flags);
> + return __receive_fd(file, NULL, o_flags);
> }
can get called with negative fd (in which case it turns into an alias for
receive_fd(), of course). As the result, that ioctl got broken in case
when SECCOMP_ADDFD_FLAG_SETFD is not set. Trivially fixed by having the
only caller check the damn condition and call either receive_fd_replace()
or receive_fd().
[PATCH] Input: goodix - Fix missing IRQF_ONESHOT as only threaded handler
From: Guangqing Zhu
Coccinelle noticed:
drivers/input/touchscreen/goodix.c:497:8-33: ERROR: Threaded IRQ with no
primary handler requested without IRQF_ONESHOT
Signed-off-by: Guangqing Zhu
---
drivers/input/touchscreen/goodix.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index c682b028f0a2..725d01e01328 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -496,7 +496,8 @@ static int goodix_request_irq(struct goodix_ts_data *ts)
{
return devm_request_threaded_irq(>client->dev, ts->client->irq,
NULL, goodix_ts_irq_handler,
-ts->irq_flags, ts->client->name, ts);
+ts->irq_flags | IRQF_ONESHOT,
+ts->client->name, ts);
}
static int goodix_check_cfg_8(struct goodix_ts_data *ts, const u8 *cfg, int
len)
@@ -1158,7 +1159,7 @@ static int goodix_configure_dev(struct goodix_ts_data *ts)
return error;
}
- ts->irq_flags = goodix_irq_flags[ts->int_trigger_type] | IRQF_ONESHOT;
+ ts->irq_flags = goodix_irq_flags[ts->int_trigger_type];
error = goodix_request_irq(ts);
if (error) {
dev_err(>client->dev, "request IRQ failed: %d\n", error);
--
2.17.1
RE: linux-next: build warning after merge of the amdgpu tree
[AMD Public Use]
Hi, Rothwell
This fix solution hasn't locked down and still being discussed and roll-updated
in the NVMe mail group.
Will update the patch once it refined done.
Thanks,
Prike
> -Original Message-
> From: Stephen Rothwell
> Sent: Friday, April 16, 2021 10:41 AM
> To: Alex Deucher
> Cc: Liang, Prike ; S-k, Shyam-sundar sundar@amd.com>; Linux Kernel Mailing List ker...@vger.kernel.org>; Linux Next Mailing List
> Subject: linux-next: build warning after merge of the amdgpu tree
>
> Hi all,
>
> After merging the amdgpu tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> drivers/pci/quirks.c: In function 'quirk_amd_nvme_fixup':
> drivers/pci/quirks.c:312:18: warning: unused variable 'rdev' [-Wunused-
> variable]
> 312 | struct pci_dev *rdev;
> | ^~~~
>
> Introduced by commit
>
> 9597624ef606 ("nvme: put some AMD PCIE downstream NVME device to
> simple suspend/resume path")
>
> --
> Cheers,
> Stephen Rothwell
[PATCH] KVM: Boost vCPU candidiate in user mode which is delivering interrupt
From: Wanpeng Li
Both lock holder vCPU and IPI receiver that has halted are condidate for
boost. However, the PLE handler was originally designed to deal with the
lock holder preemption problem. The Intel PLE occurs when the spinlock
waiter is in kernel mode. This assumption doesn't hold for IPI receiver,
they can be in either kernel or user mode. the vCPU candidate in user mode
will not be boosted even if they should respond to IPIs. Some benchmarks
like pbzip2, swaptions etc do the TLB shootdown in kernel mode and most
of the time they are running in user mode. It can lead to a large number
of continuous PLE events because the IPI sender causes PLE events
repeatedly until the receiver is scheduled while the receiver is not
candidate for a boost.
This patch boosts the vCPU candidiate in user mode which is delivery
interrupt. We can observe the speed of pbzip2 improves 10% in 96 vCPUs
VM in over-subscribe scenario (The host machine is 2 socket, 48 cores,
96 HTs Intel CLX box). There is no performance regression for other
benchmarks like Unixbench spawn (most of the time contend read/write
lock in kernel mode), ebizzy (most of the time contend read/write sem
and TLB shoodtdown in kernel mode).
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/x86.c | 8
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c | 6 ++
3 files changed, 15 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0d2dd3f..0f16fa5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -11069,6 +11069,14 @@ bool kvm_arch_dy_runnable(struct kvm_vcpu *vcpu)
return false;
}
+bool kvm_arch_interrupt_delivery(struct kvm_vcpu *vcpu)
+{
+ if (vcpu->arch.apicv_active &&
static_call(kvm_x86_dy_apicv_has_pending_interrupt)(vcpu))
+ return true;
+
+ return false;
+}
+
bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
{
return vcpu->arch.preempted_in_kernel;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 3b06d12..5012fc4 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -954,6 +954,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu);
bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu);
int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu);
bool kvm_arch_dy_runnable(struct kvm_vcpu *vcpu);
+bool kvm_arch_interrupt_delivery(struct kvm_vcpu *vcpu);
int kvm_arch_post_init_vm(struct kvm *kvm);
void kvm_arch_pre_destroy_vm(struct kvm *kvm);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 0a481e7..781d2db 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3012,6 +3012,11 @@ static bool vcpu_dy_runnable(struct kvm_vcpu *vcpu)
return false;
}
+bool __weak kvm_arch_interrupt_delivery(struct kvm_vcpu *vcpu)
+{
+ return false;
+}
+
void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool yield_to_kernel_mode)
{
struct kvm *kvm = me->kvm;
@@ -3045,6 +3050,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool
yield_to_kernel_mode)
!vcpu_dy_runnable(vcpu))
continue;
if (READ_ONCE(vcpu->preempted) && yield_to_kernel_mode
&&
+ !kvm_arch_interrupt_delivery(vcpu) &&
!kvm_arch_vcpu_in_kernel(vcpu))
continue;
if (!kvm_vcpu_eligible_for_directed_yield(vcpu))
--
2.7.4
Re: [PATCH v1] ARM: dts: Fix 64MiB OpenBMC flash layout and aspeed-ast2600-evb.dts
On Tue, 16 Mar 2021 at 08:59, Troy Lee wrote:
>
> Aspeed AST2600 u-boot requires 600KiB+ flash space. Sharing the same
> openbmc-flash-layout-64.dtsi requires to resize the flash partition.
>
> The updated flash layout as follows:
> - u-boot: 896 KiB
> - u-boot-env: 128 KiB
> - kernel: 9MiB
> - rofs: 32 MiB
> - rwfs: 22 MiB
Changing the 64MB layout will break the systems that are already using
this layout. I'll get the Bytedance people to chime in, as theirs is
the only system using this layout so far.
John, Lei?
>
> Signed-off-by: Troy Lee
> ---
> arch/arm/boot/dts/aspeed-ast2600-evb.dts | 32 +--
> .../arm/boot/dts/openbmc-flash-layout-64.dtsi | 18 +--
> 2 files changed, 10 insertions(+), 40 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
> b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
> index 89be13197780..2cfae9cfed3a 100644
> --- a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
> +++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
> @@ -121,37 +121,7 @@ flash@0 {
> m25p,fast-read;
> label = "bmc";
> spi-max-frequency = <5000>;
> -
> - partitions {
> - compatible = "fixed-partitions";
> - #address-cells = <1>;
> - #size-cells = <1>;
> -
> - u-boot@0 {
> - reg = <0x0 0xe>; // 896KB
> - label = "u-boot";
> - };
> -
> - u-boot-env@e {
> - reg = <0xe 0x2>; // 128KB
> - label = "u-boot-env";
> - };
> -
> - kernel@10 {
> - reg = <0x10 0x90>; // 9MB
> - label = "kernel";
> - };
> -
> - rofs@a0 {
> - reg = <0xa0 0x200>; // 32MB
> - label = "rofs";
> - };
> -
> - rwfs@600 {
> - reg = <0x2a0 0x160>; // 22MB
> - label = "rwfs";
> - };
> - };
> +#include "openbmc-flash-layout-64.dtsi"
> };
> };
>
> diff --git a/arch/arm/boot/dts/openbmc-flash-layout-64.dtsi
> b/arch/arm/boot/dts/openbmc-flash-layout-64.dtsi
> index 91163867be34..31f59de5190b 100644
> --- a/arch/arm/boot/dts/openbmc-flash-layout-64.dtsi
> +++ b/arch/arm/boot/dts/openbmc-flash-layout-64.dtsi
> @@ -9,27 +9,27 @@ partitions {
> #size-cells = <1>;
>
> u-boot@0 {
> - reg = <0x0 0x6>; // 384KB
> + reg = <0x0 0xe>; // 896KB
> label = "u-boot";
> };
>
> - u-boot-env@6 {
> - reg = <0x6 0x2>; // 128KB
> + u-boot-env@e {
> + reg = <0xe 0x2>; // 128KB
> label = "u-boot-env";
> };
>
> - kernel@8 {
> - reg = <0x8 0x50>; // 5MB
> + kernel@10 {
> + reg = <0x10 0x90>; // 9MB
> label = "kernel";
> };
>
> - rofs@58 {
> - reg = <0x58 0x2a8>; // 42.5MB
> + rofs@a0 {
> + reg = <0xa0 0x200>; // 32MB
> label = "rofs";
> };
>
> - rwfs@300 {
> - reg = <0x300 0x100>; // 16MB
> + rwfs@600 {
> + reg = <0x2a0 0x160>; // 22MB
> label = "rwfs";
> };
> };
> --
> 2.25.1
>
Re: [PATCH 4/8] dt-bindings: arm: mediatek: Add new document bindings for APU
On Thu, 2021-04-15 at 16:24 -0500, Rob Herring wrote:
> On Mon, Apr 12, 2021 at 1:45 AM Flora Fu wrote:
> >
> > On Fri, 2021-04-09 at 13:25 -0500, Rob Herring wrote:
> > > On Wed, Apr 07, 2021 at 11:28:02AM +0800, Flora Fu wrote:
> > > > Document the apusys bindings.
> > > >
> > > > Signed-off-by: Flora Fu
> > > > ---
> > > > .../arm/mediatek/mediatek,apusys.yaml | 56 +++
> > > > 1 file changed, 56 insertions(+)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> > > > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> > > > new file mode 100644
> > > > index ..dc04a46f1bad
> > > > --- /dev/null
> > > > +++
> > > > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> > > > @@ -0,0 +1,56 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id:
> > > > https://urldefense.com/v3/__http://devicetree.org/schemas/arm/mediatek/mediatek,apusys.yaml*__;Iw!!CTRNKA9wMg0ARbw!3ryKFTA2CvsVss4Pt2ZOG7wv4jgR-2LPxuGn30IxFmpxoxSRdzNdf8FrAYYvZWcw$
> > > > +$schema:
> > > > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!3ryKFTA2CvsVss4Pt2ZOG7wv4jgR-2LPxuGn30IxFmpxoxSRdzNdf8FrARlhCQ0w$
> > > > +
> > > > +title: MediaTek APUSYS Controller
> > > > +
> > > > +maintainers:
> > > > + - Flora Fu
> > > > +
> > > > +description:
> > > > + The Mediatek apusys controller provides functional configurations
> > > > and clocks
> > > > + to the system.
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > +items:
> > > > + - enum:
> > > > + - mediatek,mt8192-apu_mbox
> > > > + - mediatek,mt8192-apu_conn
> > > > + - mediatek,mt8192-apu_vcore
> > >
> > > s/_/-/
> > >
> >
> > OK. I will update expression strings in the next version.
> >
> > > > + - const: syscon
> > > > +
> > > > + reg:
> > > > +maxItems: 1
> > > > +
> > > > + '#clock-cells':
> > > > +const: 1
> > > > +
> > > > +required:
> > > > + - compatible
> > > > + - reg
> > > > +
> > > > +additionalProperties: false
> > > > +
> > > > +examples:
> > > > + - |
> > > > +apu_mbox: apu_mbox@1900 {
> > >
> > > mailbox@...? Is this a mailbox provider?
> > >
> >
> > Yes, the apu_mbox is the for setup mailbox in the APU hardware.
>
> Then you need #mbox-cells here.
>
> And in that case, what makes it a syscon?
>
The apu_mbox are registers for setup mail box communications between apu
processor and the AP side kernel drivers. It also has spare registers
that reserved for keep specific information between apu and AP side.
That's why I set it as syscon to avoid ioremap from users. Do you think
it is reasonable or it is better to be kept inside the user nodes when
using it?
> >
> > > > +compatible = "mediatek,mt8192-apu_mbox", "syscon";
> > > > +reg = <0x1900 0x1000>;
> > > > +};
[PATCH v4] kernel/resource: Fix locking in request_free_mem_region
request_free_mem_region() is used to find an empty range of physical
addresses for hotplugging ZONE_DEVICE memory. It does this by iterating
over the range of possible addresses using region_intersects() to see if
the range is free.
region_intersects() obtains a read lock before walking the resource tree
to protect against concurrent changes. However it drops the lock prior
to returning. This means by the time request_mem_region() is called in
request_free_mem_region() another thread may have already reserved the
requested region resulting in unexpected failures and a message in the
kernel log from hitting this condition:
/*
* mm/hmm.c reserves physical addresses which then
* become unavailable to other users. Conflicts are
* not expected. Warn to aid debugging if encountered.
*/
if (conflict->desc == IORES_DESC_DEVICE_PRIVATE_MEMORY) {
pr_warn("Unaddressable device %s %pR conflicts with %pR",
conflict->name, conflict, res);
To fix this create versions of region_intersects() and
request_mem_region() that allow the caller to take the appropriate lock
such that it may be held over the required calls.
Instead of creating another version of devm_request_mem_region() that
doesn't take the lock open-code it to allow the caller to pre-allocate
the required memory prior to taking the lock.
On some architectures and kernel configurations revoke_iomem() also
calls resource code so cannot be called with the resource lock held.
Therefore call it only after dropping the lock.
Fixes: 4ef589dc9b10c ("mm/hmm/devmem: device memory hotplug using ZONE_DEVICE")
Signed-off-by: Alistair Popple
Acked-by: Balbir Singh
Reported-by: kernel test robot
---
Changes for v4:
- Update commit log
- Moved calling revoke_iomem() to before devres_add(). This shouldn't
change anything but it maintains the original ordering.
- Fixed freeing of devres in case of failure.
- Rebased onto linux-next
---
kernel/resource.c | 144 ++
1 file changed, 94 insertions(+), 50 deletions(-)
diff --git a/kernel/resource.c b/kernel/resource.c
index 7e00239a023a..f1f7fe089fc8 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -502,6 +502,34 @@ int __weak page_is_ram(unsigned long pfn)
}
EXPORT_SYMBOL_GPL(page_is_ram);
+static int __region_intersects(resource_size_t start, size_t size,
+ unsigned long flags, unsigned long desc)
+{
+ struct resource res;
+ int type = 0; int other = 0;
+ struct resource *p;
+
+ res.start = start;
+ res.end = start + size - 1;
+
+ for (p = iomem_resource.child; p ; p = p->sibling) {
+ bool is_type = (((p->flags & flags) == flags) &&
+ ((desc == IORES_DESC_NONE) ||
+(desc == p->desc)));
+
+ if (resource_overlaps(p, ))
+ is_type ? type++ : other++;
+ }
+
+ if (type == 0)
+ return REGION_DISJOINT;
+
+ if (other == 0)
+ return REGION_INTERSECTS;
+
+ return REGION_MIXED;
+}
+
/**
* region_intersects() - determine intersection of region with known resources
* @start: region start address
@@ -525,31 +553,12 @@ EXPORT_SYMBOL_GPL(page_is_ram);
int region_intersects(resource_size_t start, size_t size, unsigned long flags,
unsigned long desc)
{
- struct resource res;
- int type = 0; int other = 0;
- struct resource *p;
-
- res.start = start;
- res.end = start + size - 1;
+ int rc;
read_lock(_lock);
- for (p = iomem_resource.child; p ; p = p->sibling) {
- bool is_type = (((p->flags & flags) == flags) &&
- ((desc == IORES_DESC_NONE) ||
-(desc == p->desc)));
-
- if (resource_overlaps(p, ))
- is_type ? type++ : other++;
- }
+ rc = __region_intersects(start, size, flags, desc);
read_unlock(_lock);
-
- if (type == 0)
- return REGION_DISJOINT;
-
- if (other == 0)
- return REGION_INTERSECTS;
-
- return REGION_MIXED;
+ return rc;
}
EXPORT_SYMBOL_GPL(region_intersects);
@@ -1150,31 +1159,16 @@ struct address_space *iomem_get_mapping(void)
return smp_load_acquire(_inode)->i_mapping;
}
-/**
- * __request_region - create a new busy resource region
- * @parent: parent resource descriptor
- * @start: resource start address
- * @n: resource region size
- * @name: reserving caller's ID string
- * @flags: IO resource flags
- */
-struct resource * __request_region(struct resource *parent,
- resource_size_t start, resource_size_t n,
- const char *name, int flags)
+static bool request_region_locked(struct resource *parent,
+
[PATCH] Input: twl4030_keypad - Fix missing IRQF_ONESHOT as only threaded handler
From: Guangqing Zhu
Coccinelle noticed:
drivers/input/keyboard/twl4030_keypad.c:413:9-34: ERROR: Threaded IRQ with
no primary handler requested without IRQF_ONESHOT
Signed-off-by: Guangqing Zhu
---
drivers/input/keyboard/twl4030_keypad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/twl4030_keypad.c
b/drivers/input/keyboard/twl4030_keypad.c
index 77e0743a3cf8..05057ebb1ab2 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -411,7 +411,7 @@ static int twl4030_kp_probe(struct platform_device *pdev)
* NOTE: we assume this host is wired to TWL4040 INT1, not INT2 ...
*/
error = devm_request_threaded_irq(>dev, kp->irq, NULL, do_kp_irq,
- 0, pdev->name, kp);
+ IRQF_ONESHOT, pdev->name, kp);
if (error) {
dev_info(kp->dbg_dev, "request_irq failed for irq no=%d: %d\n",
kp->irq, error);
--
2.17.1
Re: [PATCH] arm: dts: aspeed: tiogapass: add hotplug controller
On Thu, 15 Apr 2021 at 14:05, Paul Fertser wrote:
>
> The ADM1278 IC is accessible on I2C bus and on both Wiwynn and Quanta
> Tioga Pass implementations a pair of parallel 0.5 mOhm resistors is used
> for current measurement.
>
> Signed-off-by: Paul Fertser
Thanks, applied.
> ---
> arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> index 3cc2004fa2f2..500661956dea 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> @@ -591,6 +591,11 @@
> {
> status = "okay";
> //HSC, AirMax Conn A
> + adm1278@0x45 {
> + compatible = "adm1275";
> + reg = <0x45>;
> + shunt-resistor-micro-ohms = <250>;
> + };
> };
>
> {
> --
> 2.17.1
>
Re: [PATCH] ARM: dts: aspeed: amd-ethanolx: Enable all used I2C busses
On Thu, 15 Apr 2021 at 15:53, Konstantin Aladyshev
wrote:
>
> Enable all I2C busses that are used in AMD EthanolX CRB:
> i2c0 - APML P0
> i2c1 - APML P1
> i2c2 - FPGA
> i2c3 - 24LC128 EEPROM
> i2c4 - P0 Power regulators
> i2c5 - P1 Power regulators
> i2c6 - P0/P1 Thermal diode
> i2c7 - Thermal Sensors
> i2c8 - BMC I2C
>
> Signed-off-by: Konstantin Aladyshev
Thanks, applied.
> ---
> arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts | 30 +++
> 1 file changed, 30 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts
> b/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts
> index ac2d04cfaf2f..6aeb47c44eba 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts
> @@ -151,6 +151,31 @@ {
> status = "okay";
> };
>
> +//FPGA
> + {
> + status = "okay";
> +};
> +
> +//24LC128 EEPROM
> + {
> + status = "okay";
> +};
> +
> +//P0 Power regulators
> + {
> + status = "okay";
> +};
> +
> +//P1 Power regulators
> + {
> + status = "okay";
> +};
> +
> +//P0/P1 Thermal diode
> + {
> + status = "okay";
> +};
> +
> // Thermal Sensors
> {
> status = "okay";
> @@ -196,6 +221,11 @@ lm75a@4f {
> };
> };
>
> +//BMC I2C
> + {
> + status = "okay";
> +};
> +
> {
> status = "okay";
> aspeed,lpc-io-reg = <0x60>;
> --
> 2.25.1
>
Re: [PATCH] clk: uniphier: Fix potential infinite loop
On Fri, Apr 16, 2021 at 3:19 AM Dan Carpenter wrote:
>
> On Fri, Apr 09, 2021 at 03:46:47PM +0900, Masahiro Yamada wrote:
> > On Thu, Apr 8, 2021 at 12:25 AM Colin King wrote:
> > >
> > > From: Colin Ian King
> > >
> > > The for-loop iterates with a u8 loop counter i and compares this
> > > with the loop upper limit of num_parents that is an int type.
> > > There is a potential infinite loop if num_parents is larger than
> > > the u8 loop counter. Fix this by making the loop counter the same
> > > type as num_parents.
> > >
> > > Addresses-Coverity: ("Infinite loop")
> > > Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier
> > > clock driver")
> > > Signed-off-by: Colin Ian King
> > > ---
> > > drivers/clk/uniphier/clk-uniphier-mux.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/clk/uniphier/clk-uniphier-mux.c
> > > b/drivers/clk/uniphier/clk-uniphier-mux.c
> > > index 462c84321b2d..ce219e0d2a85 100644
> > > --- a/drivers/clk/uniphier/clk-uniphier-mux.c
> > > +++ b/drivers/clk/uniphier/clk-uniphier-mux.c
> > > @@ -34,7 +34,7 @@ static u8 uniphier_clk_mux_get_parent(struct clk_hw *hw)
> > > int num_parents = clk_hw_get_num_parents(hw);
> > > int ret;
> > > unsigned int val;
> > > - u8 i;
> > > + int i;
> > >
> > > ret = regmap_read(mux->regmap, mux->reg, );
> > > if (ret)
> > > --
> > > 2.30.2
> > >
> >
> > clk_hw_get_num_parents() returns 'unsigned int', so
> > I think 'num_parents' should also have been 'unsigned int'.
> >
> > Maybe, the loop counter 'i' also should be 'unsigned int' then?
>
> The clk_hw_get_num_parents() function returns 0-255 so the original code
> works fine.
True. clk->core->num_parents is u8,
but it is not clear just by looking at the
prototype of clk_hw_get_num_parents().
At least, it is not clear enough for tools,
and actually Coverity raised a flag.
Personally, I prefer 'unsigned int' (or 'int')
when I count the number of something.
Historically, the clk subsystem uses u8,
(maybe to save memory??), and there exists
distortion.
For example, the return type of
uniphier_clk_mux_get_parent() is u8,
but it actually returns -EINVAL for error cases.
So, u8 is not wide enough, in my opinion.
>
> It should basically always be "int i;" That's the safest assumption.
> There are other case where it has to be size_t but in those cases I
> think people should call the list iterator something else instead of "i"
> like "size_t pg_idx;".
>
> Making everthing u32 causes more bugs than it prevents. Signedness bugs
> with comparing to zero, type promotion bugs, or subtraction bugs where
> subtracting wraps to a high value. It's rare to loop more than INT_MAX
> times in the kernel. When we do need to count about 2 million then
> we're probably not going to stop counting at 4 million, we're going to
> go to 10 million or higher so size_t is more appropriate than u32.
>
> Btw, if you have a loop that does:
>
> for (i = 0; i < UINT_MAX; i++) {
>
> that loop works exactly the same if "i" is an int or if it's a u32
> because of type promotion.
You are right.
Perhaps, in hindsight, the following were natural:
unsigned int num_parents = clk_hw_get_num_parents(hw);
...
int i;
I am fine with this if it is not too late.
But, Stephen has already picked up this patch.
> So you have to look really hard to find a
> place where changing a loop iterator from int to u32 fixes bug in real
> life.
>
> regards,
> dan carpenter
--
Best Regards
Masahiro Yamada
Re: [External] : Re: [PATCH v14 4/6] locking/qspinlock: Introduce starvation avoidance into CNA
> On Apr 13, 2021, at 8:03 AM, Peter Zijlstra wrote:
>
> On Thu, Apr 01, 2021 at 11:31:54AM -0400, Alex Kogan wrote:
>
>> @@ -49,13 +55,33 @@ struct cna_node {
>> u16 real_numa_node;
>> u32 encoded_tail; /* self */
>> u32 partial_order; /* enum val */
>> +s32 start_time;
>> };
>
>> +/*
>> + * Controls the threshold time in ms (default = 10) for intra-node lock
>> + * hand-offs before the NUMA-aware variant of spinlock is forced to be
>> + * passed to a thread on another NUMA node. The default setting can be
>> + * changed with the "numa_spinlock_threshold" boot option.
>> + */
>> +#define MSECS_TO_JIFFIES(m) \
>> +(((m) + (MSEC_PER_SEC / HZ) - 1) / (MSEC_PER_SEC / HZ))
>> +static int intra_node_handoff_threshold __ro_after_init =
>> MSECS_TO_JIFFIES(10);
>> +
>> +static inline bool intra_node_threshold_reached(struct cna_node *cn)
>> +{
>> +s32 current_time = (s32)jiffies;
>> +s32 threshold = cn->start_time + intra_node_handoff_threshold;
>> +
>> +return current_time - threshold > 0;
>> +}
>
> None of this makes any sense:
>
> - why do you track time elapsed as a signed entity?
> - why are you using jiffies; that's terrible granularity.
Good points. I will address that (see below). I will just mention that
those suggestions came from senior folks on this mailing list,
and it seemed prudent to take their counsel.
>
> As Andi already said, 10ms is silly large. You've just inflated the
> lock-acquire time for every contended lock to stupid land just because
> NUMA.
I just ran a few quick tests — local_clock() (a wrapper around sched_clock())
works well, so I will switch to using that.
I also took a few numbers with different thresholds. Looks like we can drop
the threshold to 1ms with a minor penalty to performance. However,
pushing the threshold to 100us has a more significant cost. Here are
the numbers for reference:
will-it-scale/lock2_threads:
threshold: 10ms 1ms 100us
speedup at 142 threads: 2.1841.974 1.1418
will-it-scale/open1_threads:
threshold: 10ms 1ms 100us
speedup at 142 threads: 2.1461.974 1.291
Would you be more comfortable with setting the default at 1ms?
> And this also brings me to the whole premise of this series; *why* are
> we optimizing this? What locks are so contended that this actually helps
> and shouldn't you be spending your time breaking those locks? That would
> improve throughput more than this ever can.
I think for the same reason the kernel switched from ticket locks to queue locks
several years back. There always will be applications with contended locks.
Sometimes the workarounds are easy, but many times they are not, like with
legacy applications or when the workload is skewed (e.g., every client tries to
update the metadata of the same file protected by the same lock). The results
show that for those cases we leave > 2x performance on the table. Those are not
only our numbers — LKP reports show similar or even better results,
on a wide range of benchmarks, e.g.:
https://lists.01.org/hyperkitty/list/l...@lists.01.org/thread/HGVOCYDEE5KTLYPTAFBD2RXDQOCDPFUJ/
https://lists.01.org/hyperkitty/list/l...@lists.01.org/thread/OUPS7MZ3GJA2XYWM52GMU7H7EI25IT37/
https://lists.01.org/hyperkitty/list/l...@lists.01.org/thread/DNMEQPXJRQY2IKHZ3ERGRY6TUPWDTFUN/
Regards,
— Alex
Re: [PATCH] ibmvfc: Fix invalid state machine BUG_ON
On Mon, 12 Apr 2021 18:10:09 -0600, Tyrel Datwyler wrote: > This fixes an issue hitting the BUG_ON in ibmvfc_do_work. When > going through a host action of IBMVFC_HOST_ACTION_RESET, > we change the action to IBMVFC_HOST_ACTION_TGT_DEL, > then drop the host lock, and reset the CRQ, which changes > the host state to IBMVFC_NO_CRQ. If, prior to setting the > host state to IBMVFC_NO_CRQ, ibmvfc_init_host is called, > it can then end up changing the host action to IBMVFC_HOST_ACTION_INIT. > If we then change the host state to IBMVFC_NO_CRQ, we will then > hit the BUG_ON. This patch makes a couple of changes to avoid this. > It leaves the host action to be IBMVFC_HOST_ACTION_RESET > or IBMVFC_HOST_ACTION_REENABLE until after we drop the host > lock and reset or reenable the CRQ. It also hardens the > host state machine to ensure we cannot leave the reset / reenable > state until we've finished processing the reset or reenable. Applied to 5.13/scsi-queue, thanks! [1/1] ibmvfc: Fix invalid state machine BUG_ON https://git.kernel.org/mkp/scsi/c/15cfef8623a4 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH -next] scsi: qla2xxx: remove unneeded if-null-free check
On Fri, 9 Apr 2021 20:09:25 +0800, Qiheng Lin wrote: > Eliminate the following coccicheck warning: > > drivers/scsi/qla2xxx/qla_os.c:4622:2-7: > WARNING: NULL check before some freeing functions is not needed. > drivers/scsi/qla2xxx/qla_os.c:4637:3-8: > WARNING: NULL check before some freeing functions is not needed. Applied to 5.13/scsi-queue, thanks! [1/1] scsi: qla2xxx: remove unneeded if-null-free check https://git.kernel.org/mkp/scsi/c/efd2617100d9 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v3 0/2] scsi: pm8001: tiny clean up patches
On Thu, 8 Apr 2021 20:56:31 +0800, Luo Jiaxing wrote: > Several error is reported by checkpatch.pl, here are two patches to clean > them up. Applied to 5.13/scsi-queue, thanks! [1/2] scsi: pm8001: clean up for white space https://git.kernel.org/mkp/scsi/c/8a23dbc60089 [2/2] scsi: pm8001: clean up for open brace https://git.kernel.org/mkp/scsi/c/fa5ac2beabad -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH -next] scsi: qla4xxx: remove unneeded if-null-free check
On Fri, 9 Apr 2021 20:03:45 +0800, Qiheng Lin wrote: > Eliminate the following coccicheck warning: > > drivers/scsi/qla4xxx/ql4_os.c:4175:2-7: WARNING: > NULL check before some freeing functions is not needed. > drivers/scsi/qla4xxx/ql4_os.c:4196:2-7: WARNING: > NULL check before some freeing functions is not needed. > drivers/scsi/qla4xxx/ql4_os.c:4215:2-7: WARNING: > NULL check before some freeing functions is not needed. > drivers/scsi/qla4xxx/ql4_os.c:6400:2-7: WARNING: > NULL check before some freeing functions is not needed. > drivers/scsi/qla4xxx/ql4_os.c:6402:2-7: WARNING: > NULL check before some freeing functions is not needed. > drivers/scsi/qla4xxx/ql4_os.c:6555:2-7: WARNING: > NULL check before some freeing functions is not needed. > drivers/scsi/qla4xxx/ql4_os.c:6557:2-7: WARNING: > NULL check before some freeing functions is not needed. > drivers/scsi/qla4xxx/ql4_os.c:7838:2-7: WARNING: > NULL check before some freeing functions is not needed. > drivers/scsi/qla4xxx/ql4_os.c:7840:2-7: WARNING: > NULL check before some freeing functions is not needed. Applied to 5.13/scsi-queue, thanks! [1/1] scsi: qla4xxx: remove unneeded if-null-free check https://git.kernel.org/mkp/scsi/c/eb5a3e3b75fe -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: isci/phy.h: Remove unnecessary struct declaration
On Tue, 6 Apr 2021 18:59:13 +0800, Wan Jiabing wrote: > struct sci_phy_proto is defined at 142nd line. > The declaration here is unnecessary. Remove it. Applied to 5.13/scsi-queue, thanks! [1/1] scsi: isci/phy.h: Remove unnecessary struct declaration https://git.kernel.org/mkp/scsi/c/8350e19658c1 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 0/3] scsi: mptfusion: Clear the warnings indicating that the variable is not used
On Thu, 8 Apr 2021 14:18:48 +0800, Zhen Lei wrote: > Fix below warnings: > drivers/message/fusion/mptctl.c: In function ‘mptctl_do_taskmgmt’: > drivers/message/fusion/mptctl.c:324:17: warning: variable ‘time_count’ set > but not used [-Wunused-but-set-variable] > 324 | unsigned long time_count; > | ^~ > drivers/message/fusion/mptctl.c: In function ‘mptctl_gettargetinfo’: > drivers/message/fusion/mptctl.c:1372:7: warning: variable ‘port’ set but not > used [-Wunused-but-set-variable] > 1372 | u8 port; > | ^~~~ > drivers/message/fusion/mptctl.c: In function ‘mptctl_hp_hostinfo’: > drivers/message/fusion/mptctl.c:2337:8: warning: variable ‘retval’ set but > not used [-Wunused-but-set-variable] > 2337 | int retval; > |^~ > > [...] Applied to 5.13/scsi-queue, thanks! [1/3] scsi: mptfusion: Remove unused local variable 'time_count' https://git.kernel.org/mkp/scsi/c/039cf3816648 [2/3] scsi: mptfusion: Remove unused local variable 'port' https://git.kernel.org/mkp/scsi/c/30264737bd95 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH][next] scsi: mpt3sas: Fix out-of-bounds warnings in _ctl_addnl_diag_query
On Thu, 1 Apr 2021 11:20:54 -0500, Gustavo A. R. Silva wrote: > Fix the following out-of-bounds warnings by embedding existing > struct htb_rel_query into struct mpt3_addnl_diag_query, instead > of duplicating its members: > > include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset [19, > 32] from the object at 'karg' is out of the bounds of referenced subobject > 'buffer_rel_condition' with type 'short unsigned int' at offset 16 > [-Warray-bounds] > include/linux/fortify-string.h:22:29: warning: '__builtin_memset' offset [19, > 32] from the object at 'karg' is out of the bounds of referenced subobject > 'buffer_rel_condition' with type 'short unsigned int' at offset 16 > [-Warray-bounds] > > [...] Applied to 5.13/scsi-queue, thanks! [1/1] scsi: mpt3sas: Fix out-of-bounds warnings in _ctl_addnl_diag_query https://git.kernel.org/mkp/scsi/c/16660db3fc2a -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: message: fusion: remove useless variable
On Mon, 12 Apr 2021 13:59:06 +0800, Jiapeng Chong wrote: > Fix the following gcc warning: > > drivers/message/fusion/mptsas.c:783:14: warning: variable ‘vtarget’ set > but not used [-Wunused-but-set-variable]. Applied to 5.13/scsi-queue, thanks! [1/1] scsi: message: fusion: remove useless variable https://git.kernel.org/mkp/scsi/c/cf17ff267880 -- Martin K. Petersen Oracle Linux Engineering
