[PATCH v3 6/6] ARM: dts: Add dts for RPi4b + Cirrus Logic Lochnagar2 + CS47L15
This adds a devicetree configuration for Raspberry Pi 4b connected to
Cirrus Logic Lochnagar 2 audio development board and CS47L15 codec.
The common (codec-independent) Lochnagar 2 configuration is separated
into a dtsi to simplify re-using it for other codecs.
Signed-off-by: Richard Fitzgerald
---
MAINTAINERS | 1 +
arch/arm/boot/dts/Makefile| 1 +
...bcm2711-rpi4b-cirrus-lochnagar-cs47l15.dts | 186
.../dts/bcm2711-rpi4b-cirrus-lochnagar.dtsi | 201 ++
4 files changed, 389 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm2711-rpi4b-cirrus-lochnagar-cs47l15.dts
create mode 100644 arch/arm/boot/dts/bcm2711-rpi4b-cirrus-lochnagar.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index 5cc595ac7b28..7dca1db52144 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4193,6 +4193,7 @@ M:Charles Keepax
M: Richard Fitzgerald
L: patc...@opensource.cirrus.com
S: Supported
+F: arch/arm/boot/dts/bcm2711-rpi4b-cirrus-lochnagar*
F: Documentation/devicetree/bindings/clock/cirrus,lochnagar.yaml
F: Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.yaml
F: Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ce66ffd5a1bb..240cc58fd954 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -93,6 +93,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
bcm2837-rpi-3-b-plus.dtb \
bcm2837-rpi-cm3-io3.dtb \
bcm2711-rpi-4-b.dtb \
+ bcm2711-rpi4b-cirrus-lochnagar-cs47l15.dtb \
bcm2835-rpi-zero.dtb \
bcm2835-rpi-zero-w.dtb
dtb-$(CONFIG_ARCH_BCM_5301X) += \
diff --git a/arch/arm/boot/dts/bcm2711-rpi4b-cirrus-lochnagar-cs47l15.dts
b/arch/arm/boot/dts/bcm2711-rpi4b-cirrus-lochnagar-cs47l15.dts
new file mode 100644
index ..b6b91289bc6f
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2711-rpi4b-cirrus-lochnagar-cs47l15.dts
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+#include "bcm2711-rpi4b-cirrus-lochnagar.dtsi"
+#include
+
+/ {
+ sound {
+ status = "okay";
+
+ compatible = "audio-graph-card";
+ label = "sound-card-cs47l15";
+
+ clocks = <_24m>, <_out>, <_dsp>;
+ clock-names = "ln-clk-24m", "fll1-out", "fll1-dsp";
+
+ plls = <
+MADERA_FLL1_REFCLK MADERA_FLL_SRC_MCLK1
98304000
+ >;
+ plls-clocks = "ln-clk-24m";
+
+ sysclks = <
+MADERA_CLK_SYSCLK_1 MADERA_CLK_SRC_FLL1 0
+MADERA_CLK_DSPCLK MADERA_CLK_SRC_FLL1 0
+ >;
+ sysclks-clocks = "fll1-out", "fll1-dsp";
+
+ widgets = "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack";
+
+ routing = "Microphone Jack", "MICBIAS1A",
+ "IN1BRN", "Microphone Jack",
+ "IN1BRP", "Microphone Jack",
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR";
+
+ dais = <_i2s_port _trace_port>;
+
+ /* Main output from FLL1 */
+ fll1_out: fll1_out {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <98304000>;
+ };
+
+ /* x1.5 DSP output from FLL1 */
+ fll1_dsp: fll1_dsp {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <147456000>;
+ };
+ };
+};
+
+ {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu_i2s_port: port@0 {
+ reg = <0>;
+ cpu_i2s_ep: endpoint {
+ remote-endpoint = <_aif1>;
+ dai-format = "i2s";
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ cs47l15: cs47l15@1 {
+ status = "okay";
+
+ compatible = "cirrus,cs47l15";
+ reg = <0x1>;
+
+ spi-max-frequency = <1100>;
+
+ interrupts = <27 8>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #sound-dai-cells = <1>;
+
+ AVDD-supply = <_vdd1v8>;
+ DCVDD-supply = <_vddcore>;
+ DBVDD1-supply = <_vdd1v8>;
+ CPVDD1-supply = <_vdd1v8>;
+ SPKVDD-supply = <>;
+ MICVDD-supply = <_micvdd>;
+
+ reset-gpios = <_pin 0 0>;
+
+ cirrus,dmic-ref = <
+
[PATCH v3 2/6] ASoC: audio-graph-card: Add plls and sysclks DT bindings
The audio-graph-card driver has bindings for configuring the clocking
for DAIs within a component, but is missing bindings for setting
up the PLLs and sysclks of the component.
This patch adds the two new bindings 'plls' and 'sysclks' so that the
audio-graph-driver can fully configure the component clocking.
Signed-off-by: Richard Fitzgerald
---
.../bindings/sound/audio-graph-card.txt | 72 +++
1 file changed, 72 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/audio-graph-card.txt
b/Documentation/devicetree/bindings/sound/audio-graph-card.txt
index d5f6919a2d69..30405e64cfbb 100644
--- a/Documentation/devicetree/bindings/sound/audio-graph-card.txt
+++ b/Documentation/devicetree/bindings/sound/audio-graph-card.txt
@@ -32,6 +32,40 @@ Required properties:
Optional properties:
- pa-gpios: GPIO used to control external amplifier.
+- plls: A list of component pll settings. There are 4 cells per PLL setting:
+ - phandle to the node of the codec or cpu component,
+ - component PLL id,
+ - component clock source id,
+ - frequency (in Hz) of the PLL output clock.
+
+ The PLL id and clock source id are specific to the particular component
+ so see the relevant component driver for the ids. Typically the
+ clock source id indicates the pin the source clock is connected to.
+
+ The same phandle can appear in multiple entries so that several plls
+ can be set in the same component.
+
+- plls-clocks: A list of clock names giving the source clock for each setting
+ in the plls property.
+
+- sysclks: A list of component sysclk settings. There are 4 cells per sysclk
+ setting:
+ - phandle to the node of the codec or cpu component,
+ - component sysclk id,
+ - component clock source id,
+ - direction of the clock: 0 if the clock is an input to the component,
+ 1 if it is an output.
+
+ The sysclk id and clock source id are specific to the particular
+ component so see the relevant component driver for the ids. Typically
+ the clock source id indicates the pin the source clock is connected to.
+
+ The same phandle can appear in multiple entries so that several sysclks
+ can be set in the same component.
+
+- sysclks-clocks: A list of clock names giving the source clock for each
setting
+ in the sysclks property.
+
---
Example: Single DAI case
---
@@ -335,3 +369,41 @@ Example: Multi DAI with DPCM
};
};
};
+
+---
+Example: Set component sysclks and PLLs
+---
+
+ sound {
+ compatible = "audio-graph-card";
+
+ clocks = <>, <>;
+ clock-names = "audioclk", "pll1";
+
+ plls = < MADERA_FLL1_REFCLK MADERA_FLL_SRC_MCLK1
98304000>;
+ plls-clocks = "audioclk";
+
+ sysclks = < MADERA_CLK_SYSCLK_1 MADERA_CLK_SRC_FLL1 0>;
+ sysclks-clocks = "pll1";
+
+ dais = <_i2s_port>;
+
+ pll1: pll1 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <98304000>;
+ };
+ };
+
+ cs47l15: codec@0 {
+ ...
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cs47l15_aif1_port: port@0 {
+ reg = <0>;
+ cs47l15_aif1: endpoint {
+ remote-endpoint = <_i2s_endpoint>;
+ };
+ };
+ };
--
2.20.1
Re: [PATCH 0/3] add support for metadata encryption to F2FS
On Sat, Oct 10, 2020 at 05:53:06PM +0800, Chao Yu wrote: > On 2020/10/5 15:36, Satya Tangirala wrote: > > This patch series adds support for metadata encryption to F2FS using > > blk-crypto. > > It looks this implementation is based on hardware crypto engine, could you > please add this info into f2fs.rst as well like inlinecrypt... > To be precise, the implementation requires either a hardware crypto engine *or* blk-crypto-fallback. I tried to clarify this a little better in the commit messages and in fscrypt.rst, but thinking about it again now, I think I should add a section about metadata encryption at the end of f2fs.rst. I'll do that when I send out v3 of this patch series (I just sent out v2). > > > > Patch 3 wires up F2FS with the functions introduced in Patch 2. F2FS > > will encrypt every block (that's not being encrypted by some other > > encryption key, e.g. a per-file key) with the metadata encryption key > > except the superblock (and the redundant copy of the superblock). The DUN > > of a block is the offset of the block from the start of the F2FS > > filesystem. > > Why not using nid as DUN, then GC could migrate encrypted node block directly > via > meta inode's address space like we do for encrypted data block, rather than > decrypting node block to node page and then encrypting node page with DUN of > new > blkaddr it migrates to. > The issue is, the bi_crypt_context in a bio holds a single DUN value, which is the DUN for the first data unit in the bio. blk-crypto assumes that the DUN of each subsequent data unit can be computed by simply incrementing the DUN. So physically contiguous data units can only be put into the same bio if they also have contiguous DUNs. I don't know much about nids, but if the nid is invariant w.r.t the physical block location, then there might be more fragmentation of bios in regular read/writes (because physical contiguity may have no relation to DUN contiguity). So I think we should continue using the fsblk number as the DUN.
Re: [PATCH RFC 1/2] Documentation: devicetree: Add property for ignoring the dummy bits sent before read transfer
On Thu, Dec 17, 2020 at 7:48 AM Aswath Govindraju wrote: > > Hi Rob, > > On 15/12/20 9:42 pm, Aswath Govindraju wrote: > > Hi Rob, > > On 15/12/20 3:53 am, Rob Herring wrote: > >> On Fri, Dec 11, 2020 at 08:34:57PM +0530, Aswath Govindraju wrote: > >>> Hi, > >>> On 11/12/20 9:03 am, Rob Herring wrote: > On Wed, Dec 09, 2020 at 11:27:07PM +0530, Aswath Govindraju wrote: > > Dummy zero bits are sent before data during a read transfer. This causes > > the data read to be shifted to the right. To fix this send zero bits > > after > > the address during a read transfer. > > > > Add property to send zero bits after the address during a read transfer. > > When is this necessary? Why can't it be implied by the compatible > string which should be specific to the chip model? > > >>> > >>> This is necessary for 93AA46A/B/C, 93LC46A/B/C, 93C46A/B/C eeproms, as > >>> it can be seen in section 2.7 of [1]. We were not sure if these were the > >>> only devices supported by the driver(eeprom_93xx46.c). So, in order to > >>> apply this only to the above listed devices, we thought that it would be > >>> better to apply this change when required by introducing a DT property. > >>> > >>> May I know how has this case been handled till now ?? > >>> > >> > >> No idea. From the at93c46d (which has a compatible string) datasheet it > >> looks like it has the same thing. > >> > >>> If this is required by all the devices then we can drop the property and > >>> include the zero bit by default. > >> > >> Looks like you need a combination of compatible strings for the above > >> devices and a property for the ORG pin state on the C devices. I assume > >> s/w needs to know if x8 or x16? > >> > > Yes, there are separate properties for indicating different types of > > types of eeproms. > > > > Here I was saying about x8 or x16 using the data-size property. ORG pin > state is implied through data-size property and an additional property > is not required for ORG pin state. Ah, I missed that property. > > > So, do you think that it is better to add it as a seperate property?? > > > > > These are the available options to my knowledge, > > 1) As you mentioned earlier all the eeprom's supported by the driver > send a dummy bit before the read data. This can be thought of a bug and > add this change as a fix for it. This might a problem for users who are > already using this driver and working around it using user space tools. > > 2) Add a special compatible string "eeprom-93xx46B", to add the extra > dummy cycle and not add an additional property. No. Genericish compatible strings are what cause the problem and this whole discussion. > 3) Add an additional property as proposed in this patch and use when > required. > > Are there any other suggestions on solving this issue?? You need a compatible string for each vendor+model. Period. Rob
Re: [PATCH v2 7/8] usb: host: ehci-tegra: Remove the driver
On Thu, Dec 17, 2020 at 12:40:06PM +0300, Dmitry Osipenko wrote: > The ChipIdea driver now provides USB2 host mode support for NVIDIA Tegra > SoCs. The ehci-tegra driver is obsolete now, remove it and redirect the > older Kconfig entry to the CI driver. > > Tested-by: Matt Merhar > Tested-by: Nicolas Chauvet > Tested-by: Peter Geis > Tested-by: Ion Agorria > Signed-off-by: Dmitry Osipenko > --- > drivers/usb/host/Kconfig | 8 +- > drivers/usb/host/Makefile | 1 - > drivers/usb/host/ehci-tegra.c | 604 -- > 3 files changed, 6 insertions(+), 607 deletions(-) > delete mode 100644 drivers/usb/host/ehci-tegra.c > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > index 31e59309da1f..318315602337 100644 > --- a/drivers/usb/host/Kconfig > +++ b/drivers/usb/host/Kconfig > @@ -269,9 +269,13 @@ config USB_EHCI_HCD_AT91 > config USB_EHCI_TEGRA > tristate "NVIDIA Tegra HCD support" > depends on ARCH_TEGRA > - select USB_EHCI_ROOT_HUB_TT > - select USB_TEGRA_PHY > + select USB_CHIPIDEA > + select USB_CHIPIDEA_HOST > + select USB_CHIPIDEA_TEGRA > help > + This option is deprecated now and the driver was removed, use > + USB_CHIPIDEA_TEGRA instead. > + > This driver enables support for the internal USB Host Controllers > found in NVIDIA Tegra SoCs. The controllers are EHCI compliant. It doesn't really make sense to say "... the driver was removed..." and then in the next paragraph say "This driver enables...". You should change the second paragraph to begin: "Enable support for...". That's a minor matter, though, and you can easily fix it in the next patch version. Everything else is okay. Acked-by: Alan Stern Alan Stern
Re: [External] Re: [PATCH v10 00/11] Free some vmemmap pages of HugeTLB page
On Thu, Dec 17, 2020 at 11:00 PM Oscar Salvador wrote: > > On Thu, Dec 17, 2020 at 08:12:52PM +0800, Muchun Song wrote: > > In this case, for the 1GB HugeTLB page, we can save 4088 pages(There are > > 4096 pages for struct page structs, we reserve 2 pages for vmemmap and 8 > > pages for page tables. So we can save 4088 pages). This is a very > > substantial > > gain. On our server, run some SPDK/QEMU applications which will use 1024GB > > hugetlbpage. With this feature enabled, we can save ~16GB(1G hugepage)/~11GB > > (2MB hugepage, the worst case is 10GB while the best is 12GB) memory. > > Is the above really true? > We no longer need to allocate pagetables, so the savings go up to 4094, right? Yeah, you are right. I forget to update this. > > I will be off for a few days but I expect to get back to this and review the > missing bits when I am back. > Thanks. > -- > Oscar Salvador > SUSE L3 -- Yours, Muchun
KASAN: null-ptr-deref Read in filp_close
Hello,
syzbot found the following issue on:
HEAD commit:5e60366d Merge tag 'fallthrough-fixes-clang-5.11-rc1' of g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15f1541350
kernel config: https://syzkaller.appspot.com/x/.config?x=db720fe37a6a41d8
dashboard link: https://syzkaller.appspot.com/bug?extid=96cfd2b22b3213646a93
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10e1a00b50
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1128e41f50
The issue was bisected to:
commit 582f1fb6b721facf04848d2ca57f34468da1813e
Author: Giuseppe Scrivano
Date: Wed Nov 18 10:47:45 2020 +
fs, close_range: add flag CLOSE_RANGE_CLOEXEC
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16e8561350
final oops: https://syzkaller.appspot.com/x/report.txt?x=15e8561350
console output: https://syzkaller.appspot.com/x/log.txt?x=11e8561350
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+96cfd2b22b3213646...@syzkaller.appspotmail.com
Fixes: 582f1fb6b721 ("fs, close_range: add flag CLOSE_RANGE_CLOEXEC")
==
BUG: KASAN: null-ptr-deref in instrument_atomic_read
include/linux/instrumented.h:71 [inline]
BUG: KASAN: null-ptr-deref in atomic64_read
include/asm-generic/atomic-instrumented.h:837 [inline]
BUG: KASAN: null-ptr-deref in atomic_long_read
include/asm-generic/atomic-long.h:29 [inline]
BUG: KASAN: null-ptr-deref in filp_close+0x22/0x170 fs/open.c:1274
Read of size 8 at addr 0077 by task syz-executor511/8522
CPU: 1 PID: 8522 Comm: syz-executor511 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x107/0x163 lib/dump_stack.c:120
__kasan_report mm/kasan/report.c:549 [inline]
kasan_report.cold+0x5/0x37 mm/kasan/report.c:562
check_memory_region_inline mm/kasan/generic.c:186 [inline]
check_memory_region+0x13d/0x180 mm/kasan/generic.c:192
instrument_atomic_read include/linux/instrumented.h:71 [inline]
atomic64_read include/asm-generic/atomic-instrumented.h:837 [inline]
atomic_long_read include/asm-generic/atomic-long.h:29 [inline]
filp_close+0x22/0x170 fs/open.c:1274
close_files fs/file.c:402 [inline]
put_files_struct fs/file.c:417 [inline]
put_files_struct+0x1cc/0x350 fs/file.c:414
exit_files+0x12a/0x170 fs/file.c:435
do_exit+0xb4f/0x2a00 kernel/exit.c:818
do_group_exit+0x125/0x310 kernel/exit.c:920
get_signal+0x428/0x2100 kernel/signal.c:2792
arch_do_signal_or_restart+0x2a8/0x1eb0 arch/x86/kernel/signal.c:811
handle_signal_work kernel/entry/common.c:147 [inline]
exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
exit_to_user_mode_prepare+0x124/0x200 kernel/entry/common.c:201
__syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:302
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x447039
Code: Unable to access opcode bytes at RIP 0x44700f.
RSP: 002b:7f1b1225cdb8 EFLAGS: 0246 ORIG_RAX: 00ca
RAX: 0001 RBX: 006dbc28 RCX: 00447039
RDX: 000f4240 RSI: 0081 RDI: 006dbc2c
RBP: 006dbc20 R08: R09:
R10: R11: 0246 R12: 006dbc2c
R13: 7fff223b6bef R14: 7f1b1225d9c0 R15: 006dbc2c
==
---
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.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH] kfence: fix typo in test
On Wed, Dec 16, 2020 at 12:44 AM Marco Elver wrote: > > On Wed, 16 Dec 2020 at 00:31, Marco Elver wrote: > > Fix a typo/accidental copy-paste that resulted in the obviously > > incorrect 'GFP_KERNEL * 2' expression. > > > > Reported-by: kernel test robot > > Signed-off-by: Marco Elver Acked-by: Alexander Potapenko > > --- > > mm/kfence/kfence_test.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/kfence/kfence_test.c b/mm/kfence/kfence_test.c > > index 1433a35a1644..f57c61c833e6 100644 > > --- a/mm/kfence/kfence_test.c > > +++ b/mm/kfence/kfence_test.c > > @@ -665,7 +665,7 @@ static void test_krealloc(struct kunit *test) > > for (; i < size * 3; i++) /* Fill to extra bytes. */ > > buf[i] = i + 1; > > > > - buf = krealloc(buf, size * 2, GFP_KERNEL * 2); /* Shrink. */ > > + buf = krealloc(buf, size * 2, GFP_KERNEL); /* Shrink. */ > > KUNIT_EXPECT_GE(test, ksize(buf), size * 2); > > for (i = 0; i < size * 2; i++) > > KUNIT_EXPECT_EQ(test, buf[i], (char)(i + 1)); > > -- > > 2.29.2.684.gfbc64c5ab5-goog > > > > This patch could, if appropriate, be squashed into "kfence: add test suite". > > Thanks, > -- Marco -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
[PATCH v5 0/9] Add k/uprobe & fentry & error_injection supported
From: Guo Ren This the 5th round of riscv k/uprobe support patchset, it's based on linux-5.10 and you can test it with the repo: https://github.com/c-sky/csky-linux/tree/linux-5.10-probe-dev The important fixup is about the trampoline call site, we change the prologue of the function call site from: : nop -> addi sp, sp, -SZREG nop -> REG_S ra, (sp) nop -> auipc ra, 0x? nop -> jalr ?(ra) nop -> REG_L ra, (sp) nop -> addi sp, sp, -SZREG ... to: : nop -> REG_S ra, -SZREG(sp) nop -> auipc ra, 0x? nop -> jalr ?(ra) nop -> REG_L ra, -SZREG(sp) ... It's wrong to change the sp in callsite, because when you change the value of ra then the sp is broken and the same with HAVE_OPTPROBES. The patchset includes kprobe/uprobe support and some related fixups. Patrick provides HAVE_REGS_AND_STACK_ACCESS_API support and some kprobe's code. The framework of k/uprobe is from csky but also refers to other arches'. kprobes on ftrace is also supported in the patchset. Modify dynamic ftrace mechanism from mcount to fentry. There is no single step exception in riscv ISA, only single-step facility for jtag. See riscv-Privileged spec: Interrupt Exception Code-Description 1 0 Reserved 1 1 Supervisor software interrupt 1 2–4 Reserved 1 5 Supervisor timer interrupt 1 6–8 Reserved 1 9 Supervisor external interrupt 1 10–15 Reserved 1 ≥16 Available for platform use 0 0 Instruction address misaligned 0 1 Instruction access fault 0 2 Illegal instruction 0 3 Breakpoint 0 4 Load address misaligned 0 5 Load access fault 0 6 Store/AMO address misaligned 0 7 Store/AMO access fault 0 8 Environment call from U-mode 0 9 Environment call from S-mode 0 10–11 Reserved 0 12 Instruction page fault 0 13 Load page fault 0 14 Reserved 0 15 Store/AMO page fault 0 16–23 Reserved 0 24–31 Available for custom use 0 32–47 Reserved 0 48–63 Available for custom use 0 ≥64 Reserved No single step! Other arches use hardware single-step exception for k/uprobe, eg: - powerpc: regs->msr |= MSR_SINGLESTEP - arm/arm64: PSTATE.D for enabling software step exceptions - s390: Set PER control regs, turns on single step for the given address - x86: regs->flags |= X86_EFLAGS_TF - csky: of course use hw single step :) All the above arches use a hardware single-step exception mechanism to execute the instruction that was replaced with a probe breakpoint. So utilize ebreak to simulate. Some pc related instructions couldn't be executed out of line and some system/fence instructions couldn't be a trace site at all. So we give out a reject list and simulate list in decode-insn.c. You could use uprobe to test simulate code like this: echo 'p:enter_current_state_one /hello:0x6e4 a0=%a0 a1=%a1' >> /sys/kernel/debug/tracing/uprobe_events echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable /hello ^C cat /sys/kernel/debug/tracing/trace tracer: nop entries-in-buffer/entries-written: 1/1 #P:1 _-=> irqs-off / _=> need-resched | / _---=> hardirq/softirq || / _--=> preempt-depth ||| / delay TASK-PID CPU# TIMESTAMP FUNCTION | | | | | hello-94[000] d...55.404242: enter_current_state_one: (0x106e4) a0=0x1 a1=0x3fffa8ada8 Be care /hello:0x6e4 is the file offset in elf and it relate to 0x106e4 in memory and hello is your target elf program. Try kprobe like this: echo 'p:myprobe sys_clone a0=%a0 a1=%a1 a2=%a2 a3=%a3 stach_val=+4($stack)' > /sys/kernel/debug/tracing/kprobe_events echo 'r:myretprobe sys_clone $retval' >> /sys/kernel/debug/tracing/kprobe_events echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable cat /sys/kernel/debug/tracing/trace tracer: nop entries-in-buffer/entries-written: 2/2 #P:1 _-=> irqs-off / _=> need-resched | / _---=> hardirq/softirq || / _--=> preempt-depth ||| / delay TASK-PID CPU# TIMESTAMP FUNCTION | | | | | sh-92 [000] .n.. 8506.435857: myprobe: (sys_clone+0x0/0x28) a0=0x1200011 a1=0x0 a2=0x0 a3=0x0 stach_val=0x2044ecffe0 sh-92 [000] d... 8506.445620: myretprobe: (ret_from_syscall+0x0/0x2 <- sys_clone) arg1=0x64 Changlog v5: - Fixup fentry modified sp cause fail_inject error - Fixup function_graph broken - Update to linux-5.10 - Fixup checkpatch.pl issues Changlog v4: - Revert fixup kprobes handler couldn't change pc - Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT - rebase on linux-tree: commit 071a0578b0ce0b0e543d1e38ee6926b9cc21c198 Merge: fad7011 be4df0c Author: Linus Torvalds Date:
Re: [PATCH RFC 1/2] Documentation: devicetree: Add property for ignoring the dummy bits sent before read transfer
Hi Rob, On 17/12/20 9:18 pm, Rob Herring wrote: > On Thu, Dec 17, 2020 at 7:48 AM Aswath Govindraju wrote: >> >> Hi Rob, >> >> On 15/12/20 9:42 pm, Aswath Govindraju wrote: >>> Hi Rob, >>> On 15/12/20 3:53 am, Rob Herring wrote: On Fri, Dec 11, 2020 at 08:34:57PM +0530, Aswath Govindraju wrote: > Hi, > On 11/12/20 9:03 am, Rob Herring wrote: >> On Wed, Dec 09, 2020 at 11:27:07PM +0530, Aswath Govindraju wrote: >>> Dummy zero bits are sent before data during a read transfer. This causes >>> the data read to be shifted to the right. To fix this send zero bits >>> after >>> the address during a read transfer. >>> >>> Add property to send zero bits after the address during a read transfer. >> >> When is this necessary? Why can't it be implied by the compatible >> string which should be specific to the chip model? >> > > This is necessary for 93AA46A/B/C, 93LC46A/B/C, 93C46A/B/C eeproms, as > it can be seen in section 2.7 of [1]. We were not sure if these were the > only devices supported by the driver(eeprom_93xx46.c). So, in order to > apply this only to the above listed devices, we thought that it would be > better to apply this change when required by introducing a DT property. > > May I know how has this case been handled till now ?? > No idea. From the at93c46d (which has a compatible string) datasheet it looks like it has the same thing. > If this is required by all the devices then we can drop the property and > include the zero bit by default. Looks like you need a combination of compatible strings for the above devices and a property for the ORG pin state on the C devices. I assume s/w needs to know if x8 or x16? >>> Yes, there are separate properties for indicating different types of >>> types of eeproms. >>> >> >> Here I was saying about x8 or x16 using the data-size property. ORG pin >> state is implied through data-size property and an additional property >> is not required for ORG pin state. > > Ah, I missed that property. > >> >>> So, do you think that it is better to add it as a seperate property?? >>> >> >> >> These are the available options to my knowledge, >> >> 1) As you mentioned earlier all the eeprom's supported by the driver >> send a dummy bit before the read data. This can be thought of a bug and >> add this change as a fix for it. This might a problem for users who are >> already using this driver and working around it using user space tools. >> >> 2) Add a special compatible string "eeprom-93xx46B", to add the extra >> dummy cycle and not add an additional property. > > No. Genericish compatible strings are what cause the problem and this > whole discussion. > >> 3) Add an additional property as proposed in this patch and use when >> required. >> >> Are there any other suggestions on solving this issue?? > > You need a compatible string for each vendor+model. Period. > Thank you for the comments. This change is required for microchip "93LC46B" model . I will add a new compatible string "microchip,93LC46B" and use it to implement the driver changes. Thanks, Aswath
[PATCH v5 1/9] RISC-V: Implement ptrace regs and stack API
From: Patrick Stählin
Needed for kprobes support. Copied and adapted from arm64 code.
Guo Ren fixup pt_regs type for linux-5.8-rc1.
Signed-off-by: Patrick Stählin
Signed-off-by: Guo Ren
Reviewed-by: Pekka Enberg
Reviewed-by: Zong Li
Reviewed-by: Masami Hiramatsu
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/ptrace.h | 29
arch/riscv/kernel/ptrace.c | 99 +
3 files changed, 129 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 44377fd..62a4958 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -72,6 +72,7 @@ config RISCV
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
+ select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_STACKPROTECTOR
select HAVE_SYSCALL_TRACEPOINTS
select IRQ_DOMAIN
diff --git a/arch/riscv/include/asm/ptrace.h b/arch/riscv/include/asm/ptrace.h
index ee49f80..23372bb 100644
--- a/arch/riscv/include/asm/ptrace.h
+++ b/arch/riscv/include/asm/ptrace.h
@@ -8,6 +8,7 @@
#include
#include
+#include
#ifndef __ASSEMBLY__
@@ -60,6 +61,7 @@ struct pt_regs {
#define user_mode(regs) (((regs)->status & SR_PP) == 0)
+#define MAX_REG_OFFSET offsetof(struct pt_regs, orig_a0)
/* Helpers for working with the instruction pointer */
static inline unsigned long instruction_pointer(struct pt_regs *regs)
@@ -85,6 +87,12 @@ static inline void user_stack_pointer_set(struct pt_regs
*regs,
regs->sp = val;
}
+/* Valid only for Kernel mode traps. */
+static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
+{
+ return regs->sp;
+}
+
/* Helpers for working with the frame pointer */
static inline unsigned long frame_pointer(struct pt_regs *regs)
{
@@ -101,6 +109,27 @@ static inline unsigned long regs_return_value(struct
pt_regs *regs)
return regs->a0;
}
+extern int regs_query_register_offset(const char *name);
+extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
+ unsigned int n);
+
+/**
+ * regs_get_register() - get register value from its offset
+ * @regs: pt_regs from which register value is gotten
+ * @offset:offset of the register.
+ *
+ * regs_get_register returns the value of a register whose offset from @regs.
+ * The @offset is the offset of the register in struct pt_regs.
+ * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
+ */
+static inline unsigned long regs_get_register(struct pt_regs *regs,
+ unsigned int offset)
+{
+ if (unlikely(offset > MAX_REG_OFFSET))
+ return 0;
+
+ return *(unsigned long *)((unsigned long)regs + offset);
+}
#endif /* __ASSEMBLY__ */
#endif /* _ASM_RISCV_PTRACE_H */
diff --git a/arch/riscv/kernel/ptrace.c b/arch/riscv/kernel/ptrace.c
index 2d6395f..1a85305 100644
--- a/arch/riscv/kernel/ptrace.c
+++ b/arch/riscv/kernel/ptrace.c
@@ -114,6 +114,105 @@ const struct user_regset_view
*task_user_regset_view(struct task_struct *task)
return _user_native_view;
}
+struct pt_regs_offset {
+ const char *name;
+ int offset;
+};
+
+#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+
+static const struct pt_regs_offset regoffset_table[] = {
+ REG_OFFSET_NAME(epc),
+ REG_OFFSET_NAME(ra),
+ REG_OFFSET_NAME(sp),
+ REG_OFFSET_NAME(gp),
+ REG_OFFSET_NAME(tp),
+ REG_OFFSET_NAME(t0),
+ REG_OFFSET_NAME(t1),
+ REG_OFFSET_NAME(t2),
+ REG_OFFSET_NAME(s0),
+ REG_OFFSET_NAME(s1),
+ REG_OFFSET_NAME(a0),
+ REG_OFFSET_NAME(a1),
+ REG_OFFSET_NAME(a2),
+ REG_OFFSET_NAME(a3),
+ REG_OFFSET_NAME(a4),
+ REG_OFFSET_NAME(a5),
+ REG_OFFSET_NAME(a6),
+ REG_OFFSET_NAME(a7),
+ REG_OFFSET_NAME(s2),
+ REG_OFFSET_NAME(s3),
+ REG_OFFSET_NAME(s4),
+ REG_OFFSET_NAME(s5),
+ REG_OFFSET_NAME(s6),
+ REG_OFFSET_NAME(s7),
+ REG_OFFSET_NAME(s8),
+ REG_OFFSET_NAME(s9),
+ REG_OFFSET_NAME(s10),
+ REG_OFFSET_NAME(s11),
+ REG_OFFSET_NAME(t3),
+ REG_OFFSET_NAME(t4),
+ REG_OFFSET_NAME(t5),
+ REG_OFFSET_NAME(t6),
+ REG_OFFSET_NAME(status),
+ REG_OFFSET_NAME(badaddr),
+ REG_OFFSET_NAME(cause),
+ REG_OFFSET_NAME(orig_a0),
+ REG_OFFSET_END,
+};
+
+/**
+ * regs_query_register_offset() - query register offset from its name
+ * @name: the name of a register
+ *
+ * regs_query_register_offset() returns the offset of a register in struct
+ * pt_regs from its name. If the name is invalid, this returns -EINVAL;
+ */
+int regs_query_register_offset(const char *name)
+{
+ const struct pt_regs_offset *roff;
+
+ for (roff = regoffset_table; roff->name != NULL; roff++)
+ if
[PATCH v5 3/9] riscv: Fixup wrong ftrace remove cflag
From: Guo Ren We must use $(CC_FLAGS_FTRACE) instead of directly using -pg. It will cause -fpatchable-function-entry error. Signed-off-by: Guo Ren --- arch/riscv/kernel/Makefile | 4 ++-- arch/riscv/mm/Makefile | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile index fa896c5..27f10eb 100644 --- a/arch/riscv/kernel/Makefile +++ b/arch/riscv/kernel/Makefile @@ -4,8 +4,8 @@ # ifdef CONFIG_FTRACE -CFLAGS_REMOVE_ftrace.o = -pg -CFLAGS_REMOVE_patch.o = -pg +CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_patch.o = $(CC_FLAGS_FTRACE) endif extra-y += head.o diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile index c0185e5..6b4b7ec 100644 --- a/arch/riscv/mm/Makefile +++ b/arch/riscv/mm/Makefile @@ -2,7 +2,7 @@ CFLAGS_init.o := -mcmodel=medany ifdef CONFIG_FTRACE -CFLAGS_REMOVE_init.o = -pg +CFLAGS_REMOVE_init.o = $(CC_FLAGS_FTRACE) endif KCOV_INSTRUMENT_init.o := n -- 2.7.4
[PATCH v5 4/9] riscv: Fixup patch_text panic in ftrace
From: Guo Ren Just like arm64, we can't trace the function in the patch_text path. Here is the bug log: [ 45.234334] Unable to handle kernel paging request at virtual address ffd38ae80900 [ 45.242313] Oops [#1] [ 45.244600] Modules linked in: [ 45.247678] CPU: 0 PID: 11 Comm: migration/0 Not tainted 5.9.0-00025-g9b7db83-dirty #215 [ 45.255797] epc: ffe00021689a ra : ffe00021718e sp : ffe01afabb58 [ 45.262955] gp : ffe00136afa0 tp : ffe01af94d00 t0 : 0002 [ 45.270200] t1 : t2 : 0001 s0 : ffe01afabc08 [ 45.277443] s1 : ffe0013718a8 a0 : a1 : ffe01afabba8 [ 45.284686] a2 : a3 : a4 : c4c16ad38ae80900 [ 45.291929] a5 : a6 : a7 : 52464e43 [ 45.299173] s2 : 0001 s3 : ffe000206a60 s4 : ffe000206a60 [ 45.306415] s5 : 09ec s6 : ffe0013718a8 s7 : c4c16ad38ae80900 [ 45.313658] s8 : 0004 s9 : 0001 s10: 0001 [ 45.320902] s11: 0003 t3 : 0001 t4 : d192fe79 [ 45.328144] t5 : b8f8 t6 : 0004 [ 45.333472] status: 00020100 badaddr: ffd38ae80900 cause: 000f [ 45.341514] ---[ end trace d95102172248fdcf ]--- [ 45.346176] note: migration/0[11] exited with preempt_count 1 (gdb) x /2i $pc => 0xffe00021689a <__do_proc_dointvec+196>: sd zero,0(s7) 0xffe00021689e <__do_proc_dointvec+200>: li s11,0 (gdb) bt 0 __do_proc_dointvec (tbl_data=0x0, table=0xffe01afabba8, write=0, buffer=0x0, lenp=0x7bf897061f9a0800, ppos=0x4, conv=0x0, data=0x52464e43) at kernel/sysctl.c:581 1 0xffe00021718e in do_proc_dointvec (data=, conv=, ppos=, lenp=, buffer=, write=, table=) at kernel/sysctl.c:964 2 proc_dointvec_minmax (ppos=, lenp=, buffer=, write=, table=) at kernel/sysctl.c:964 3 proc_do_static_key (table=, write=1, buffer=0x0, lenp=0x0, ppos=0x7bf897061f9a0800) at kernel/sysctl.c:1643 4 0xffe000206792 in ftrace_make_call (rec=, addr=) at arch/riscv/kernel/ftrace.c:109 5 0xffe0002c9c04 in __ftrace_replace_code (rec=0xffe01ae40c30, enable=3) at kernel/trace/ftrace.c:2503 6 0xffe0002ca0b2 in ftrace_replace_code (mod_flags=) at kernel/trace/ftrace.c:2530 7 0xffe0002ca26a in ftrace_modify_all_code (command=5) at kernel/trace/ftrace.c:2677 8 0xffe0002ca30e in __ftrace_modify_code (data=) at kernel/trace/ftrace.c:2703 9 0xffe0002c13b0 in multi_cpu_stop (data=0x0) at kernel/stop_machine.c:224 10 0xffe0002c0fde in cpu_stopper_thread (cpu=) at kernel/stop_machine.c:491 11 0xffe0002343de in smpboot_thread_fn (data=0x0) at kernel/smpboot.c:165 12 0xffe00022f8b4 in kthread (_create=0xffe01af0c040) at kernel/kthread.c:292 13 0xffe000201fac in handle_exception () at arch/riscv/kernel/entry.S:236 0xffe00020678a <+114>: auipc ra,0xe 0xffe00020678e <+118>: jalr-118(ra) # 0xffe000204714 0xffe000206792 <+122>: sneza0,a0 (gdb) disassemble patch_text_nosync Dump of assembler code for function patch_text_nosync: 0xffe000204714 <+0>: addisp,sp,-32 0xffe000204716 <+2>: sd s0,16(sp) 0xffe000204718 <+4>: sd ra,24(sp) 0xffe00020471a <+6>: addis0,sp,32 0xffe00020471c <+8>: auipc ra,0x0 0xffe000204720 <+12>:jalr-384(ra) # 0xffe00020459c 0xffe000204724 <+16>:beqza0,0xffe00020472e 0xffe000204726 <+18>:ld ra,24(sp) 0xffe000204728 <+20>:ld s0,16(sp) 0xffe00020472a <+22>:addisp,sp,32 0xffe00020472c <+24>:ret 0xffe00020472e <+26>:sd a0,-24(s0) 0xffe000204732 <+30>:auipc ra,0x4 0xffe000204736 <+34>:jalr-1464(ra) # 0xffe00020817a 0xffe00020473a <+38>:ld a0,-24(s0) 0xffe00020473e <+42>:ld ra,24(sp) 0xffe000204740 <+44>:ld s0,16(sp) 0xffe000204742 <+46>:addisp,sp,32 0xffe000204744 <+48>:ret (gdb) disassemble flush_icache_all-4 Dump of assembler code for function flush_icache_all: 0xffe00020817a <+0>: addisp,sp,-8 0xffe00020817c <+2>: sd ra,0(sp) 0xffe00020817e <+4>: auipc ra,0xf 0xffe000208182 <+8>: jalr-1822(ra) # 0xffe000206a60 0xffe000208186 <+12>:ld ra,0(sp) 0xffe000208188 <+14>:addisp,sp,8 0xffe00020818a <+0>: addisp,sp,-16 0xffe00020818c <+2>: sd s0,0(sp) 0xffe00020818e <+4>: sd ra,8(sp) 0xffe000208190 <+6>: addis0,sp,16 0xffe000208192 <+8>: li a0,0 0xffe000208194 <+10>:auipc ra,0xf 0xffe000208198 <+14>:jalr-410(ra) # 0xffe000206ffa 0xffe00020819c <+18>:
[PATCH v5 5/9] riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT
From: Guo Ren
This patch changes the current detour mechanism of dynamic ftrace
which has been discussed during LPC 2020 RISCV-MC [1].
Before the patch, we used mcount for detour:
:
addi sp,sp,-16
sd ra,8(sp)
sd s0,0(sp)
addi s0,sp,16
mv a5,ra
mv a0,a5
auipc ra,0x0 -> nop
jalr -296(ra) <_mcount@plt> ->nop
...
After the patch, we use nop call site area for detour:
:
nop -> REG_S ra, -SZREG(sp)
nop -> auipc ra, 0x?
nop -> jalr ?(ra)
nop -> REG_L ra, -SZREG(sp)
...
The mcount mechanism is mixed with gcc function prologue which is
not very clear. The patchable function entry just put 16 bytes nop
before the front of the function prologue which could be filled
with a separated detour mechanism.
[1] https://www.linuxplumbersconf.org/event/7/contributions/807/
Signed-off-by: Guo Ren
Cc: Alan Kao
Cc: Masami Hiramatsu
Cc: Palmer Dabbelt
Cc: Paul Walmsley
---
arch/riscv/Makefile| 2 +
arch/riscv/kernel/ftrace.c | 95 ++--
arch/riscv/kernel/mcount-dyn.S | 342 ++---
3 files changed, 204 insertions(+), 235 deletions(-)
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 0289a97..b6eb946 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -12,6 +12,8 @@ OBJCOPYFLAGS:= -O binary
LDFLAGS_vmlinux :=
ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
LDFLAGS_vmlinux := --no-relax
+ KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY
+ CC_FLAGS_FTRACE := -fpatchable-function-entry=8
endif
ifeq ($(CONFIG_64BIT)$(CONFIG_CMODEL_MEDLOW),yy)
diff --git a/arch/riscv/kernel/ftrace.c b/arch/riscv/kernel/ftrace.c
index 765b624..7f1e520 100644
--- a/arch/riscv/kernel/ftrace.c
+++ b/arch/riscv/kernel/ftrace.c
@@ -72,29 +72,56 @@ static int __ftrace_modify_call(unsigned long hook_pos,
unsigned long target,
return 0;
}
+/*
+ * Put 5 instructions with 16 bytes at the front of function within
+ * patchable function entry nops' area.
+ *
+ * 0: REG_S ra, -SZREG(sp)
+ * 1: auipc ra, 0x?
+ * 2: jalr -?(ra)
+ * 3: REG_L ra, -SZREG(sp)
+ *
+ * So the opcodes is:
+ * 0: 0xfe113c23 (sd)/0xfe112e23 (sw)
+ * 1: 0x -> auipc
+ * 2: 0x -> jalr
+ * 3: 0xff813083 (ld)/0xffc12083 (lw)
+ */
+#if __riscv_xlen == 64
+#define INSN0 0xfe113c23
+#define INSN3 0xff813083
+#elif __riscv_xlen == 32
+#define INSN0 0xfe112e23
+#define INSN3 0xffc12083
+#endif
+
+#define FUNC_ENTRY_SIZE16
+#define FUNC_ENTRY_JMP 4
+
int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
{
- int ret = ftrace_check_current_call(rec->ip, NULL);
+ unsigned int call[4] = {INSN0, 0, 0, INSN3};
+ unsigned long target = addr;
+ unsigned long caller = rec->ip + FUNC_ENTRY_JMP;
- if (ret)
- return ret;
+ call[1] = to_auipc_insn((unsigned int)(target - caller));
+ call[2] = to_jalr_insn((unsigned int)(target - caller));
- return __ftrace_modify_call(rec->ip, addr, true);
+ if (patch_text_nosync((void *)rec->ip, call, FUNC_ENTRY_SIZE))
+ return -EPERM;
+
+ return 0;
}
int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
unsigned long addr)
{
- unsigned int call[2];
- int ret;
+ unsigned int nops[4] = {NOP4, NOP4, NOP4, NOP4};
- make_call(rec->ip, addr, call);
- ret = ftrace_check_current_call(rec->ip, call);
-
- if (ret)
- return ret;
+ if (patch_text_nosync((void *)rec->ip, nops, FUNC_ENTRY_SIZE))
+ return -EPERM;
- return __ftrace_modify_call(rec->ip, addr, false);
+ return 0;
}
@@ -139,15 +166,16 @@ int ftrace_modify_call(struct dyn_ftrace *rec, unsigned
long old_addr,
unsigned long addr)
{
unsigned int call[2];
+ unsigned long caller = rec->ip + FUNC_ENTRY_JMP;
int ret;
- make_call(rec->ip, old_addr, call);
- ret = ftrace_check_current_call(rec->ip, call);
+ make_call(caller, old_addr, call);
+ ret = ftrace_check_current_call(caller, call);
if (ret)
return ret;
- return __ftrace_modify_call(rec->ip, addr, true);
+ return __ftrace_modify_call(caller, addr, true);
}
#endif
@@ -176,53 +204,30 @@ void prepare_ftrace_return(unsigned long *parent,
unsigned long self_addr,
#ifdef CONFIG_DYNAMIC_FTRACE
extern void ftrace_graph_call(void);
+extern void ftrace_graph_regs_call(void);
int ftrace_enable_ftrace_graph_caller(void)
{
- unsigned int call[2];
- static int init_graph = 1;
int ret;
- make_call(_graph_call, _stub, call);
-
- /*
-* When enabling graph tracer for the first time, ftrace_graph_call
-* should contains a call to ftrace_stub. Once it has been disabled,
-* the 8-bytes at the position becomes NOPs.
-
UBSAN: invalid-load in param_get_bool
Hello, syzbot found the following issue on: HEAD commit:accefff5 Merge tag 'arm-soc-omap-genpd-5.11' of git://git... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1238561350 kernel config: https://syzkaller.appspot.com/x/.config?x=5d42216b510180e3 dashboard link: https://syzkaller.appspot.com/bug?extid=438cc6c21c384f9efa5e compiler: gcc (GCC) 10.1.0-syz 20200507 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+438cc6c21c384f9ef...@syzkaller.appspotmail.com UBSAN: invalid-load in kernel/params.c:302:33 load of value 255 is not a valid value for type '_Bool' CPU: 0 PID: 8488 Comm: syz-fuzzer Not tainted 5.10.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_load_invalid_value.cold+0x62/0x6c lib/ubsan.c:427 param_get_bool.cold+0x14/0x19 kernel/params.c:302 param_attr_show+0x14a/0x220 kernel/params.c:549 module_attr_show+0x48/0x70 kernel/params.c:884 sysfs_kf_seq_show+0x1f8/0x400 fs/sysfs/file.c:61 seq_read_iter+0x4d3/0x1220 fs/seq_file.c:227 seq_read+0x3dd/0x5b0 fs/seq_file.c:159 kernfs_fop_read+0xe9/0x590 fs/kernfs/file.c:251 vfs_read+0x1b5/0x570 fs/read_write.c:494 ksys_read+0x12d/0x250 fs/read_write.c:634 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x4b3d8b Code: ff e9 69 ff ff ff cc cc cc cc cc cc cc cc cc e8 db a1 f8 ff 48 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 RSP: 002b:00ca3740 EFLAGS: 0202 ORIG_RAX: RAX: ffda RBX: 00c2c000 RCX: 004b3d8b RDX: 1200 RSI: 00c000341300 RDI: 0006 RBP: 00ca3790 R08: 0001 R09: 0002 R10: 1200 R11: 0202 R12: R13: 0002 R14: 0001 R15: 0005 --- 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.
[PATCH v3 0/5] Backport of patch series for stable 4.4 branch
From: SeongJae Park Changes from v2 (https://lore.kernel.org/stable/20201217130501.12702-1-sjp...@amazon.com/) - Move 'nr_pending' increase from 5th patch to 4th patch Changes from v1 (https://lore.kernel.org/stable/20201217081727.8253-1-sjp...@amazon.com/) - Remove wrong 'Signed-off-by' lines for 'Author Redacted' SeongJae Park (5): xen/xenbus: Allow watches discard events before queueing xen/xenbus: Add 'will_handle' callback support in xenbus_watch_path() xen/xenbus/xen_bus_type: Support will_handle watch callback xen/xenbus: Count pending messages for each watch xenbus/xenbus_backend: Disallow pending watch messages drivers/block/xen-blkback/xenbus.c| 3 +- drivers/net/xen-netback/xenbus.c | 4 ++- drivers/xen/xen-pciback/xenbus.c | 2 +- drivers/xen/xenbus/xenbus_client.c| 8 - drivers/xen/xenbus/xenbus_probe.c | 1 + drivers/xen/xenbus/xenbus_probe.h | 2 ++ drivers/xen/xenbus/xenbus_probe_backend.c | 7 + drivers/xen/xenbus/xenbus_xs.c| 38 +++ include/xen/xenbus.h | 15 - 9 files changed, 62 insertions(+), 18 deletions(-) -- 2.17.1
[PATCH v5 2/9] riscv: Fixup compile error BUILD_BUG_ON failed
From: Guo Ren
Unfortunately, the current code couldn't be compiled:
CC arch/riscv/kernel/patch.o
In file included from ./include/linux/kernel.h:11,
from ./include/linux/list.h:9,
from ./include/linux/preempt.h:11,
from ./include/linux/spinlock.h:51,
from arch/riscv/kernel/patch.c:6:
In function ‘fix_to_virt’,
inlined from ‘patch_map’ at arch/riscv/kernel/patch.c:37:17:
./include/linux/compiler.h:392:38: error: call to ‘__compiletime_assert_205’
declared with attribute error: BUILD_BUG_ON failed: idx >=
__end_of_fixed_addresses
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^
./include/linux/compiler.h:373:4: note: in definition of macro
‘__compiletime_assert’
prefix ## suffix();\
^~
./include/linux/compiler.h:392:2: note: in expansion of macro
‘_compiletime_assert’
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^~~
./include/linux/build_bug.h:39:37: note: in expansion of macro
‘compiletime_assert’
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
./include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~
./include/asm-generic/fixmap.h:32:2: note: in expansion of macro ‘BUILD_BUG_ON’
BUILD_BUG_ON(idx >= __end_of_fixed_addresses);
^~~~
Because fix_to_virt(, idx) needs a const value, not a dynamic variable of
reg-a0 or BUILD_BUG_ON failed with "idx >= __end_of_fixed_addresses".
Signed-off-by: Guo Ren
Reviewed-by: Masami Hiramatsu
Reviewed-by: Pekka Enberg
Cc: Paul Walmsley
Cc: Palmer Dabbelt
---
arch/riscv/kernel/patch.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/kernel/patch.c b/arch/riscv/kernel/patch.c
index 3fe7a52..0b55287 100644
--- a/arch/riscv/kernel/patch.c
+++ b/arch/riscv/kernel/patch.c
@@ -20,7 +20,12 @@ struct patch_insn {
};
#ifdef CONFIG_MMU
-static void *patch_map(void *addr, int fixmap)
+/*
+ * The fix_to_virt(, idx) needs a const value (not a dynamic variable of
+ * reg-a0) or BUILD_BUG_ON failed with "idx >= __end_of_fixed_addresses".
+ * So use '__always_inline' and 'const unsigned int fixmap' here.
+ */
+static __always_inline void *patch_map(void *addr, const unsigned int fixmap)
{
uintptr_t uintaddr = (uintptr_t) addr;
struct page *page;
@@ -37,7 +42,6 @@ static void *patch_map(void *addr, int fixmap)
return (void *)set_fixmap_offset(fixmap, page_to_phys(page) +
(uintaddr & ~PAGE_MASK));
}
-NOKPROBE_SYMBOL(patch_map);
static void patch_unmap(int fixmap)
{
--
2.7.4
[PATCH v5 6/9] riscv: Add kprobes supported
From: Guo Ren
This patch enables "kprobe & kretprobe" to work with ftrace
interface. It utilized software breakpoint as single-step
mechanism.
Some instructions which can't be single-step executed must be
simulated in kernel execution slot, such as: branch, jal, auipc,
la ...
Some instructions should be rejected for probing and we use a
blacklist to filter, such as: ecall, ebreak, ...
We use ebreak & c.ebreak to replace origin instruction and the
kprobe handler prepares an executable memory slot for out-of-line
execution with a copy of the original instruction being probed.
In execution slot we add ebreak behind original instruction to
simulate a single-setp mechanism.
The patch is based on packi's work [1] and csky's work [2].
- The kprobes_trampoline.S is all from packi's patch
- The single-step mechanism is new designed for riscv without hw
single-step trap
- The simulation codes are from csky
- Frankly, all codes refer to other archs' implementation
[1] https://lore.kernel.org/linux-riscv/20181113195804.22825-1...@packi.ch/
[2]
https://lore.kernel.org/linux-csky/20200403044150.20562-9-guo...@kernel.org/
Signed-off-by: Guo Ren
Co-developed-by: Patrick Stählin
Signed-off-by: Patrick Stählin
Acked-by: Masami Hiramatsu
Tested-by: Zong Li
Reviewed-by: Pekka Enberg
Cc: Patrick Stählin
Cc: Palmer Dabbelt
Cc: Björn Töpel
---
arch/riscv/Kconfig| 2 +
arch/riscv/include/asm/kprobes.h | 40 +++
arch/riscv/include/asm/probes.h | 24 ++
arch/riscv/kernel/Makefile| 1 +
arch/riscv/kernel/probes/Makefile | 4 +
arch/riscv/kernel/probes/decode-insn.c| 48
arch/riscv/kernel/probes/decode-insn.h| 18 ++
arch/riscv/kernel/probes/kprobes.c| 398 ++
arch/riscv/kernel/probes/kprobes_trampoline.S | 93 ++
arch/riscv/kernel/probes/simulate-insn.c | 85 ++
arch/riscv/kernel/probes/simulate-insn.h | 47 +++
arch/riscv/kernel/traps.c | 9 +
arch/riscv/mm/fault.c | 4 +
13 files changed, 773 insertions(+)
create mode 100644 arch/riscv/include/asm/probes.h
create mode 100644 arch/riscv/kernel/probes/Makefile
create mode 100644 arch/riscv/kernel/probes/decode-insn.c
create mode 100644 arch/riscv/kernel/probes/decode-insn.h
create mode 100644 arch/riscv/kernel/probes/kprobes.c
create mode 100644 arch/riscv/kernel/probes/kprobes_trampoline.S
create mode 100644 arch/riscv/kernel/probes/simulate-insn.c
create mode 100644 arch/riscv/kernel/probes/simulate-insn.h
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 62a4958..9a920ed 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -68,6 +68,8 @@ config RISCV
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_GCC_PLUGINS
select HAVE_GENERIC_VDSO if MMU && 64BIT
+ select HAVE_KPROBES
+ select HAVE_KRETPROBES
select HAVE_PCI
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
diff --git a/arch/riscv/include/asm/kprobes.h b/arch/riscv/include/asm/kprobes.h
index 56a98ea3..4647d38 100644
--- a/arch/riscv/include/asm/kprobes.h
+++ b/arch/riscv/include/asm/kprobes.h
@@ -11,4 +11,44 @@
#include
+#ifdef CONFIG_KPROBES
+#include
+#include
+#include
+
+#define __ARCH_WANT_KPROBES_INSN_SLOT
+#define MAX_INSN_SIZE 2
+
+#define flush_insn_slot(p) do { } while (0)
+#define kretprobe_blacklist_size 0
+
+#include
+
+struct prev_kprobe {
+ struct kprobe *kp;
+ unsigned int status;
+};
+
+/* Single step context for kprobe */
+struct kprobe_step_ctx {
+ unsigned long ss_pending;
+ unsigned long match_addr;
+};
+
+/* per-cpu kprobe control block */
+struct kprobe_ctlblk {
+ unsigned int kprobe_status;
+ unsigned long saved_status;
+ struct prev_kprobe prev_kprobe;
+ struct kprobe_step_ctx ss_ctx;
+};
+
+void arch_remove_kprobe(struct kprobe *p);
+int kprobe_fault_handler(struct pt_regs *regs, unsigned int trapnr);
+bool kprobe_breakpoint_handler(struct pt_regs *regs);
+bool kprobe_single_step_handler(struct pt_regs *regs);
+void kretprobe_trampoline(void);
+void __kprobes *trampoline_probe_handler(struct pt_regs *regs);
+
+#endif /* CONFIG_KPROBES */
#endif /* _ASM_RISCV_KPROBES_H */
diff --git a/arch/riscv/include/asm/probes.h b/arch/riscv/include/asm/probes.h
new file mode 100644
index ..a787e6d
--- /dev/null
+++ b/arch/riscv/include/asm/probes.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_RISCV_PROBES_H
+#define _ASM_RISCV_PROBES_H
+
+typedef u32 probe_opcode_t;
+typedef bool (probes_handler_t) (u32 opcode, unsigned long addr, struct
pt_regs *);
+
+/* architecture specific copy of original instruction */
+struct arch_probe_insn {
+ probe_opcode_t *insn;
+ probes_handler_t *handler;
+ /* restore address after simulation */
+
[PATCH v3 2/5] xen/xenbus: Add 'will_handle' callback support in xenbus_watch_path()
From: SeongJae Park
Some code does not directly make 'xenbus_watch' object and call
'register_xenbus_watch()' but use 'xenbus_watch_path()' instead. This
commit adds support of 'will_handle' callback in the
'xenbus_watch_path()' and it's wrapper, 'xenbus_watch_pathfmt()'.
This is part of XSA-349
This is upstream commit 2e85d32b1c865bec703ce0c962221a5e955c52c2
Cc: sta...@vger.kernel.org
Signed-off-by: SeongJae Park
Reported-by: Michael Kurth
Reported-by: Pawel Wieczorkiewicz
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkback/xenbus.c | 3 ++-
drivers/net/xen-netback/xenbus.c | 2 +-
drivers/xen/xen-pciback/xenbus.c | 2 +-
drivers/xen/xenbus/xenbus_client.c | 9 +++--
drivers/xen/xenbus/xenbus_probe.c | 2 +-
include/xen/xenbus.h | 6 +-
6 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index 0ec257e69e95..823f3480ebd1 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -553,7 +553,8 @@ static int xen_blkbk_probe(struct xenbus_device *dev,
/* setup back pointer */
be->blkif->be = be;
- err = xenbus_watch_pathfmt(dev, >backend_watch, backend_changed,
+ err = xenbus_watch_pathfmt(dev, >backend_watch, NULL,
+ backend_changed,
"%s/%s", dev->nodename, "physical-device");
if (err)
goto fail;
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 23f03af0a2d4..21c8e2720b40 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -849,7 +849,7 @@ static void connect(struct backend_info *be)
xenvif_carrier_on(be->vif);
unregister_hotplug_status_watch(be);
- err = xenbus_watch_pathfmt(dev, >hotplug_status_watch,
+ err = xenbus_watch_pathfmt(dev, >hotplug_status_watch, NULL,
hotplug_status_changed,
"%s/%s", dev->nodename, "hotplug-status");
if (!err)
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 48196347f2f9..12497a2140c2 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -691,7 +691,7 @@ static int xen_pcibk_xenbus_probe(struct xenbus_device *dev,
/* watch the backend node for backend configuration information */
err = xenbus_watch_path(dev, dev->nodename, >be_watch,
- xen_pcibk_be_watch);
+ NULL, xen_pcibk_be_watch);
if (err)
goto out;
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index d02d25f784c9..8bbd887ca422 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -114,19 +114,22 @@ EXPORT_SYMBOL_GPL(xenbus_strstate);
*/
int xenbus_watch_path(struct xenbus_device *dev, const char *path,
struct xenbus_watch *watch,
+ bool (*will_handle)(struct xenbus_watch *,
+ const char **, unsigned int),
void (*callback)(struct xenbus_watch *,
const char **, unsigned int))
{
int err;
watch->node = path;
- watch->will_handle = NULL;
+ watch->will_handle = will_handle;
watch->callback = callback;
err = register_xenbus_watch(watch);
if (err) {
watch->node = NULL;
+ watch->will_handle = NULL;
watch->callback = NULL;
xenbus_dev_fatal(dev, err, "adding watch on %s", path);
}
@@ -153,6 +156,8 @@ EXPORT_SYMBOL_GPL(xenbus_watch_path);
*/
int xenbus_watch_pathfmt(struct xenbus_device *dev,
struct xenbus_watch *watch,
+bool (*will_handle)(struct xenbus_watch *,
+const char **, unsigned int),
void (*callback)(struct xenbus_watch *,
const char **, unsigned int),
const char *pathfmt, ...)
@@ -169,7 +174,7 @@ int xenbus_watch_pathfmt(struct xenbus_device *dev,
xenbus_dev_fatal(dev, -ENOMEM, "allocating path for watch");
return -ENOMEM;
}
- err = xenbus_watch_path(dev, path, watch, callback);
+ err = xenbus_watch_path(dev, path, watch, will_handle, callback);
if (err)
kfree(path);
diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
index c2d447687e33..c560c1b8489a 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -137,7 +137,7 @@ static int watch_otherend(struct xenbus_device *dev)
[PATCH v3 1/5] xen/xenbus: Allow watches discard events before queueing
From: SeongJae Park
If handling logics of watch events are slower than the events enqueue
logic and the events can be created from the guests, the guests could
trigger memory pressure by intensively inducing the events, because it
will create a huge number of pending events that exhausting the memory.
This is known as XSA-349.
Fortunately, some watch events could be ignored, depending on its
handler callback. For example, if the callback has interest in only one
single path, the watch wouldn't want multiple pending events. Or, some
watches could ignore events to same path.
To let such watches to volutarily help avoiding the memory pressure
situation, this commit introduces new watch callback, 'will_handle'. If
it is not NULL, it will be called for each new event just before
enqueuing it. Then, if the callback returns false, the event will be
discarded. No watch is using the callback for now, though.
This is part of XSA-349
This is upstream commit fed1755b118147721f2c87b37b9d66e62c39b668
Cc: sta...@vger.kernel.org
Signed-off-by: SeongJae Park
Reported-by: Michael Kurth
Reported-by: Pawel Wieczorkiewicz
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
---
drivers/net/xen-netback/xenbus.c | 2 ++
drivers/xen/xenbus/xenbus_client.c | 1 +
drivers/xen/xenbus/xenbus_xs.c | 7 ++-
include/xen/xenbus.h | 7 +++
4 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 56ebd8267386..23f03af0a2d4 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -697,12 +697,14 @@ static int xen_register_watchers(struct xenbus_device
*dev, struct xenvif *vif)
return -ENOMEM;
snprintf(node, maxlen, "%s/rate", dev->nodename);
vif->credit_watch.node = node;
+ vif->credit_watch.will_handle = NULL;
vif->credit_watch.callback = xen_net_rate_changed;
err = register_xenbus_watch(>credit_watch);
if (err) {
pr_err("Failed to set watcher %s\n", vif->credit_watch.node);
kfree(node);
vif->credit_watch.node = NULL;
+ vif->credit_watch.will_handle = NULL;
vif->credit_watch.callback = NULL;
}
return err;
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index 266f446ba331..d02d25f784c9 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -120,6 +120,7 @@ int xenbus_watch_path(struct xenbus_device *dev, const char
*path,
int err;
watch->node = path;
+ watch->will_handle = NULL;
watch->callback = callback;
err = register_xenbus_watch(watch);
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index ce65591b4168..0ea1c259f2f1 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -903,7 +903,12 @@ static int process_msg(void)
spin_lock(_lock);
msg->u.watch.handle = find_watch(
msg->u.watch.vec[XS_WATCH_TOKEN]);
- if (msg->u.watch.handle != NULL) {
+ if (msg->u.watch.handle != NULL &&
+ (!msg->u.watch.handle->will_handle ||
+msg->u.watch.handle->will_handle(
+msg->u.watch.handle,
+(const char **)msg->u.watch.vec,
+msg->u.watch.vec_size))) {
spin_lock(_events_lock);
list_add_tail(>list, _events);
wake_up(_events_waitq);
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index 32b944b7cebd..11697aa023b5 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -58,6 +58,13 @@ struct xenbus_watch
/* Path being watched. */
const char *node;
+ /*
+* Called just before enqueing new event while a spinlock is held.
+* The event will be discarded if this callback returns false.
+*/
+ bool (*will_handle)(struct xenbus_watch *,
+ const char **vec, unsigned int len);
+
/* Callback (executed in a process context with no locks held). */
void (*callback)(struct xenbus_watch *,
const char **vec, unsigned int len);
--
2.17.1
[PATCH v5 7/9] riscv: Add KPROBES_ON_FTRACE supported
From: Guo Ren
This patch adds support for kprobes on ftrace call sites to avoids
much of the overhead with regular kprobes. Try it with simple
steps:
echo 'p:myprobe sys_clone a0=%a0 a1=%a1 stack_val=+4($stack)' > /sys/kernel/de
bug/tracing/kprobe_events
echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
cat /sys/kernel/debug/tracing/trace
tracer: nop
entries-in-buffer/entries-written: 1/1 #P:1
_-=> irqs-off
/ _=> need-resched
| / _---=> hardirq/softirq
|| / _--=> preempt-depth
||| / delay
TASK-PID CPU# TIMESTAMP FUNCTION
| | | | |
sh-92 [000] 369.899962: myprobe: (sys_clone+0x0/0x28)
a0=0x1200011 a1=0x0 stack_val=0x201c20ffe0
cat /sys/kernel/debug/kprobes/list
ffe00020b584 k sys_clone+0x0[FTRACE]
^^
Signed-off-by: Guo Ren
Reviewed-by: Masami Hiramatsu
Cc: Palmer Dabbelt
Cc: Paul Walmsley
Cc: Björn Töpel
Cc: Zong Li
Cc: Pekka Enberg
---
arch/riscv/Kconfig| 1 +
arch/riscv/kernel/probes/Makefile | 1 +
arch/riscv/kernel/probes/ftrace.c | 53 +++
3 files changed, 55 insertions(+)
create mode 100644 arch/riscv/kernel/probes/ftrace.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 9a920ed..f58b234 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -69,6 +69,7 @@ config RISCV
select HAVE_GCC_PLUGINS
select HAVE_GENERIC_VDSO if MMU && 64BIT
select HAVE_KPROBES
+ select HAVE_KPROBES_ON_FTRACE
select HAVE_KRETPROBES
select HAVE_PCI
select HAVE_PERF_EVENTS
diff --git a/arch/riscv/kernel/probes/Makefile
b/arch/riscv/kernel/probes/Makefile
index 8a39507..abbd131 100644
--- a/arch/riscv/kernel/probes/Makefile
+++ b/arch/riscv/kernel/probes/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o simulate-insn.o
obj-$(CONFIG_KPROBES) += kprobes_trampoline.o
+obj-$(CONFIG_KPROBES_ON_FTRACE)+= ftrace.o
CFLAGS_REMOVE_simulate-insn.o = $(CC_FLAGS_FTRACE)
diff --git a/arch/riscv/kernel/probes/ftrace.c
b/arch/riscv/kernel/probes/ftrace.c
new file mode 100644
index ..c7ccfff
--- /dev/null
+++ b/arch/riscv/kernel/probes/ftrace.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+
+/* Ftrace callback handler for kprobes -- called under preepmt disabed */
+void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
+ struct ftrace_ops *ops, struct pt_regs *regs)
+{
+ struct kprobe *p;
+ struct kprobe_ctlblk *kcb;
+
+ p = get_kprobe((kprobe_opcode_t *)ip);
+ if (unlikely(!p) || kprobe_disabled(p))
+ return;
+
+ kcb = get_kprobe_ctlblk();
+ if (kprobe_running()) {
+ kprobes_inc_nmissed_count(p);
+ } else {
+ unsigned long orig_ip = instruction_pointer(regs);
+
+ instruction_pointer_set(regs, ip);
+
+ __this_cpu_write(current_kprobe, p);
+ kcb->kprobe_status = KPROBE_HIT_ACTIVE;
+ if (!p->pre_handler || !p->pre_handler(p, regs)) {
+ /*
+* Emulate singlestep (and also recover regs->pc)
+* as if there is a nop
+*/
+ instruction_pointer_set(regs,
+ (unsigned long)p->addr + MCOUNT_INSN_SIZE);
+ if (unlikely(p->post_handler)) {
+ kcb->kprobe_status = KPROBE_HIT_SSDONE;
+ p->post_handler(p, regs, 0);
+ }
+ instruction_pointer_set(regs, orig_ip);
+ }
+
+ /*
+* If pre_handler returns !0, it changes regs->pc. We have to
+* skip emulating post_handler.
+*/
+ __this_cpu_write(current_kprobe, NULL);
+ }
+}
+NOKPROBE_SYMBOL(kprobe_ftrace_handler);
+
+int arch_prepare_kprobe_ftrace(struct kprobe *p)
+{
+ p->ainsn.api.insn = NULL;
+ return 0;
+}
--
2.7.4
Re: [RFC 0/4] vfio-pci/zdev: Fixing s390 vfio-pci ISM support
On 12/17/20 7:59 AM, Cornelia Huck wrote: On Fri, 11 Dec 2020 10:04:43 -0500 Matthew Rosato wrote: On 12/11/20 10:01 AM, Matthew Rosato wrote: On 12/11/20 9:35 AM, Cornelia Huck wrote: Let me summarize this to make sure I understand this new region correctly: - some devices may have relaxed alignment/length requirements for pcistb (and friends?) The relaxed alignment bit is really specific to PCISTB behavior, so the "and friends" doesn't apply there. Ok. - some devices may actually require writes to be done in a large chunk instead of being broken up (is that a strict subset of the devices above?) Yes, this is specific to ISM devices, which are always a relaxed alignment/length device. The inverse is an interesting question though (relaxed alignment devices that are not ISM, which you've posed as a possible future extension for emulated devices). I'm not sure that any (real devices) exist where (relaxed_alignment && !ism), but 'what if' -- I guess the right approach would mean additional code in QEMU to handle relaxed alignment for the vfio mmio path as well (seen as pcistb_default in my qemu patchset) and being very specific in QEMU to only enable the region for an ism device. Let me be more precise there... It would be additional code to handle relaxed alignment for the default pcistb path (pcistb_default) which would include BOTH emulated devices (should we ever surface the relaxed alignment CLP bit and the guest kernel honor it) as well as any s390x vfio-pci device that doesn't use this new I/O region described here. Understood. Not sure if it is useful, but the important part is that we could extend it if we wanted. - some devices do not support the new MIO instructions (is that a subset of the relaxed alignment devices? I'm not familiar with the MIO instructions) The non-MIO requirement is again specific to ISM, which is a subset of the relaxed alignment devices. In this case, the requirement is not limited to PCISTB, and that's why PCILG is also included here. The ISM driver does not use PCISTG, and the only PCISTG instructions coming from the guest against an ISM device would be against the config space and those are OK to go through vfio still; so what was provided via the region is effectively the bare-minimum requirement to allow ISM to function properly in the guest. The patchsets introduce a new region that (a) is used by QEMU to submit writes in one go, and (b) makes sure to call into the non-MIO instructions directly; it's basically killing two birds with one stone for ISM devices. Are these two requirements (large writes and non-MIO) always going hand-in-hand, or is ISM just an odd device? I would say that ISM is definitely a special-case device, even just looking at the way it's implemented in the base kernel (interacting directly with the s390 kernel PCI layer in order to avoid use of MIO instructions -- no other driver does this). But that said, having the two requirements hand-in-hand I think is not bad, though -- This approach ensures the specific instruction the guest wanted (or in this case, needed) is actually executed on the underlying host. The basic question I have is whether it makes sense to specialcase the ISM device (can we even find out that we're dealing with an ISM device here?) to force the non-MIO instructions, as it is just a device with Yes, with the addition of the CLP data passed from the host via vfio capabilities, we can tell this is an ISM device specifically via the 'pft' field in VFOI_DEVICE_INFO_CAP_ZPCI_BASE. We don't actually surface that field to the guest itself in the Q PCI FN clp rsponse (has to do with Function Measurement Block requirements) but we can certainly use that information in QEMU to restrict this behavior to only ISM devices. some special requirements, or tie non-MIO to relaxed alignment. (Could relaxed alignment devices in theory be served by MIO instructions as well?) In practice, I think there are none today, but per the architecture it IS possible to have relaxed alignment devices served by MIO instructions, so we shouldn't rely on that bit alone as I'm doing in this RFC. I think instead relying on the pft value as I mention above is what we have to do. Another thing that came to my mind is whether we consider the guest to be using a pci device and needing weird instructions to do that because it's on s390, or whether it is issuing instructions for a device that happens to be a pci device (sorry if that sounds a bit meta :) Typically, I'd classify things as the former but I think ISM seems more like the latter -- To me, ISM seems like less a classic PCI device and more a device that happens to be using s390 PCI interfaces to accomplish its goal. But it's probably more of a case of this particular device (and it's driver) are s390-specific and therefore built with the unique s390 interface in-mind (and in fact invokes it directly
[PATCH v3 4/5] xen/xenbus: Count pending messages for each watch
From: SeongJae Park
This commit adds a counter of pending messages for each watch in the
struct. It is used to skip unnecessary pending messages lookup in
'unregister_xenbus_watch()'. It could also be used in 'will_handle'
callback.
This is part of XSA-349
This is upstream commit 3dc86ca6b4c8cfcba9da7996189d1b5a358a94fc
Cc: sta...@vger.kernel.org
Signed-off-by: SeongJae Park
Reported-by: Michael Kurth
Reported-by: Pawel Wieczorkiewicz
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
---
drivers/xen/xenbus/xenbus_xs.c | 31 +++
include/xen/xenbus.h | 2 ++
2 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 0ea1c259f2f1..d98d88fae58a 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -701,6 +701,8 @@ int register_xenbus_watch(struct xenbus_watch *watch)
sprintf(token, "%lX", (long)watch);
+ watch->nr_pending = 0;
+
down_read(_state.watch_mutex);
spin_lock(_lock);
@@ -750,12 +752,15 @@ void unregister_xenbus_watch(struct xenbus_watch *watch)
/* Cancel pending watch events. */
spin_lock(_events_lock);
- list_for_each_entry_safe(msg, tmp, _events, list) {
- if (msg->u.watch.handle != watch)
- continue;
- list_del(>list);
- kfree(msg->u.watch.vec);
- kfree(msg);
+ if (watch->nr_pending) {
+ list_for_each_entry_safe(msg, tmp, _events, list) {
+ if (msg->u.watch.handle != watch)
+ continue;
+ list_del(>list);
+ kfree(msg->u.watch.vec);
+ kfree(msg);
+ }
+ watch->nr_pending = 0;
}
spin_unlock(_events_lock);
@@ -802,7 +807,6 @@ void xs_suspend_cancel(void)
static int xenwatch_thread(void *unused)
{
- struct list_head *ent;
struct xs_stored_msg *msg;
for (;;) {
@@ -815,13 +819,15 @@ static int xenwatch_thread(void *unused)
mutex_lock(_mutex);
spin_lock(_events_lock);
- ent = watch_events.next;
- if (ent != _events)
- list_del(ent);
+ msg = list_first_entry_or_null(_events,
+ struct xs_stored_msg, list);
+ if (msg) {
+ list_del(>list);
+ msg->u.watch.handle->nr_pending--;
+ }
spin_unlock(_events_lock);
- if (ent != _events) {
- msg = list_entry(ent, struct xs_stored_msg, list);
+ if (msg) {
msg->u.watch.handle->callback(
msg->u.watch.handle,
(const char **)msg->u.watch.vec,
@@ -911,6 +917,7 @@ static int process_msg(void)
msg->u.watch.vec_size))) {
spin_lock(_events_lock);
list_add_tail(>list, _events);
+ msg->u.watch.handle->nr_pending++;
wake_up(_events_waitq);
spin_unlock(_events_lock);
} else {
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index 1772507dc2c9..ed9e7e3307b7 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -58,6 +58,8 @@ struct xenbus_watch
/* Path being watched. */
const char *node;
+ unsigned int nr_pending;
+
/*
* Called just before enqueing new event while a spinlock is held.
* The event will be discarded if this callback returns false.
--
2.17.1
[PATCH v5 8/9] riscv: Add uprobes supported
From: Guo Ren
This patch adds support for uprobes on riscv architecture.
Just like kprobe, it support single-step and simulate instructions.
Signed-off-by: Guo Ren
Reviewed-by: Pekka Enberg
Cc: Oleg Nesterov
Cc: Masami Hiramatsu
Cc: Palmer Dabbelt
---
arch/riscv/Kconfig | 3 +
arch/riscv/include/asm/processor.h | 1 +
arch/riscv/include/asm/thread_info.h | 4 +-
arch/riscv/include/asm/uprobes.h | 40
arch/riscv/kernel/probes/Makefile| 1 +
arch/riscv/kernel/probes/uprobes.c | 186 +++
arch/riscv/kernel/signal.c | 3 +
arch/riscv/kernel/traps.c| 10 ++
arch/riscv/mm/fault.c| 6 ++
9 files changed, 253 insertions(+), 1 deletion(-)
create mode 100644 arch/riscv/include/asm/uprobes.h
create mode 100644 arch/riscv/kernel/probes/uprobes.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index f58b234..af0ec36 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -160,6 +160,9 @@ config ARCH_WANT_GENERAL_HUGETLB
config ARCH_SUPPORTS_DEBUG_PAGEALLOC
def_bool y
+config ARCH_SUPPORTS_UPROBES
+ def_bool y
+
config SYS_SUPPORTS_HUGETLBFS
depends on MMU
def_bool y
diff --git a/arch/riscv/include/asm/processor.h
b/arch/riscv/include/asm/processor.h
index bdddcd5..3a24003 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -34,6 +34,7 @@ struct thread_struct {
unsigned long sp; /* Kernel mode stack */
unsigned long s[12];/* s[0]: frame pointer */
struct __riscv_d_ext_state fstate;
+ unsigned long bad_cause;
};
#define INIT_THREAD { \
diff --git a/arch/riscv/include/asm/thread_info.h
b/arch/riscv/include/asm/thread_info.h
index a390711..bdb5928 100644
--- a/arch/riscv/include/asm/thread_info.h
+++ b/arch/riscv/include/asm/thread_info.h
@@ -74,6 +74,7 @@ struct thread_info {
#define TIF_SYSCALL_TRACEPOINT 6 /* syscall tracepoint instrumentation
*/
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing */
#define TIF_SECCOMP8 /* syscall secure computing */
+#define TIF_UPROBE 9 /* uprobe breakpoint or singlestep */
#define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
#define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
@@ -82,9 +83,10 @@ struct thread_info {
#define _TIF_SYSCALL_TRACEPOINT(1 << TIF_SYSCALL_TRACEPOINT)
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
+#define _TIF_UPROBE(1 << TIF_UPROBE)
#define _TIF_WORK_MASK \
- (_TIF_NOTIFY_RESUME | _TIF_SIGPENDING | _TIF_NEED_RESCHED)
+ (_TIF_NOTIFY_RESUME | _TIF_SIGPENDING | _TIF_NEED_RESCHED | _TIF_UPROBE)
#define _TIF_SYSCALL_WORK \
(_TIF_SYSCALL_TRACE | _TIF_SYSCALL_TRACEPOINT | _TIF_SYSCALL_AUDIT | \
diff --git a/arch/riscv/include/asm/uprobes.h b/arch/riscv/include/asm/uprobes.h
new file mode 100644
index ..f2183e0
--- /dev/null
+++ b/arch/riscv/include/asm/uprobes.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_RISCV_UPROBES_H
+#define _ASM_RISCV_UPROBES_H
+
+#include
+#include
+#include
+
+#define MAX_UINSN_BYTES8
+
+#ifdef CONFIG_RISCV_ISA_C
+#define UPROBE_SWBP_INSN __BUG_INSN_16
+#define UPROBE_SWBP_INSN_SIZE 2
+#else
+#define UPROBE_SWBP_INSN __BUG_INSN_32
+#define UPROBE_SWBP_INSN_SIZE 4
+#endif
+#define UPROBE_XOL_SLOT_BYTES MAX_UINSN_BYTES
+
+typedef u32 uprobe_opcode_t;
+
+struct arch_uprobe_task {
+ unsigned long saved_cause;
+};
+
+struct arch_uprobe {
+ union {
+ u8 insn[MAX_UINSN_BYTES];
+ u8 ixol[MAX_UINSN_BYTES];
+ };
+ struct arch_probe_insn api;
+ unsigned long insn_size;
+ bool simulate;
+};
+
+bool uprobe_breakpoint_handler(struct pt_regs *regs);
+bool uprobe_single_step_handler(struct pt_regs *regs);
+
+#endif /* _ASM_RISCV_UPROBES_H */
diff --git a/arch/riscv/kernel/probes/Makefile
b/arch/riscv/kernel/probes/Makefile
index abbd131..7f0840d 100644
--- a/arch/riscv/kernel/probes/Makefile
+++ b/arch/riscv/kernel/probes/Makefile
@@ -2,4 +2,5 @@
obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o simulate-insn.o
obj-$(CONFIG_KPROBES) += kprobes_trampoline.o
obj-$(CONFIG_KPROBES_ON_FTRACE)+= ftrace.o
+obj-$(CONFIG_UPROBES) += uprobes.o decode-insn.o simulate-insn.o
CFLAGS_REMOVE_simulate-insn.o = $(CC_FLAGS_FTRACE)
diff --git a/arch/riscv/kernel/probes/uprobes.c
b/arch/riscv/kernel/probes/uprobes.c
new file mode 100644
index ..7a057b5
--- /dev/null
+++ b/arch/riscv/kernel/probes/uprobes.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include
+#include
+#include
+
+#include "decode-insn.h"
+
+#define UPROBE_TRAP_NR UINT_MAX
+
+bool is_swbp_insn(uprobe_opcode_t *insn)
+{
+#ifdef
[PATCH v3 3/5] xen/xenbus/xen_bus_type: Support will_handle watch callback
From: SeongJae Park
This commit adds support of the 'will_handle' watch callback for
'xen_bus_type' users.
This is part of XSA-349
This is upstream commit be987200fbaceaef340872841d4f7af2c5ee8dc3
Cc: sta...@vger.kernel.org
Signed-off-by: SeongJae Park
Reported-by: Michael Kurth
Reported-by: Pawel Wieczorkiewicz
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
---
drivers/xen/xenbus/xenbus_probe.c | 3 ++-
drivers/xen/xenbus/xenbus_probe.h | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
index c560c1b8489a..ba7590d75985 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -137,7 +137,8 @@ static int watch_otherend(struct xenbus_device *dev)
container_of(dev->dev.bus, struct xen_bus_type, bus);
return xenbus_watch_pathfmt(dev, >otherend_watch,
- NULL, bus->otherend_changed,
+ bus->otherend_will_handle,
+ bus->otherend_changed,
"%s/%s", dev->otherend, "state");
}
diff --git a/drivers/xen/xenbus/xenbus_probe.h
b/drivers/xen/xenbus/xenbus_probe.h
index c9ec7ca1f7ab..2c394c6ba605 100644
--- a/drivers/xen/xenbus/xenbus_probe.h
+++ b/drivers/xen/xenbus/xenbus_probe.h
@@ -42,6 +42,8 @@ struct xen_bus_type {
int (*get_bus_id)(char bus_id[XEN_BUS_ID_SIZE], const char *nodename);
int (*probe)(struct xen_bus_type *bus, const char *type,
const char *dir);
+ bool (*otherend_will_handle)(struct xenbus_watch *watch,
+const char **vec, unsigned int len);
void (*otherend_changed)(struct xenbus_watch *watch, const char **vec,
unsigned int len);
struct bus_type bus;
--
2.17.1
[PATCH v5 9/9] riscv: Add support for function error injection
From: Guo Ren
Inspired by the commit 42d038c4fb00 ("arm64: Add support for function
error injection"), this patch supports function error injection for
riscv.
This patch mainly support two functions: one is regs_set_return_value()
which is used to overwrite the return value; the another function is
override_function_with_return() which is to override the probed
function returning and jump to its caller.
Test log:
cd /sys/kernel/debug/fail_function
echo sys_clone > inject
echo 100 > probability
echo 1 > interval
ls /
[ 313.176875] FAULT_INJECTION: forcing a failure.
[ 313.176875] name fail_function, interval 1, probability 100, space 0, times 1
[ 313.184357] CPU: 0 PID: 87 Comm: sh Not tainted 5.8.0-rc5-7-g6a758cc #117
[ 313.187616] Call Trace:
[ 313.189100] [] walk_stackframe+0x0/0xc2
[ 313.191626] [] show_stack+0x40/0x4c
[ 313.193927] [] dump_stack+0x7c/0x96
[ 313.194795] [] should_fail+0x140/0x142
[ 313.195923] [] fei_kprobe_handler+0x2c/0x5a
[ 313.197687] [] kprobe_breakpoint_handler+0xb4/0x18a
[ 313.200054] [] do_trap_break+0x36/0xca
[ 313.202147] [] ret_from_exception+0x0/0xc
[ 313.204556] [] ret_from_syscall+0x0/0x2
-sh: can't fork: Invalid argument
Signed-off-by: Guo Ren
Reviewed-by: Masami Hiramatsu
Cc: Palmer Dabbelt
Cc: Paul Walmsley
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/ptrace.h | 6 ++
arch/riscv/lib/Makefile | 2 ++
arch/riscv/lib/error-inject.c | 10 ++
4 files changed, 19 insertions(+)
create mode 100644 arch/riscv/lib/error-inject.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index af0ec36..a627ae2 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -67,6 +67,7 @@ config RISCV
select HAVE_EBPF_JIT if MMU
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_GCC_PLUGINS
+ select HAVE_FUNCTION_ERROR_INJECTION
select HAVE_GENERIC_VDSO if MMU && 64BIT
select HAVE_KPROBES
select HAVE_KPROBES_ON_FTRACE
diff --git a/arch/riscv/include/asm/ptrace.h b/arch/riscv/include/asm/ptrace.h
index 23372bb..cb4abb6 100644
--- a/arch/riscv/include/asm/ptrace.h
+++ b/arch/riscv/include/asm/ptrace.h
@@ -109,6 +109,12 @@ static inline unsigned long regs_return_value(struct
pt_regs *regs)
return regs->a0;
}
+static inline void regs_set_return_value(struct pt_regs *regs,
+unsigned long val)
+{
+ regs->a0 = val;
+}
+
extern int regs_query_register_offset(const char *name);
extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
unsigned int n);
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 47e7a82..699ed20 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -4,3 +4,5 @@ lib-y += memcpy.o
lib-y += memset.o
lib-$(CONFIG_MMU) += uaccess.o
lib-$(CONFIG_64BIT)+= tishift.o
+
+obj-$(CONFIG_FUNCTION_ERROR_INJECTION) += error-inject.o
diff --git a/arch/riscv/lib/error-inject.c b/arch/riscv/lib/error-inject.c
new file mode 100644
index ..d667ade
--- /dev/null
+++ b/arch/riscv/lib/error-inject.c
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+
+void override_function_with_return(struct pt_regs *regs)
+{
+ instruction_pointer_set(regs, regs->ra);
+}
+NOKPROBE_SYMBOL(override_function_with_return);
--
2.7.4
[PATCH v3 5/5] xenbus/xenbus_backend: Disallow pending watch messages
From: SeongJae Park
'xenbus_backend' watches 'state' of devices, which is writable by
guests. Hence, if guests intensively updates it, dom0 will have lots of
pending events that exhausting memory of dom0. In other words, guests
can trigger dom0 memory pressure. This is known as XSA-349. However,
the watch callback of it, 'frontend_changed()', reads only 'state', so
doesn't need to have the pending events.
To avoid the problem, this commit disallows pending watch messages for
'xenbus_backend' using the 'will_handle()' watch callback.
This is part of XSA-349
This is upstream commit 9996bd494794a2fe393e97e7a982388c6249aa76
Cc: sta...@vger.kernel.org
Signed-off-by: SeongJae Park
Reported-by: Michael Kurth
Reported-by: Pawel Wieczorkiewicz
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
---
drivers/xen/xenbus/xenbus_probe_backend.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/xen/xenbus/xenbus_probe_backend.c
b/drivers/xen/xenbus/xenbus_probe_backend.c
index 04f7f85a5edf..597c0b038454 100644
--- a/drivers/xen/xenbus/xenbus_probe_backend.c
+++ b/drivers/xen/xenbus/xenbus_probe_backend.c
@@ -181,6 +181,12 @@ static int xenbus_probe_backend(struct xen_bus_type *bus,
const char *type,
return err;
}
+static bool frontend_will_handle(struct xenbus_watch *watch,
+const char **vec, unsigned int len)
+{
+ return watch->nr_pending == 0;
+}
+
static void frontend_changed(struct xenbus_watch *watch,
const char **vec, unsigned int len)
{
@@ -192,6 +198,7 @@ static struct xen_bus_type xenbus_backend = {
.levels = 3,/* backend/type// */
.get_bus_id = backend_bus_id,
.probe = xenbus_probe_backend,
+ .otherend_will_handle = frontend_will_handle,
.otherend_changed = frontend_changed,
.bus = {
.name = "xen-backend",
--
2.17.1
[PATCH net-next] net: mvpp2: prs: improve ipv4 parse flow
From: Stefan Chulski Patch didn't fix any issue, just improve parse flow and align ipv4 parse flow with ipv6 parse flow. Currently ipv4 kenguru parser first check IP protocol(TCP/UDP) and then destination IP address. Patch introduce reverse ipv4 parse, first destination IP address parsed and only then IP protocol. This would allow extend capability for packet L4 parsing and align ipv4 parsing flow with ipv6. Suggested-by: Liron Himi Signed-off-by: Stefan Chulski --- drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c | 64 -- 1 file changed, 39 insertions(+), 25 deletions(-) diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c index 5692c60..b9e5b08 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c @@ -882,15 +882,15 @@ static int mvpp2_prs_ip4_proto(struct mvpp2 *priv, unsigned short proto, mvpp2_prs_tcam_lu_set(, MVPP2_PRS_LU_IP4); pe.index = tid; - /* Set next lu to IPv4 */ - mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_IP4); - mvpp2_prs_sram_shift_set(, 12, MVPP2_PRS_SRAM_OP_SEL_SHIFT_ADD); + /* Finished: go to flowid generation */ + mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_FLOWS); + mvpp2_prs_sram_bits_set(, MVPP2_PRS_SRAM_LU_GEN_BIT, 1); + /* Set L4 offset */ mvpp2_prs_sram_offset_set(, MVPP2_PRS_SRAM_UDF_TYPE_L4, sizeof(struct iphdr) - 4, MVPP2_PRS_SRAM_OP_SEL_UDF_ADD); - mvpp2_prs_sram_ai_update(, MVPP2_PRS_IPV4_DIP_AI_BIT, -MVPP2_PRS_IPV4_DIP_AI_BIT); + mvpp2_prs_sram_ai_update(, 0, MVPP2_PRS_IPV4_DIP_AI_BIT); mvpp2_prs_sram_ri_update(, ri, ri_mask | MVPP2_PRS_RI_IP_FRAG_MASK); mvpp2_prs_tcam_data_byte_set(, 2, 0x00, @@ -899,7 +899,8 @@ static int mvpp2_prs_ip4_proto(struct mvpp2 *priv, unsigned short proto, MVPP2_PRS_TCAM_PROTO_MASK); mvpp2_prs_tcam_data_byte_set(, 5, proto, MVPP2_PRS_TCAM_PROTO_MASK); - mvpp2_prs_tcam_ai_update(, 0, MVPP2_PRS_IPV4_DIP_AI_BIT); + mvpp2_prs_tcam_ai_update(, MVPP2_PRS_IPV4_DIP_AI_BIT, +MVPP2_PRS_IPV4_DIP_AI_BIT); /* Unmask all ports */ mvpp2_prs_tcam_port_map_set(, MVPP2_PRS_PORT_MASK); @@ -967,12 +968,17 @@ static int mvpp2_prs_ip4_cast(struct mvpp2 *priv, unsigned short l3_cast) return -EINVAL; } - /* Finished: go to flowid generation */ - mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_FLOWS); - mvpp2_prs_sram_bits_set(, MVPP2_PRS_SRAM_LU_GEN_BIT, 1); + /* Go again to ipv4 */ + mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_IP4); - mvpp2_prs_tcam_ai_update(, MVPP2_PRS_IPV4_DIP_AI_BIT, + mvpp2_prs_sram_ai_update(, MVPP2_PRS_IPV4_DIP_AI_BIT, MVPP2_PRS_IPV4_DIP_AI_BIT); + + /* Shift back to IPv4 proto */ + mvpp2_prs_sram_shift_set(, -12, MVPP2_PRS_SRAM_OP_SEL_SHIFT_ADD); + + mvpp2_prs_tcam_ai_update(, 0, MVPP2_PRS_IPV4_DIP_AI_BIT); + /* Unmask all ports */ mvpp2_prs_tcam_port_map_set(, MVPP2_PRS_PORT_MASK); @@ -1392,8 +1398,9 @@ static int mvpp2_prs_etype_init(struct mvpp2 *priv) mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_IP4); mvpp2_prs_sram_ri_update(, MVPP2_PRS_RI_L3_IP4, MVPP2_PRS_RI_L3_PROTO_MASK); - /* Skip eth_type + 4 bytes of IP header */ - mvpp2_prs_sram_shift_set(, MVPP2_ETH_TYPE_LEN + 4, + /* goto ipv4 dest-address (skip eth_type + IP-header-size - 4) */ + mvpp2_prs_sram_shift_set(, MVPP2_ETH_TYPE_LEN + +sizeof(struct iphdr) - 4, MVPP2_PRS_SRAM_OP_SEL_SHIFT_ADD); /* Set L3 offset */ mvpp2_prs_sram_offset_set(, MVPP2_PRS_SRAM_UDF_TYPE_L3, @@ -1597,8 +1604,9 @@ static int mvpp2_prs_pppoe_init(struct mvpp2 *priv) mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_IP4); mvpp2_prs_sram_ri_update(, MVPP2_PRS_RI_L3_IP4_OPT, MVPP2_PRS_RI_L3_PROTO_MASK); - /* Skip eth_type + 4 bytes of IP header */ - mvpp2_prs_sram_shift_set(, MVPP2_ETH_TYPE_LEN + 4, + /* goto ipv4 dest-address (skip eth_type + IP-header-size - 4) */ + mvpp2_prs_sram_shift_set(, MVPP2_ETH_TYPE_LEN + +sizeof(struct iphdr) - 4, MVPP2_PRS_SRAM_OP_SEL_SHIFT_ADD); /* Set L3 offset */ mvpp2_prs_sram_offset_set(, MVPP2_PRS_SRAM_UDF_TYPE_L3, @@ -1727,19 +1735,20 @@ static int mvpp2_prs_ip4_init(struct mvpp2 *priv) mvpp2_prs_tcam_lu_set(, MVPP2_PRS_LU_IP4); pe.index = MVPP2_PE_IP4_PROTO_UN; - /* Set next lu to IPv4 */ - mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_IP4); - mvpp2_prs_sram_shift_set(, 12,
Re: [PATCH] remoteproc: Create a separate workqueue for recovery tasks
On 12/15/20 4:55 PM, Bjorn Andersson wrote:
On Sat 12 Dec 14:48 CST 2020, Rishabh Bhatnagar wrote:
Create an unbound high priority workqueue for recovery tasks.
I have been looking at a different issue that is caused by
crash notification.
What happened was that the modem crashed while the AP was
in system suspend (or possibly even resuming) state. And
there is no guarantee that the system will have called a
driver's ->resume callback when the crash notification is
delivered.
In my case (in the IPA driver), handling a modem crash
cannot be done while the driver is suspended; i.e. the
activities in its ->resume callback must be completed
before we can recover from the crash.
For this reason I might like to change the way the
crash notification is handled, but what I'd rather see
is to have the work queue not run until user space
is unfrozen, which would guarantee that all drivers
that have registered for a crash notification will
be resumed when the notification arrives.
I'm not sure how that interacts with what you are
looking for here. I think the workqueue could still
be unbound, but its work would be delayed longer before
any notification (and recovery) started.
-Alex
This simply repeats $subject
Recovery time is an important parameter for a subsystem and there
might be situations where multiple subsystems crash around the same
time. Scheduling into an unbound workqueue increases parallelization
and avoids time impact.
You should be able to write this more succinctly. The important part is
that you want an unbound work queue to allow recovery to happen in
parallel - which naturally implies that you care about recovery latency.
Also creating a high priority workqueue
will utilize separate worker threads with higher nice values than
normal ones.
This doesn't describe why you need the higher priority.
I believe, and certainly with the in-line coredump, that we're running
our recovery work for way too long to be queued on the system_wq. As
such the content of the patch looks good!
Regards,
Bjorn
Signed-off-by: Rishabh Bhatnagar
---
drivers/remoteproc/remoteproc_core.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 46c2937..8fd8166 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -48,6 +48,8 @@ static DEFINE_MUTEX(rproc_list_mutex);
static LIST_HEAD(rproc_list);
static struct notifier_block rproc_panic_nb;
+static struct workqueue_struct *rproc_wq;
+
typedef int (*rproc_handle_resource_t)(struct rproc *rproc,
void *, int offset, int avail);
@@ -2475,7 +2477,7 @@ void rproc_report_crash(struct rproc *rproc, enum rproc_crash_type type)
rproc->name, rproc_crash_to_string(type));
/* create a new task to handle the error */
- schedule_work(>crash_handler);
+ queue_work(rproc_wq, >crash_handler);
}
EXPORT_SYMBOL(rproc_report_crash);
@@ -2520,6 +2522,10 @@ static void __exit rproc_exit_panic(void)
static int __init remoteproc_init(void)
{
+ rproc_wq = alloc_workqueue("rproc_wq", WQ_UNBOUND | WQ_HIGHPRI, 0);
+ if (!rproc_wq)
+ return -ENOMEM;
+
rproc_init_sysfs();
rproc_init_debugfs();
rproc_init_cdev();
@@ -2536,6 +2542,7 @@ static void __exit remoteproc_exit(void)
rproc_exit_panic();
rproc_exit_debugfs();
rproc_exit_sysfs();
+ destroy_workqueue(rproc_wq);
}
module_exit(remoteproc_exit);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: keembay-ocs-aes-core.c:undefined reference to `devm_ioremap_resource'
On Thu, 2020-12-17 at 13:23 +0800, kernel test robot wrote: > tree: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: accefff5b547a9a1d959c7e76ad539bf2480e78b > commit: 88574332451380f4b51f6ca88ab9810e714bfb9b crypto: keembay - > Add support for Keem Bay OCS AES/SM4 > date: 6 days ago > config: s390-randconfig-c004-20201217 (attached as .config) > compiler: s390-linux-gcc (GCC) 9.3.0 > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=88574332451380f4b51f6ca88ab9810e714bfb9b > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 88574332451380f4b51f6ca88ab9810e714bfb9b > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 > make.cross ARCH=s390 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >s390-linux-ld: kernel/dma/coherent.o: in function > `dma_init_coherent_memory': >coherent.c:(.text+0x54c): undefined reference to `memremap' >s390-linux-ld: coherent.c:(.text+0x67e): undefined reference to > `memunmap' >s390-linux-ld: kernel/dma/coherent.o: in function > `dma_declare_coherent_memory': >coherent.c:(.text+0x8ee): undefined reference to `memunmap' >s390-linux-ld: drivers/clk/clk-fixed-mmio.o: in function > `fixed_mmio_clk_setup': >clk-fixed-mmio.c:(.text+0x98): undefined reference to `of_iomap' >s390-linux-ld: clk-fixed-mmio.c:(.text+0xe8): undefined reference > to `iounmap' >s390-linux-ld: drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.o: in > function `dw_probe': >dw-axi-dmac-platform.c:(.text+0x20ac): undefined reference to > `devm_ioremap_resource' >s390-linux-ld: drivers/dma/fsl-edma.o: in function > `fsl_edma_probe': >fsl-edma.c:(.text+0x1238): undefined reference to > `devm_ioremap_resource' >s390-linux-ld: fsl-edma.c:(.text+0x1628): undefined reference to > `devm_ioremap_resource' >s390-linux-ld: drivers/dma/sf-pdma/sf-pdma.o: in function > `sf_pdma_probe': >sf-pdma.c:(.text+0x92e): undefined reference to > `devm_ioremap_resource' >s390-linux-ld: drivers/crypto/ccree/cc_driver.o: in function > `init_cc_resources': >cc_driver.c:(.text+0x89e): undefined reference to > `devm_ioremap_resource' >s390-linux-ld: drivers/crypto/ccree/cc_debugfs.o: in function > `cc_debugfs_init': >cc_debugfs.c:(.text+0x108): undefined reference to > `debugfs_create_regset32' >s390-linux-ld: cc_debugfs.c:(.text+0x206): undefined reference to > `debugfs_create_regset32' >s390-linux-ld: drivers/crypto/keembay/keembay-ocs-aes-core.o: in > function `kmb_ocs_aes_probe': > > > keembay-ocs-aes-core.c:(.text+0x1ed2): undefined reference to > > > `devm_ioremap_resource' Looks like this is due to a missing HAS_IOMEM dependency. Herbert, I'll prepare a patch fixing this and I'll send it to you. > > --- > 0-DAY CI Kernel Test Service, Intel Corporation > https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH] f2fs-tools: man page fix for sload compression
From: Robin Hsu Fix man page for sload.f2fs compression support Signed-off-by: Robin Hsu --- man/sload.f2fs.8 | 94 ++-- 1 file changed, 84 insertions(+), 10 deletions(-) diff --git a/man/sload.f2fs.8 b/man/sload.f2fs.8 index d07330c..c165b35 100644 --- a/man/sload.f2fs.8 +++ b/man/sload.f2fs.8 @@ -7,22 +7,48 @@ sload.f2fs \- load directories and files into the device directly .B sload.f2fs [ .B \-f -.I source directory path +.I source-directory-path ] [ .B \-t -.I mount point +.I mount-point ] [ .B \-d .I debugging-level ] +[ +.B \-c +[ +.B \-L +.I log-of-blocks-per-cluster +] +[ +.B \-a +.I compression-algorithm +] +[ +.B \-x +.I file-extension-to-exclude-from-compression +| +.B \-i +.I file-extension-to-include-for-compression +] +[ +.B \-m +.I minimum-compressed-blocks-per-cluster +] +[ +.B \-r +] +] .I device .SH DESCRIPTION .B sload.f2fs -is used to load directories and files into a disk partition. -\fIdevice\fP is the special file corresponding to the device (e.g. -\fI/dev/sdXX\fP). +is used to load directories and files into a disk partition, or an F2FS +image (file). +\fIdevice\fP could a special file corresponding to the device (e.g. +\fI/dev/sdXX\fP), or an F2FS image file. .PP The exit code returned by @@ -30,24 +56,72 @@ The exit code returned by is 0 on success and -1 on failure. .SH OPTIONS .TP -.BI \-f " source directory path" +.BI \-f " source-directory-path" Specify the source directory path to be loaded. .TP -.BI \-t " mount point path" +.BI \-t " mount-point-path" Specify the mount point path in the partition to load. .TP .BI \-d " debug-level" Specify the level of debugging options. The default number is 0, which shows basic debugging messages. .TP +.BI \-c +Enable a cluster-based file compression. +The file would be chopped into clusters, and each cluster is compressed +independently. +.TP +.BI \-L " log-of-blocks-per-cluster +Specify cluster size in power of two blocks. +The minimum value is 2 (4 blocks, default). +The maximum value is 8 (256 blocks). +Note that a block contains 4096 bytes. +This option must be used with option \fB\-c\fR. +.TP +.BI \-a " compression-algorithm" +Choose the algorithm for compression. Available options are: +lzo, lz4 (default). +This option must be used with option \fB\-c\fR. +.TP +.BI \-i " file-extension-to-include-for-compression" +Specify a file extension to include for the compression. +To specify multiple file extensions, use multiple option \fB\-i\fR's. +Files having one of the listed extensions will be compressed. +This option must be used with option \fB\-c\fR. +.TP +.BI \-x " file-extension-to-exclude-from-compression" +Specify a file extension to exclude from compression. +To specify multiple file extensions, use multiple option \fB\-x\fR's. +Files having one of the listed extensions won't be compressed. +This option must be used with option \fB\-c\fR. +.TP +.BI \-m " minimum-compressed-blocks-per-cluster" +Specify a minimum block count saved (by compression) per cluster. +The minimum value is 1 (default). +Maximum value is the cluster size in blocks minus 1. +If compression of a cluster fails to save at least the minimum compressed +block count given by the option, the cluster will not be compressed. +This option must be used with option \fB\-c\fR. +.TP +.BI \-r +Specify read-only flag for the compressed files. +It allows filesystem to release compressed space to the users, since, without +this option, filesystem should keep the space for future file updates. +This option must be used with option \fB\-c\fR. + +.SH NOTES +If neither \fB\-i\fR nor \fB\-x\fR is used, all files will be compressed. +Obviously, option \fB\-i\fR and \fB-x\fR can not be used together. + .SH AUTHOR This version of .B sload.f2fs -has been written by Hou Pengyang , -Liu Shuoran , Jaegeuk Kim +has been contributed by Hou Pengyang , +Liu Shuoran , Jaegeuk Kim , +Robin Hsu .SH AVAILABILITY .B sload.f2fs -is available from git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git. +is available from . .SH SEE ALSO .BR mkfs.f2fs(8), .BR fsck.f2fs(8), -- 2.29.2.684.gfbc64c5ab5-goog
Re: [PATCH 1/3] vfs: add new f_op->syncfs vector
On Thu, Dec 17, 2020 at 10:57:28AM +0100, Jan Kara wrote: > On Thu 17-12-20 00:49:35, Al Viro wrote: > > [Christoph added to Cc...] > > On Wed, Dec 16, 2020 at 06:31:47PM -0500, Vivek Goyal wrote: > > > Current implementation of __sync_filesystem() ignores the return code > > > from ->sync_fs(). I am not sure why that's the case. There must have > > > been some historical reason for this. > > > > > > Ignoring ->sync_fs() return code is problematic for overlayfs where > > > it can return error if sync_filesystem() on upper super block failed. > > > That error will simply be lost and sycnfs(overlay_fd), will get > > > success (despite the fact it failed). > > > > > > If we modify existing implementation, there is a concern that it will > > > lead to user space visible behavior changes and break things. So > > > instead implement a new file_operations->syncfs() call which will > > > be called in syncfs() syscall path. Return code from this new > > > call will be captured. And all the writeback error detection > > > logic can go in there as well. Only filesystems which implement > > > this call get affected by this change. Others continue to fallback > > > to existing mechanism. > > > > That smells like a massive source of confusion down the road. I'd just > > looked through the existing instances; many always return 0, but quite > > a few sometimes try to return an error: > > fs/btrfs/super.c:2412: .sync_fs= btrfs_sync_fs, > > fs/exfat/super.c:204: .sync_fs= exfat_sync_fs, > > fs/ext4/super.c:1674: .sync_fs= ext4_sync_fs, > > fs/f2fs/super.c:2480: .sync_fs= f2fs_sync_fs, > > fs/gfs2/super.c:1600: .sync_fs= gfs2_sync_fs, > > fs/hfsplus/super.c:368: .sync_fs= hfsplus_sync_fs, > > fs/nilfs2/super.c:689: .sync_fs= nilfs_sync_fs, > > fs/ocfs2/super.c:139: .sync_fs= ocfs2_sync_fs, > > fs/overlayfs/super.c:399: .sync_fs= ovl_sync_fs, > > fs/ubifs/super.c:2052: .sync_fs = ubifs_sync_fs, > > is the list of such. There are 4 method callers: > > dquot_quota_sync(), dquot_disable(), __sync_filesystem() and > > sync_fs_one_sb(). For sync_fs_one_sb() we want to ignore the > > return value; for __sync_filesystem() we almost certainly > > do *not* - it ends with return __sync_blockdev(sb->s_bdev, wait), > > after all. The question for that one is whether we want > > __sync_blockdev() called even in case of ->sync_fs() reporting > > a failure, and I suspect that it's safer to call it anyway and > > return the first error value we'd got. No idea about quota > > situation. > > WRT quota situation: All the ->sync_fs() calls there are due to cache > coherency reasons (we need to get quota changes to disk, then prune quota > files's page cache, and then userspace can read current quota structures > from the disk). We don't want to fail dquot_disable() just because caches > might be incoherent so ignoring ->sync_fs() return value there is fine. > With dquot_quota_sync() it might make some sense to return the error - > that's just a backend for Q_SYNC quotactl(2). OTOH I'm not sure anybody > really cares - Q_SYNC is rarely used. Thanks Jan. May be I will leave dquot_quota_sync() untouched for now. When somebody has a need to capture return code from ->sync_fs() there, it can be easily added. Vivek
Re: [PATCH] f2fs-tools: man page fix for sload compression
Applied into the original patch. Thanks~ On 12/18, Robin Hsu wrote: > From: Robin Hsu > > Fix man page for sload.f2fs compression support > > Signed-off-by: Robin Hsu > --- > man/sload.f2fs.8 | 94 ++-- > 1 file changed, 84 insertions(+), 10 deletions(-) > > diff --git a/man/sload.f2fs.8 b/man/sload.f2fs.8 > index d07330c..c165b35 100644 > --- a/man/sload.f2fs.8 > +++ b/man/sload.f2fs.8 > @@ -7,22 +7,48 @@ sload.f2fs \- load directories and files into the device > directly > .B sload.f2fs > [ > .B \-f > -.I source directory path > +.I source-directory-path > ] > [ > .B \-t > -.I mount point > +.I mount-point > ] > [ > .B \-d > .I debugging-level > ] > +[ > +.B \-c > +[ > +.B \-L > +.I log-of-blocks-per-cluster > +] > +[ > +.B \-a > +.I compression-algorithm > +] > +[ > +.B \-x > +.I file-extension-to-exclude-from-compression > +| > +.B \-i > +.I file-extension-to-include-for-compression > +] > +[ > +.B \-m > +.I minimum-compressed-blocks-per-cluster > +] > +[ > +.B \-r > +] > +] > .I device > .SH DESCRIPTION > .B sload.f2fs > -is used to load directories and files into a disk partition. > -\fIdevice\fP is the special file corresponding to the device (e.g. > -\fI/dev/sdXX\fP). > +is used to load directories and files into a disk partition, or an F2FS > +image (file). > +\fIdevice\fP could a special file corresponding to the device (e.g. > +\fI/dev/sdXX\fP), or an F2FS image file. > > .PP > The exit code returned by > @@ -30,24 +56,72 @@ The exit code returned by > is 0 on success and -1 on failure. > .SH OPTIONS > .TP > -.BI \-f " source directory path" > +.BI \-f " source-directory-path" > Specify the source directory path to be loaded. > .TP > -.BI \-t " mount point path" > +.BI \-t " mount-point-path" > Specify the mount point path in the partition to load. > .TP > .BI \-d " debug-level" > Specify the level of debugging options. > The default number is 0, which shows basic debugging messages. > .TP > +.BI \-c > +Enable a cluster-based file compression. > +The file would be chopped into clusters, and each cluster is compressed > +independently. > +.TP > +.BI \-L " log-of-blocks-per-cluster > +Specify cluster size in power of two blocks. > +The minimum value is 2 (4 blocks, default). > +The maximum value is 8 (256 blocks). > +Note that a block contains 4096 bytes. > +This option must be used with option \fB\-c\fR. > +.TP > +.BI \-a " compression-algorithm" > +Choose the algorithm for compression. Available options are: > +lzo, lz4 (default). > +This option must be used with option \fB\-c\fR. > +.TP > +.BI \-i " file-extension-to-include-for-compression" > +Specify a file extension to include for the compression. > +To specify multiple file extensions, use multiple option \fB\-i\fR's. > +Files having one of the listed extensions will be compressed. > +This option must be used with option \fB\-c\fR. > +.TP > +.BI \-x " file-extension-to-exclude-from-compression" > +Specify a file extension to exclude from compression. > +To specify multiple file extensions, use multiple option \fB\-x\fR's. > +Files having one of the listed extensions won't be compressed. > +This option must be used with option \fB\-c\fR. > +.TP > +.BI \-m " minimum-compressed-blocks-per-cluster" > +Specify a minimum block count saved (by compression) per cluster. > +The minimum value is 1 (default). > +Maximum value is the cluster size in blocks minus 1. > +If compression of a cluster fails to save at least the minimum compressed > +block count given by the option, the cluster will not be compressed. > +This option must be used with option \fB\-c\fR. > +.TP > +.BI \-r > +Specify read-only flag for the compressed files. > +It allows filesystem to release compressed space to the users, since, without > +this option, filesystem should keep the space for future file updates. > +This option must be used with option \fB\-c\fR. > + > +.SH NOTES > +If neither \fB\-i\fR nor \fB\-x\fR is used, all files will be compressed. > +Obviously, option \fB\-i\fR and \fB-x\fR can not be used together. > + > .SH AUTHOR > This version of > .B sload.f2fs > -has been written by Hou Pengyang , > -Liu Shuoran , Jaegeuk Kim > +has been contributed by Hou Pengyang , > +Liu Shuoran , Jaegeuk Kim , > +Robin Hsu > .SH AVAILABILITY > .B sload.f2fs > -is available from > git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git. > +is available from > . > .SH SEE ALSO > .BR mkfs.f2fs(8), > .BR fsck.f2fs(8), > -- > 2.29.2.684.gfbc64c5ab5-goog
[bisected] Re: drm, qxl: post 5.11 merge warning+explosion
ee5d2a8e549e90325fcc31825269f89647cd6fac is the first bad commit commit ee5d2a8e549e90325fcc31825269f89647cd6fac Author: Christian König Date: Sat Oct 24 13:10:28 2020 +0200 drm/ttm: wire up the new pool as default one v2 Provide the necessary parameters by all drivers and use the new pool alloc when no driver specific function is provided. v2: fix the GEM VRAM helpers Signed-off-by: Christian König Reviewed-by: Dave Airlie Reviewed-by: Madhav Chauhan Tested-by: Huang Rui Link: https://patchwork.freedesktop.org/patch/397081/?series=83051=1 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++-- drivers/gpu/drm/drm_gem_vram_helper.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_ttm.c | 14 +- drivers/gpu/drm/qxl/qxl_ttm.c | 5 ++--- drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- drivers/gpu/drm/ttm/ttm_bo.c| 8 ++-- drivers/gpu/drm/ttm/ttm_memory.c| 2 +- drivers/gpu/drm/ttm/ttm_tt.c| 5 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 +++-- include/drm/ttm/ttm_bo_driver.h | 11 +++ 10 files changed, 36 insertions(+), 26 deletions(-) git bisect start 'drivers/gpu/drm/qxl' # good: [2c85ebc57b3e1817b6ce1a6b703928e113a90442] Linux 5.10 git bisect good 2c85ebc57b3e1817b6ce1a6b703928e113a90442 # bad: [accefff5b547a9a1d959c7e76ad539bf2480e78b] Merge tag 'arm-soc-omap-genpd-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc git bisect bad accefff5b547a9a1d959c7e76ad539bf2480e78b # bad: [d635a69dd4981cc51f90293f5f64268620ed1565] Merge tag 'net-next-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next git bisect bad d635a69dd4981cc51f90293f5f64268620ed1565 # bad: [0ca2ce81eb8ee30f3ba8ac7967fef9cfbb44dbdb] Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux git bisect bad 0ca2ce81eb8ee30f3ba8ac7967fef9cfbb44dbdb # bad: [f8aab60422c371425365d386dfd51e0c6c5b1041] drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs git bisect bad f8aab60422c371425365d386dfd51e0c6c5b1041 # bad: [c0f98d2f8b076bf3e3183aa547395f919c943a14] Merge tag 'drm-misc-next-2020-11-05' of git://anongit.freedesktop.org/drm/drm-misc into drm-next git bisect bad c0f98d2f8b076bf3e3183aa547395f919c943a14 # good: [6a6e5988a2657cd0c91f6f1a3e7d194599248b6d] drm/ttm: replace last move_notify with delete_mem_notify git bisect good 6a6e5988a2657cd0c91f6f1a3e7d194599248b6d # good: [f566fdcd6cc49a9d5b5d782f56e3e7cb243f01b8] drm/i915: Force VT'd workarounds when running as a guest OS git bisect good f566fdcd6cc49a9d5b5d782f56e3e7cb243f01b8 # good: [e76ab2cf21c38331155ea613cdf18582f011c30f] drm/i915: Remove per-platform IIR HPD masking git bisect good e76ab2cf21c38331155ea613cdf18582f011c30f # bad: [268af50f38b1f2199a2e85e38073d7a25c20190c] drm/panfrost: Support cache-coherent integrations git bisect bad 268af50f38b1f2199a2e85e38073d7a25c20190c # good: [e000650375b65ff77c5ee852b5086f58c741179e] fbdev/atafb: Remove unused extern variables git bisect good e000650375b65ff77c5ee852b5086f58c741179e # bad: [461619f5c3242aaee9ec3f0b7072719bd86ea207] drm/nouveau: switch to new allocator git bisect bad 461619f5c3242aaee9ec3f0b7072719bd86ea207 # good: [d099fc8f540add80f725014fdd4f7f49f3c58911] drm/ttm: new TT backend allocation pool v3 git bisect good d099fc8f540add80f725014fdd4f7f49f3c58911 # bad: [e93b2da9799e5cb97760969f3e1f02a5bdac29fe] drm/amdgpu: switch to new allocator v2 git bisect bad e93b2da9799e5cb97760969f3e1f02a5bdac29fe # bad: [ee5d2a8e549e90325fcc31825269f89647cd6fac] drm/ttm: wire up the new pool as default one v2 git bisect bad ee5d2a8e549e90325fcc31825269f89647cd6fac # first bad commit: [ee5d2a8e549e90325fcc31825269f89647cd6fac] drm/ttm: wire up the new pool as default one v2
Re: [bisected] Re: drm, qxl: post 5.11 merge warning+explosion
Hi Mike, what exactly is the warning from qxl you are seeing? Thanks, Christian. Am 17.12.20 um 17:21 schrieb Mike Galbraith: ee5d2a8e549e90325fcc31825269f89647cd6fac is the first bad commit commit ee5d2a8e549e90325fcc31825269f89647cd6fac Author: Christian König Date: Sat Oct 24 13:10:28 2020 +0200 drm/ttm: wire up the new pool as default one v2 Provide the necessary parameters by all drivers and use the new pool alloc when no driver specific function is provided. v2: fix the GEM VRAM helpers Signed-off-by: Christian König Reviewed-by: Dave Airlie Reviewed-by: Madhav Chauhan Tested-by: Huang Rui Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F397081%2F%3Fseries%3D83051%26rev%3D1data=04%7C01%7Cchristian.koenig%40amd.com%7C5e5b079ebef74f3ef56b08d8a2a7c416%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637438189325014013%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=7dT4qkc4SEBLYDZwl5V4glm9ynvFHwAVdzn3y7eO7Kc%3Dreserved=0 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++-- drivers/gpu/drm/drm_gem_vram_helper.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_ttm.c | 14 +- drivers/gpu/drm/qxl/qxl_ttm.c | 5 ++--- drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- drivers/gpu/drm/ttm/ttm_bo.c| 8 ++-- drivers/gpu/drm/ttm/ttm_memory.c| 2 +- drivers/gpu/drm/ttm/ttm_tt.c| 5 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 +++-- include/drm/ttm/ttm_bo_driver.h | 11 +++ 10 files changed, 36 insertions(+), 26 deletions(-) git bisect start 'drivers/gpu/drm/qxl' # good: [2c85ebc57b3e1817b6ce1a6b703928e113a90442] Linux 5.10 git bisect good 2c85ebc57b3e1817b6ce1a6b703928e113a90442 # bad: [accefff5b547a9a1d959c7e76ad539bf2480e78b] Merge tag 'arm-soc-omap-genpd-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc git bisect bad accefff5b547a9a1d959c7e76ad539bf2480e78b # bad: [d635a69dd4981cc51f90293f5f64268620ed1565] Merge tag 'net-next-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next git bisect bad d635a69dd4981cc51f90293f5f64268620ed1565 # bad: [0ca2ce81eb8ee30f3ba8ac7967fef9cfbb44dbdb] Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux git bisect bad 0ca2ce81eb8ee30f3ba8ac7967fef9cfbb44dbdb # bad: [f8aab60422c371425365d386dfd51e0c6c5b1041] drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs git bisect bad f8aab60422c371425365d386dfd51e0c6c5b1041 # bad: [c0f98d2f8b076bf3e3183aa547395f919c943a14] Merge tag 'drm-misc-next-2020-11-05' of git://anongit.freedesktop.org/drm/drm-misc into drm-next git bisect bad c0f98d2f8b076bf3e3183aa547395f919c943a14 # good: [6a6e5988a2657cd0c91f6f1a3e7d194599248b6d] drm/ttm: replace last move_notify with delete_mem_notify git bisect good 6a6e5988a2657cd0c91f6f1a3e7d194599248b6d # good: [f566fdcd6cc49a9d5b5d782f56e3e7cb243f01b8] drm/i915: Force VT'd workarounds when running as a guest OS git bisect good f566fdcd6cc49a9d5b5d782f56e3e7cb243f01b8 # good: [e76ab2cf21c38331155ea613cdf18582f011c30f] drm/i915: Remove per-platform IIR HPD masking git bisect good e76ab2cf21c38331155ea613cdf18582f011c30f # bad: [268af50f38b1f2199a2e85e38073d7a25c20190c] drm/panfrost: Support cache-coherent integrations git bisect bad 268af50f38b1f2199a2e85e38073d7a25c20190c # good: [e000650375b65ff77c5ee852b5086f58c741179e] fbdev/atafb: Remove unused extern variables git bisect good e000650375b65ff77c5ee852b5086f58c741179e # bad: [461619f5c3242aaee9ec3f0b7072719bd86ea207] drm/nouveau: switch to new allocator git bisect bad 461619f5c3242aaee9ec3f0b7072719bd86ea207 # good: [d099fc8f540add80f725014fdd4f7f49f3c58911] drm/ttm: new TT backend allocation pool v3 git bisect good d099fc8f540add80f725014fdd4f7f49f3c58911 # bad: [e93b2da9799e5cb97760969f3e1f02a5bdac29fe] drm/amdgpu: switch to new allocator v2 git bisect bad e93b2da9799e5cb97760969f3e1f02a5bdac29fe # bad: [ee5d2a8e549e90325fcc31825269f89647cd6fac] drm/ttm: wire up the new pool as default one v2 git bisect bad ee5d2a8e549e90325fcc31825269f89647cd6fac # first bad commit: [ee5d2a8e549e90325fcc31825269f89647cd6fac] drm/ttm: wire up the new pool as default one v2
Re: New objtool warning..
On Thu, Dec 17, 2020 at 11:45:56AM +0100, Peter Zijlstra wrote: > On Wed, Dec 16, 2020 at 02:01:58PM -0600, Josh Poimboeuf wrote: > > So this is kind of tricky, because the unreachable() annotation usually > > means "the previous instruction is a dead end". Most of the time, the > > next instruction -- the one actually pointed to by the annotation -- is > > actually reachable from another path. > > *groan*, this is why I ended up sticking a nop in > instrumentation_begin()/_end(). Oh yeah, I forgot about that. That would be another option if my patch doesn't work out. /me grumbles something about integrating objtool with compiler plugins someday... -- Josh
[PATCH] ASoC: wm8962: Add optional mclk device tree binding
The driver can request an optional clock for mclk.
Update the txt file to reflect this.
Suggested-by: Geert Uytterhoeven
Signed-off-by: Adam Ford
diff --git a/Documentation/devicetree/bindings/sound/wm8962.txt
b/Documentation/devicetree/bindings/sound/wm8962.txt
index dcfa9a3369fd..c36c649ddfd0 100644
--- a/Documentation/devicetree/bindings/sound/wm8962.txt
+++ b/Documentation/devicetree/bindings/sound/wm8962.txt
@@ -9,6 +9,9 @@ Required properties:
- reg : the I2C address of the device.
Optional properties:
+
+ - clocks : The clock source of the mclk
+
- spk-mono: This is a boolean property. If present, the SPK_MONO bit
of R51 (Class D Control 2) gets set, indicating that the speaker is
in mono mode.
@@ -27,6 +30,7 @@ Example:
wm8962: codec@1a {
compatible = "wlf,wm8962";
reg = <0x1a>;
+ clocks = < IMX6QDL_CLK_CKO>;
gpio-cfg = <
0x /* 0:Default */
--
2.25.1
[GIT PULL] Ceph updates for 5.11-rc1
Hi Linus,
The following changes since commit 2c85ebc57b3e1817b6ce1a6b703928e113a90442:
Linux 5.10 (2020-12-13 14:41:30 -0800)
are available in the Git repository at:
https://github.com/ceph/ceph-client.git tags/ceph-for-5.11-rc1
for you to fetch changes up to 2f0df6cfa325d7106b8a65bc0e02db1086e3f73b:
libceph: drop ceph_auth_{create,update}_authorizer() (2020-12-14 23:21:50
+0100)
There is a build conflict caused by the split of crypto/sha.h into
crypto/sha1.h and crypto/sha2.h that affects net/ceph/messenger_v2.c.
The resolution is to include the latter, done in for-linus-merged
just in case.
The big ticket item here is support for msgr2 on-wire protocol, which
adds the option of full in-transit encryption using AES-GCM algorithm
(myself). On top of that we have a series to avoid intermittent
errors during recovery with recover_session=clean and some MDS request
encoding work from Jeff, a cap handling fix and assorted observability
improvements from Luis and Xiubo and a good number of cleanups. Luis
also ran into a corner case with quotas which sadly means that we are
back to denying cross-quota-realm renames.
Colin Ian King (1):
ceph: remove redundant assignment to variable i
Ilya Dryomov (34):
libceph: include middle_len in process_message() dout
libceph: lower exponential backoff delay
libceph: don't call reset_connection() on version/feature mismatches
libceph: split protocol reset bits out of reset_connection()
libceph: rename reset_connection() to ceph_con_reset_session()
libceph: clear con->peer_global_seq on RESETSESSION
libceph: remove redundant session reset log message
libceph: drop msg->ack_stamp field
libceph: handle discarding acked and requeued messages separately
libceph: change ceph_msg_data_cursor_init() to take cursor
libceph: change ceph_con_in_msg_alloc() to take hdr
libceph: factor out ceph_con_get_out_msg()
libceph: make sure our addr->port is zero and addr->nonce is non-zero
libceph: don't export ceph_messenger_{init_fini}() to modules
libceph: make con->state an int
libceph: rename and export con->state states
libceph: rename and export con->flags bits
libceph: export zero_page
libceph: export remaining protocol independent infrastructure
libceph: separate msgr1 protocol implementation
libceph: move msgr1 protocol implementation to its own file
libceph: move msgr1 protocol specific fields to its own struct
libceph: more insight into ticket expiry and invalidation
libceph: safer en/decoding of cephx requests and replies
libceph, ceph: incorporate nautilus cephx changes
libceph: amend cephx init_protocol() and build_request()
libceph: drop ac->ops->name field
libceph: factor out finish_auth()
libceph, ceph: get and handle cluster maps with addrvecs
libceph, rbd: ignore addr->type while comparing in some cases
libceph: introduce connection modes and ms_mode option
libceph, ceph: implement msgr2.1 protocol (crc and secure modes)
libceph, ceph: make use of __ceph_auth_get_authorizer() in msgr1
libceph: drop ceph_auth_{create,update}_authorizer()
Jeff Layton (15):
ceph: don't WARN when removing caps due to blocklisting
ceph: make fsc->mount_state an int
ceph: add new RECOVER mount_state when recovering session
ceph: remove timeout on allowing reconnect after blocklisting
ceph: queue MDS requests to REJECTED sessions when CLEANRECOVER is set
ceph: fix up some warnings on W=1 builds
ceph: acquire Fs caps when getting dir stats
ceph: ensure we have Fs caps when fetching dir link count
ceph: pass down the flags to grab_cache_page_write_begin
ceph: fix inode refcount leak when ceph_fill_inode on non-I_NEW inode
fails
ceph: when filling trace, call ceph_get_inode outside of mutexes
ceph: don't reach into request header for readdir info
ceph: take a cred reference instead of tracking individual uid/gid
ceph: clean up argument lists to __prepare_send_request and __send_request
ceph: implement updated ceph_mds_request_head structure
Liu, Changcheng (1):
libceph: remove unused port macros
Luis Henriques (4):
ceph: fix race in concurrent __ceph_remove_cap invocations
ceph: downgrade warning from mdsmap decode to debug
Revert "ceph: allow rename operation under different quota realms"
ceph: add ceph.caps vxattr
Xiubo Li (4):
ceph: send dentry lease metrics to MDS daemon
ceph: add status debugfs file
ceph: add ceph.{cluster_fsid/client_id} vxattrs
ceph: set osdmap epoch for setxattr
drivers/block/rbd.c|8 +-
fs/ceph/addr.c |6 +-
fs/ceph/caps.c
Re: [PATCH 1/1] mwifiex: Fix possible buffer overflows in mwifiex_config_scan
Brian Norris writes:
> On Tue, Dec 8, 2020 at 7:14 AM Xiaohui Zhang wrote:
>>
>> From: Zhang Xiaohui
>>
>> mwifiex_config_scan() calls memcpy() without checking
>> the destination size may trigger a buffer overflower,
>> which a local user could use to cause denial of service
>> or the execution of arbitrary code.
>> Fix it by putting the length check before calling memcpy().
>
> ^^ That's not really what you're doing any more, for the record. But
> then, describing "what" is not really the point of a commit message
> (that's what the code is for), so maybe that's not that important.
>
>> Signed-off-by: Zhang Xiaohui
>> ---
>> drivers/net/wireless/marvell/mwifiex/scan.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c
>> b/drivers/net/wireless/marvell/mwifiex/scan.c
>> index c2a685f63..34293fd80 100644
>> --- a/drivers/net/wireless/marvell/mwifiex/scan.c
>> +++ b/drivers/net/wireless/marvell/mwifiex/scan.c
>> @@ -931,7 +931,7 @@ mwifiex_config_scan(struct mwifiex_private *priv,
>> wildcard_ssid_tlv->max_ssid_length = 0xfe;
>>
>> memcpy(wildcard_ssid_tlv->ssid,
>> - user_scan_in->ssid_list[i].ssid, ssid_len);
>> + user_scan_in->ssid_list[i].ssid, min_t(u32,
>> ssid_len, 1));
>
> This *looks* like it should be wrong, because SSIDs are clearly longer
> than 1 byte in many cases, but you *are* right that this is what the
> struct is defined as:
>
> struct mwifiex_ie_types_wildcard_ssid_params {
> ...
> u8 ssid[1];
> };
>
> This feels like something that could use some confirmation from
> NXP/ex-Marvell folks if possible, but if not that, at least some
> creative testing. Did you actually test this patch, to make sure
> non-wildcard scans still work?
>
> Also, even if this is correct, it seems like it would be more correct
> to use 'sizeof(wildcard_ssid_tlv->ssid)' instead of a magic number 1.
Xiaohui, please respond to Brian's comments. If you ignore review
comments I have a hard time trusting your patches.
Also when you submit a new version you should mark it as v2. See more in
the wiki link below.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v1 ] ALSA: core: memalloc: add page alignment for iram
On Thu, 17 Dec 2020 16:38:22 +0100,
Lars-Peter Clausen wrote:
>
> >> Maybe what we need is a check that runtime->dma_area is page aligned
> >> and runtime->dma_bytes is a multiple of PAGE_SIZE. With a warning at
> >> first and then turn this into a error a year later or so.
> > OK, how about the following instead?
> > Just check SNDRV_PCM_INFO_MMAP in runtime->info; if this is set, the
> > buffer size must be aligned with the page size, and we are safe to
> > extend the size to clear.
> >
> > So the revised fix is much simpler, something like below.
>
> I think this will work for the leaking data issue.
>
> But it will not help with the original issue that
> gen_pool_dma_alloc_align() does not reserve the remainder of the page
> and could give it out to other allocations. We'd need a separate patch
> for that.
That can be fixed by the pcm_memory.c change in the previous patch.
Recited below.
Of course it won't cover the non-standard allocation case, but then
it's rather the responsibility of such driver.
Takashi
---
--- a/sound/core/pcm_memory.c
+++ b/sound/core/pcm_memory.c
@@ -36,6 +36,7 @@ static int do_alloc_pages(struct snd_card *card, int type,
struct device *dev,
{
int err;
+ size = PAGE_ALIGN(size)
if (max_alloc_per_card &&
card->total_pcm_alloc_bytes + size > max_alloc_per_card)
return -ENOMEM;
@@ -187,7 +188,7 @@ static void snd_pcm_lib_preallocate_proc_write(struct
snd_info_entry *entry,
buffer->error = -ENOMEM;
return;
}
- substream->buffer_bytes_max = size;
+ substream->buffer_bytes_max = new_dmab.bytes;
} else {
substream->buffer_bytes_max = UINT_MAX;
}
Re: [bisected] Re: drm, qxl: post 5.11 merge warning+explosion
On Thu, 2020-12-17 at 17:24 +0100, Christian König wrote: > Hi Mike, > > what exactly is the warning from qxl you are seeing? [1.815561] WARNING: CPU: 7 PID: 355 at drivers/gpu/drm/ttm/ttm_pool.c:365 ttm_pool_alloc+0x41b/0x540 [ttm] [1.815561] Modules linked in: ext4(E) crc16(E) mbcache(E) jbd2(E) ata_generic(E) ata_piix(E) virtio_console(E) virtio_rng(E) virtio_blk(E) qxl(E) drm_ttm_helper(E) ttm(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) ahci(E) fb_sys_fops(E) cec(E) libahci(E) uhci_hcd(E) ehci_pci(E) rc_core(E) ehci_hcd(E) crc32c_intel(E) serio_raw(E) virtio_pci(E) virtio_ring(E) 8139cp(E) virtio(E) libata(E) drm(E) usbcore(E) mii(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) scsi_mod(E) autofs4(E) [1.815589] CPU: 7 PID: 355 Comm: kworker/7:2 Tainted: GE 5.10.0.g489e9fe-master #26 [1.815590] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014 [1.815614] Workqueue: events drm_fb_helper_dirty_work [drm_kms_helper] [1.815621] RIP: 0010:ttm_pool_alloc+0x41b/0x540 [ttm] [1.815623] Code: fc ff ff 89 ea 48 8d 04 d5 00 00 00 00 48 29 d0 48 8d 3c c5 00 1c 40 a0 e9 d7 fc ff ff 85 c0 0f 89 2f fc ff ff e9 28 fc ff ff <0f> 0b e9 35 fc ff ff 89 e9 49 8b 7d 00 b8 00 10 00 00 48 d3 e0 45 [1.815623] RSP: 0018:888105d3b818 EFLAGS: 00010246 [1.815625] RAX: RBX: 888106978800 RCX: [1.815626] RDX: 888105d3bc68 RSI: 0001 RDI: 888106238820 [1.815626] RBP: 888106238758 R08: c9296000 R09: 816b [1.815627] R10: 0001 R11: c9296000 R12: [1.815628] R13: 888106238820 R14: R15: 888106978800 [1.815628] FS: () GS:888237dc() knlGS: [1.815632] CS: 0010 DS: ES: CR0: 80050033 [1.815633] CR2: 7eff52a0d5b8 CR3: 02010003 CR4: 001706e0 [1.815633] Call Trace: [1.815644] ttm_tt_populate+0xb1/0xc0 [ttm] [1.815647] ttm_bo_move_memcpy+0x4a5/0x500 [ttm] [1.815652] qxl_bo_move+0x230/0x2f0 [qxl] [1.815655] ttm_bo_handle_move_mem+0x79/0x140 [ttm] [1.815657] ttm_bo_evict+0x124/0x250 [ttm] [1.815693] ? drm_mm_insert_node_in_range+0x55c/0x580 [drm] [1.815696] ttm_mem_evict_first+0x110/0x3d0 [ttm] [1.815698] ttm_bo_mem_space+0x261/0x270 [ttm] [1.815702] ? qxl_ttm_debugfs_init+0xb0/0xb0 [qxl] [1.815705] ttm_bo_validate+0x117/0x150 [ttm] [1.815756] ttm_bo_init_reserved+0x2c8/0x3c0 [ttm] [1.815772] qxl_bo_create+0x134/0x1d0 [qxl] [1.815775] ? qxl_ttm_debugfs_init+0xb0/0xb0 [qxl] [1.815791] qxl_alloc_bo_reserved+0x2c/0x90 [qxl] [1.815794] qxl_image_alloc_objects+0xa3/0x120 [qxl] [1.815797] qxl_draw_dirty_fb+0x155/0x450 [qxl] [1.815815] ? _cond_resched+0x15/0x40 [1.815819] ? ww_mutex_lock_interruptible+0x12/0x60 [1.815822] qxl_framebuffer_surface_dirty+0x14f/0x1a0 [qxl] [1.815841] drm_fb_helper_dirty_work+0x11d/0x180 [drm_kms_helper] [1.815853] process_one_work+0x1f5/0x3c0 [1.815866] ? process_one_work+0x3c0/0x3c0 [1.815867] worker_thread+0x2d/0x3d0 [1.815868] ? process_one_work+0x3c0/0x3c0 [1.815872] kthread+0x117/0x130 [1.815876] ? kthread_park+0x90/0x90 [1.815880] ret_from_fork+0x1f/0x30 [1.815886] ---[ end trace 51e464c1e89a1728 ]--- [1.815894] BUG: kernel NULL pointer dereference, address: 0230 [1.815895] #PF: supervisor read access in kernel mode [1.815895] #PF: error_code(0x) - not-present page [1.815896] PGD 0 P4D 0 [1.815898] Oops: [#1] SMP NOPTI [1.815900] CPU: 7 PID: 355 Comm: kworker/7:2 Tainted: GW E 5.10.0.g489e9fe-master #26 [1.815901] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014 [1.815916] Workqueue: events drm_fb_helper_dirty_work [drm_kms_helper] [1.815921] RIP: 0010:dma_map_page_attrs+0xf/0x1c0 [1.815922] Code: 1f 17 5b 01 48 85 c0 75 e3 31 c0 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 41 55 41 54 55 53 48 83 ec 08 <48> 8b 87 30 02 00 00 48 85 c0 48 0f 44 05 e7 16 5b 01 41 83 f8 02 [1.815923] RSP: 0018:888105d3b7e8 EFLAGS: 00010296 [1.815924] RAX: 1000 RBX: 0001 RCX: 1000 [1.815924] RDX: RSI: ea0004171e40 RDI: [1.815925] RBP: R08: R09: [1.815925] R10: ea0004171e40 R11: c9296000 R12: 0001 [1.815926] R13: 888106238820 R14: 888105d07100 R15: 888106978800 [1.815926] FS: () GS:888237dc() knlGS: [1.815928] CS: 0010 DS: ES: CR0: 80050033 [
[PATCH RESEND v4] riscv: Enable per-task stack canaries
From: Guo Ren
This enables the use of per-task stack canary values if GCC has
support for emitting the stack canary reference relative to the
value of tp, which holds the task struct pointer in the riscv
kernel.
After compare arm64 and x86 implementations, seems arm64's is more
flexible and readable. The key point is how gcc get the offset of
stack_canary from gs/el0_sp.
x86: Use a fix offset from gs, not flexible.
struct fixed_percpu_data {
/*
* GCC hardcodes the stack canary as %gs:40. Since the
* irq_stack is the object at %gs:0, we reserve the bottom
* 48 bytes of the irq stack for the canary.
*/
chargs_base[40]; // :(
unsigned long stack_canary;
};
arm64: Use -mstack-protector-guard-offset & guard-reg
gcc options:
-mstack-protector-guard=sysreg
-mstack-protector-guard-reg=sp_el0
-mstack-protector-guard-offset=xxx
riscv: Use -mstack-protector-guard-offset & guard-reg
gcc options:
-mstack-protector-guard=tls
-mstack-protector-guard-reg=tp
-mstack-protector-guard-offset=xxx
GCC's implementation has been merged:
commit c931e8d5a96463427040b0d11f9c4352ac22b2b0
Author: Cooper Qu
Date: Mon Jul 13 16:15:08 2020 +0800
RISC-V: Add support for TLS stack protector canary access
In the end, these codes are inserted by gcc before return:
* 0xffe00020b396 <+120>: ld a5,1008(tp) # 0x3f0
* 0xffe00020b39a <+124>: xor a5,a5,a4
* 0xffe00020b39c <+126>: mv a0,s5
* 0xffe00020b39e <+128>: bneza5,0xffe00020b61c <_do_fork+766>
0xffe00020b3a2 <+132>: ld ra,136(sp)
0xffe00020b3a4 <+134>: ld s0,128(sp)
0xffe00020b3a6 <+136>: ld s1,120(sp)
0xffe00020b3a8 <+138>: ld s2,112(sp)
0xffe00020b3aa <+140>: ld s3,104(sp)
0xffe00020b3ac <+142>: ld s4,96(sp)
0xffe00020b3ae <+144>: ld s5,88(sp)
0xffe00020b3b0 <+146>: ld s6,80(sp)
0xffe00020b3b2 <+148>: ld s7,72(sp)
0xffe00020b3b4 <+150>: addisp,sp,144
0xffe00020b3b6 <+152>: ret
...
* 0xffe00020b61c <+766>: auipc ra,0x7f8
* 0xffe00020b620 <+770>: jalr-1764(ra) # 0xffe000a02f38
<__stack_chk_fail>
Signed-off-by: Guo Ren
Signed-off-by: Cooper Qu
Reviewed-by: Kees Cook
Cc: Palmer Dabbelt
---
arch/riscv/Kconfig | 7 +++
arch/riscv/Makefile | 10 ++
arch/riscv/include/asm/stackprotector.h | 3 ++-
arch/riscv/kernel/asm-offsets.c | 3 +++
arch/riscv/kernel/process.c | 2 +-
5 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index a627ae2..3d9daee 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -420,6 +420,13 @@ config EFI
allow the kernel to be booted as an EFI application. This
is only useful on systems that have UEFI firmware.
+config CC_HAVE_STACKPROTECTOR_TLS
+ def_bool $(cc-option,-mstack-protector-guard=tls
-mstack-protector-guard-reg=tp -mstack-protector-guard-offset=0)
+
+config STACKPROTECTOR_PER_TASK
+ def_bool y
+ depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_TLS
+
endmenu
config BUILTIN_DTB
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index b6eb946..508de08 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -67,6 +67,16 @@ KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-relax)
# architectures. It's faster to have GCC emit only aligned accesses.
KBUILD_CFLAGS += $(call cc-option,-mstrict-align)
+ifeq ($(CONFIG_STACKPROTECTOR_PER_TASK),y)
+prepare: stack_protector_prepare
+stack_protector_prepare: prepare0
+ $(eval KBUILD_CFLAGS += -mstack-protector-guard=tls \
+ -mstack-protector-guard-reg=tp\
+ -mstack-protector-guard-offset=$(shell\
+ awk '{if ($$2 == "TSK_STACK_CANARY") print $$3;}' \
+ include/generated/asm-offsets.h))
+endif
+
# arch specific predefines for sparse
CHECKFLAGS += -D__riscv -D__riscv_xlen=$(BITS)
diff --git a/arch/riscv/include/asm/stackprotector.h
b/arch/riscv/include/asm/stackprotector.h
index 5962f88..09093af 100644
--- a/arch/riscv/include/asm/stackprotector.h
+++ b/arch/riscv/include/asm/stackprotector.h
@@ -24,6 +24,7 @@ static __always_inline void boot_init_stack_canary(void)
canary &= CANARY_MASK;
current->stack_canary = canary;
- __stack_chk_guard = current->stack_canary;
+ if (!IS_ENABLED(CONFIG_STACKPROTECTOR_PER_TASK))
+ __stack_chk_guard = current->stack_canary;
}
#endif /* _ASM_RISCV_STACKPROTECTOR_H */
diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c
index db20344..877ff65 100644
--- a/arch/riscv/kernel/asm-offsets.c
+++
Re: [PATCH] ARM: dts: sun8i-v3s: Add PWM controller and pins definitions
Hi,
On Thu, Dec 17, 2020 at 12:20:31PM +0100, Paul Kocialkowski wrote:
> This introduces definitions for the PWM controller found in the V3s,
> as well as associated pins. This fashion of the controller has two PWM
> outputs and is register-compatible with the A20.
>
> Both PWM outputs were tested on a Lichee Pi Zero with a simple
> transistor-LED setup.
>
> Signed-off-by: Paul Kocialkowski
> ---
> arch/arm/boot/dts/sun8i-v3s.dtsi | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
> b/arch/arm/boot/dts/sun8i-v3s.dtsi
> index a9f5795d4e57..34a4e638c762 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -398,6 +398,16 @@ spi0_pins: spi0-pins {
> pins = "PC0", "PC1", "PC2", "PC3";
> function = "spi0";
> };
> +
> + pwm0_pin: pwm0-pin {
> + pins = "PB4";
> + function = "pwm0";
> + };
> +
> + pwm1_pin: pwm1-pin {
> + pins = "PB5";
> + function = "pwm1";
> + };
> };
>
> timer@1c20c00 {
> @@ -416,6 +426,14 @@ wdt0: watchdog@1c20ca0 {
> clocks = <>;
> };
>
> + pwm: pwm@1c21400 {
> + compatible = "allwinner,sun7i-a20-pwm";
We should have a (documented) v3s compatible there along with the A20
Thanks!
Maxime
[PATCH] crypto: keembay-ocs-aes - Add dependency on HAS_IOMEM
From: Daniele Alessandrelli
Add dependency for CRYPTO_DEV_KEEMBAY_OCS_AES_SM4 on HAS_IOMEM to
prevent build failures.
Fixes: 88574332451380f4 ("crypto: keembay - Add support for Keem Bay OCS
AES/SM4")
Reported-by: kernel test robot
Signed-off-by: Daniele Alessandrelli
---
drivers/crypto/keembay/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/keembay/Kconfig b/drivers/crypto/keembay/Kconfig
index 3c16797b25b9..8eb5200d2f60 100644
--- a/drivers/crypto/keembay/Kconfig
+++ b/drivers/crypto/keembay/Kconfig
@@ -1,5 +1,6 @@
config CRYPTO_DEV_KEEMBAY_OCS_AES_SM4
tristate "Support for Intel Keem Bay OCS AES/SM4 HW acceleration"
+ depends on HAS_IOMEM
depends on OF || COMPILE_TEST
select CRYPTO_SKCIPHER
select CRYPTO_AEAD
base-commit: 90cc8cf2d1ab87d708ebc311ac104ccbbefad9fc
--
2.26.2
Re: [bisected] Re: drm, qxl: post 5.11 merge warning+explosion
Am 17.12.20 um 17:26 schrieb Mike Galbraith: On Thu, 2020-12-17 at 17:24 +0100, Christian König wrote: Hi Mike, what exactly is the warning from qxl you are seeing? [1.815561] WARNING: CPU: 7 PID: 355 at drivers/gpu/drm/ttm/ttm_pool.c:365 ttm_pool_alloc+0x41b/0x540 [ttm] Yeah, that is an expected result. Looks like qxl does something quite odd here, it allocates an dma_address array but doesn't have a device to fill them. On the other hand I don't see qxl using the allocated dma_addresses. Dave do you have an idea why qxl is doing that? Mike can you test the attached patch? Thanks in advance, Christian. [1.815561] Modules linked in: ext4(E) crc16(E) mbcache(E) jbd2(E) ata_generic(E) ata_piix(E) virtio_console(E) virtio_rng(E) virtio_blk(E) qxl(E) drm_ttm_helper(E) ttm(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) ahci(E) fb_sys_fops(E) cec(E) libahci(E) uhci_hcd(E) ehci_pci(E) rc_core(E) ehci_hcd(E) crc32c_intel(E) serio_raw(E) virtio_pci(E) virtio_ring(E) 8139cp(E) virtio(E) libata(E) drm(E) usbcore(E) mii(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) scsi_mod(E) autofs4(E) [1.815589] CPU: 7 PID: 355 Comm: kworker/7:2 Tainted: GE 5.10.0.g489e9fe-master #26 [1.815590] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014 [1.815614] Workqueue: events drm_fb_helper_dirty_work [drm_kms_helper] [1.815621] RIP: 0010:ttm_pool_alloc+0x41b/0x540 [ttm] [1.815623] Code: fc ff ff 89 ea 48 8d 04 d5 00 00 00 00 48 29 d0 48 8d 3c c5 00 1c 40 a0 e9 d7 fc ff ff 85 c0 0f 89 2f fc ff ff e9 28 fc ff ff <0f> 0b e9 35 fc ff ff 89 e9 49 8b 7d 00 b8 00 10 00 00 48 d3 e0 45 [1.815623] RSP: 0018:888105d3b818 EFLAGS: 00010246 [1.815625] RAX: RBX: 888106978800 RCX: [1.815626] RDX: 888105d3bc68 RSI: 0001 RDI: 888106238820 [1.815626] RBP: 888106238758 R08: c9296000 R09: 816b [1.815627] R10: 0001 R11: c9296000 R12: [1.815628] R13: 888106238820 R14: R15: 888106978800 [1.815628] FS: () GS:888237dc() knlGS: [1.815632] CS: 0010 DS: ES: CR0: 80050033 [1.815633] CR2: 7eff52a0d5b8 CR3: 02010003 CR4: 001706e0 [1.815633] Call Trace: [1.815644] ttm_tt_populate+0xb1/0xc0 [ttm] [1.815647] ttm_bo_move_memcpy+0x4a5/0x500 [ttm] [1.815652] qxl_bo_move+0x230/0x2f0 [qxl] [1.815655] ttm_bo_handle_move_mem+0x79/0x140 [ttm] [1.815657] ttm_bo_evict+0x124/0x250 [ttm] [1.815693] ? drm_mm_insert_node_in_range+0x55c/0x580 [drm] [1.815696] ttm_mem_evict_first+0x110/0x3d0 [ttm] [1.815698] ttm_bo_mem_space+0x261/0x270 [ttm] [1.815702] ? qxl_ttm_debugfs_init+0xb0/0xb0 [qxl] [1.815705] ttm_bo_validate+0x117/0x150 [ttm] [1.815756] ttm_bo_init_reserved+0x2c8/0x3c0 [ttm] [1.815772] qxl_bo_create+0x134/0x1d0 [qxl] [1.815775] ? qxl_ttm_debugfs_init+0xb0/0xb0 [qxl] [1.815791] qxl_alloc_bo_reserved+0x2c/0x90 [qxl] [1.815794] qxl_image_alloc_objects+0xa3/0x120 [qxl] [1.815797] qxl_draw_dirty_fb+0x155/0x450 [qxl] [1.815815] ? _cond_resched+0x15/0x40 [1.815819] ? ww_mutex_lock_interruptible+0x12/0x60 [1.815822] qxl_framebuffer_surface_dirty+0x14f/0x1a0 [qxl] [1.815841] drm_fb_helper_dirty_work+0x11d/0x180 [drm_kms_helper] [1.815853] process_one_work+0x1f5/0x3c0 [1.815866] ? process_one_work+0x3c0/0x3c0 [1.815867] worker_thread+0x2d/0x3d0 [1.815868] ? process_one_work+0x3c0/0x3c0 [1.815872] kthread+0x117/0x130 [1.815876] ? kthread_park+0x90/0x90 [1.815880] ret_from_fork+0x1f/0x30 [1.815886] ---[ end trace 51e464c1e89a1728 ]--- [1.815894] BUG: kernel NULL pointer dereference, address: 0230 [1.815895] #PF: supervisor read access in kernel mode [1.815895] #PF: error_code(0x) - not-present page [1.815896] PGD 0 P4D 0 [1.815898] Oops: [#1] SMP NOPTI [1.815900] CPU: 7 PID: 355 Comm: kworker/7:2 Tainted: GW E 5.10.0.g489e9fe-master #26 [1.815901] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014 [1.815916] Workqueue: events drm_fb_helper_dirty_work [drm_kms_helper] [1.815921] RIP: 0010:dma_map_page_attrs+0xf/0x1c0 [1.815922] Code: 1f 17 5b 01 48 85 c0 75 e3 31 c0 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 41 55 41 54 55 53 48 83 ec 08 <48> 8b 87 30 02 00 00 48 85 c0 48 0f 44 05 e7 16 5b 01 41 83 f8 02 [1.815923] RSP: 0018:888105d3b7e8 EFLAGS: 00010296 [1.815924] RAX: 1000 RBX: 0001 RCX: 1000 [1.815924] RDX: RSI: ea0004171e40 RDI: [
[PATCH] selftests/vDSO: add additional binaries to .gitignore
Add the test binaries introduced by commit 693f5ca08ca0 ("kselftest:
Extend vDSO selftest"), commit 03f55c7952c9 ("kselftest: Extend vDSO
selftest to clock_getres") and commit c7e5789b24d3 ("kselftest: Move
test_vdso to the vDSO test suite") to .gitignore.
Signed-off-by: Tobias Klauser
---
tools/testing/selftests/vDSO/.gitignore | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/testing/selftests/vDSO/.gitignore
b/tools/testing/selftests/vDSO/.gitignore
index 5eb64d41e541..a8dc51af5a9c 100644
--- a/tools/testing/selftests/vDSO/.gitignore
+++ b/tools/testing/selftests/vDSO/.gitignore
@@ -1,5 +1,8 @@
# SPDX-License-Identifier: GPL-2.0-only
vdso_test
+vdso_test_abi
+vdso_test_clock_getres
+vdso_test_correctness
vdso_test_gettimeofday
vdso_test_getcpu
vdso_standalone_test_x86
--
2.29.0
Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'
On Thu, Dec 17, 2020 at 4:32 PM Andreas Larsson wrote: > On 2020-12-16 00:24, Arnd Bergmann wrote: > > On Tue, Dec 15, 2020 at 8:38 PM Sam Ravnborg wrote: > >> On Tue, Dec 15, 2020 at 12:26:10PM +0100, Arnd Bergmann wrote: > >>> > >>> - Disable SMP support for sun4m/sun4d. From the historic git > >>>tree, it's unclear how well this ever worked, and very few machines > >>>of this class ever existed > >> Yeah, I have collection of sparc32 machines that I played around with > >> once. Including one sun4d that I brought from a friendly Linux fellow in > >> the UK. But somehow I lost interest as this is all very nice machines > >> but not useful for anything real work. > >> > >> I think we would be better served dropping support for sun4m and sun4d > >> from the kernel. > > > > This seems appropriate as well to me. > > > >> Last I suggested deleting sun4m/sun4d the argument to keep sun4m was that > >> QEMU supports sun4m - which is a good argument for sun4m. I dunno what > >> would be needed to migrate QEMU to LEON, see below. > > > > "qemu-system-sparc -M help" shows a "leon3_generic" platform, apparently > > added in 2013. Do you think that would be sufficient? > > We have only use QEMU for LEON3 on limited and simpler system > setups. For example the Zephyr SPARC arch + LEON3 BSP port we recently > submitted to the Linux Foundation Zephyr project run their test-suite > successfully on QEMU+LEON3. We will have to look into the QEMU for LEON > and Linux situation. > > We mainly use TSIM that is our own high fidelity simulator. I don't think there is a need to have many features supported in qemu, as long as you have enough RAM, block and network devices (which are trivial if you have PCI or USB). > >>> - Mark SMP for LEON as temporarily broken. As I see in the LEON > >>>patch set, they have changes to enable compare-and-swap-atomic > >>>instructions unconditionally, as all SMP Leons have those and > >>>seem to require this support already for other things. > > Regarding unconditional compare-and-swap-atomic instructions (CASA) for > LEON. I tried to get those into mainline under the LEON configuration > option but did not get OK for that at that time, with the feedback to do > it dynamically instead. I haven't come around to try to get an updated > patch doing probing instead into mainline yet. If the thought now is to > drop support for SMP for sparc32, maybe we can have the CASA > unconditionally on SMP configured kernels instead. Still we'd like to > have CASA usage even for non-SMP kernels for LEON systems that > supports it. It does make sense to require that a single kernel can work on all possible hardware. So if we remove sun4m/sun4d support, all that is left is LEON, and you likely wouldn't need to worry about other CPUs any more. However, there is still the question whether a single kernel needs to work on LEON both with and without CASA. Do you still care about Linux users on LEON cores that do not support CASA, or is widespread enough that you just make it unconditional for both SMP and non-SMP? > >> LEON on the other hand could have some nice future. They are right now > >> stuck on an older kernel and someone that was motivated should be able > >> to get LEON4 running on latest upstream. > >> We had it working in the past - but is was around the time I lost my > >> sparc interest and no-one jumped in to move it much more forward. > > I would not say that we are stuck on an old kernel. It is rather that > for our official releases we stay on long term support kernels. We still > aim for kernels based on master to work on LEON. Right now we do have a > bit of backlog of things to get into upstream. Ok, good to hear. There were a couple of old bugs that got found on mainline that made me wonder whether mainline sparc32 was used on any hardware at all these days. I looked at your v4.9 patches and didn't see anything too scary there, in particular once sparc32 becomes leon-only, you no longer have to worry about making it work across different CPUs. > > My best guess from the public information I could find on LEON is that > > it keeps shifting away from Linux on LEON to other OSs, and to > > and to Linux on NOEL-V. > > On the contrary. Our LEON users shows an increased interest in running > Linux, now that LEON-based systems gains in number of processors, > processor performance and memory. We are adding NOEL as a new processor > line. With NOEL we have a 64-bit architecture. We are not shifting from > LEON to NOEL. LEON is not going away. Ok. > > So even though the CPU itself will likely have a long life ahead of it > > with LEON5 only a year old, it's unclear how many more updates > > we'll see to the kernel from the current 4.9 based release. > > Our latest release was indeed based on 4.9, but we have no plans to stay > there forever. We just tend to select long term support kernels for our > official releases. The next step will be to go to 5.4 if not 5.10. I
Re: [PATCH v3 14/15] x86/paravirt: switch functions with custom code to ALTERNATIVE
Hi Juergen,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to xen-tip/linux-next tip/x86/core tip/x86/asm v5.10
next-20201217]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Juergen-Gross/x86-major-paravirt-cleanup/20201217-173646
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
accefff5b547a9a1d959c7e76ad539bf2480e78b
config: x86_64-randconfig-a002-20201217 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/bc3cbe0ff1b123a4b7f48c91b32198d7dfe57797
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Juergen-Gross/x86-major-paravirt-cleanup/20201217-173646
git checkout bc3cbe0ff1b123a4b7f48c91b32198d7dfe57797
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>):
arch/x86/entry/entry_64.S: Assembler messages:
>> arch/x86/entry/entry_64.S:1092: Error: junk at end of line, first
>> unrecognized character is `('
>> arch/x86/entry/entry_64.S:1092: Error: backward ref to unknown label "771:"
>> arch/x86/entry/entry_64.S:1092: Error: backward ref to unknown label "771:"
>> arch/x86/entry/entry_64.S:1092: Error: junk at end of line, first
>> unrecognized character is `,'
>> arch/x86/entry/entry_64.S:1092: Warning: missing closing '"'
>> arch/x86/entry/entry_64.S:1092: Error: expecting mnemonic; got nothing
vim +1092 arch/x86/entry/entry_64.S
ddeb8f2149de280 arch/x86/kernel/entry_64.S Alexander van Heukelum 2008-11-24
1089
424c7d0a9a396ba arch/x86/entry/entry_64.S Thomas Gleixner2020-03-26
1090 SYM_CODE_START_LOCAL(error_return)
424c7d0a9a396ba arch/x86/entry/entry_64.S Thomas Gleixner2020-03-26
1091 UNWIND_HINT_REGS
424c7d0a9a396ba arch/x86/entry/entry_64.S Thomas Gleixner2020-03-26
@1092 DEBUG_ENTRY_ASSERT_IRQS_OFF
424c7d0a9a396ba arch/x86/entry/entry_64.S Thomas Gleixner2020-03-26
1093 testb $3, CS(%rsp)
424c7d0a9a396ba arch/x86/entry/entry_64.S Thomas Gleixner2020-03-26
1094 jz restore_regs_and_return_to_kernel
424c7d0a9a396ba arch/x86/entry/entry_64.S Thomas Gleixner2020-03-26
1095 jmp swapgs_restore_regs_and_return_to_usermode
424c7d0a9a396ba arch/x86/entry/entry_64.S Thomas Gleixner2020-03-26
1096 SYM_CODE_END(error_return)
424c7d0a9a396ba arch/x86/entry/entry_64.S Thomas Gleixner2020-03-26
1097
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] selftests/vDSO: fix -Wformat warning in vdso_test_correctness
Fix the following -Wformat warnings in vdso_test_correctness.c:
vdso_test_correctness.c: In function ‘test_one_clock_gettime64’:
vdso_test_correctness.c:352:21: warning: format ‘%ld’ expects argument of type
‘long int’, but argument 3 has type ‘long long int’ [-Wformat=]
352 | printf("\t%llu.%09ld %llu.%09ld %llu.%09ld\n",
| ^
| |
| long int
| %09lld
353 | (unsigned long long)start.tv_sec, start.tv_nsec,
| ~
||
|long long int
vdso_test_correctness.c:352:32: warning: format ‘%ld’ expects argument of type
‘long int’, but argument 5 has type ‘long long int’ [-Wformat=]
352 | printf("\t%llu.%09ld %llu.%09ld %llu.%09ld\n",
|^
||
|long int
|%09lld
353 | (unsigned long long)start.tv_sec, start.tv_nsec,
354 | (unsigned long long)vdso.tv_sec, vdso.tv_nsec,
|
| |
| long long int
vdso_test_correctness.c:352:43: warning: format ‘%ld’ expects argument of type
‘long int’, but argument 7 has type ‘long long int’ [-Wformat=]
The tv_sec member of __kernel_timespec is long long, both in
uapi/linux/time_types.h and locally in vdso_test_correctness.c.
Signed-off-by: Tobias Klauser
---
tools/testing/selftests/vDSO/vdso_test_correctness.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/vDSO/vdso_test_correctness.c
b/tools/testing/selftests/vDSO/vdso_test_correctness.c
index 5029ef9b228c..c4aea794725a 100644
--- a/tools/testing/selftests/vDSO/vdso_test_correctness.c
+++ b/tools/testing/selftests/vDSO/vdso_test_correctness.c
@@ -349,7 +349,7 @@ static void test_one_clock_gettime64(int clock, const char
*name)
return;
}
- printf("\t%llu.%09ld %llu.%09ld %llu.%09ld\n",
+ printf("\t%llu.%09lld %llu.%09lld %llu.%09lld\n",
(unsigned long long)start.tv_sec, start.tv_nsec,
(unsigned long long)vdso.tv_sec, vdso.tv_nsec,
(unsigned long long)end.tv_sec, end.tv_nsec);
--
2.29.0
Re: KASAN: null-ptr-deref Read in filp_close
On Thu, Dec 17, 2020 at 07:54:09AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:5e60366d Merge tag 'fallthrough-fixes-clang-5.11-rc1' of g..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15f1541350
> kernel config: https://syzkaller.appspot.com/x/.config?x=db720fe37a6a41d8
> dashboard link: https://syzkaller.appspot.com/bug?extid=96cfd2b22b3213646a93
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10e1a00b50
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1128e41f50
>
> The issue was bisected to:
>
> commit 582f1fb6b721facf04848d2ca57f34468da1813e
> Author: Giuseppe Scrivano
> Date: Wed Nov 18 10:47:45 2020 +
>
> fs, close_range: add flag CLOSE_RANGE_CLOEXEC
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16e8561350
> final oops: https://syzkaller.appspot.com/x/report.txt?x=15e8561350
> console output: https://syzkaller.appspot.com/x/log.txt?x=11e8561350
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+96cfd2b22b3213646...@syzkaller.appspotmail.com
> Fixes: 582f1fb6b721 ("fs, close_range: add flag CLOSE_RANGE_CLOEXEC")
Ok, I think the bug is simply that max_fd is not correctly updated when
CLOSE_RANGE_UNSHARE is combined with CLOSE_RANGE_CLOEXEC.
I'll write a patch for syszbot to chew on.
Christian
Re: linux-next: Tree for Dec 17 (objtool warnings)
On 12/16/20 9:53 PM, Stephen Rothwell wrote: > Hi all, > > Please do not add any v5.12 destined code to your linux-next included > branches until after v5.11-rc1 has been released. > > Changes since 20201216: > on x86_64: (These are on 2 different builds.) > gcc --version gcc (SUSE Linux) 7.5.0 drivers/gpu/drm/drm_edid.o: warning: objtool: do_cvt_mode() falls through to next function drm_get_override_edid.isra.30() lib/iov_iter.o: warning: objtool: iovec_from_user()+0x22d: call to __ubsan_handle_add_overflow() with UACCESS enabled Do you want .config files or .o files or what? thanks. -- ~Randy Reported-by: Randy Dunlap
Re: [PATCH v3 10/15] x86/paravirt: simplify paravirt macros
Hi Juergen, I love your patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v5.10] [cannot apply to xen-tip/linux-next tip/x86/core tip/x86/asm next-20201217] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Juergen-Gross/x86-major-paravirt-cleanup/20201217-173646 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git accefff5b547a9a1d959c7e76ad539bf2480e78b config: x86_64-randconfig-a016-20201217 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project cee1e7d14f4628d6174b33640d502bff3b54ae45) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu # https://github.com/0day-ci/linux/commit/0d13a33e925f799d8487bcc597e2dc016d1fdd16 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Juergen-Gross/x86-major-paravirt-cleanup/20201217-173646 git checkout 0d13a33e925f799d8487bcc597e2dc016d1fdd16 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from arch/x86/kernel/asm-offsets.c:13: In file included from include/linux/suspend.h:5: In file included from include/linux/swap.h:9: In file included from include/linux/memcontrol.h:22: In file included from include/linux/writeback.h:14: In file included from include/linux/blk-cgroup.h:23: In file included from include/linux/blkdev.h:26: In file included from include/linux/scatterlist.h:9: In file included from arch/x86/include/asm/io.h:244: >> arch/x86/include/asm/paravirt.h:44:2: warning: variable '__eax' is >> uninitialized when used within its own initialization [-Wuninitialized] PVOP_VCALL0(mmu.flush_tlb_user); ^~~ arch/x86/include/asm/paravirt_types.h:504:2: note: expanded from macro 'PVOP_VCALL0' __PVOP_VCALL(op) ^~~~ arch/x86/include/asm/paravirt_types.h:492:8: note: expanded from macro '__PVOP_VCALL' (void)PVOP_CALL(long, op, CLBR_ANY, PVOP_VCALL_CLOBBERS,\ ^~~ arch/x86/include/asm/paravirt_types.h:471:3: note: expanded from macro 'PVOP_CALL' PVOP_CALL_ARGS; \ ^~ arch/x86/include/asm/paravirt_types.h:431:41: note: expanded from macro 'PVOP_CALL_ARGS' __edx = __edx, __ecx = __ecx, __eax = __eax; ~ ^ In file included from arch/x86/kernel/asm-offsets.c:13: In file included from include/linux/suspend.h:5: In file included from include/linux/swap.h:9: In file included from include/linux/memcontrol.h:22: In file included from include/linux/writeback.h:14: In file included from include/linux/blk-cgroup.h:23: In file included from include/linux/blkdev.h:26: In file included from include/linux/scatterlist.h:9: In file included from arch/x86/include/asm/io.h:244: arch/x86/include/asm/paravirt.h:49:2: warning: variable '__eax' is uninitialized when used within its own initialization [-Wuninitialized] PVOP_VCALL0(mmu.flush_tlb_kernel); ^ arch/x86/include/asm/paravirt_types.h:504:2: note: expanded from macro 'PVOP_VCALL0' __PVOP_VCALL(op) ^~~~ arch/x86/include/asm/paravirt_types.h:492:8: note: expanded from macro '__PVOP_VCALL' (void)PVOP_CALL(long, op, CLBR_ANY, PVOP_VCALL_CLOBBERS,\ ^~~ arch/x86/include/asm/paravirt_types.h:471:3: note: expanded from macro 'PVOP_CALL' PVOP_CALL_ARGS; \ ^~ arch/x86/include/asm/paravirt_types.h:431:41: note: expanded from macro 'PVOP_CALL_ARGS' __edx = __edx, __ecx = __ecx, __eax = __eax; ~ ^ In file included from arch/x86/kernel/asm-offsets.c:13: In file included from include/linux/suspend.h:5: In file included from include/linux/swap.h:9: In file included from include/linux/memcontrol.h:22: In
Re: [PATCH v5 1/7] pwm: pca9685: Switch to atomic API
Hi Sven,
On Wed, Dec 16, 2020 at 10:58:07PM -0500, Sven Van Asbroeck wrote:
> Hi Clemens, this looks compact, simple and neat. I like it a lot !!
Thanks!
>
> Few very minor nits below.
>
> On Wed, Dec 16, 2020 at 7:53 AM Clemens Gruber
> wrote:
> >
> > The switch to the atomic API goes hand in hand with a few fixes to
> > previously experienced issues:
> > - The duty cycle is no longer lost after disable/enable (previously the
> > OFF registers were cleared in disable and the user was required to
> > call config to restore the duty cycle settings)
> > - If one sets a period resulting in the same prescale register value,
> > the sleep and write to the register is now skipped
> >
> > Signed-off-by: Clemens Gruber
> > ---
> > Changes since v4:
> > - Patches split up
> > - Use a single set_duty function
> > - Improve readability / new macros
> > - Added a patch to restrict prescale changes to the first user
> >
> > Changes since v3:
> > - Refactoring: Extracted common functions
> > - Read prescale register value instead of caching it
> > - Return all zeros and disabled for "all LEDs" channel state
> > - Improved duty calculation / mapping to 0..4096
> >
> > Changes since v2:
> > - Always set default prescale value in probe
> > - Simplified probe code
> > - Inlined functions with one callsite
> >
> > Changes since v1:
> > - Fixed a logic error
> > - Impoved PM runtime handling and fixed !CONFIG_PM
> > - Write default prescale reg value if invalid in probe
> > - Reuse full_off/_on functions throughout driver
> > - Use cached prescale value whenever possible
> >
> > drivers/pwm/pwm-pca9685.c | 253 +-
> > 1 file changed, 87 insertions(+), 166 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
> > index 4a55dc18656c..1b5b5fb93b43 100644
> > --- a/drivers/pwm/pwm-pca9685.c
> > +++ b/drivers/pwm/pwm-pca9685.c
> > @@ -51,7 +51,6 @@
> > #define PCA9685_PRESCALE_MAX 0xFF/* => min. frequency of 24 Hz */
> >
> > #define PCA9685_COUNTER_RANGE 4096
> > -#define PCA9685_DEFAULT_PERIOD 500 /* Default period_ns = 1/200 Hz */
> > #define PCA9685_OSC_CLOCK_MHZ 25 /* Internal oscillator with 25 MHz
> > */
> >
> > #define PCA9685_NUMREGS0xFF
> > @@ -71,10 +70,14 @@
> > #define LED_N_OFF_H(N) (PCA9685_LEDX_OFF_H + (4 * (N)))
> > #define LED_N_OFF_L(N) (PCA9685_LEDX_OFF_L + (4 * (N)))
> >
> > +#define REG_ON_H(C)((C) >= PCA9685_MAXCHAN ? PCA9685_ALL_LED_ON_H :
> > LED_N_ON_H((C)))
> > +#define REG_ON_L(C)((C) >= PCA9685_MAXCHAN ? PCA9685_ALL_LED_ON_L :
> > LED_N_ON_L((C)))
> > +#define REG_OFF_H(C) ((C) >= PCA9685_MAXCHAN ? PCA9685_ALL_LED_OFF_H :
> > LED_N_OFF_H((C)))
> > +#define REG_OFF_L(C) ((C) >= PCA9685_MAXCHAN ? PCA9685_ALL_LED_OFF_L :
> > LED_N_OFF_L((C)))
>
> Yes !!
>
> > +
> > struct pca9685 {
> > struct pwm_chip chip;
> > struct regmap *regmap;
> > - int period_ns;
> > #if IS_ENABLED(CONFIG_GPIOLIB)
> > struct mutex lock;
> > struct gpio_chip gpio;
> > @@ -87,6 +90,49 @@ static inline struct pca9685 *to_pca(struct pwm_chip
> > *chip)
> > return container_of(chip, struct pca9685, chip);
> > }
> >
> > +static void pca9685_pwm_set_duty(struct pca9685 *pca, int channel,
> > unsigned int duty)
> > +{
>
> Add brief function documentation to clarify that 'duty' sets the duty cycle
> _ratio_ to 'duty/4096' on ? I.e.
> duty == 2048 => duty cycle ratio = 2048/4096 = 50% on
> duty == 4096 => duty cycle ratio = 4096/4086 = 100% on etc
Will do.
>
> > + if (duty == 0) {
> > + /* Set the full OFF bit, which has the highest precedence */
> > + regmap_write(pca->regmap, REG_OFF_H(channel), LED_FULL);
> > + } else if (duty >= PCA9685_COUNTER_RANGE) {
> > + /* Set the full ON bit and clear the full OFF bit */
> > + regmap_write(pca->regmap, REG_ON_H(channel), LED_FULL);
> > + regmap_write(pca->regmap, REG_OFF_H(channel), 0);
> > + } else {
> > + /* Set OFF time (clears the full OFF bit) */
> > + regmap_write(pca->regmap, REG_OFF_L(channel), duty & 0xff);
> > + regmap_write(pca->regmap, REG_OFF_H(channel), (duty >> 8) &
> > 0xf);
> > + /* Clear the full ON bit */
> > + regmap_write(pca->regmap, REG_ON_H(channel), 0);
> > + }
> > +}
> > +
> > +static unsigned int pca9685_pwm_get_duty(struct pca9685 *pca, int channel)
> > +{
> > + unsigned int off_h, val;
> > +
> > + if (WARN_ON(channel >= PCA9685_MAXCHAN)) {
> > + /* Hardware readout not supported for "all LEDs" channel */
> > + return 0;
> > + }
> > +
> > + regmap_read(pca->regmap, LED_N_OFF_H(channel), _h);
> > + if (off_h & LED_FULL) {
>
> I believe this may trigger bots which are monitoring patches on LKML:
> if regmap_read() somehow fails, off_h will be used
Re: [PATCH] arm64: Kconfig: Add SYS_SUPPORTS_APM_EMULATION
On Thu, Dec 17, 2020 at 12:41:47AM +0800, Lecopzer Chen wrote: > so there is two points > 1. out-of-tree function can't be approved > I totally agree with this :) so we may have a driver upstream in the > future. It may not be upstreamable if it relies on the old APM interface ;). > 2. APM not make sense on arm64 > Could you please let me konw the reason why APM on ARM64 doesn't make sense? It's a very old interface, even on x86 it is disabled in the distro kernels. There are more modern alternatives and you should update your driver and user space to use them (e.g. /sys/power/). -- Catalin
Re: [PATCH v2 1/3] dt-bindings: rtc: add reset-source property
On Fri, Dec 11, 2020 at 5:10 PM Rasmus Villemoes wrote: > > On 11/12/2020 23.30, Rob Herring wrote: > > On Fri, Dec 11, 2020 at 3:56 PM Rasmus Villemoes > > wrote: > >> > >> Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But > >> if the reset pin is not actually wired up, the driver exposes a > >> watchdog device that doesn't actually work. > >> > >> Provide a standard binding that can be used to indicate that a given > >> RTC can perform a reset of the machine, similar to wakeup-source. > > > > Why not use the watchdog 'timeout-sec' property? > > Wouldn't that be overloading that property? AFAIU, that is used to ask > the kernel to program an initial timeout value into the watchdog device. > But what if one doesn't want to start the watchdog device at kernel > boot, but just indicate that the RTC has that capability? Yeah, I guess you're right. > It's quite possible that if it can act as a watchdog device (and > has-watchdog was also suggested), one would also want timeout-sec and > other watchdog bindings to apply. But that can be added later, by those > who actually want that. > > For now, I'd really like to get my board booting again (or rather, not > get reset by the real watchdog just because the pcf2127 driver now > exposes something as /dev/wathdog0, pushing the real one to > /dev/wathcdog1 which doesn't get pinged from userspace). I'm wondering how you solve which wdog to ping when there are multiple without relying on numbering. I guess 'reset-source' will solve that even if that's not your current fix. So I guess I'm fine with this. But you need to send to the DT list so checks are run. Rob
[PATCH] proc/wchan: Use printk format instead of lookup_symbol_name()
To resolve the symbol fuction name for wchan, use the printk format
specifier %ps instead of manually looking up the symbol function name
via lookup_symbol_name().
Signed-off-by: Helge Deller
diff --git a/fs/proc/base.c b/fs/proc/base.c
index b362523a9829..c4593e1cafa4 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -67,7 +67,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -386,19 +385,17 @@ static int proc_pid_wchan(struct seq_file *m, struct
pid_namespace *ns,
struct pid *pid, struct task_struct *task)
{
unsigned long wchan;
- char symname[KSYM_NAME_LEN];
- if (!ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS))
- goto print0;
+ if (ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS))
+ wchan = get_wchan(task);
+ else
+ wchan = 0;
- wchan = get_wchan(task);
- if (wchan && !lookup_symbol_name(wchan, symname)) {
- seq_puts(m, symname);
- return 0;
- }
+ if (wchan)
+ seq_printf(m, "%ps", (void *) wchan);
+ else
+ seq_putc(m, '0');
-print0:
- seq_putc(m, '0');
return 0;
}
#endif /* CONFIG_KALLSYMS */
Re: [bisected] Re: drm, qxl: post 5.11 merge warning+explosion
On Thu, 2020-12-17 at 17:38 +0100, Christian König wrote: > > Mike can you test the attached patch? Yup, one-liner made it all better. That was quick like bunny. -Mike
Re: [PATCH v2] net: mhi: Add raw IP mode support
On Thu, 17 Dec 2020 16:34:09 +0100 Loic Poulain wrote: > MHI net is protocol agnostic, the payload protocol depends on the modem > configuration, which can be either RMNET (IP muxing and aggregation) or > raw IP. This patch adds support for incomming IPv4/IPv6 packets, that > was previously unconditionnaly reported as RMNET packets. Now it sounds a lot more like an extension than a fix. Is the interface usable without this change? If it is we should merge this into net-next after the merge window. Either way you need to cc netdev for this patch to get into patchwork.
Re: [PATCH V3.1] entry: Pass irqentry_state_t by reference
On Mon, Nov 23 2020 at 22:09, ira weiny wrote: > From: Ira Weiny > > Currently struct irqentry_state_t only contains a single bool value > which makes passing it by value is reasonable. However, future patches > add information to this struct. This includes the PKRS thread state, > included in this series, as well as information to store kmap reference > tracking and PKS global state outside this series. In total, we > anticipate 2 new 32 bit fields and an integer field to be added to the > struct beyond the existing bool value. Well yes, but why can't you provide at least in the comment section below the '---' a pointer to the latest version of this reference muck and PKS global state if you can't explain at least the concept of the two things here? It's one thing that you anticipate something but a different thing whether it's the right thing to do. Thanks, tglx
[PATCH 0/2] MAINTAINERS: update STMicroelectronics email
From: Patrice Chotard This series: _ update st.com to foss.st.com email for some maintainers. _ Remove Vincent Abriou as STI/STM DRM driver Patrice Chotard (2): MAINTAINERS: Update some st.com email addresses to foss.st.com MAINTAINERS: Remove Vincent Abriou for STM/STI DRM drivers. MAINTAINERS | 30 ++ 1 file changed, 14 insertions(+), 16 deletions(-) -- 2.17.1
[PATCH 1/2] MAINTAINERS: Update some st.com email addresses to foss.st.com
From: Patrice Chotard Update some st.com to foss.st.com addresses related to STMicroelectronics drivers. All these people will now use this new email address for upstream activities. Signed-off-by: Patrice Chotard --- MAINTAINERS | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 281de213ef47..685b72a22cee 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2497,7 +2497,7 @@ N:sc27xx N: sc2731 ARM/STI ARCHITECTURE -M: Patrice Chotard +M: Patrice Chotard L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained W: http://www.stlinux.com @@ -2530,7 +2530,7 @@ F:include/linux/remoteproc/st_slim_rproc.h ARM/STM32 ARCHITECTURE M: Maxime Coquelin -M: Alexandre Torgue +M: Alexandre Torgue L: linux-st...@st-md-mailman.stormreply.com (moderated for non-subscribers) L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained @@ -3143,7 +3143,7 @@ C:irc://irc.oftc.net/bcache F: drivers/md/bcache/ BDISP ST MEDIA DRIVER -M: Fabien Dessenne +M: Fabien Dessenne L: linux-me...@vger.kernel.org S: Supported W: https://linuxtv.org @@ -5007,7 +5007,7 @@ S:Maintained F: drivers/platform/x86/dell-wmi.c DELTA ST MEDIA DRIVER -M: Hugues Fruchet +M: Hugues Fruchet L: linux-me...@vger.kernel.org S: Supported W: https://linuxtv.org @@ -5921,8 +5921,8 @@ F: Documentation/devicetree/bindings/display/st,stih4xx.txt F: drivers/gpu/drm/sti DRM DRIVERS FOR STM -M: Yannick Fertre -M: Philippe Cornu +M: Yannick Fertre +M: Philippe Cornu M: Benjamin Gaignard M: Vincent Abriou L: dri-de...@lists.freedesktop.org @@ -8116,7 +8116,7 @@ F:include/linux/hugetlb.h F: mm/hugetlb.c HVA ST MEDIA DRIVER -M: Jean-Christophe Trotin +M: Jean-Christophe Trotin L: linux-me...@vger.kernel.org S: Supported W: https://linuxtv.org @@ -10972,7 +10972,7 @@ T: git git://linuxtv.org/media_tree.git F: drivers/media/dvb-frontends/stv6111* MEDIA DRIVERS FOR STM32 - DCMI -M: Hugues Fruchet +M: Hugues Fruchet L: linux-me...@vger.kernel.org S: Supported T: git git://linuxtv.org/media_tree.git @@ -16567,7 +16567,7 @@ F: Documentation/devicetree/bindings/media/i2c/st,st-mipid02.txt F: drivers/media/i2c/st-mipid02.c ST STM32 I2C/SMBUS DRIVER -M: Pierre-Yves MORDRET +M: Pierre-Yves MORDRET L: linux-...@vger.kernel.org S: Maintained F: drivers/i2c/busses/i2c-stm32* @@ -16682,7 +16682,7 @@ S: Maintained F: drivers/block/skd*[ch] STI AUDIO (ASoC) DRIVERS -M: Arnaud Pouliquen +M: Arnaud Pouliquen L: alsa-de...@alsa-project.org (moderated for non-subscribers) S: Maintained F: Documentation/devicetree/bindings/sound/st,sti-asoc-card.txt @@ -16702,15 +16702,15 @@ T:git git://linuxtv.org/media_tree.git F: drivers/media/usb/stk1160/ STM32 AUDIO (ASoC) DRIVERS -M: Olivier Moysan -M: Arnaud Pouliquen +M: Olivier Moysan +M: Arnaud Pouliquen L: alsa-de...@alsa-project.org (moderated for non-subscribers) S: Maintained F: Documentation/devicetree/bindings/sound/st,stm32-*.txt F: sound/soc/stm/ STM32 TIMER/LPTIMER DRIVERS -M: Fabrice Gasnier +M: Fabrice Gasnier S: Maintained F: Documentation/ABI/testing/*timer-stm32 F: Documentation/devicetree/bindings/*/*stm32-*timer* @@ -16720,7 +16720,7 @@ F: include/linux/*/stm32-*tim* STMMAC ETHERNET DRIVER M: Giuseppe Cavallaro -M: Alexandre Torgue +M: Alexandre Torgue M: Jose Abreu L: net...@vger.kernel.org S: Supported -- 2.17.1
[PATCH 2/2] MAINTAINERS: Remove Vincent Abriou for STM/STI DRM drivers.
From: Patrice Chotard Remove Vincent Abriou's email as he has no more review activities on STM/STI DRM drivers. Signed-off-by: Patrice Chotard Cc: Vincent Abriou --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 685b72a22cee..010160a89a10 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5913,7 +5913,6 @@ F:drivers/gpu/drm/rockchip/ DRM DRIVERS FOR STI M: Benjamin Gaignard -M: Vincent Abriou L: dri-de...@lists.freedesktop.org S: Maintained T: git git://anongit.freedesktop.org/drm/drm-misc @@ -5924,7 +5923,6 @@ DRM DRIVERS FOR STM M: Yannick Fertre M: Philippe Cornu M: Benjamin Gaignard -M: Vincent Abriou L: dri-de...@lists.freedesktop.org S: Maintained T: git git://anongit.freedesktop.org/drm/drm-misc -- 2.17.1
Re: [PATCH] checkpatch: fix false positive for COMMIT_LOG_LONG_LINE with URLs
On Thu, 2020-12-17 at 19:12 +0530, Aditya Srivastava wrote:
> Currently checkpatch warns for long line in commit messages even for
> URL lines.
>
> An evaluation over v4.13..v5.8 showed that out of ~11000 warnings for
> this class, around 790 are due to the line containing link.
>
> E.g. running checkpatch on commit 3cde818cd02b ("ASoC: topology:
> Consolidate how dtexts and dvalues are freed") reports this warning:
>
> WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per
> line)
> https://mailman.alsa-project.org/pipermail/alsa-devel/2019-January/144761.html
>
> Avoid giving users warning for character limit, instead suggest them to
> prefix the URLs with "Link:"
>
> Signed-off-by: Aditya Srivastava
> ---
> scripts/checkpatch.pl | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -3032,8 +3032,14 @@ sub process {
> $line =~ /^\s*(?:Fixes:|Link:|$signature_tags)/i ||
> # A Fixes: or Link: line or signature
> tag line
> $commit_log_possible_stack_dump)) {
> - WARN("COMMIT_LOG_LONG_LINE",
> - "Possible unwrapped commit description (prefer a
> maximum 75 chars per line)\n" . $herecurr);
> + if ($line =~ /(?:http|https|ftp):\/\//) {
> + WARN("COMMIT_LOG_LONG_LINE",
> + "Consider prefixing the URL with
> 'Link:'\n" . $herecurr);
> + }
> + else {
> + WARN("COMMIT_LOG_LONG_LINE",
> + "Possible unwrapped commit description
> (prefer a maximum 75 chars per line)\n" . $herecurr);
> + }
NAK.
Aditya, you've submitted several patches to checkpatch and
you should know better by now what coding style is necessary
for acceptance.
} else {
Make the URI/URL check follow the styles allowed by RFC 3986.
Look at the long_line check around line 3500 introduced by
commit 2e4bbbc550be336cbb3defc67430fc0700aa1426
Author: Andreas Brauchli
Date: Tue Feb 6 15:38:45 2018 -0800
checkpatch: allow long lines containing URL
Also likely the URI should not be allowed to exceed the line
maximum unless it's the first non-whitespace of the line and
not starting after some other word in the line.
Lastly, this sets $commit_log_long_line even for lines that
are now nominally exempted from the long line check.
The number of nominal fixes you showed above is not correct.
Retrospective testing of checkpatch using --git history
should be aware of changes to checkpatch.
This should count only lines from 75 to 80 chars for the
commit range you tested and only for 75 to 100 for commits
after checkpatch changed its allowed long line maximum in
commit bdc48fa11e46f867ea4d75fa59ee87a7f48be144
checkpatch/coding-style: deprecate 80-column warning
general protection fault in bond_ipsec_add_sa
Hello, syzbot found the following issue on: HEAD commit:6bff9bb8 Merge tag 'scsi-fixes' of git://git.kernel.org/pu.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=14aba80f50 kernel config: https://syzkaller.appspot.com/x/.config?x=a438b63f5a7f3806 dashboard link: https://syzkaller.appspot.com/bug?extid=cfd446c119a93741a3c2 compiler: gcc (GCC) 10.1.0-syz 20200507 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+cfd446c119a93741a...@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdc00: [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x-0x0007] CPU: 3 PID: 10570 Comm: syz-executor.0 Not tainted 5.10.0-rc7-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:bond_ipsec_add_sa+0x9e/0x240 drivers/net/bonding/bond_main.c:396 Code: 04 31 ff 89 c3 89 c6 e8 f0 2c d8 fc 85 db 0f 85 f6 00 00 00 e8 93 34 d8 fc 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 5f 01 00 00 48 8d bd d0 02 00 00 49 8b 5d 00 48 RSP: 0018:c90002e47498 EFLAGS: 00010246 RAX: dc00 RBX: 0001 RCX: c90006ee9000 RDX: RSI: 8497d16d RDI: 0001 RBP: 888016539c00 R08: R09: R10: R11: 0001 R12: 88806c23 R13: R14: 888016539ee0 R15: 888016539ee4 FS: 7f5eca4f9700() GS:88802cd0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 007120d0 CR3: 50d1d000 CR4: 00350ee0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: xfrm_dev_state_add+0x2da/0x7b0 net/xfrm/xfrm_device.c:268 xfrm_state_construct net/xfrm/xfrm_user.c:655 [inline] xfrm_add_sa+0x2166/0x34f0 net/xfrm/xfrm_user.c:684 xfrm_user_rcv_msg+0x42f/0x8b0 net/xfrm/xfrm_user.c:2752 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494 xfrm_netlink_rcv+0x6b/0x90 net/xfrm/xfrm_user.c:2764 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:671 sys_sendmsg+0x6e8/0x810 net/socket.c:2353 ___sys_sendmsg+0xf3/0x170 net/socket.c:2407 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45dcd9 Code: bd b1 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 8b b1 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f5eca4f8c78 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 0045dcd9 RDX: RSI: 2180 RDI: 0003 RBP: 004aae00 R08: R09: R10: R11: 0246 R12: 0075bf40 R13: 7ffcc1582edf R14: 7f5eca4d9000 R15: 0003 Modules linked in: ---[ end trace f71849d5db08409b ]--- RIP: 0010:bond_ipsec_add_sa+0x9e/0x240 drivers/net/bonding/bond_main.c:396 Code: 04 31 ff 89 c3 89 c6 e8 f0 2c d8 fc 85 db 0f 85 f6 00 00 00 e8 93 34 d8 fc 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 5f 01 00 00 48 8d bd d0 02 00 00 49 8b 5d 00 48 RSP: 0018:c90002e47498 EFLAGS: 00010246 RAX: dc00 RBX: 0001 RCX: c90006ee9000 RDX: RSI: 8497d16d RDI: 0001 RBP: 888016539c00 R08: R09: R10: R11: 0001 R12: 88806c23 R13: R14: 888016539ee0 R15: 888016539ee4 FS: 7f5eca4f9700() GS:88802cd0() knlGS: CS: 0010 DS: ES: CR0: 80050033 --- 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: linux-next: manual merge of the akpm-current tree with the risc-v tree
On Thu, 17 Dec 2020 01:40:51 PST (-0800), andy.shevche...@gmail.com wrote:
On Thu, Dec 17, 2020 at 3:28 AM Stephen Rothwell wrote:
Hi all,
On Mon, 14 Dec 2020 20:21:07 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> lib/Makefile
>
> between commit:
>
> 527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
>
> from the risc-v tree and commits:
>
> 8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit
tests")
> 17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention for
KUnit tests")
> 23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit
tests")
> 1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")
AFAIU Linus rejected the above patches. I hope kselftest/kunit tree
can pick them up.
> diff --cc lib/Makefile
> index bcedd691ef63,dc623561ef9d..
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
>
> # KUnit tests
> obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
> - obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
> - obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
> - obj-$(CONFIG_BITS_TEST) += test_bits.o
> + obj-$(CONFIG_BITS_TEST) += bits_kunit.o
> + obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
> + obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
> + obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
> +
> +obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o
This is now a conflict between the risc-v tree and Linus' tree.
Yeah, and it's slightly different. Perhaps RISC-V tree can handle this
by moving Makefile entry somewhere else in the file.
I was planning on just posting the merge conflict along with the PR, which I
was going to do this morning (though in practice that means this afternoon...
;)). I'd been considering fixing this stuff as I was likely going to have to
rewrite history to sort out our boot bug, but as it's only manifesting on
old-ish QEMU versions I've decided that it's not really worth making it a
blocker.
If you think that's an issue then I'm happy to rewrite my history, but I do
generally try to stay away from that and for this sort of thing I've yet to
have any complaints. I probably will put it up near the other GENERIC_LIB
stuff in my conflict resolution, though.
Re: dwc: tegra194: issue with card containing a bridge
On Thu, Dec 17, 2020 at 08:58:57AM -0600, Rob Herring wrote: > On Tue, Dec 15, 2020 at 09:52:35PM +0100, Mian Yousaf Kaukab wrote: > > On Tue, Dec 15, 2020 at 09:41:47AM -0600, Rob Herring wrote: > > > On Tue, Dec 15, 2020 at 02:25:04PM +0100, Mian Yousaf Kaukab wrote: > > > > On Tue, Dec 15, 2020 at 05:45:59PM +0530, Vidya Sagar wrote: > > > > > Thanks Mian for bringing it to our notice. > > > > > Have you tried removing the dw_pcie_setup_rc(pp); call from > > > > > pcie-tegra194.c > > > > > file on top of linux-next? and does that solve the issue? > > > > > > > > > > diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c > > > > > b/drivers/pci/controller/dwc/pcie-tegra194.c > > > > > index 5597b2a49598..1c9e9c054592 100644 > > > > > --- a/drivers/pci/controller/dwc/pcie-tegra194.c > > > > > +++ b/drivers/pci/controller/dwc/pcie-tegra194.c > > > > > @@ -907,7 +907,7 @@ static void tegra_pcie_prepare_host(struct > > > > > pcie_port > > > > > *pp) > > > > > dw_pcie_writel_dbi(pci, > > > > > CFG_TIMER_CTRL_MAX_FUNC_NUM_OFF, > > > > > val); > > > > > } > > > > > > > > > > - dw_pcie_setup_rc(pp); > > > > > + //dw_pcie_setup_rc(pp); > > > > I still see the same issue with this change. > > > > Reverting b9ac0f9dc8ea works though. > > > > > > > > > > clk_set_rate(pcie->core_clk, GEN4_CORE_CLK_FREQ); > > > > > > > > > > I took a quick look at the dw_pcie_setup_rc() implementation and I'm > > > > > not > > > > > sure why calling it second time should create any issue for the > > > > > enumeration > > > > > of devices behind a switch. Perhaps I need to spend more time to > > > > > debug that > > > > > part. > > > > > In any case, since dw_pcie_setup_rc() is already part of > > > > > dw_pcie_host_init(), I think it can be removed from > > > > > tegra_pcie_prepare_host() implemention. > > > > > > I think the 2nd time is making the link go down is my guess. Tegra was > > > odd in that its start/stop link functions don't do link handling, so I > > > didn't implement those functions and left the link handling in the Tegra > > > driver. > > > > > > Can you try the below patch. It needs some more work as it breaks > > > endpoint mode. > > [...] > > > Boot is ok with this patch. Some improvement in lspci as well: > > Some improvement? Meaning not completely working still? > > > # lspci > > 0001:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad2 (rev a1) > > 0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 > > (rev 13) > > 0005:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad0 (rev a1) > > 0005:01:00.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab) > > This patch was closer to the original flow, but would not have worked if > DLFE disabled mode was needed. > > Please give this patch a try: Thank you for the patch! Initial results with it looks very promising. I’ll get back to you tomorrow after running a few more tests. BR, Yousaf
Re: [PATCH v8 3/3] net: ax88796c: ASIX AX88796C SPI Ethernet Adapter Driver
On Thu, 17 Dec 2020 12:46:57 +0100 Lukasz Stelmach wrote:
> > to the correct values so the stack pre-allocates the needed spaces,
> > when it can.
>
> Yes, I fonud these. However, I am not sure setting needed_tailroom has
> any effect. In many places where alloc_skb() is called needed_headrom
> and hard_header_len are refered to via the LL_RESERVED_SPACE macro. But
> the macro does not refer to needed_tailroom. Once (f5184d267c1a ("net:
> Allow netdevices to specify needed head/tailroom") there was
> LL_ALLOCATED_SPACE macro, but but it was removed in 56c978f1da1f ("net:
> Remove LL_ALLOCATED_SPACE"). And now only some protocols refer to
> needet_tailroom.
Yeah, tailroom is used a lot less often. Only really crappy HW requires
it.
> BTW. What is hard_header_len for? Is it the length of the link layer
> header? Considering "my" hardware requires some headers with each
> packet, I find hard_headr_len name a bit confusing.
Yup, L2 headers, not hardware. Not sure why "hard" was chosen, that must
have happened way back.
Re: [PATCH v3 0/3] UIO support for dfl devices
On Thu, Dec 17, 2020 at 05:35:51AM -0800, Tom Rix wrote: > > On 12/16/20 9:44 PM, Xu Yilun wrote: > > This patchset supports some dfl device drivers written in userspace. > > > > In the patchset v1, the "driver_override" interface should be used to bind > > the DFL UIO driver to DFL devices. But there is concern that the > > "driver_override" interface is not OK itself. So in v2, we use a new > > matching algorithem. The "driver_override" interface is abandoned, the DFL > > UIO driver matches any DFL device which could not be handled by other DFL > > drivers. So the DFL UIO driver could be used for new DFL devices which are > > not supported by kernel, also it will not impact the devices which are > > already got supported. > > This set looks good to me. > > Moritz, > > Is it possible to get this into 5.11 ? How would that be possible? New features have to be in linux-next successfully, _BEFORE_ the merge window opens. Please read Documentation/process/ for how we do all of this... thanks, greg k-h
Re: [PATCH] cpufreq: intel_pstate: Use the latest guaranteed freq during verify
On Thu, 2020-12-17 at 16:24 +0100, Rafael J. Wysocki wrote:
> On Thu, Dec 17, 2020 at 4:21 PM Srinivas Pandruvada
> wrote:
> >
> > On Thu, 2020-12-17 at 16:12 +0100, Rafael J. Wysocki wrote:
> > > On Thursday, December 17, 2020 3:23:44 PM CET Srinivas Pandruvada
> > > wrote:
> > > > On Thu, 2020-12-17 at 06:19 -0800, Srinivas Pandruvada wrote:
> > > > > On Thu, 2020-12-17 at 14:58 +0100, Rafael J. Wysocki wrote:
> > > > > > On Thu, Dec 17, 2020 at 11:44 AM Srinivas Pandruvada
> > > > > > wrote:
> > > > > > >
> > > > > > > This change tries to address an issue, when BIOS disabled
> > > > > > > turbo
> > > > > > > but HWP_CAP guaranteed is changed later and user space
> > > > > > > wants
> > > > > > > to
> > > > > > > take
> > > > > > > advantage of this increased guaranteed performance.
> > > > > > >
> > > > > > > The HWP_CAP.GUARANTEED value is not a static value. It
> > > > > > > can be
> > > > > > > changed
> > > > > > > by some out of band agent or during Intel Speed Select
> > > > > > > performance
> > > > > > > level change. The HWP_CAP.MAX still shows max possible
> > > > > > > performance
> > > > > > > when
> > > > > > > BIOS disabled turbo. So guaranteed can still change as
> > > > > > > long
> > > > > > > as
> > > > > > > this
> > > > > > > is
> > > > > > > same or below HWP_CAP.MAX.
> > > > > > >
> > > > > > > When guaranteed is changed, the sysfs base_frequency
> > > > > > > attributes
> > > > > > > shows
> > > > > > > the latest guaranteed frequency. This attribute can be
> > > > > > > used
> > > > > > > by
> > > > > > > user
> > > > > > > space software to update scaling min/max frequency.
> > > > > > >
> > > > > > > Currently the setpolicy callback already uses the latest
> > > > > > > HWP_CAP
> > > > > > > values when setting HWP_REQ. But the verify callback will
> > > > > > > still
> > > > > > > restrict
> > > > > > > the user settings to the to old guaranteed value. So if
> > > > > > > the
> > > > > > > guaranteed
> > > > > > > is increased, user space can't take advantage of it.
> > > > > > >
> > > > > > > To solve this similar to setpolicy callback, read the
> > > > > > > latest
> > > > > > > HWP_CAP
> > > > > > > values and use it to restrict the maximum setting. This
> > > > > > > is
> > > > > > > done
> > > > > > > by
> > > > > > > calling intel_pstate_get_hwp_max(), which already
> > > > > > > accounts
> > > > > > > for
> > > > > > > user
> > > > > > > and BIOS turbo disable to get the current max
> > > > > > > performance.
> > > > > > >
> > > > > > > This issue is side effect of fixing the issue of scaling
> > > > > > > frequency
> > > > > > > limits by the
> > > > > > > 'commit eacc9c5a927e ("cpufreq: intel_pstate:
> > > > > > > Fix intel_pstate_get_hwp_max() for turbo disabled")'
> > > > > > > The fix resulted in correct setting of reduced scaling
> > > > > > > frequencies,
> > > > > > > but this resulted in capping HWP.REQ to
> > > > > > > HWP_CAP.GUARANTEED in
> > > > > > > this
> > > > > > > case.
> > > > > > >
> > > > > > > Cc: 5.8+ # 5.8+
> > > > > > > Signed-off-by: Srinivas Pandruvada <
> > > > > > > srinivas.pandruv...@linux.intel.com>
> > > > > > > ---
> > > > > > > drivers/cpufreq/intel_pstate.c | 6 ++
> > > > > > > 1 file changed, 6 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/cpufreq/intel_pstate.c
> > > > > > > b/drivers/cpufreq/intel_pstate.c
> > > > > > > index 2a4db856222f..7081d1edb22b 100644
> > > > > > > --- a/drivers/cpufreq/intel_pstate.c
> > > > > > > +++ b/drivers/cpufreq/intel_pstate.c
> > > > > > > @@ -2199,6 +2199,12 @@ static void
> > > > > > > intel_pstate_clear_update_util_hook(unsigned int cpu)
> > > > > > >
> > > > > > > static int intel_pstate_get_max_freq(struct cpudata
> > > > > > > *cpu)
> > > > > > > {
> > > > > > > + if (hwp_active) {
> > > > > > > + int turbo_max, max_state;
> > > > > > > +
> > > > > > > + intel_pstate_get_hwp_max(cpu->cpu,
> > > > > > > _max,
> > > > > > > _state);
> > > > > >
> > > > > > This would cause intel_pstate_get_hwp_max() to be called
> > > > > > twice
> > > > > > in
> > > > > > intel_pstate_update_perf_limits() which is not perfect.
> > > > >
> > > > > We can optimize by using cached value.
> > > > >
> > > > >
> > > > > diff --git a/drivers/cpufreq/intel_pstate.c
> > > > > b/drivers/cpufreq/intel_pstate.c
> > > > > index 7081d1edb22b..d345c9ef240c 100644
> > > > > --- a/drivers/cpufreq/intel_pstate.c
> > > > > +++ b/drivers/cpufreq/intel_pstate.c
> > > > > @@ -2223,7 +2223,11 @@ static void
> > > > > intel_pstate_update_perf_limits(struct cpudata *cpu,
> > > > > * rather than pure ratios.
> > > > > */
> > > > > if (hwp_active) {
> > > > > - intel_pstate_get_hwp_max(cpu->cpu,
> > > > > _max,
> > > > > _state);
> > > > > + if (global.no_turbo || global.turbo_disabled)
> > > > > + max_state = HWP_GUARANTEED_PERF(cpu-
> > > > > > hwp_cap_cached);
> > > > > +
Re: [PATCH v5 1/7] pwm: pca9685: Switch to atomic API
On Thu, Dec 17, 2020 at 11:48 AM Clemens Gruber wrote: > > I can initialize the values to 0 of course and check the file for other > places with missing initializations. > > Or would it be better to check the return codes of regmap_read/write in > such cases? I'm not sure. I think that checking the regmap_read/write return values is overkill in this driver. These functions can't realistically fail, except if the i2c bus is bad, i.e. h/w failure or intermittency. And that's an externality which I believe we can ignore. Maybe Thierry or Uwe have further insights here.
Re: [EXT] Re: [PATCH 1/2] mmc: Support kmsg dumper based on pstore/blk
On Thu, 17 Dec 2020 at 12:36, Bhaskara Budiredla wrote: > > > [...] > > >> >> An extra check can be added to see if host was runtime suspended > >> >> ahead of panic write attempt. > >> > > >> >What if that is the case, should we just return an error? > >> > > >> Yes. > >> > >> >Moreover, even the device belonging to the mmc card can be runtime > >> >suspended too. So if that is the case, we should return an error too? > >> > > >> > >> Yes, same here. > >> > > Please comment if returning error is sufficient here or > can there be an attempt to wake the device through either of the atomic > activation calls: > pm_runtime_get(), pm_request_resume()? Hmm, I would start with playing with the below. mmc_claim_host supports also nested claims. mmc_claim_host(host) - this will call pm_runtime_get_sync(host) mmc_get_card(card, NULL) - this will call can pm_runtime_get_sync(card)) and also try to claim the host Kind regards Uffe
[PATCH] checkpatch: add new warning when lookup_symbol_name() is used
In most cases people use lookup_symbol_name() to resolve a kernel symbol
and then print it via printk().
In such cases using the %ps, %pS, %pSR or %pB printk formats are easier
to use and thus should be preferred.
Signed-off-by: Helge Deller
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index fab38b493cef..0d5515a3d875 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4317,6 +4317,12 @@ sub process {
"LINUX_VERSION_CODE should be avoided, code should
be for the version to which it is merged\n" . $herecurr);
}
+# avoid lookup_symbol_name()
+ if ($line =~ /\blookup_symbol_name\b/) {
+ WARN("PREFER_PRINTK_FORMAT",
+"If possible prefer %ps or %pS printk format
string to print symbol name instead of using lookup_symbol_name()\n" .
$herecurr);
+ }
+
# check for uses of printk_ratelimit
if ($line =~ /\bprintk_ratelimit\s*\(/) {
WARN("PRINTK_RATELIMITED",
Re: [PATCH v3 6/6] ARM: dts: Add dts for RPi4b + Cirrus Logic Lochnagar2 + CS47L15
On 12/17/20 7:41 AM, 'Richard Fitzgerald' via BCM-KERNEL-FEEDBACK-LIST,PDL wrote: > This adds a devicetree configuration for Raspberry Pi 4b connected to > Cirrus Logic Lochnagar 2 audio development board and CS47L15 codec. > > The common (codec-independent) Lochnagar 2 configuration is separated > into a dtsi to simplify re-using it for other codecs. > > Signed-off-by: Richard Fitzgerald > --- > MAINTAINERS | 1 + > arch/arm/boot/dts/Makefile| 1 + > ...bcm2711-rpi4b-cirrus-lochnagar-cs47l15.dts | 186 > .../dts/bcm2711-rpi4b-cirrus-lochnagar.dtsi | 201 ++ > 4 files changed, 389 insertions(+) > create mode 100644 > arch/arm/boot/dts/bcm2711-rpi4b-cirrus-lochnagar-cs47l15.dts > create mode 100644 arch/arm/boot/dts/bcm2711-rpi4b-cirrus-lochnagar.dtsi > > diff --git a/MAINTAINERS b/MAINTAINERS > index 5cc595ac7b28..7dca1db52144 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4193,6 +4193,7 @@ M: Charles Keepax > M: Richard Fitzgerald > L: patc...@opensource.cirrus.com > S: Supported > +F: arch/arm/boot/dts/bcm2711-rpi4b-cirrus-lochnagar* > F: Documentation/devicetree/bindings/clock/cirrus,lochnagar.yaml > F: Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.yaml > F: Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index ce66ffd5a1bb..240cc58fd954 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -93,6 +93,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \ > bcm2837-rpi-3-b-plus.dtb \ > bcm2837-rpi-cm3-io3.dtb \ > bcm2711-rpi-4-b.dtb \ > + bcm2711-rpi4b-cirrus-lochnagar-cs47l15.dtb \ Is there a reason you are not following the convention established above and have this file be named: bcm2711-rpi-4-b-cirrus-lochnagar-cs47l15.dtb? -- Florian
[PATCH] ARM: sti: Fix spelling mistake in Kconfig "targetted" -> "targeted"
From: Colin Ian King There is a spelling mistake in the Kconfig help text. Fix it. Signed-off-by: Colin Ian King --- arch/arm/mach-sti/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig index b2d45cf10a3c..74640bbaeba6 100644 --- a/arch/arm/mach-sti/Kconfig +++ b/arch/arm/mach-sti/Kconfig @@ -50,7 +50,7 @@ config SOC_STIH407 select STIH407_RESET help This enables support for STMicroelectronics Digital Consumer - Electronics family StiH407 parts, targetted at set-top-box + Electronics family StiH407 parts, targeted at set-top-box and other digital audio/video applications using Flattened Device Trees. -- 2.29.2
Re: i386: rcu-torture: WARNING: at kernel/rcu/rcutorture.c:1169 rcu_torture_writer [rcutorture]
> Is this reproducible? If so, could you please try bisection? Yes. This issue is reproducible. I will run bisection and get back to you (might take some time). - Naresh
Re: [PATCH] ARM: sti: Fix spelling mistake in Kconfig "targetted" -> "targeted"
Hi Colin On 12/17/20 6:13 PM, Colin King wrote: > From: Colin Ian King > > There is a spelling mistake in the Kconfig help text. Fix it. > > Signed-off-by: Colin Ian King > --- > arch/arm/mach-sti/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig > index b2d45cf10a3c..74640bbaeba6 100644 > --- a/arch/arm/mach-sti/Kconfig > +++ b/arch/arm/mach-sti/Kconfig > @@ -50,7 +50,7 @@ config SOC_STIH407 > select STIH407_RESET > help > This enables support for STMicroelectronics Digital Consumer > - Electronics family StiH407 parts, targetted at set-top-box > + Electronics family StiH407 parts, targeted at set-top-box > and other digital audio/video applications using Flattened Device > Trees. > Reviewed-by: Patrice Chotard Thanks Patrice
[PATCH] timekeeping: Fix spelling mistake in Kconfig "fullfill" -> "fulfill"
From: Colin Ian King There is a spelling mistake in the Kconfig help text. Fix it. Signed-off-by: Colin Ian King --- kernel/time/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig index 9a41848b6ebb..83e158d016ba 100644 --- a/kernel/time/Kconfig +++ b/kernel/time/Kconfig @@ -141,7 +141,7 @@ config CONTEXT_TRACKING_FORCE dynticks working. This option stands for testing when an arch implements the - context tracking backend but doesn't yet fullfill all the + context tracking backend but doesn't yet fulfill all the requirements to make the full dynticks feature working. Without the full dynticks, there is no way to test the support for context tracking and the subsystems that rely on it: RCU -- 2.29.2
Re: [PATCH -next] tools: perf: convert comma to semicolon
On Wed, 2020-12-16 at 21:15 +0800, Zheng Yongjun wrote:
> Replace a comma between expression statements by a semicolon.
If you are going to submit patches for comma/semicolon conversions,
please to not use checkpatch to produce them.
checkpatch is a trivial tool that does not have very good coverage
of the possible uses of commas that would generally be written with
a semicolon.
Use the coccinelle script that Julia Lawall provided instead.
https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2008201856110.2524@hadrien/
This misses these 2 uses in tools/perf.
diff --git a/tools/perf/ui/tui/util.c b/tools/perf/ui/tui/util.c
index 0f562e2cb1e8..ee549b07b9ae 100644
--- a/tools/perf/ui/tui/util.c
+++ b/tools/perf/ui/tui/util.c
@@ -190,7 +190,7 @@ void __ui__info_window(const char *title, const char *text,>
nr_lines += 2;
if (exit_msg)
nr_lines += 2;
- y = SLtt_Screen_Rows / 2 - nr_lines / 2,
+ y = SLtt_Screen_Rows / 2 - nr_lines / 2;
x = SLtt_Screen_Cols / 2 - max_len / 2;
SLsmg_set_color(0);
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 1cad6051d8b0..76abb08f9e14 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -269,7 +269,7 @@ struct evsel *evsel__new_idx(struct perf_event_attr *attr,
int idx)
if (evsel__is_bpf_output(evsel)) {
evsel->core.attr.sample_type |= (PERF_SAMPLE_RAW |
PERF_SAMPLE_TIME |
- PERF_SAMPLE_CPU |
PERF_SAMPLE_PERIOD),
+ PERF_SAMPLE_CPU |
PERF_SAMPLE_PERIOD);
evsel->core.attr.sample_period = 1;
}
> Signed-off-by: Zheng Yongjun
> ---
> tools/perf/builtin-diff.c | 4 ++--
> tools/perf/builtin-inject.c | 2 +-
> tools/perf/ui/browsers/annotate.c | 2 +-
> tools/perf/util/annotate.c| 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
> index cefc71506409..9064419b108f 100644
> --- a/tools/perf/builtin-diff.c
> +++ b/tools/perf/builtin-diff.c
> @@ -1912,8 +1912,8 @@ static int data_init(int argc, const char **argv)
> struct perf_data *data = >data;
>
>
> data->path = use_default ? defaults[i] : argv[i];
> - data->mode = PERF_DATA_MODE_READ,
> - data->force = force,
> + data->mode = PERF_DATA_MODE_READ;
> + data->force = force;
>
>
> d->idx = i;
> }
> diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
> index 0462dc8db2e3..235a91a907fd 100644
> --- a/tools/perf/builtin-inject.c
> +++ b/tools/perf/builtin-inject.c
> @@ -747,7 +747,7 @@ static int __cmd_inject(struct perf_inject *inject)
> inject->tool.auxtrace_info = perf_event__process_auxtrace_info;
> inject->tool.auxtrace = perf_event__process_auxtrace;
> inject->tool.aux= perf_event__drop_aux;
> - inject->tool.itrace_start = perf_event__drop_aux,
> + inject->tool.itrace_start = perf_event__drop_aux;
> inject->tool.ordered_events = true;
> inject->tool.ordering_requires_timestamps = true;
> /* Allow space in the header for new attributes */
> diff --git a/tools/perf/ui/browsers/annotate.c
> b/tools/perf/ui/browsers/annotate.c
> index bd77825fd5a1..3d857b1e0e62 100644
> --- a/tools/perf/ui/browsers/annotate.c
> +++ b/tools/perf/ui/browsers/annotate.c
> @@ -928,7 +928,7 @@ int symbol__tui_annotate(struct map_symbol *ms, struct
> evsel *evsel,
>
>
> browser.b.width = notes->max_line_len;
> browser.b.nr_entries = notes->nr_entries;
> - browser.b.entries = >src->source,
> + browser.b.entries = >src->source;
> browser.b.width += 18; /* Percentage */
>
>
> if (notes->options->hide_src_code)
> diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
> index 6c8575e182ed..3b4663f8229e 100644
> --- a/tools/perf/util/annotate.c
> +++ b/tools/perf/util/annotate.c
> @@ -367,7 +367,7 @@ static int jump__parse(struct arch *arch, struct
> ins_operands *ops, struct map_s
> }
>
>
> target.addr = map__objdump_2mem(map, ops->target.addr);
> - start = map->unmap_ip(map, sym->start),
> + start = map->unmap_ip(map, sym->start);
> end = map->unmap_ip(map, sym->end);
>
>
> ops->target.outside = target.addr < start || target.addr > end;
[PATCH] mpt3sas: fix spelling mistake in Kconfig: "compatiblity" -> "compatibility"
From: Colin Ian King There is a spelling mistake in the Kconfig help text. Fix it. Signed-off-by: Colin Ian King --- drivers/scsi/mpt3sas/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/mpt3sas/Kconfig b/drivers/scsi/mpt3sas/Kconfig index 86209455172d..c299f7e078fb 100644 --- a/drivers/scsi/mpt3sas/Kconfig +++ b/drivers/scsi/mpt3sas/Kconfig @@ -79,5 +79,5 @@ config SCSI_MPT2SAS select SCSI_MPT3SAS depends on PCI && SCSI help - Dummy config option for backwards compatiblity: configure the MPT3SAS + Dummy config option for backwards compatibility: configure the MPT3SAS driver instead. -- 2.29.2
Re: [PATCH] x86/sev-es: Fix SEV-ES OUT/IN immediate opcode vc handling
On Wed, Dec 16, 2020, Peter Gonda wrote: > > The IN and OUT immediate instructions only use an 8-bit immediate. The > current VC handler uses the entire 32-bit immediate value. These > instructions only set the first bytes. > > Tested with a loop back port with "outb %0,$0xe0". Before the port seen > by KVM was 0xffe0 instead of 0xe0. After the correct port > was seen by KVM and the guests loop back OUT then IN were equal. > > > Signed-off-by: Peter Gonda > Acked-by: David Rientjes > > > --- > arch/x86/kernel/sev-es-shared.c | 8 ++-- > drivers/Makefile| 1 + > 2 files changed, 7 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kernel/sev-es-shared.c b/arch/x86/kernel/sev-es-shared.c > index 7d04b356d44d..6c790377c55c 100644 > --- a/arch/x86/kernel/sev-es-shared.c > +++ b/arch/x86/kernel/sev-es-shared.c > @@ -305,14 +305,14 @@ static enum es_result vc_ioio_exitinfo(struct > es_em_ctxt *ctxt, u64 *exitinfo) > case 0xe4: > case 0xe5: > *exitinfo |= IOIO_TYPE_IN; > - *exitinfo |= (u64)insn->immediate.value << 16; > + *exitinfo |= insn->immediate.bytes[0] << 16; Can't we just drop the explicit cast to u64? Or explicitly cast to u8? Doesn't really matter, but poking into the backing bytes feels a bit backwards. > break; > > /* OUT immediate opcodes */ > case 0xe6: > case 0xe7: > *exitinfo |= IOIO_TYPE_OUT; > - *exitinfo |= (u64)insn->immediate.value << 16; > + *exitinfo |= insn->immediate.bytes[0] << 16; > break;
[RFC PATCH v2] taskstats: add /proc/taskstats to fetch pid/tgid status
If a program needs monitor lots of process's status, it needs two
syscalls for every process. The first one is telling kernel which
pid/tgid should be monitored by send a command(write socket) to kernel.
The second one is read the statistics by read socket. This patch add
a new interface /proc/taskstats to reduce two syscalls to one ioctl.
The user just set the target pid/tgid to the struct taskstats.ac_pid,
then kernel will collect statistics for that pid/tgid.
Signed-off-by: Weiping Zhang
---
Changes since v1:
* use /proc/taskstats instead of /dev/taskstats
include/uapi/linux/taskstats.h | 5 +++
kernel/taskstats.c | 73 +-
2 files changed, 77 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/taskstats.h b/include/uapi/linux/taskstats.h
index ccbd08709321..077eab84c77e 100644
--- a/include/uapi/linux/taskstats.h
+++ b/include/uapi/linux/taskstats.h
@@ -214,6 +214,11 @@ enum {
#define TASKSTATS_CMD_ATTR_MAX (__TASKSTATS_CMD_ATTR_MAX - 1)
+/* ioctl command */
+#define TASKSTATS_IOC_ATTR_PID _IO('T', TASKSTATS_CMD_ATTR_PID)
+#define TASKSTATS_IOC_ATTR_TGID_IO('T', TASKSTATS_CMD_ATTR_TGID)
+
+
/* NETLINK_GENERIC related info */
#define TASKSTATS_GENL_NAME"TASKSTATS"
diff --git a/kernel/taskstats.c b/kernel/taskstats.c
index a2802b6ff4bb..c0f9e2f2308b 100644
--- a/kernel/taskstats.c
+++ b/kernel/taskstats.c
@@ -21,6 +21,8 @@
#include
#include
#include
+#include
+#include
/*
* Maximum length of a cpumask that can be specified in
@@ -28,6 +30,10 @@
*/
#define TASKSTATS_CPUMASK_MAXLEN (100+6*NR_CPUS)
+#ifdef CONFIG_PROC_FS
+#define PROC_TASKSTATS "taskstats"
+#endif
+
static DEFINE_PER_CPU(__u32, taskstats_seqnum);
static int family_registered;
struct kmem_cache *taskstats_cache;
@@ -666,6 +672,60 @@ static struct genl_family family __ro_after_init = {
.n_ops = ARRAY_SIZE(taskstats_ops),
};
+#ifdef CONFIG_PROC_FS
+static long taskstats_ioctl_pid_tgid(unsigned long arg, bool tgid)
+{
+ struct taskstats kstat;
+ struct taskstats *ustat = (struct taskstats *)arg;
+ u32 id;
+ unsigned long offset = offsetof(struct taskstats, ac_pid);
+ long ret;
+
+ /* userspace set monitored pid/tgid to the field "ac_pid" */
+ if (unlikely(copy_from_user(, (void *)(arg + offset), sizeof(u32
+ return -EFAULT;
+
+ if (tgid)
+ ret = fill_stats_for_tgid(id, );
+ else
+ ret = fill_stats_for_pid(id, );
+ if (ret < 0)
+ return ret;
+
+ if (unlikely(copy_to_user(ustat, , sizeof(struct taskstats
+ return -EFAULT;
+
+ return 0;
+}
+
+static long taskstats_ioctl(struct file *file, unsigned int cmd, unsigned long
arg)
+{
+ long ret;
+
+ switch (cmd) {
+ case TASKSTATS_IOC_ATTR_PID:
+ ret = taskstats_ioctl_pid_tgid(arg, false);
+ break;
+ case TASKSTATS_IOC_ATTR_TGID:
+ ret = taskstats_ioctl_pid_tgid(arg, true);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ return ret;
+}
+
+static const struct proc_ops taskstats_proc_ops = {
+ .proc_ioctl = taskstats_ioctl,
+#ifdef CONFIG_COMPAT
+ .proc_compat_ioctl = taskstats_ioctl,
+#endif
+};
+#endif
+
+
/* Needed early in initialization */
void __init taskstats_init_early(void)
{
@@ -682,9 +742,20 @@ static int __init taskstats_init(void)
{
int rc;
+#ifdef CONFIG_PROC_FS
+ if (!proc_create(PROC_TASKSTATS, 0, NULL, _proc_ops)) {
+ pr_err("failed to create /proc/%s\n", PROC_TASKSTATS);
+ return -1;
+ }
+#endif
+
rc = genl_register_family();
- if (rc)
+ if (rc) {
+#ifdef CONFIG_PROC_FS
+ remove_proc_entry(PROC_TASKSTATS, NULL);
+#endif
return rc;
+ }
family_registered = 1;
pr_info("registered taskstats version %d\n", TASKSTATS_GENL_VERSION);
--
2.17.2
[PATCH] xtensa: fix spelling mistake in Kconfig "wont" -> "won't"
From: Colin Ian King There is a spelling mistake in the Kconfig help text. Fix it. Signed-off-by: Colin Ian King --- arch/xtensa/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig index 37ce1489364e..97beddc9d645 100644 --- a/arch/xtensa/Kconfig +++ b/arch/xtensa/Kconfig @@ -467,7 +467,7 @@ config INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX then enter your normal kernel breakpoints once the MMU was mapped to the kernel mappings (0XC000). - This unfortunately won't work for U-Boot and likely also wont + This unfortunately won't work for U-Boot and likely also won't work for using KEXEC to have a hot kernel ready for doing a KDUMP. -- 2.29.2
[GIT PULL]: dmaengine update for v5.11-rc1
Hi Linus, Please pull to receive last dmaengine updates for this year :) This contains couple of new drivers, new device support and updates to bunch of drivers. SFR reminded me to tell you that there will be a merge conflict which I am pretty sure would be easy for you. Nevertheless correct resolution is already in linux-next by SFR. The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git tags/dmaengine-5.11-rc1 for you to fetch changes up to 115ff12aecfd55376d704fa2c0a2d117e5827f9f: soc: ti: k3-ringacc: Use correct error casting in k3_ringacc_dmarings_init (2020-12-14 12:33:09 +0530) dmaengine updates for v5.11-rc1 New drivers/devices - Qualcomm ADM driver - Qualcomm GPI driver - Allwinner A100 DMA support - Microchip Sama7g5 support - Mediatek MT8516 apdma - Updates: - more updates to idxd driver and support for IAX config - runtime PM support for dw driver - TI keystone drivers for 5.11 included here due to dependency for TI drivers Amelie Delaunay (4): dmaengine: stm32-dma: rework irq handler to manage error before xfer events dmaengine: stm32-dma: clean channel configuration when channel is freed dmaengine: stm32-dma: take address into account when computing max width dmaengine: stm32-mdma: rework interrupt handler Andy Shevchenko (2): dmaengine: dw: Enable runtime PM dmaengine: idma64: Switch to use __maybe_unused instead of ifdeffery Barry Song (10): dmaengine: ipu_idmac: remove redundant irqsave and restore in hardIRQ dmaengine: ti: k3-udma: remove redundant irqsave and irqrestore in hardIRQ dmaengine: sf-pdma: remove redundant irqsave and irqrestore in hardIRQ dmaengine: tegra210-adma: remove redundant irqsave and irqrestore in hardIRQ dmaengine: milbeaut-xdmac: remove redundant irqsave and irqrestore in hardIRQ dmaengine: k3dma: remove redundant irqsave and irqrestore in hardIRQ dmaengine: hisi_dma: remove redundant irqsave and irqrestore in hardIRQ dmaengine: moxart-dma: remove redundant irqsave and irqrestore in hardIRQ dmaengine: ste_dma40: remove redundant irqsave and irqrestore in hardIRQ dmaengine: pxa_dma: remove redundant irqsave and irqrestore in hardIRQ Dave Jiang (8): dmaengine: idxd: fix wq config registers offset programming dmaengine: idxd: Add shared workqueue support dmaengine: idxd: Clean up descriptors with fault error dmaengine: idxd: Add ABI documentation for shared wq dmaengine: idxd: Update calculation of group offset to be more readable dmaengine: idxd: define table offset multiplier dmaengine: idxd: add ATS disable knob for work queues dmaengine: idxd: add IAX configuration support in the IDXD driver Eugen Hristev (4): dt-bindings: dmaengine: at_xdmac: add compatible with microchip,sama7g5 dmaengine: at_xdmac: adapt perid for mem2mem operations dmaengine: at_xdmac: add support for sama7g5 based at_xdmac dmaengine: at_xdmac: add AXI priority support and recommended settings Fabien Parent (1): dt-bindings: dma: mtk-apdma: add bindings for MT8516 SOC Fabio Estevam (3): dmaengine: imx-sdma: Remove unused .id_table support dmaengine: imx-dma: Remove unused .id_table dmaengine: mxs-dma: Remove the unused .id_table Grygorii Strashko (2): dmaengine: ti: k3-udma-glue: move psi-l pairing in channel en/dis functions soc: ti: k3-ringacc: add AM64 DMA rings support. Grzegorz Jaszczyk (1): soc: ti: pruss: Remove wrong check against *get_match_data return value Gustavo A. R. Silva (1): dmaengine: stm32-mdma: Use struct_size() in kzalloc() Jonathan McDowell (2): dmaengine: qcom: Add ADM driver dmaengine: qcom: Fix ADM driver kerneldoc markup Krzysztof Kozlowski (8): dmaengine: ppc4xx: make ppc440spe_adma_chan_list static dmaengine: ppc4xx: remove xor_hw_desc assignment without reading dmaengine: jz4780: drop of_match_ptr from of_device_id table dmaengine: dw-axi-dmac: drop of_match_ptr from of_device_id table dmaengine: mv_xor: drop of_match_ptr from of_device_id table dmaengine: sf: drop of_match_ptr from of_device_id table dmaengine: stm32: mark of_device_id table as maybe unused dmaengine: ti: drop of_match_ptr and mark of_device_id table as maybe unused Lee Jones (6): soc: ti: knav_qmss_queue: Remove set but unchecked variable 'ret' soc: ti: knav_qmss_queue: Fix a whole host of function documentation issues soc: ti: knav_dma: Fix a kernel function doc formatting issue soc: ti: pm33xx: Remove set but unused variable 'ret' soc: ti:
[PATCH 1/2] ARM: dts: imx6q-logicpd: Drop unused clock-names reference
The wlf,wm8962 driver does not use the clock-names property.
Drop it.
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi
b/arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi
index 665d63765cdc..d9de9b4f0c52 100644
--- a/arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi
+++ b/arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi
@@ -238,7 +238,6 @@ wm8962: audio-codec@1a {
compatible = "wlf,wm8962";
reg = <0x1a>;
clocks = < IMX6QDL_CLK_CKO>;
- clock-names = "xclk";
DCVDD-supply = <_audio>;
DBVDD-supply = <_audio>;
AVDD-supply = <_audio>;
--
2.25.1
[PATCH net] net: mvpp2: prs: fix PPPoE with ipv6 packet parse
From: Stefan Chulski
Current PPPoE+IPv6 entry is jumping to 'next-hdr'
field and not to 'DIP' field as done for IPv4.
Fixes: db9d7d36eecc ("net: mvpp2: Split the PPv2 driver to a dedicated
directory")
Reported-by: Liron Himi
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
index b9e5b08..1a272c2 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
@@ -1655,8 +1655,9 @@ static int mvpp2_prs_pppoe_init(struct mvpp2 *priv)
mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_IP6);
mvpp2_prs_sram_ri_update(, MVPP2_PRS_RI_L3_IP6,
MVPP2_PRS_RI_L3_PROTO_MASK);
- /* Skip eth_type + 4 bytes of IPv6 header */
- mvpp2_prs_sram_shift_set(, MVPP2_ETH_TYPE_LEN + 4,
+ /* Jump to DIP of IPV6 header */
+ mvpp2_prs_sram_shift_set(, MVPP2_ETH_TYPE_LEN + 8 +
+MVPP2_MAX_L3_ADDR_SIZE,
MVPP2_PRS_SRAM_OP_SEL_SHIFT_ADD);
/* Set L3 offset */
mvpp2_prs_sram_offset_set(, MVPP2_PRS_SRAM_UDF_TYPE_L3,
--
1.9.1
[PATCH 2/2] arm64: dts: imx8mm-beacon: Drop unused clock-names reference
The wlf,wm8962 driver does not use the clock-names property.
Drop it.
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi
index d6b9dedd168f..6f5e63696ec0 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi
@@ -102,7 +102,6 @@ wm8962: audio-codec@1a {
compatible = "wlf,wm8962";
reg = <0x1a>;
clocks = < IMX8MM_CLK_SAI3_ROOT>;
- clock-names = "xclk";
DCVDD-supply = <_audio>;
DBVDD-supply = <_audio>;
AVDD-supply = <_audio>;
--
2.25.1
Re: [PATCH] dt-bindings: display: bridge: tc358768: Remove maintainer information
Hi Peter. On Wed, Dec 16, 2020 at 09:44:59AM +0200, Peter Ujfalusi wrote: > > On 15/12/2020 16.26, Rob Herring wrote: > > On Tue, 15 Dec 2020 14:42:27 +0200, Peter Ujfalusi wrote: > >> My employment with TI is coming to an end and I will not have access to > >> the board where this bridge is connected to. > >> > >> It is better to remove a soon bouncing email address. > >> > >> Signed-off-by: Peter Ujfalusi > >> --- > >> .../devicetree/bindings/display/bridge/toshiba,tc358768.yaml | 3 --- > >> 1 file changed, 3 deletions(-) > >> > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > yamllint warnings/errors: > > > > dtschema/dtc warnings/errors: > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml: > > 'maintainers' is a required property > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml: > > ignoring, error in schema: > > warning: no schema found in file: > > ./Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > Right, so it is not that easy to not been able to maintain this... :o > > Who should be documented as maintainer? > Andrzej, Neil, David or Daniel? I have no problem being listed as maintainer despite my very limited knowledge on the HW. So unless you end up volunteering then just add me. Sam
Re: [PATCH bpf-next 1/2] bpf: Add a bpf_kallsyms_lookup helper
On 12/17/20 7:31 AM, Florent Revest wrote:
On Mon, Dec 14, 2020 at 7:47 AM Yonghong Song wrote:
On 12/11/20 6:40 AM, Florent Revest wrote:
On Wed, Dec 2, 2020 at 10:18 PM Alexei Starovoitov
wrote:
I still think that adopting printk/vsnprintf for this instead of
reinventing the wheel
is more flexible and easier to maintain long term.
Almost the same layout can be done with vsnprintf
with exception of \0 char.
More meaningful names, etc.
See Documentation/core-api/printk-formats.rst
I agree this would be nice. I finally got a bit of time to experiment
with this and I noticed a few things:
First of all, because helpers only have 5 arguments, if we use two for
the output buffer and its size and two for the format string and its
size, we are only left with one argument for a modifier. This is still
enough for our usecase (where we'd only use "%ps" for example) but it
does not strictly-speaking allow for the same layout that Andrii
proposed.
See helper bpf_seq_printf. It packs all arguments for format string and
puts them into an array. bpf_seq_printf will unpack them as it parsed
through the format string. So it should be doable to have more than
"%ps" in format string.
This could be a nice trick, thank you for the suggestion Yonghong :)
My understanding is that this would also require two extra args (one
for the array of arguments and one for the size of this array) so it
would still not fit the 5 arguments limit I described in my previous
email.
eg: this would not be possible:
long bpf_snprintf(const char *out, u32 out_size,
const char *fmt, u32 fmt_size,
const void *data, u32 data_len)
Right. bpf allows only up to 5 parameters.
Would you then suggest that we also put the format string and its
length in the first and second cells of this array and have something
along the line of:
long bpf_snprintf(const char *out, u32 out_size,
const void *args, u32 args_len) ?
This seems like a fairly opaque signature to me and harder to verify.
One way is to define an explicit type for args, something like
struct bpf_fmt_str_data {
char *fmt;
u64 fmt_len;
u64 data[];
};
The bpf_snprintf signature can be
long bpf_snprintf(const char *out, u32 out_size,
const struct bpf_fmt_str_data *fmt_data,
u32 fmt_data_len);
Internally you can have one argument type for "struct bpf_fmt_str_data"
like PTR_TO_FMT_DATA as a verifier reg state. if bpf_snprintf is used,
when you try to verify PTR_TO_FMT_DATA, you can just verify
fmt_data->fmt and fmt_data->fmt_len which satifies mem contraints.
The rest of data can be passed to the helper as is.
Yes, still some verifier work. But may be useful for this and
future format string related helpers.
[PATCH] mm: Fix spelling mistake in Kconfig "whats" -> "what's"
From: Colin Ian King There is a spelling mistake in the Kconfig help text. Fix it. Signed-off-by: Colin Ian King --- mm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/Kconfig b/mm/Kconfig index 7af1a55b708e..585d440a554a 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -713,7 +713,7 @@ config ZSMALLOC_STAT select DEBUG_FS help This option enables code in the zsmalloc to collect various - statistics about whats happening in zsmalloc and exports that + statistics about what's happening in zsmalloc and exports that information to userspace via debugfs. If unsure, say N. -- 2.29.2
Re: [PATCH] checkpatch: add new warning when lookup_symbol_name() is used
On Thu, 2020-12-17 at 18:11 +0100, Helge Deller wrote:
> In most cases people use lookup_symbol_name() to resolve a kernel symbol
> and then print it via printk().
>
> In such cases using the %ps, %pS, %pSR or %pB printk formats are easier
> to use and thus should be preferred.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -4317,6 +4317,12 @@ sub process {
> "LINUX_VERSION_CODE should be avoided, code should
> be for the version to which it is merged\n" . $herecurr);
> }
>
> +# avoid lookup_symbol_name()
> + if ($line =~ /\blookup_symbol_name\b/) {
> + WARN("PREFER_PRINTK_FORMAT",
> + "If possible prefer %ps or %pS printk format
> string to print symbol name instead of using lookup_symbol_name()\n" .
> $herecurr);
> + }
> +
> # check for uses of printk_ratelimit
> if ($line =~ /\bprintk_ratelimit\s*\(/) {
> WARN("PRINTK_RATELIMITED",
Huh? nak.
lookup_symbol_name is used in the kernel a grand total of 3 times.
2 uses are kprobe, the other is fs/proc
None of the existing uses is equivalent to %ps
Why should this be applied?
Re: New objtool warning..
On Thu, Dec 17, 2020 at 8:25 AM Josh Poimboeuf wrote: > > Oh yeah, I forgot about that. That would be another option if my patch > doesn't work out. Well, one option is to just say "ok, we know gcc generates horrible code that falls through to another function in a situation that we claim is unreachable, so let's not claim it is unreachable". IOW, the problem here is that the compiler fundamentally isn't smart enough to see that something is unreachable, and the "unreachable()" annotation we did didn't actually really cause any code that makes it so. So we basically have code that _if_ we ever change it, it will simply be wrong, and we'll never see any warnings about it but it will fall through to nonsensical code. So maybe the option here is simply "objtool was right before, the unreachable() is fragile and wrong". We can easily write that case statement in a way that actually makes the compiler generate better code and avoids the issue by just making case 0x00 also be the default case. So I think I'll just apply this patch instead. Linus patch Description: Binary data
Re: [PATCH] atm: ambassador: remove h from printk format specifier
On Thu, 17 Dec 2020 05:17:24 -0800 Tom Rix wrote: > On 12/16/20 4:45 PM, Jakub Kicinski wrote: > > On Tue, 15 Dec 2020 06:22:28 -0800 t...@redhat.com wrote: > >> From: Tom Rix > >> > >> See Documentation/core-api/printk-formats.rst. > >> h should no longer be used in the format specifier for printk. > >> > >> Signed-off-by: Tom Rix > > That's for new code I assume? > > > > What's the harm in leaving this ancient code be? > > This change is part of a tree wide cleanup. What's the purpose of the "clean up"? Why is it making the code better? This is a quote from your change: - PRINTK (KERN_NOTICE, "debug bitmap is %hx", debug &= DBG_MASK); + PRINTK (KERN_NOTICE, "debug bitmap is %x", debug &= DBG_MASK); Are you sure that the use of %hx is the worst part of that line? > drivers/atm status is listed as Maintained in MAINTAINERS so changes > like this should be ok. > > Should drivers/atm status be changed? Up to Chas, but AFAIU we're probably only a few years away from ATM as a whole walking into the light. So IMHO "Obsolete" would be justified.
Re: [PATCH v2] fair/util_est: fix schedutil may use an old util_est.enqueued value at dequeue
On 16/12/2020 05:50, Xuewen Yan wrote:
> From: Xuewen Yan
>
> when a task dequeued, it would update it's util and cfs_rq's util,
> the following calling relationship exists here:
>
> update_load_avg() -> cfs_rq_util_change() -> cpufreq_update_util()->
> sugov_update_[shared\|single] -> sugov_get_util() -> cpu_util_cfs();
>
> util = max {rq->cfs.avg.util_avg,rq->cfs.avg.util_est.enqueued };
>
> For those tasks alternate long and short runs scenarios, the
> rq->cfs.avg.util_est.enqueued may be bigger than rq->cfs.avg.util_avg.
> but because the _task_util_est(p) didn't be subtracted, this would
> cause schedutil use an old util_est.enqueued value.
>
> This could have an effect in task ramp-down and ramp-up scenarios.
> when the task dequeued, we hope the freq could be reduced as soon
> as possible. If the schedutil's value is the old util_est.enqueued, this
> may cause the cpu couldn't reduce it's freq.
>
> separate the util_est_dequeue() into util_est_dequeue() and
> util_est_update(), and dequeue the _task_util_est(p) before update util.
IMHO we could still describe it a little bit different:
---
sched/fair: Avoid stale CPU util_est value for schedutil in task dequeue
CPU (root cfs_rq) estimated utilization (util_est) is currently used in
dequeue_task_fair() to drive frequency selection before it is updated.
with:
CPU_util: rq->cfs.avg.util_avg
CPU_util_est: rq->cfs.avg.util_est
CPU_utilization : max(CPU_util, CPU_util_est)
task_util : p->se.avg.util_avg
task_util_est : p->se.avg.util_est
dequeue_task_fair()
/* (1) CPU_util and task_util update + inform schedutil about
CPU_utilization changes */
for_each_sched_entity() /* 2 loops */
(dequeue_entity() ->) update_load_avg() -> cfs_rq_util_change()
-> cpufreq_update_util() ->...-> sugov_update_[shared\|single]
-> sugov_get_util() -> cpu_util_cfs()
/* (2) CPU_util_est and task_util_est update */
util_est_dequeue()
cpu_util_cfs() uses CPU_utilization which could lead to a false (too
high) utilization value for schedutil in task ramp-down or ramp-up
scenarios during task dequeue.
To mitigate the issue split the util_est update (2) into:
(A) CPU_util_est update in util_est_dequeue()
(B) task_util_est update in util_est_update()
Place (A) before (1) and keep (B) where (2) is. The latter is necessary
since (B) relies on task_util update in (1).
---
What do you think?
>
> Signed-off-by: Xuewen Yan
> Signed-off-by: Dietmar Eggemann
Please remove my Signed-off-by line. I'm just reviewing & testing it.
With the comments below adressed you can change it to a:
Reviewed-by: Dietmar Eggemann
> ---
> Changes since v1:
> -change the util_est_dequeue/update to inline type
> -use unsigned int enqueued rather than util_est in util_est_dequeue
> -remove "cpu" var
>
> ---
> kernel/sched/fair.c | 37 +
> 1 file changed, 25 insertions(+), 12 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index ae7ceba..864d6b9 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3945,22 +3945,31 @@ static inline bool within_margin(int value, int
> margin)
> return ((unsigned int)(value + margin - 1) < (2 * margin - 1));
> }
>
> -static void
> -util_est_dequeue(struct cfs_rq *cfs_rq, struct task_struct *p, bool
> task_sleep)
> +static inline void util_est_dequeue(struct cfs_rq *cfs_rq,
> + struct task_struct *p)
Could you move util_est_dequeue above within_margin() since the later is
only used in util_est_update().
> {
> - long last_ewma_diff;
> - struct util_est ue;
> - int cpu;
> + unsigned int enqueued;
>
> if (!sched_feat(UTIL_EST))
> return;
>
> /* Update root cfs_rq's estimated utilization */
> - ue.enqueued = cfs_rq->avg.util_est.enqueued;
> - ue.enqueued -= min_t(unsigned int, ue.enqueued, _task_util_est(p));
> - WRITE_ONCE(cfs_rq->avg.util_est.enqueued, ue.enqueued);
> + enqueued = cfs_rq->avg.util_est.enqueued;
> + enqueued -= min_t(unsigned int, enqueued, _task_util_est(p));
> + WRITE_ONCE(cfs_rq->avg.util_est.enqueued, enqueued);
>
> trace_sched_util_est_cfs_tp(cfs_rq);
> +}
> +
> +static inline void util_est_update(struct cfs_rq *cfs_rq,
> + struct task_struct *p,
> + bool task_sleep)
Nitpick: util_est_enqueue() aligns the arguments on space whereas you do
on tab for util_est_dequeue and util_est_update. I know there is no
strict rule but IMHO these util_est_xxx() should use the same.
[...]
During review I got suspicious about the 'if (sched_feat(UTIL_EST))'
condition in cpu_util_without() mentioning a race window w/
[detach_task() p->on_rq = TASK_ON_RQ_MIGRATING <-> util_est_dequeue()].
But this patch should actually make this window smaller.
Anyway, retested commit c469933e7721 ("sched/fair: Fix cpu_util_wake()
for
Re: [PATCH v4 3/5] mm: Speedup mremap on 1GB or larger regions
On Wed, Oct 14, 2020 at 12:53:08AM +, Kalesh Singh wrote: > Android needs to move large memory regions for garbage collection. > The GC requires moving physical pages of multi-gigabyte heap > using mremap. During this move, the application threads have to > be paused for correctness. It is critical to keep this pause as > short as possible to avoid jitters during user interaction. > > Optimize mremap for >= 1GB-sized regions by moving at the PUD/PGD > level if the source and destination addresses are PUD-aligned. > For CONFIG_PGTABLE_LEVELS == 3, moving at the PUD level in effect moves > PGD entries, since the PUD entry is “folded back” onto the PGD entry. > Add HAVE_MOVE_PUD so that architectures where moving at the PUD level > isn't supported/tested can turn this off by not selecting the config. > > Fix build test error from v1 of this series reported by > kernel test robot in [1]. > > [1] > https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org/thread/CKPGL4FH4NG7TGH2CVYX2UX76L25BTA3/ > > Signed-off-by: Kalesh Singh > Reported-by: kernel test robot > Acked-by: Kirill A. Shutemov > Cc: Andrew Morton I thought I reported it, but maybe I didn't. This patch causes all 'parisc' qemu emulations to fail. Typical log: Freeing unused kernel memory: 604K Write protected read-only-after-init data: 2k rodata_test: end of .rodata is not page size aligned Run /sbin/init as init process process '/bin/busybox' started with executable stack Failed to execute /sbin/init (error -12) Reverting this patch fixes the problem. Bisect log from linux-next below. The patch (and thus the problem) are now in mainline Linux. Guenter --- # bad: [7bba37a1591369e2e506d599b8f5d7d0516b2dbc] Add linux-next specific files for 20201214 # good: [0477e92881850d44910a7e94fc2c46f96faa131f] Linux 5.10-rc7 git bisect start 'HEAD' 'v5.10-rc7' # good: [fe5c40ab90a1f82ba97294637eaf875cfdd7a05f] Merge remote-tracking branch 'nand/nand/next' git bisect good fe5c40ab90a1f82ba97294637eaf875cfdd7a05f # good: [674a0d6de8bd290671f7dff405205871a70300b3] Merge remote-tracking branch 'spi/for-next' git bisect good 674a0d6de8bd290671f7dff405205871a70300b3 # good: [8623dae312f73a2ea3230b1c648d3004cfc224ce] Merge remote-tracking branch 'vfio/next' git bisect good 8623dae312f73a2ea3230b1c648d3004cfc224ce # good: [dd26635f54bcd8e5d4e875a209f82a0423ba9c08] Merge remote-tracking branch 'gpio/for-next' git bisect good dd26635f54bcd8e5d4e875a209f82a0423ba9c08 # good: [86e9c9a734889fe437442e0a35eb4c61d319cb47] Merge remote-tracking branch 'memblock/for-next' git bisect good 86e9c9a734889fe437442e0a35eb4c61d319cb47 # bad: [3452331fda80b1cb5e121e6718ca6c07264382b2] userfaultfd: add user-mode only option to unprivileged_userfaultfd sysctl knob git bisect bad 3452331fda80b1cb5e121e6718ca6c07264382b2 # bad: [19f468d54fcffc3f98b71e3e12ff23726767d953] mremap: don't allow MREMAP_DONTUNMAP on special_mappings and aio git bisect bad 19f468d54fcffc3f98b71e3e12ff23726767d953 # good: [d89f3ababcac54493a4cb0582c61eb5f426b44e3] mm: remove pagevec_lookup_range_nr_tag() git bisect good d89f3ababcac54493a4cb0582c61eb5f426b44e3 # good: [eba8373dcb40d30952f31d5fc0cff56b78f46273] mm/mlock: remove __munlock_isolate_lru_page() git bisect good eba8373dcb40d30952f31d5fc0cff56b78f46273 # good: [8831d3f3564beba0f3f1b5291c88b35725bc45c9] xen/unpopulated-alloc: consolidate pgmap manipulation git bisect good 8831d3f3564beba0f3f1b5291c88b35725bc45c9 # bad: [b8d53d70851821d8a2040ddca3aa6ee88fc8aaec] mm/page_vma_mapped.c: add colon to fix kernel-doc markups error for check_pte git bisect bad b8d53d70851821d8a2040ddca3aa6ee88fc8aaec # bad: [e77846c3da1862faa25c08e186a62b03e98c862f] x86: mremap speedup - Enable HAVE_MOVE_PUD git bisect bad e77846c3da1862faa25c08e186a62b03e98c862f # bad: [72ad8951bac1c559ea1b691a0b035fb339e4d71d] mm: speedup mremap on 1GB or larger regions git bisect bad 72ad8951bac1c559ea1b691a0b035fb339e4d71d # good: [fa94bfe31609787501a1ff8d7659ade5734ec4e5] kselftests: vm: add mremap tests git bisect good fa94bfe31609787501a1ff8d7659ade5734ec4e5 # first bad commit: [72ad8951bac1c559ea1b691a0b035fb339e4d71d] mm: speedup mremap on 1GB or larger regions
Re: [PATCH] cpufreq: intel_pstate: Use the latest guaranteed freq during verify
On Thu, Dec 17, 2020 at 6:09 PM Srinivas Pandruvada
wrote:
>
> On Thu, 2020-12-17 at 16:24 +0100, Rafael J. Wysocki wrote:
> > On Thu, Dec 17, 2020 at 4:21 PM Srinivas Pandruvada
> > wrote:
> > >
> > > On Thu, 2020-12-17 at 16:12 +0100, Rafael J. Wysocki wrote:
> > > > On Thursday, December 17, 2020 3:23:44 PM CET Srinivas Pandruvada
> > > > wrote:
> > > > > On Thu, 2020-12-17 at 06:19 -0800, Srinivas Pandruvada wrote:
> > > > > > On Thu, 2020-12-17 at 14:58 +0100, Rafael J. Wysocki wrote:
> > > > > > > On Thu, Dec 17, 2020 at 11:44 AM Srinivas Pandruvada
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > This change tries to address an issue, when BIOS disabled
> > > > > > > > turbo
> > > > > > > > but HWP_CAP guaranteed is changed later and user space
> > > > > > > > wants
> > > > > > > > to
> > > > > > > > take
> > > > > > > > advantage of this increased guaranteed performance.
> > > > > > > >
> > > > > > > > The HWP_CAP.GUARANTEED value is not a static value. It
> > > > > > > > can be
> > > > > > > > changed
> > > > > > > > by some out of band agent or during Intel Speed Select
> > > > > > > > performance
> > > > > > > > level change. The HWP_CAP.MAX still shows max possible
> > > > > > > > performance
> > > > > > > > when
> > > > > > > > BIOS disabled turbo. So guaranteed can still change as
> > > > > > > > long
> > > > > > > > as
> > > > > > > > this
> > > > > > > > is
> > > > > > > > same or below HWP_CAP.MAX.
> > > > > > > >
> > > > > > > > When guaranteed is changed, the sysfs base_frequency
> > > > > > > > attributes
> > > > > > > > shows
> > > > > > > > the latest guaranteed frequency. This attribute can be
> > > > > > > > used
> > > > > > > > by
> > > > > > > > user
> > > > > > > > space software to update scaling min/max frequency.
> > > > > > > >
> > > > > > > > Currently the setpolicy callback already uses the latest
> > > > > > > > HWP_CAP
> > > > > > > > values when setting HWP_REQ. But the verify callback will
> > > > > > > > still
> > > > > > > > restrict
> > > > > > > > the user settings to the to old guaranteed value. So if
> > > > > > > > the
> > > > > > > > guaranteed
> > > > > > > > is increased, user space can't take advantage of it.
> > > > > > > >
> > > > > > > > To solve this similar to setpolicy callback, read the
> > > > > > > > latest
> > > > > > > > HWP_CAP
> > > > > > > > values and use it to restrict the maximum setting. This
> > > > > > > > is
> > > > > > > > done
> > > > > > > > by
> > > > > > > > calling intel_pstate_get_hwp_max(), which already
> > > > > > > > accounts
> > > > > > > > for
> > > > > > > > user
> > > > > > > > and BIOS turbo disable to get the current max
> > > > > > > > performance.
> > > > > > > >
> > > > > > > > This issue is side effect of fixing the issue of scaling
> > > > > > > > frequency
> > > > > > > > limits by the
> > > > > > > > 'commit eacc9c5a927e ("cpufreq: intel_pstate:
> > > > > > > > Fix intel_pstate_get_hwp_max() for turbo disabled")'
> > > > > > > > The fix resulted in correct setting of reduced scaling
> > > > > > > > frequencies,
> > > > > > > > but this resulted in capping HWP.REQ to
> > > > > > > > HWP_CAP.GUARANTEED in
> > > > > > > > this
> > > > > > > > case.
> > > > > > > >
> > > > > > > > Cc: 5.8+ # 5.8+
> > > > > > > > Signed-off-by: Srinivas Pandruvada <
> > > > > > > > srinivas.pandruv...@linux.intel.com>
> > > > > > > > ---
> > > > > > > > drivers/cpufreq/intel_pstate.c | 6 ++
> > > > > > > > 1 file changed, 6 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/drivers/cpufreq/intel_pstate.c
> > > > > > > > b/drivers/cpufreq/intel_pstate.c
> > > > > > > > index 2a4db856222f..7081d1edb22b 100644
> > > > > > > > --- a/drivers/cpufreq/intel_pstate.c
> > > > > > > > +++ b/drivers/cpufreq/intel_pstate.c
> > > > > > > > @@ -2199,6 +2199,12 @@ static void
> > > > > > > > intel_pstate_clear_update_util_hook(unsigned int cpu)
> > > > > > > >
> > > > > > > > static int intel_pstate_get_max_freq(struct cpudata
> > > > > > > > *cpu)
> > > > > > > > {
> > > > > > > > + if (hwp_active) {
> > > > > > > > + int turbo_max, max_state;
> > > > > > > > +
> > > > > > > > + intel_pstate_get_hwp_max(cpu->cpu,
> > > > > > > > _max,
> > > > > > > > _state);
> > > > > > >
> > > > > > > This would cause intel_pstate_get_hwp_max() to be called
> > > > > > > twice
> > > > > > > in
> > > > > > > intel_pstate_update_perf_limits() which is not perfect.
> > > > > >
> > > > > > We can optimize by using cached value.
> > > > > >
> > > > > >
> > > > > > diff --git a/drivers/cpufreq/intel_pstate.c
> > > > > > b/drivers/cpufreq/intel_pstate.c
> > > > > > index 7081d1edb22b..d345c9ef240c 100644
> > > > > > --- a/drivers/cpufreq/intel_pstate.c
> > > > > > +++ b/drivers/cpufreq/intel_pstate.c
> > > > > > @@ -2223,7 +2223,11 @@ static void
> > > > > > intel_pstate_update_perf_limits(struct cpudata *cpu,
> > > > > > * rather than pure ratios.
> > > > > > */
> > > > > > if
Re: [PATCH v2 1/7] regulator: dt-bindings: remove useless properties
On Wed, Dec 16, 2020 at 5:26 AM Adrien Grassein wrote: > > regulator-name is a generic property of the regulator. > Don't repeat it here. > > Signed-off-by: Adrien Grassein > --- > .../regulator/nxp,pf8x00-regulator.yaml | 17 - > 1 file changed, 17 deletions(-) Please add pf8x00 in commit head, otherwise Reviewed-by: Jagan Teki
RE: [PATCH v3 06/15] x86/paravirt: switch time pvops functions to use static_call()
From: Juergen Gross Sent: Thursday, December 17, 2020 1:31 AM
> The time pvops functions are the only ones left which might be
> used in 32-bit mode and which return a 64-bit value.
>
> Switch them to use the static_call() mechanism instead of pvops, as
> this allows quite some simplification of the pvops implementation.
>
> Due to include hell this requires to split out the time interfaces
> into a new header file.
>
> Signed-off-by: Juergen Gross
> ---
> arch/x86/Kconfig | 1 +
> arch/x86/include/asm/mshyperv.h | 11
> arch/x86/include/asm/paravirt.h | 14 --
> arch/x86/include/asm/paravirt_time.h | 38 +++
> arch/x86/include/asm/paravirt_types.h | 6 -
> arch/x86/kernel/cpu/vmware.c | 5 ++--
> arch/x86/kernel/kvm.c | 3 ++-
> arch/x86/kernel/kvmclock.c| 3 ++-
> arch/x86/kernel/paravirt.c| 16 ---
> arch/x86/kernel/tsc.c | 3 ++-
> arch/x86/xen/time.c | 12 -
> drivers/clocksource/hyperv_timer.c| 5 ++--
> drivers/xen/time.c| 3 ++-
> kernel/sched/sched.h | 1 +
> 14 files changed, 71 insertions(+), 50 deletions(-)
> create mode 100644 arch/x86/include/asm/paravirt_time.h
>
[snip]
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> index ffc289992d1b..45942d420626 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -56,17 +56,6 @@ typedef int (*hyperv_fill_flush_list_func)(
> #define hv_get_raw_timer() rdtsc_ordered()
> #define hv_get_vector() HYPERVISOR_CALLBACK_VECTOR
>
> -/*
> - * Reference to pv_ops must be inline so objtool
> - * detection of noinstr violations can work correctly.
> - */
> -static __always_inline void hv_setup_sched_clock(void *sched_clock)
> -{
> -#ifdef CONFIG_PARAVIRT
> - pv_ops.time.sched_clock = sched_clock;
> -#endif
> -}
> -
> void hyperv_vector_handler(struct pt_regs *regs);
>
> static inline void hv_enable_stimer0_percpu_irq(int irq) {}
[snip]
> diff --git a/drivers/clocksource/hyperv_timer.c
> b/drivers/clocksource/hyperv_timer.c
> index ba04cb381cd3..1ed79993fc50 100644
> --- a/drivers/clocksource/hyperv_timer.c
> +++ b/drivers/clocksource/hyperv_timer.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> static struct clock_event_device __percpu *hv_clock_event;
> static u64 hv_sched_clock_offset __ro_after_init;
> @@ -445,7 +446,7 @@ static bool __init hv_init_tsc_clocksource(void)
> clocksource_register_hz(_cs_tsc, NSEC_PER_SEC/100);
>
> hv_sched_clock_offset = hv_read_reference_counter();
> - hv_setup_sched_clock(read_hv_sched_clock_tsc);
> + paravirt_set_sched_clock(read_hv_sched_clock_tsc);
>
> return true;
> }
> @@ -470,6 +471,6 @@ void __init hv_init_clocksource(void)
> clocksource_register_hz(_cs_msr, NSEC_PER_SEC/100);
>
> hv_sched_clock_offset = hv_read_reference_counter();
> - hv_setup_sched_clock(read_hv_sched_clock_msr);
> + static_call_update(pv_sched_clock, read_hv_sched_clock_msr);
> }
> EXPORT_SYMBOL_GPL(hv_init_clocksource);
These Hyper-V changes are problematic as we want to keep hyperv_timer.c
architecture independent. While only the code for x86/x64 is currently
accepted upstream, code for ARM64 support is in progress. So we need
to use hv_setup_sched_clock() in hyperv_timer.c, and have the per-arch
implementation in mshyperv.h.
Michael
Re: [PATCH V2 0/3] mm/hotplug: Pre-validate the address range with platform
On 17.12.20 16:28, Anshuman Khandual wrote: > This series adds a mechanism allowing platforms to weigh in and prevalidate > incoming address range before proceeding further with the memory hotplug. > This helps prevent potential platform errors for the given address range, > down the hotplug call chain, which inevitably fails the hotplug itself. > > This mechanism was suggested by David Hildenbrand during another discussion > with respect to a memory hotplug fix on arm64 platform. > > https://lore.kernel.org/linux-arm-kernel/1600332402-30123-1-git-send-email-anshuman.khand...@arm.com/ > > This mechanism focuses on the addressibility aspect and not [sub] section > alignment aspect. Hence check_hotplug_memory_range() and check_pfn_span() > have been left unchanged. Wondering if all these can still be unified in > an expanded memhp_range_allowed() check, that can be called from multiple > memory hot add and remove paths. > > This series applies on v5.10 and has been tested on arm64. But only > build tested on s390. > > Changes in V2: > > - Changed s390 version per Heiko and updated the commit message > - Called memhp_range_allowed() only for arch_add_memory() in pagemap_range() > - Exported the symbol memhp_get_pluggable_range() > > Changes in V1: > > https://lore.kernel.org/linux-mm/1607400978-31595-1-git-send-email-anshuman.khand...@arm.com/ > > - Fixed build problems with (MEMORY_HOTPLUG & !MEMORY_HOTREMOVE) > - Added missing prototype for arch_get_mappable_range() > - Added VM_BUG_ON() check for memhp_range_allowed() in arch_add_memory() per > David > > Changes in RFC V2: > > https://lore.kernel.org/linux-mm/1606706992-26656-1-git-send-email-anshuman.khand...@arm.com/ > > Incorporated all review feedbacks from David. > > - Added additional range check in __segment_load() on s390 which was lost > - Changed is_private init in pagemap_range() > - Moved the framework into mm/memory_hotplug.c > - Made arch_get_addressable_range() a __weak function > - Renamed arch_get_addressable_range() as arch_get_mappable_range() > - Callback arch_get_mappable_range() only handles range requiring linear > mapping > - Merged multiple memhp_range_allowed() checks in register_memory_resource() > - Replaced WARN() with pr_warn() in memhp_range_allowed() > - Replaced error return code ERANGE with E2BIG > > Changes in RFC V1: > > https://lore.kernel.org/linux-mm/1606098529-7907-1-git-send-email-anshuman.khand...@arm.com/ > > Cc: Heiko Carstens > Cc: Vasily Gorbik > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Ard Biesheuvel > Cc: Mark Rutland > Cc: David Hildenbrand > Cc: Andrew Morton > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-s...@vger.kernel.org > Cc: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org > > Anshuman Khandual (3): > mm/hotplug: Prevalidate the address range being added with platform > arm64/mm: Define arch_get_mappable_range() > s390/mm: Define arch_get_mappable_range() Thanks, I'm planning on reviewing + sending a virtio-mem patch to use memhp_get_mappable_range() in the new year. I assume we also have restrictions when it comes to x86-64, will have a look. -- Thanks, David / dhildenb
Re: [PATCH v2 2/7] regulator: pf8x00: add a doc for the module
On Wed, Dec 16, 2020 at 5:27 AM Adrien Grassein wrote: > > pf8x00 module build was not documented. > > Signed-off-by: Adrien Grassein > --- > drivers/regulator/Kconfig | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig > index 53fa84f4d1e1..9c6508e99fdd 100644 > --- a/drivers/regulator/Kconfig > +++ b/drivers/regulator/Kconfig > @@ -828,6 +828,10 @@ config REGULATOR_PF8X00 > Say y here to support the regulators found on the NXP > PF8100/PF8121A/PF8200 PMIC. > > + Say M here if you want to support for the regulators found > + on the NXP PF8100/PF8121A/PF8200 PMIC. The module will be named > + "pf8x00-regulator". Reviewed-by: Jagan Teki
[PATCH v12 0/4] Carry forward IMA measurement log on kexec on ARM64
On kexec file load Integrity Measurement Architecture (IMA) subsystem
may verify the IMA signature of the kernel and initramfs, and measure
it. The command line parameters passed to the kernel in the kexec call
may also be measured by IMA. A remote attestation service can verify
a TPM quote based on the TPM event log, the IMA measurement list, and
the TPM PCR data. This can be achieved only if the IMA measurement log
is carried over from the current kernel to the next kernel across
the kexec call.
powerpc already supports carrying forward the IMA measurement log on
kexec. This patch set adds support for carrying forward the IMA
measurement log on kexec on ARM64.
This patch set moves the platform independent code defined for powerpc
such that it can be reused for other platforms as well. A chosen node
"linux,ima-kexec-buffer" is added to the DTB for ARM64 to hold
the address and the size of the memory reserved to carry
the IMA measurement log.
This patch set has been tested for ARM64 platform using QEMU.
I would like help from the community for testing this change on powerpc.
Thanks.
This patch set is based on
commit a29a64445089 ("powerpc: Use common of_kexec_setup_new_fdt()")
in https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
"dt/kexec" branch.
Changelog:
v12
- Use fdt_appendprop_addrrange() in setup_ima_buffer()
to setup the IMA measurement list property in
the device tree.
- Moved architecture independent functions from
"arch/powerpc/kexec/ima.c" to "drivers/of/kexec."
- Deleted "arch/powerpc/kexec/ima.c" and
"arch/powerpc/include/asm/ima.h".
v11
- Rebased the changes on the kexec code refactoring done by
Rob Herring in his "dt/kexec" branch
- Removed "extern" keyword in function declarations
- Removed unnecessary header files included in C files
- Updated patch descriptions per Thiago's comments
v10
- Moved delete_fdt_mem_rsv(), remove_ima_buffer(),
get_ima_kexec_buffer, and get_root_addr_size_cells()
to drivers/of/kexec.c
- Moved arch_ima_add_kexec_buffer() to
security/integrity/ima/ima_kexec.c
- Conditionally define IMA buffer fields in struct kimage_arch
v9
- Moved delete_fdt_mem_rsv() to drivers/of/kexec_fdt.c
- Defined a new function get_ima_kexec_buffer() in
drivers/of/ima_kexec.c to replace do_get_kexec_buffer()
- Changed remove_ima_kexec_buffer() to the original function name
remove_ima_buffer()
- Moved remove_ima_buffer() to drivers/of/ima_kexec.c
- Moved ima_get_kexec_buffer() and ima_free_kexec_buffer()
to security/integrity/ima/ima_kexec.c
v8:
- Moved remove_ima_kexec_buffer(), do_get_kexec_buffer(), and
delete_fdt_mem_rsv() to drivers/of/fdt.c
- Moved ima_dump_measurement_list() and ima_add_kexec_buffer()
back to security/integrity/ima/ima_kexec.c
v7:
- Renamed remove_ima_buffer() to remove_ima_kexec_buffer() and moved
this function definition to kernel.
- Moved delete_fdt_mem_rsv() definition to kernel
- Moved ima_dump_measurement_list() and ima_add_kexec_buffer() to
a new file namely ima_kexec_fdt.c in IMA
v6:
- Remove any existing FDT_PROP_IMA_KEXEC_BUFFER property in the device
tree and also its corresponding memory reservation in the currently
running kernel.
- Moved the function remove_ima_buffer() defined for powerpc to IMA
and renamed the function to ima_remove_kexec_buffer(). Also, moved
delete_fdt_mem_rsv() from powerpc to IMA.
v5:
- Merged get_addr_size_cells() and do_get_kexec_buffer() into a single
function when moving the arch independent code from powerpc to IMA
- Reverted the change to use FDT functions in powerpc code and added
back the original code in get_addr_size_cells() and
do_get_kexec_buffer() for powerpc.
- Added fdt_add_mem_rsv() for ARM64 to reserve the memory for
the IMA log buffer during kexec.
- Fixed the warning reported by kernel test bot for ARM64
arch_ima_add_kexec_buffer() - moved this function to a new file
namely arch/arm64/kernel/ima_kexec.c
v4:
- Submitting the patch series on behalf of the original author
Prakhar Srivastava
- Moved FDT_PROP_IMA_KEXEC_BUFFER ("linux,ima-kexec-buffer") to
libfdt.h so that it can be shared by multiple platforms.
v3:
Breakup patches further into separate patches.
- Refactoring non architecture specific code out of powerpc
- Update powerpc related code to use fdt functions
- Update IMA buffer read related code to use of functions
- Add support to store the memory information of the IMA
measurement logs to be carried forward.
- Update the property strings to align with documented nodes
https://github.com/devicetree-org/dt-schema/pull/46
v2:
Break patches into separate patches.
- Powerpc related Refactoring
- Updating the docuemntation for chosen node
- Updating arm64 to support IMA buffer pass
v1:
Refactoring carrying over IMA measuremnet logs over Kexec. This patch
moves the non-architecture
