[PATCH 0/2] Add /sys/firmware/lefi/boardinfo for Loongson64
Tiezhu Yang (2): MIPS: Loongson64: Add /sys/firmware/lefi/boardinfo Documentation: ABI: Add /sys/firmware/lefi/boardinfo description for Loongson64 .../ABI/testing/sysfs-firmware-lefi-boardinfo | 35 arch/mips/include/asm/mach-loongson64/boot_param.h | 4 ++ arch/mips/loongson64/Makefile | 1 + arch/mips/loongson64/boardinfo.c | 48 ++ arch/mips/loongson64/env.c | 10 + 5 files changed, 98 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-lefi-boardinfo create mode 100644 arch/mips/loongson64/boardinfo.c -- 2.1.0
[PATCH] tracing: add tgid into common field
Sometimes we want to trace a specific mutil-threaded process, which may
create threads dynamically. Currently it is not easy to trace all its
threads, because we can only filter these threads out by using
common_pid.
This patch adds the tgid into the common field as well, with which we
can easily filter this mutil-threaded process out. E.g.
$ cd /sys/kernel/debug/tracing
$ echo 'common_tgid == 4054' > events/sched/sched_wakeup/filter
$ cat trace_pipe
python-4057[005] d... 48003.898560: sched_wakeup: comm=python
pid=4054 prio=120 target_cpu=002
python-4054[002] dNs. 48003.932906: sched_wakeup:
comm=kworker/2:2 pid=130 prio=120 target_cpu=002
python-4054[002] dNH. 48003.932907: sched_wakeup: comm=cat
pid=4084 prio=120 target_cpu=004
python-4055[003] d... 48004.816596: sched_wakeup: comm=python
pid=4054 prio=120 target_cpu=002
With record-tgid set into trace_options, we can show the tgid,
$ echo record-tgid > trace_options
$ cat trace_pipe
python-4054( 4054) [002] d... 48166.611771: sched_wakeup:
comm=python pid=4055 prio=120 target_cpu=004
python-4057( 4054) [005] d... 48166.611776: sched_wakeup:
comm=python pid=4054 prio=120 target_cpu=002
python-4055( 4054) [004] d... 48166.611848: sched_wakeup:
comm=python pid=4054 prio=120 target_cpu=002
After that change, tgid_map is only used by saved_tgid, which may be
used by some user tools, so I just keep it as-is.
Signed-off-by: Yafang Shao
---
include/linux/trace_events.h | 1 +
kernel/trace/trace.c | 1 +
kernel/trace/trace_events.c | 1 +
kernel/trace/trace_output.c | 2 +-
4 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index 5c6943354049..3725c05f0b01 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -67,6 +67,7 @@ struct trace_entry {
unsigned char flags;
unsigned char preempt_count;
int pid;
+ int tgid;
};
#define TRACE_EVENT_TYPE_MAX \
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index d3e5de717df2..c2423efaac2c 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2445,6 +2445,7 @@ tracing_generic_entry_update(struct trace_entry *entry,
unsigned short type,
entry->preempt_count= pc & 0xff;
entry->pid = (tsk) ? tsk->pid : 0;
+ entry->tgid = (tsk) ? tsk->tgid : 0;
entry->type = type;
entry->flags =
#ifdef CONFIG_TRACE_IRQFLAGS_SUPPORT
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index a85effb2373b..9a5adcecf245 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -182,6 +182,7 @@ static int trace_define_common_fields(void)
__common_field(unsigned char, flags);
__common_field(unsigned char, preempt_count);
__common_field(int, pid);
+ __common_field(int, tgid);
return ret;
}
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 000e9dc224c6..e04dd45267c7 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -591,7 +591,7 @@ int trace_print_context(struct trace_iterator *iter)
trace_seq_printf(s, "%16s-%-7d ", comm, entry->pid);
if (tr->trace_flags & TRACE_ITER_RECORD_TGID) {
- unsigned int tgid = trace_find_tgid(entry->pid);
+ unsigned int tgid = entry->tgid;
if (!tgid)
trace_seq_printf(s, "(---) ");
--
2.17.1
[PATCH 2/2] Documentation: ABI: Add /sys/firmware/lefi/boardinfo description for Loongson64
Add a description for /sys/firmware/lefi/boardinfo on the Loongson platform. Signed-off-by: Tiezhu Yang --- .../ABI/testing/sysfs-firmware-lefi-boardinfo | 35 ++ 1 file changed, 35 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-lefi-boardinfo diff --git a/Documentation/ABI/testing/sysfs-firmware-lefi-boardinfo b/Documentation/ABI/testing/sysfs-firmware-lefi-boardinfo new file mode 100644 index 000..5e3f614 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-lefi-boardinfo @@ -0,0 +1,35 @@ +What: /sys/firmware/lefi/boardinfo +Date: October 2020 +Contact: Tiezhu Yang +Description: + Get mainboard and BIOS info easily on the Loongson platform, + this is useful to point out the current used mainboard type + and BIOS version when there exists problems related with + hardware or firmware. + + The related structures are already defined in the interface + specification about firmware and kernel which are common + requirement and specific for Loongson64, so only add a new + boardinfo.c file in arch/mips/loongson64. + + For example: + + [loongson@linux ~]$ cat /sys/firmware/lefi/boardinfo + Board Info + Manufacturer: LEMOTE + Board Name : LEMOTE-LS3A4000-7A1000-1w-V01-pc + Family : LOONGSON3 + + BIOS Info + Vendor : Kunlun + Version : Kunlun-A1901-V4.1.3-20200414093938 + ROM Size: 4 KB + Release Date: 2020-04-14 + + By the way, using dmidecode command can get the similar info if there + exists SMBIOS in firmware, but the fact is that there is no SMBIOS on + some machines, we can see nothing when execute dmidecode, like this: + + [root@linux loongson]# dmidecode + # dmidecode 2.12 + # No SMBIOS nor DMI entry point found, sorry. -- 2.1.0
[PATCH 1/2] MIPS: Loongson64: Add /sys/firmware/lefi/boardinfo
Add /sys/firmware/lefi/boardinfo to get mainboard and BIOS info easily
on the Loongson platform, this is useful to point out the current used
mainboard type and BIOS version when there exists problems related with
hardware or firmware.
The related structures are already defined in the interface specification
about firmware and kernel which are common requirement and specific for
Loongson64, so only add a new boardinfo.c file in arch/mips/loongson64.
E.g. with this patch:
[loongson@linux ~]$ cat /sys/firmware/lefi/boardinfo
Board Info
Manufacturer: LEMOTE
Board Name : LEMOTE-LS3A4000-7A1000-1w-V01-pc
Family : LOONGSON3
BIOS Info
Vendor : Kunlun
Version : Kunlun-A1901-V4.1.3-20200414093938
ROM Size: 4 KB
Release Date: 2020-04-14
By the way, using dmidecode command can get the similar info if there
exists SMBIOS in firmware, but the fact is that there is no SMBIOS on
some machines, we can see nothing when execute dmidecode, like this:
[root@linux loongson]# dmidecode
# dmidecode 2.12
# No SMBIOS nor DMI entry point found, sorry.
Signed-off-by: Tiezhu Yang
---
arch/mips/include/asm/mach-loongson64/boot_param.h | 4 ++
arch/mips/loongson64/Makefile | 1 +
arch/mips/loongson64/boardinfo.c | 48 ++
arch/mips/loongson64/env.c | 10 +
4 files changed, 63 insertions(+)
create mode 100644 arch/mips/loongson64/boardinfo.c
diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h
b/arch/mips/include/asm/mach-loongson64/boot_param.h
index afc92b7..4592841 100644
--- a/arch/mips/include/asm/mach-loongson64/boot_param.h
+++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
@@ -228,6 +228,10 @@ struct loongson_system_configuration {
extern struct efi_memory_map_loongson *loongson_memmap;
extern struct loongson_system_configuration loongson_sysconf;
+extern struct board_devices *eboard;
+extern struct interface_info *einter;
+extern struct loongson_special_attribute *especial;
+
extern u32 node_id_offset;
extern void ls7a_early_config(void);
extern void rs780e_early_config(void);
diff --git a/arch/mips/loongson64/Makefile b/arch/mips/loongson64/Makefile
index 39c06f5..cc76944 100644
--- a/arch/mips/loongson64/Makefile
+++ b/arch/mips/loongson64/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_RS780_HPET) += hpet.o
obj-$(CONFIG_SUSPEND) += pm.o
obj-$(CONFIG_PCI_QUIRKS) += vbios_quirk.o
obj-$(CONFIG_CPU_LOONGSON3_CPUCFG_EMULATION) += cpucfg-emul.o
+obj-$(CONFIG_SYSFS) += boardinfo.o
diff --git a/arch/mips/loongson64/boardinfo.c b/arch/mips/loongson64/boardinfo.c
new file mode 100644
index 000..280989c
--- /dev/null
+++ b/arch/mips/loongson64/boardinfo.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+
+static ssize_t boardinfo_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ char board_manufacturer[64] = {0};
+ char *tmp_board_manufacturer = board_manufacturer;
+ char bios_vendor[64] = {0};
+ char *tmp_bios_vendor = bios_vendor;
+
+ strcpy(board_manufacturer, eboard->name);
+ strcpy(bios_vendor, einter->description);
+
+ return sprintf(buf,
+ "Board Info\n"
+ "Manufacturer\t\t: %s\n"
+ "Board Name\t\t: %s\n"
+ "Family\t\t\t: LOONGSON3\n\n"
+ "BIOS Info\n"
+ "Vendor\t\t\t: %s\n"
+ "Version\t\t\t: %s\n"
+ "ROM Size\t\t: %d KB\n"
+ "Release Date\t\t: %s\n",
+ strsep(_board_manufacturer, "-"),
+ eboard->name,
+ strsep(_bios_vendor, "-"),
+ einter->description,
+ einter->size,
+ especial->special_name);
+}
+static struct kobj_attribute boardinfo_attr = __ATTR(boardinfo, 0444,
+boardinfo_show, NULL);
+
+static int __init boardinfo_init(void)
+{
+ struct kobject *lefi_kobj;
+
+ lefi_kobj = kobject_create_and_add("lefi", firmware_kobj);
+ if (!lefi_kobj) {
+ pr_err("lefi: Firmware registration failed.\n");
+ return -ENOMEM;
+ }
+
+ return sysfs_create_file(lefi_kobj, _attr.attr);
+}
+late_initcall(boardinfo_init);
diff --git a/arch/mips/loongson64/env.c b/arch/mips/loongson64/env.c
index 134cb8e..51a5d05 100644
--- a/arch/mips/loongson64/env.c
+++ b/arch/mips/loongson64/env.c
@@ -28,6 +28,10 @@ EXPORT_SYMBOL(cpu_clock_freq);
struct efi_memory_map_loongson *loongson_memmap;
struct loongson_system_configuration loongson_sysconf;
+struct board_devices *eboard;
+struct interface_info *einter;
+struct loongson_special_attribute *especial;
+
u64 loongson_chipcfg[MAX_PACKAGES] =
Re: [PATCH 5.4 00/85] 5.4.71-rc1 review
On Mon, 12 Oct 2020 at 19:11, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.4.71 release. > There are 85 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 14 Oct 2020 13:26:14 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.71-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.4.71-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.4.y git commit: 228d88e992eb144f13037001b6b6d0289b9b2f00 git describe: v5.4.70-86-g228d88e992eb Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.70-86-g228d88e992eb No regressions (compared to build v5.4.69-58-g7b199c4db17f) No fixes (compared to build v5.4.69-58-g7b199c4db17f) Ran 35909 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * linux-log-parser * ltp-cap_bounds-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-io-tests * ltp-ipc-tests * ltp-sched-tests * ltp-syscalls-tests * perf * v4l2-compliance * libhugetlbfs * ltp-commands-tests * ltp-hugetlb-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * ltp-tracing-tests * network-basic-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * ssuite -- Linaro LKFT https://lkft.linaro.org
RE: [PATCH 00/15] dmaengine: dw-axi-dmac: support Intel KeemBay AxiDMA
> -Original Message- > From: Andy Shevchenko > Sent: 12 October 2020 9:59 PM > To: Sia, Jee Heng > Cc: vk...@kernel.org; eugeniy.palt...@synopsys.com; > dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 00/15] dmaengine: dw-axi-dmac: support Intel KeemBay > AxiDMA > > On Mon, Oct 12, 2020 at 12:21:45PM +0800, Sia Jee Heng wrote: > > The below patch series are to support AxiDMA running on Intel KeemBay SoC. > > The base driver is dw-axi-dmac but code refactoring is needed, for example: > > - Support YAML Schemas DT binding. > > - Replacing Linked List with virtual descriptor management. > > - Remove unrelated hw desc stuff from dma memory pool. > > - Manage dma memory pool alloc/destroy based on channel activity. > > - Support dmaengine device_sync() callback. > > - Support dmaengine device_config(). > > - Support dmaegnine device_prep_slave_sg(). > > - Support dmaengine device_prep_dma_cyclic(). > > - Support of_dma_controller_register(). > > - Support burst residue granularity. > > - Support Intel KeemBay AxiDMA registers. > > - Support Intel KeemBay AxiDMA device handshake. > > - Support Intel KeemBay AxiDMA BYTE and HALFWORD device operation. > > - Add constraint to Max segment size. > > > > This patch set is to replace the patch series submitted at: > > https://lore.kernel.org/dmaengine/1599213094-30144-1-git-send-email-je > > e.heng@intel.com/ > > And it means effectively the bumped version, besides the fact that you double > sent this one... > > > Please fix and resend. Note, now is merge window is open. Depends on > maintainer's flow it may be good or bad time to resend with properly formed > changelog and version of the series. [>>] Thanks. Will resend the patch set with v1 in the header. > > > This patch series are tested on Intel KeemBay platform. > > > > > > Sia Jee Heng (15): > > dt-bindings: dma: Add YAML schemas for dw-axi-dmac > > dmaengine: dw-axi-dmac: simplify descriptor management > > dmaengine: dw-axi-dmac: move dma_pool_create() to > > alloc_chan_resources() > > dmaengine: dw-axi-dmac: Add device_synchronize() callback > > dmaengine: dw-axi-dmac: Add device_config operation > > dmaengine: dw-axi-dmac: Support device_prep_slave_sg > > dmaegine: dw-axi-dmac: Support device_prep_dma_cyclic() > > dmaengine: dw-axi-dmac: Support of_dma_controller_register() > > dmaengine: dw-axi-dmac: Support burst residue granularity > > dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA support > > dt-binding: dma: dw-axi-dmac: Add support for Intel KeemBay AxiDMA > > dmaengine: dw-axi-dmac: Add Intel KeemBay DMA register fields > > dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA handshake > > dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA BYTE and HALFWORD > > registers > > dmaengine: dw-axi-dmac: Set constraint to the Max segment size > > > > .../bindings/dma/snps,dw-axi-dmac.txt | 39 - > > .../bindings/dma/snps,dw-axi-dmac.yaml| 149 > > .../dma/dw-axi-dmac/dw-axi-dmac-platform.c| 696 +++--- > > drivers/dma/dw-axi-dmac/dw-axi-dmac.h | 33 +- > > 4 files changed, 783 insertions(+), 134 deletions(-) delete mode > > 100644 Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt > > create mode 100644 > > Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml > > > > -- > > 2.18.0 > > > > -- > With Best Regards, > Andy Shevchenko >
Re: [PATCH 5.8 000/124] 5.8.15-rc1 review
On Mon, 12 Oct 2020 at 19:15, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.8.15 release. > There are 124 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 14 Oct 2020 13:31:22 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.15-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.8.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.8.15-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.8.y git commit: f4ed6fb8f1680de812daf362f28342e6bf19fdcc git describe: v5.8.14-125-gf4ed6fb8f168 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.8.y/build/v5.8.14-125-gf4ed6fb8f168 No regressions (compared to build v5.8.14-5-g0b030df1725b) No fixes (compared to build v5.8.14-5-g0b030df1725b) Ran 37577 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * v4l2-compliance * libhugetlbfs * ltp-sched-tests * network-basic-tests * ltp-open-posix-tests * ltp-tracing-tests * ltp-quickhit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * ssuite -- Linaro LKFT https://lkft.linaro.org
Re: [linux-safety] [PATCH] usb: host: ehci-sched: add comment about find_tt() not returning error
On Tue, 13 Oct 2020, Greg Kroah-Hartman wrote: > On Mon, Oct 12, 2020 at 08:17:34PM +0200, Lukas Bulwahn wrote: > > > If you are suggesting some sort of special code annotation that the tool > > > would understand, I am open to that. But I'm not aware of any even > > > vaguely standard way of marking up a particular function call to > > > indicate it will not return an error. > > > > I cannot yet say if some annotation would work, we, Sudip and me, need to > > investigate. It could be that something like, assert(!IS_ERR(tt)), is > > sufficient to let the tools know that they can safely assume that the > > path they are complaining about is not possible. > > > > We could make the assert() a nop, so it would not effect the resulting > > object code in any way. > > Things like assert() have been rejected numberous times in the past in > the kernel, good luck with that :) > Greg, we have been warned by you now; so, we are well aware what could await us just as numerous others before. Lukas
Re: [RFC PATCH 10/24] vdpa: introduce config operations for associating ASID to a virtqueue group
On 2020/10/12 下午4:17, Eli Cohen wrote: On Mon, Oct 12, 2020 at 03:45:10PM +0800, Jason Wang wrote: So in theory we can have several asid's (for different virtqueues), each one should be followed by a specific set_map call. If this is so, how do I know if I met all the conditions run my driver? Maybe we need another callback to let the driver know it should not expect more set_maps(). This should work similarly as in the past. Two parts of the work is expected to be done by the driver: 1) store the mapping somewhere (e.g hardware) during set_map() 2) associating mapping with a specific virtqueue The only difference is that more than one mapping is used now. ok, so like today, I will always get DRIVER_OK after I got all the set_maps(), right? Yes. Thanks For the issue of more set_maps(), driver should be always ready for the new set_maps() call instead of not expecting new set_maps() since guest memory topology could be changed due to several reasons. Qemu or vhost-vDPA will try their best to avoid the frequency of set_maps() for better performance (e.g through batched IOTLB updating). E.g there should be at most one set_map() during one time of guest booting.
WARNING: kernel/irq/chip.c:242 __irq_startup+0xa8/0xb0
On stable rc 5.8.15 the following kernel warning was noticed once while boot and this is hard to reproduce. metadata: git branch: linux-5.8.y git repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc git commit: f4ed6fb8f1680de812daf362f28342e6bf19fdcc git describe: v5.8.14-125-gf4ed6fb8f168 make_kernelversion: 5.8.15-rc1 kernel-config: https://builds.tuxbuild.com/5nFtomB9FDlQVjafKdyR9A/kernel.config warning log: [ 43.512935] [ cut here ] [ 43.517563] WARNING: CPU: 0 PID: 424 at kernel/irq/chip.c:242 __irq_startup+0xa8/0xb0 [ 43.517564] Modules linked in: caam error crct10dif_ce ina2xx lm90 qoriq_thermal fuse [ 43.533218] CPU: 0 PID: 424 Comm: (agetty) Not tainted 5.8.15-rc1 #1 [ 43.533219] Hardware name: Freescale Layerscape 2088A RDB Board (DT) [ 43.533223] pstate: 6085 (nZCv daIf -PAN -UAO BTYPE=--) [ 43.533225] pc : __irq_startup+0xa8/0xb0 [ 43.533229] lr : irq_startup+0x64/0x140 [ 43.559218] sp : 800010b838c0 [ 43.559219] x29: 800010b838c0 x28: 0082cd3bab00 [ 43.559222] x27: b8c772ed8ec0 x26: 00020902 [ 43.573133] x25: b8c771d39e68 x24: b8c771d39b08 [ 43.573135] x23: x22: 0001 [ 43.573138] x21: 0001 x20: 0082edf42c40 [ 43.573140] x19: 0082ede29200 x18: 0001 [ 43.573142] x17: x16: [ 43.573145] x15: 0082edf430c0 x14: 800010bf5000 [ 43.573147] x13: 800010bed000 x12: 800010be9000 [ 43.573149] x11: 0040 x10: b8c772cdb940 [ 43.573153] x9 : b8c770b7fe0c x8 : 0082ee000270 [ 43.620866] x7 : x6 : b8c772cbaa08 [ 43.620869] x5 : b8c772cba000 x4 : 0504 [ 43.620871] x3 : 0082ede29200 x2 : 03032004 [ 43.636780] x1 : 03032004 x0 : 0082ede29258 [ 43.636783] Call trace: [ 43.636786] __irq_startup+0xa8/0xb0 [ 43.636789] irq_startup+0x64/0x140 [ 43.651569] __enable_irq+0x78/0x88 [ 43.651571] enable_irq+0x54/0xa8 [ 43.651577] serial8250_do_startup+0x670/0x718 [ 43.662791] serial8250_startup+0x30/0x40 [ 43.666793] uart_startup.part.0+0x12c/0x2e0 [ 43.671055] uart_port_activate+0x68/0xa0 [ 43.675058] tty_port_open+0x98/0x250 [ 43.678712] uart_open+0x24/0x38 [ 43.681932] tty_open+0x100/0x480 [ 43.685240] chrdev_open+0xac/0x1a8 [ 43.688721] do_dentry_open+0x130/0x3d0 [ 43.692548] vfs_open+0x34/0x40 [ 43.695681] path_openat+0x888/0xde8 [ 43.699247] do_filp_open+0x80/0x108 [ 43.702814] do_sys_openat2+0x1ec/0x2a8 [ 43.706642] do_sys_open+0x60/0xa8 [ 43.710035] __arm64_sys_openat+0x2c/0x38 [ 43.714037] el0_svc_common.constprop.0+0x7c/0x198 [ 43.718820] do_el0_svc+0x2c/0x98 [ 43.722128] el0_sync_handler+0x9c/0x1b8 [ 43.726041] el0_sync+0x158/0x180 [ 43.729347] ---[ end trace 434ed7c8787a1d1f ]--- full log, https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.8.y/build/v5.8.14-125-gf4ed6fb8f168/testrun/3297947/suite/linux-log-parser/test/check-kernel-warning-93863/log -- Linaro LKFT https://lkft.linaro.org
Re: [linux-safety] [PATCH] usb: host: ehci-sched: add comment about find_tt() not returning error
On Tue, 13 Oct 2020, Greg Kroah-Hartman wrote: > On Mon, Oct 12, 2020 at 08:25:30PM +0200, Lukas Bulwahn wrote: > > > > > > On Mon, 12 Oct 2020, Greg Kroah-Hartman wrote: > > > > > On Mon, Oct 12, 2020 at 05:10:21PM +0200, Lukas Bulwahn wrote: > > > > And for the static analysis finding, we need to find a way to ignore > > > > this > > > > finding without simply ignoring all findings or new findings that just > > > > look very similar to the original finding, but which are valid. > > > > > > Then I suggest you fix the tool that "flagged" this, surely this is not > > > the only thing it detected with a test like this, right? > > > > > > What tool reported this? > > > > > > > Sudip and I are following on clang analyzer findings. > > > > On linux-next, there is new build target 'make clang-analyzer' that > > outputs a bunch of warnings, just as you would expect from such static > > analysis tools. > > Why not fix the things that it finds that are actually issues? If there > are no actual issues found, then perhaps you should use a better tool? :) > Completely agree. That is why I was against adding comments here and elsewhere just to have the "good feeling of doing something" after the tool reported a warning and we spend some time understanding the code to conclude that we now understand the code better than the tool. If you know a better tool, we will use it :) unfortunately, there is no easy way of finding out that a tool just reports false positives and not a single true positive among 1000 reports... Lukas
[PATCH v2] sched/features: Fix !CONFIG_JUMP_LABEL case
Commit 765cc3a4b224e ("sched/core: Optimize sched_feat() for
!CONFIG_SCHED_DEBUG builds") made sched features static for
!CONFIG_SCHED_DEBUG configurations, but overlooked the CONFIG_
SCHED_DEBUG enabled and !CONFIG_JUMP_LABEL cases. For the latter echoing
changes to /sys/kernel/debug/sched_features has the nasty effect of
effectively changing what sched_features reports, but without actually
changing the scheduler behaviour (since different translation units get
different sysctl_sched_features).
Fix CONFIG_SCHED_DEBUG and !CONFIG_JUMP_LABEL configurations by properly
restructuring ifdefs.
Fixes: 765cc3a4b224e ("sched/core: Optimize sched_feat() for
!CONFIG_SCHED_DEBUG builds")
Co-developed-by: Daniel Bristot de Oliveira
Signed-off-by: Daniel Bristot de Oliveira
Signed-off-by: Juri Lelli
---
v1->v2
- use CONFIG_JUMP_LABEL (and not the old HAVE_JUMP_LABEL) [Valentin]
---
kernel/sched/core.c | 2 +-
kernel/sched/sched.h | 13 ++---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 3dc415f58bd7..a7949e3ed7e7 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -44,7 +44,7 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(sched_update_nr_running_tp);
DEFINE_PER_CPU_SHARED_ALIGNED(struct rq, runqueues);
-#if defined(CONFIG_SCHED_DEBUG) && defined(CONFIG_JUMP_LABEL)
+#ifdef CONFIG_SCHED_DEBUG
/*
* Debugging: various feature bits
*
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 28709f6b0975..8d1ca65db3b0 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1629,7 +1629,7 @@ enum {
#undef SCHED_FEAT
-#if defined(CONFIG_SCHED_DEBUG) && defined(CONFIG_JUMP_LABEL)
+#ifdef CONFIG_SCHED_DEBUG
/*
* To support run-time toggling of sched features, all the translation units
@@ -1637,6 +1637,7 @@ enum {
*/
extern const_debug unsigned int sysctl_sched_features;
+#ifdef CONFIG_JUMP_LABEL
#define SCHED_FEAT(name, enabled) \
static __always_inline bool static_branch_##name(struct static_key *key) \
{ \
@@ -1649,7 +1650,13 @@ static __always_inline bool static_branch_##name(struct
static_key *key) \
extern struct static_key sched_feat_keys[__SCHED_FEAT_NR];
#define sched_feat(x) (static_branch_##x(_feat_keys[__SCHED_FEAT_##x]))
-#else /* !(SCHED_DEBUG && CONFIG_JUMP_LABEL) */
+#else /* !CONFIG_JUMP_LABEL */
+
+#define sched_feat(x) (sysctl_sched_features & (1UL << __SCHED_FEAT_##x))
+
+#endif /* CONFIG_JUMP_LABEL */
+
+#else /* !SCHED_DEBUG */
/*
* Each translation unit has its own copy of sysctl_sched_features to allow
@@ -1665,7 +1672,7 @@ static const_debug __maybe_unused unsigned int
sysctl_sched_features =
#define sched_feat(x) !!(sysctl_sched_features & (1UL << __SCHED_FEAT_##x))
-#endif /* SCHED_DEBUG && CONFIG_JUMP_LABEL */
+#endif /* SCHED_DEBUG */
extern struct static_key_false sched_numa_balancing;
extern struct static_key_false sched_schedstats;
--
2.26.2
Re: [linux-safety] [PATCH] usb: host: ehci-sched: add comment about find_tt() not returning error
On Mon, Oct 12, 2020 at 08:25:30PM +0200, Lukas Bulwahn wrote: > > > On Mon, 12 Oct 2020, Greg Kroah-Hartman wrote: > > > On Mon, Oct 12, 2020 at 05:10:21PM +0200, Lukas Bulwahn wrote: > > > And for the static analysis finding, we need to find a way to ignore this > > > finding without simply ignoring all findings or new findings that just > > > look very similar to the original finding, but which are valid. > > > > Then I suggest you fix the tool that "flagged" this, surely this is not > > the only thing it detected with a test like this, right? > > > > What tool reported this? > > > > Sudip and I are following on clang analyzer findings. > > On linux-next, there is new build target 'make clang-analyzer' that > outputs a bunch of warnings, just as you would expect from such static > analysis tools. Why not fix the things that it finds that are actually issues? If there are no actual issues found, then perhaps you should use a better tool? :) thanks, greg k-h
Re: [linux-safety] [PATCH] usb: host: ehci-sched: add comment about find_tt() not returning error
On Mon, Oct 12, 2020 at 08:17:34PM +0200, Lukas Bulwahn wrote: > > If you are suggesting some sort of special code annotation that the tool > > would understand, I am open to that. But I'm not aware of any even > > vaguely standard way of marking up a particular function call to > > indicate it will not return an error. > > I cannot yet say if some annotation would work, we, Sudip and me, need to > investigate. It could be that something like, assert(!IS_ERR(tt)), is > sufficient to let the tools know that they can safely assume that the > path they are complaining about is not possible. > > We could make the assert() a nop, so it would not effect the resulting > object code in any way. Things like assert() have been rejected numberous times in the past in the kernel, good luck with that :) greg k-h
[PATCH 0/3] Add QPIC NAND support for IPQ6018
IPQ6018 has the QPIC NAND controller of version 1.5.0, which uses the BAM DMA. Add support for the QPIC BAM, QPIC NAND and enable the same in the board DTS file. Kathiravan T (3): dt-bindings: qcom_nandc: IPQ6018 QPIC NAND documentation mtd: rawnand: qcom: Support for IPQ6018 QPIC NAND controller arm64: dts: ipq6018: Add the QPIC peripheral nodes .../devicetree/bindings/mtd/qcom_nandc.txt| 2 + arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts | 16 arch/arm64/boot/dts/qcom/ipq6018.dtsi | 41 +++ drivers/mtd/nand/raw/qcom_nandc.c | 4 ++ 4 files changed, 63 insertions(+) base-commit: bbf5c979011a099af5dc76498918ed7df445635b -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 2/3] mtd: rawnand: qcom: Support for IPQ6018 QPIC NAND controller
Add the compatible string for IPQ6018 QPIC NAND controller
version 1.5.0. It's properties are same as IPQ8074, so reuse
the same.
Signed-off-by: Kathiravan T
---
drivers/mtd/nand/raw/qcom_nandc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c
b/drivers/mtd/nand/raw/qcom_nandc.c
index bd7a7251429b..e7480b53ad40 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -3071,6 +3071,10 @@ static const struct of_device_id qcom_nandc_of_match[] =
{
.compatible = "qcom,ipq4019-nand",
.data = _nandc_props,
},
+ {
+ .compatible = "qcom,ipq6018-nand",
+ .data = _nandc_props,
+ },
{
.compatible = "qcom,ipq8074-nand",
.data = _nandc_props,
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
[PATCH 1/3] dt-bindings: qcom_nandc: IPQ6018 QPIC NAND documentation
Add the binding for the QPIC NAND used on IPQ6018 SoC. Signed-off-by: Kathiravan T --- Documentation/devicetree/bindings/mtd/qcom_nandc.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt index 5c2fba4b30fe..5bdcd9990a94 100644 --- a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt +++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt @@ -6,6 +6,8 @@ Required properties: SoC and it uses ADM DMA * "qcom,ipq4019-nand" - for QPIC NAND controller v1.4.0 being used in IPQ4019 SoC and it uses BAM DMA +* "qcom,ipq6018-nand" - for QPIC NAND controller v1.5.0 being used in +IPQ6018 SoC and it uses BAM DMA * "qcom,ipq8074-nand" - for QPIC NAND controller v1.5.0 being used in IPQ8074 SoC and it uses BAM DMA -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 3/3] arm64: dts: ipq6018: Add the QPIC peripheral nodes
Add the QPIC BAM and QPIC NAND controller support and
enable the same in board DTS file.
Co-developed-by: Anusha Canchi Ramachandra Rao
Signed-off-by: Anusha Canchi Ramachandra Rao
Signed-off-by: Kathiravan T
---
arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts | 16
arch/arm64/boot/dts/qcom/ipq6018.dtsi| 41
2 files changed, 57 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
b/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
index b31117a93995..6e68de1a0b0a 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
+++ b/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
@@ -62,3 +62,19 @@ spi_0_pins: spi-0-pins {
bias-pull-down;
};
};
+
+_bam {
+ status = "ok";
+};
+
+_nand {
+ status = "ok";
+
+ nand@0 {
+ reg = <0>;
+
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ nand-bus-width = <8>;
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
index 1aa8d8579463..6b13e390ee29 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
@@ -173,6 +173,17 @@ serial_3_pins: serial3-pinmux {
drive-strength = <8>;
bias-pull-down;
};
+
+ qpic_pins: qpic-pins {
+ pins = "gpio1", "gpio3", "gpio4",
+ "gpio5", "gpio6", "gpio7",
+ "gpio8", "gpio10", "gpio11",
+ "gpio12", "gpio13", "gpio14",
+ "gpio15", "gpio17";
+ function = "qpic_pad";
+ drive-strength = <8>;
+ bias-disable;
+ };
};
gcc: gcc@180 {
@@ -274,6 +285,36 @@ i2c_1: i2c@78b7000 { /* BLSP1 QUP2 */
status = "disabled";
};
+ qpic_bam: dma@7984000 {
+ compatible = "qcom,bam-v1.7.0";
+ reg = <0x07984000 0x1a000>;
+ interrupts = ;
+ clocks = < GCC_QPIC_CLK>,
+< GCC_QPIC_AHB_CLK>;
+ clock-names = "iface_clk", "bam_clk";
+ #dma-cells = <1>;
+ qcom,ee = <0>;
+ status = "disabled";
+ };
+
+ qpic_nand: nand@79b {
+ compatible = "qcom,ipq6018-nand";
+ reg = <0x079b 0x1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = < GCC_QPIC_CLK>,
+< GCC_QPIC_AHB_CLK>;
+ clock-names = "core", "aon";
+
+ dmas = <_bam 0>,
+ <_bam 1>,
+ <_bam 2>;
+ dma-names = "tx", "rx", "cmd";
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ status = "disabled";
+ };
+
intc: interrupt-controller@b00 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
Re: [RFC] openprom: Fix 'opiocnextprop'; ensure integer conversions; use string size
Hi--
Here are a few corrections for the source code.
On 9/4/20 12:40 PM, Michael Witten wrote:
The following patch improves the quality and correctness of the openprom code.
I have neither a machine to test the result nor a toolchain to compile it, and
that is why it is listed currently as an "RFC". Nonetheless, I believe those
what is your host build system?
https://mirrors.edge.kernel.org/pub/tools/crosstool/
who do have these tools will find the proposed changes useful; I hope you will
help me iterate this patch into something worthy of merging (or use it as the
basis for your own changes).
Sincerely,
Michael Witten
--8<8<8<8<8<8<8<8<8<8<8<8<8<--
...
Signed-off-by: Michael Witten
---
arch/sparc/include/asm/prom.h | 2 +-
arch/sparc/kernel/prom_common.c | 14 +--
drivers/sbus/char/openprom.c| 263
3 files changed, 194 insertions(+), 85 deletions(-)
diff --git a/drivers/sbus/char/openprom.c b/drivers/sbus/char/openprom.c
index 30b9751aad30..9bc2877aa09a 100644
--- a/drivers/sbus/char/openprom.c
+++ b/drivers/sbus/char/openprom.c
@@ -120,69 +154,109 @@ static int getstrings(struct openpromio __user *info,
struct openpromio **opp_p)
-static int opromgetprop(void __user *argp, struct device_node *dp, struct
openpromio *op, int bufsize)
+static int opromgetprop(void __user *argp, struct device_node *dp, struct
openpromio *op, const size_t bufsize)
{
const void *pval;
- int len;
+ int pval_size;
if (!dp ||
- !(pval = of_get_property(dp, op->oprom_array, )) ||
- len <= 0 || len > bufsize)
+ !(pval = of_get_property(dp, op->oprom_array, _size)) ||
+ pval_size <= 0 || pval_size > bufsize) {
+ #ifdef CONFIG_DEBUG_KERNEL
+ if (WARN_ON(op->oprom_size))
+ op->oprom_size = 0;
+ #endif
return copyout(argp, op, sizeof(int));
+ }
+
+ op->oprom_size = pval_size;
+ memcpy(op->oprom_array, pval, pval_size);
- memcpy(op->oprom_array, pval, len);
- op->oprom_array[len] = '\0';
- op->oprom_size = len;
+ #ifdef CONFIG_DEBUG_KERNEL
+ // If the buffer is larger than needed, then
+ // the contents should be nul-terminated in
+ // case the PROM erroneously produces a string
+ // that is not nul-terminated.
+ if (pval_size < bufsize)
+ char *const end = op->oprom_array + pval_size;
+ if (WARN_ON(*end))
+ *end = 0;
Missing braces above?
+ #endif
return copyout(argp, op, sizeof(int) + bufsize);
}
-static int opromnxtprop(void __user *argp, struct device_node *dp, struct openpromio *op, int bufsize)
+static int opromnxtprop(void __user *argp, struct device_node *dp, struct
openpromio *op, const size_t bufsize)
{
struct property *prop;
- int len;
+ size_t name_size;
+ unsigned int uint_name_size;
if (!dp)
- return copyout(argp, op, sizeof(int));
+ goto nothing;
+
if (op->oprom_array[0] == '\0') {
prop = dp->properties;
- if (!prop)
- return copyout(argp, op, sizeof(int));
- len = strlen(prop->name);
} else {
prop = of_find_property(dp, op->oprom_array, NULL);
+ if (prop)
+ prop = prop->next;
+ }
- if (!prop ||
- !prop->next ||
- (len = strlen(prop->next->name)) + 1 > bufsize)
- return copyout(argp, op, sizeof(int));
+ if (!prop)
+ goto nothing;
- prop = prop->next;
- }
+ name_size = 1 + strlen(prop->name);
+
+ uint_name_size = name_size;
+ if (unlikely(uint_name_size != name_size))
+ goto nothing; // overflow
+
+ if (name_size > bufsize)
+ goto nothing;
- memcpy(op->oprom_array, prop->name, len);
- op->oprom_array[len] = '\0';
- op->oprom_size = ++len;
+ memcpy(op->oprom_array, prop->name, name_size);
+ op->oprom_size = uint_name_size;
return copyout(argp, op, sizeof(int) + bufsize);
+
+nothing:
+ #ifdef CONFIG_DEBUG_KERNEL
+ if (WARN_ON(op->oprom_size))
+ op-oprom_size = 0;
op->oprom_size = 0;
+ #endif
+ return copyout(argp, op, sizeof(int));
}
@@ -301,6 +384,12 @@ static long openprom_sunos_ioctl(struct file * file,
else
bufsize = copyin(argp, );
+ #ifdef CONFIG_DEBUG_KERNEL
+ if (WARN_ON(bufsize == 0))
+ bufsize = -EFAULT;
+ #enif
#endif
+
+ static_assert(LONG_MIN <=
Re: [PATCH v2 2/2] cpufreq: tegra194: Fix unlisted boot freq warning
On 12-10-20, 22:36, Sumit Gupta wrote: > Yes, this will also work. Then we don't need the current patch. > You want me to send a patch with change from pr_warn to pr_info? I have sent one. -- viresh
[PATCH] cpufreq: Improve code around unlisted freq check
The cpufreq core checks if the frequency programmed by the bootloaders
is not listed in the freq table and programs one from the table in such
a case. This is done only if the driver has set the
CPUFREQ_NEED_INITIAL_FREQ_CHECK flag.
Currently we print two separate messages, with almost the same content,
and do this with a pr_warn() which may be a bit too much as the driver
only asked us to check this as it expected this to be the case. Lower
down the severity of the print message by switching to pr_info() instead
and print a single message only.
Reported-by: Sumit Gupta
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 2ea245a6c0c0..99864afac272 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1461,14 +1461,13 @@ static int cpufreq_online(unsigned int cpu)
*/
if ((cpufreq_driver->flags & CPUFREQ_NEED_INITIAL_FREQ_CHECK)
&& has_target()) {
+ unsigned int old_freq = policy->cur;
+
/* Are we running at unknown frequency ? */
- ret = cpufreq_frequency_table_get_index(policy, policy->cur);
+ ret = cpufreq_frequency_table_get_index(policy, old_freq);
if (ret == -EINVAL) {
- /* Warn user and fix it */
- pr_warn("%s: CPU%d: Running at unlisted freq: %u KHz\n",
- __func__, policy->cpu, policy->cur);
- ret = __cpufreq_driver_target(policy, policy->cur - 1,
- CPUFREQ_RELATION_L);
+ ret = __cpufreq_driver_target(policy, old_freq - 1,
+ CPUFREQ_RELATION_L);
/*
* Reaching here after boot in a few seconds may not
@@ -1476,8 +1475,8 @@ static int cpufreq_online(unsigned int cpu)
* frequency for longer duration. Hence, a BUG_ON().
*/
BUG_ON(ret);
- pr_warn("%s: CPU%d: Unlisted initial frequency changed
to: %u KHz\n",
- __func__, policy->cpu, policy->cur);
+ pr_info("%s: CPU%d: Running at unlisted initial
frequency: %u KHz, changing to: %u KHz\n",
+ __func__, policy->cpu, old_freq, policy->cur);
}
}
--
2.25.0.rc1.19.g042ed3e048af
Re: [PATCH net v2 1/2] socket: fix option SO_TIMESTAMPING_NEW
> On Mon, Oct 12, 2020 at 5:36 AM Christian Eggers wrote: > > v2: > > - > > - integrated proposal from Willem de Bruijn > > - added Reviewed-by: from Willem and Deepa You may add my Acked-by: Deepa Dinamani -Deepa
Re: Performance regressions in "boot_time" tests in Linux 5.8 Kernel
On 10/12/20 at 05:21pm, Rahul Gopakumar wrote: > Hi Baoquan, > > Attached collected dmesg logs for with and without > commit after adding memblock=debug to kernel cmdline. Thanks, I have got the root cause, will make a patch for your testing soon.
drivers/crypto/sa2ul.c:432:1: warning: the frame size of 1076 bytes is larger than 1024 bytes
Hi Keerthy,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 865c50e1d279671728c2936cb7680eb89355eeea
commit: d2c8ac187fc922e73930a1b2f6a211e27f595d01 crypto: sa2ul - Add AEAD
algorithm support
date: 3 months ago
config: arc-randconfig-r005-20201013 (attached as .config)
compiler: arceb-elf-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=d2c8ac187fc922e73930a1b2f6a211e27f595d01
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout d2c8ac187fc922e73930a1b2f6a211e27f595d01
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc
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 include/linux/printk.h:404,
from include/linux/kernel.h:15,
from include/linux/clk.h:13,
from drivers/crypto/sa2ul.c:11:
drivers/crypto/sa2ul.c: In function 'sa_sha_init':
drivers/crypto/sa2ul.c:1486:33: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
1486 | crypto_ahash_digestsize(tfm), (u64)rctx);
| ^
include/linux/dynamic_debug.h:125:15: note: in definition of macro
'__dynamic_func_call'
125 | func(, ##__VA_ARGS__); \
| ^~~
include/linux/dynamic_debug.h:157:2: note: in expansion of macro
'_dynamic_func_call'
157 | _dynamic_func_call(fmt,__dynamic_dev_dbg, \
| ^~
include/linux/dev_printk.h:115:2: note: in expansion of macro
'dynamic_dev_dbg'
115 | dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~
drivers/crypto/sa2ul.c:1485:2: note: in expansion of macro 'dev_dbg'
1485 | dev_dbg(sa_k3_dev, "init: digest size: %d, rctx=%llx\n",
| ^~~
drivers/crypto/sa2ul.c: In function 'sa_prepare_iopads':
>> drivers/crypto/sa2ul.c:432:1: warning: the frame size of 1076 bytes is
>> larger than 1024 bytes [-Wframe-larger-than=]
432 | }
| ^
vim +432 drivers/crypto/sa2ul.c
407
408 static void sa_prepare_iopads(struct algo_data *data, const u8 *key,
409u16 key_sz, __be32 *ipad, __be32 *opad)
410 {
411 SHASH_DESC_ON_STACK(shash, data->ctx->shash);
412 int block_size = crypto_shash_blocksize(data->ctx->shash);
413 int digest_size = crypto_shash_digestsize(data->ctx->shash);
414 u8 k_ipad[SHA1_BLOCK_SIZE];
415 u8 k_opad[SHA1_BLOCK_SIZE];
416
417 shash->tfm = data->ctx->shash;
418
419 prepare_kiopad(k_ipad, k_opad, key, key_sz);
420
421 memzero_explicit(ipad, block_size);
422 memzero_explicit(opad, block_size);
423
424 crypto_shash_init(shash);
425 crypto_shash_update(shash, k_ipad, block_size);
426 sa_export_shash(shash, block_size, digest_size, ipad);
427
428 crypto_shash_init(shash);
429 crypto_shash_update(shash, k_opad, block_size);
430
431 sa_export_shash(shash, block_size, digest_size, opad);
> 432 }
433
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
linux-next: manual merge of the tty tree with the parisc-hd tree
Hi all,
Today's linux-next merge of the tty tree got a conflict in:
drivers/video/console/sticon.c
between commit:
fbb75b71b131 ("parisc/sticon: Add user font support")
from the parisc-hd tree and commits:
d73568c4ccb0 ("vt: make vc_data pointers const in selection.h")
23f87274f0ad ("sticon: remove no-op sticon_set_origin()")
from the tty tree.
I fixed it up (there is some overlap and I more or less used the former
version of the conflicting bits) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
pgpLyA1TCxg3Z.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 3/4 RESEND] MIPS: Loongson64: Add /proc/boardinfo
On 10/13/2020 08:15 AM, Jiaxun Yang wrote:
于 2020年10月12日 GMT+08:00 下午8:02:25, Tiezhu Yang 写到:
On 10/12/2020 06:38 PM, Thomas Bogendoerfer wrote:
On Sun, Oct 11, 2020 at 07:47:53AM +0800, Tiezhu Yang wrote:
Add /proc/boardinfo to get mainboard and BIOS info easily on the Loongson
platform, this is useful to point out the current used mainboard type and
BIOS version when there exists problems related with hardware or firmware.
E.g. with this patch:
[loongson@linux ~]$ cat /proc/boardinfo
Board Info
Manufacturer: LEMOTE
Board Name : LEMOTE-LS3A4000-7A1000-1w-V01-pc
Family : LOONGSON3
BIOS Info
Vendor : Kunlun
Version : Kunlun-A1901-V4.1.3-20200414093938
ROM Size: 4 KB
Release Date: 2020-04-14
Why does Loongson64 need this extra file no other architecture or MIPS
platform need ? Do others provide this information via a different method ?
If yes, why can't Loongson64 do the same ?
Hi Thomas,
This is related with the implementation of firmware.
Using dmidecode command can get the similar info if there exists SMBIOS
in firmware, but the fact is there is no SMBIOS on some machines, we can
see nothing when execute dmidecode, like this:
[root@linux loongson]# dmidecode
# dmidecode 2.12
# No SMBIOS nor DMI entry point found, sorry.
The following three structures are already defined in the interface
specification about firmware and kernel on the Loongson platform,
this is common requirement and specific for Loongson64, so add a
new boardinfo.c file in arch/mips/loongson64.
arch/mips/include/asm/mach-loongson64/boot_param.h
struct interface_info {
u16 vers; /* version of the specificition */
u16 size;
u8 flag;
char description[64];
} __packed;
struct board_devices {
char name[64];/* hold the device name */
u32 num_resources; /* number of device_resource */
/* for each device's resource */
struct resource_loongson resource[MAX_RESOURCE_NUMBER];
/* arch specific additions */
struct archdev_data archdata;
};
struct loongson_special_attribute {
u16 vers; /* version of this special */
char special_name[64]; /* special_atribute_name */
u32 loongson_special_type; /* type of special device */
/* for each device's resource */
struct resource_loongson resource[MAX_RESOURCE_NUMBER];
};
Hi Tiezhu,
Through I don't think touching top level of proc would be a good idea. It's all
about API consistency.
If you intend to provide user an interface then I guess /sys/firmware/lefi
like what DMI did or somewhere less critical is better.
There is no guarantee that Loongson64 device would come with LEFI,
although it's mandatory for now.
Hi Jiaxun,
Thank you very much.
Let us add /sys/firmware/lefi/boardinfo, I will do it and then send a
new patch.
Thanks,
Tiezhu
Thanks.
- Jiaxun
Thanks,
Tiezhu
Thomas.
[PATCH V4] dt-bindings: mailbox : arm,mhuv2: Add bindings
This patch adds device tree binding for ARM Message Handling Unit (MHU) controller version 2. Based on earlier work by Morten Borup Petersen. Co-developed-by: Tushar Khandelwal Signed-off-by: Tushar Khandelwal Signed-off-by: Viresh Kumar --- V3->V4: - Made interrupts property compulsory for receiver - Added interrupts for both nodes in example - Fixed min/max items for protocols property - Don't add -tx/rx to node's name. V2->V3: - compatible is changed to arm-mhuv2-tx/rx. Later version of MHUv2 have an interrupt in the sender mode as well and we can't find if a mailbox is sender or receiver just based on an interrupt anymore. We needed a better way. - arm-mhuv2-mode is renamed to arm,mhuv2-protocols to fit the purpose better. - Minor formatting otherwise. Morten: Please let me know if you want me to add your signoff here from some other email id as you no longer work with ARM. --- .../bindings/mailbox/arm,mhuv2.yaml | 215 ++ 1 file changed, 215 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml new file mode 100644 index ..013b7aeda713 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml @@ -0,0 +1,215 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/arm,mhuv2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM MHUv2 Mailbox Controller + +maintainers: + - Tushar Khandelwal + - Viresh Kumar + +description: | + The Arm Message Handling Unit (MHU) Version 2 is a mailbox controller that has + between 1 and 124 channel windows (each 32-bit wide) to provide unidirectional + communication with remote processor(s), where the number of channel windows + are implementation dependent. + + Given the unidirectional nature of the controller, an MHUv2 mailbox may only + be written to or read from. If a pair of MHU controllers is implemented + between two processing elements to provide bidirectional communication, these + must be specified as two separate mailboxes. + + If the interrupts property is present in device tree node, then its treated as + a "receiver" mailbox, otherwise a "sender". + + An MHU controller must be specified along with the supported transport + protocols. The transport protocols determine the method of data transmission + as well as the number of provided mailbox channels. + + Following are the possible transport protocols. + + - Doorbell: Each transfer is made up of single bit flag, using any one of the +bits in a channel window. A channel window can support up to 32 doorbells +and the entire window shall be used in doorbell protocol. Optionally, data +may be transmitted through a shared memory region, wherein the MHU is used +strictly as an interrupt generation mechanism but that is out of the scope +of these bindings. + + - Single-word: Each transfer is single word, using a single Channel window. + + - Multi-word: Each transfer is made of two or more words, using two or more +channel windows. + +# We need a select here so we don't match all nodes with 'arm,primecell' +select: + properties: +compatible: + contains: +enum: + - arm,mhuv2-tx + - arm,mhuv2-rx + required: +- compatible + +properties: + compatible: +oneOf: + - description: Sender mode +items: + - const: arm,mhuv2-tx + - const: arm,primecell + + - description: Receiver-mode +items: + - const: arm,mhuv2-rx + - const: arm,primecell + + reg: +maxItems: 1 + + interrupts: +description: | + The MHUv2 controller always implements an interrupt in the "receiver" + mode, while the interrupt in the "sender" mode was not available in the + version MHUv2.0, but the later versions do have it. +maxItems: 1 + + clocks: +maxItems: 1 + + clock-names: +maxItems: 1 + + arm,mhuv2-protocols: +$ref: /schemas/types.yaml#/definitions/uint32-matrix +description: | + The MHUv2 controller may contain up to 124 channel windows (each 32-bit + wide). The hardware and the DT bindings allows any combination of those to + be used for various transport protocols. + + This property allows a platform to describe how these channel windows are + used in various transport protocols. The entries in this property shall be + present as an array of tuples, where each tuple describes details about + one of the transport protocol being implemented over some channel + window(s). + + The first field of a tuple signifies the transfer protocol, 0 is reserved + for doorbell protocol, 1 is reserved for single-word protocol and 2 is + reserved for multi-word protocol. Using any other
Re: [PATCH v8 0/7] perf: Stream comparison
Hi Jiri, Hi Arnaldo, How about v8 series? V6 got ACK from Jiri and I updated the series to v8 according to Arnaldo's comments. Please let me know if there are still some issues for this version then I can continue improving the patchset. Thanks Jin Yao On 10/9/2020 10:28 AM, Jin Yao wrote: Sometimes, a small change in a hot function reducing the cycles of this function, but the overall workload doesn't get faster. It is interesting where the cycles are moved to. What it would like is to diff before/after streams. The stream is the branch history which is aggregated by the branch records from perf samples. For example, the callchains aggregated from the branch records. By browsing the hot stream, we can understand the hot code path. By browsing the hot streams, we can understand the hot code path. By comparing the cycles variation of same streams between old perf data and new perf data, we can understand if the cycles are moved to other codes. The before stream is the stream in perf.data.old. The after stream is the stream in perf.data. Diffing before/after streams compares top N hottest streams between two perf data files. If all entries of one stream in perf.data.old are fully matched with all entries of another stream in perf.data, we think two streams are matched, otherwise the streams are not matched. For example, cycles: 1, hits: 26.80% cycles: 1, hits: 27.30% -- -- main div.c:39 main div.c:39 main div.c:44 main div.c:44 The above streams are matched and we can see for the same streams the cycles (1) are equal and the callchain hit percents are slightly changed (26.80% vs. 27.30%). That's expected. Now let's see example. perf record -b ... Generate perf.data.old with branch data perf record -b ... Generate perf.data with branch data perf diff --stream [ Matched hot streams ] hot chain pair 1: cycles: 1, hits: 27.77% cycles: 1, hits: 9.24% --- -- main div.c:39 main div.c:39 main div.c:44 main div.c:44 hot chain pair 2: cycles: 34, hits: 20.06%cycles: 27, hits: 16.98% --- -- __random_r random_r.c:360 __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:380 __random_r random_r.c:357 __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:288 __random random.c:288 rand rand.c:27 rand rand.c:27 rand rand.c:26 rand rand.c:26 rand@pltrand@plt rand@pltrand@plt compute_flag div.c:25 compute_flag div.c:25 compute_flag div.c:22 compute_flag div.c:22 main div.c:40 main div.c:40 main div.c:40 main div.c:40 main div.c:39 main div.c:39 hot chain pair 3: cycles: 9, hits: 4.48% cycles: 6, hits: 4.51% --- -- __random_r random_r.c:360 __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:380 [ Hot streams in old perf data only ] hot chain 1: cycles: 18, hits: 6.75% -- __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291
Re: [PATCH] sched/cputime: correct account of irqtime
On Tue, Oct 13, 2020 at 11:10 AM jun qian wrote:
>
> Pingfan Liu 于2020年10月12日周一 下午9:54写道：
> >
> > __do_softirq() may be interrupted by hardware interrupts. In this case,
> > irqtime_account_irq() will account the time slice as CPUTIME_SOFTIRQ by
> > mistake.
> >
> > By passing irqtime_account_irq() an extra param about either hardirq or
> > softirq, irqtime_account_irq() can handle the above case.
> >
> > Signed-off-by: Pingfan Liu
> > Cc: Ingo Molnar
> > Cc: Peter Zijlstra
> > Cc: Juri Lelli
> > Cc: Vincent Guittot
> > Cc: Dietmar Eggemann
> > Cc: Steven Rostedt
> > Cc: Ben Segall
> > Cc: Mel Gorman
> > Cc: Thomas Gleixner
> > Cc: Andy Lutomirski
> > Cc: Will Deacon
> > Cc: "Paul E. McKenney"
> > Cc: Frederic Weisbecker
> > Cc: Allen Pais
> > Cc: Romain Perier
> > To: linux-kernel@vger.kernel.org
> > ---
> > include/linux/hardirq.h | 4 ++--
> > include/linux/vtime.h | 12 ++--
> > kernel/sched/cputime.c | 4 ++--
> > kernel/softirq.c| 6 +++---
> > 4 files changed, 13 insertions(+), 13 deletions(-)
> >
> > diff --git a/include/linux/hardirq.h b/include/linux/hardirq.h
> > index 754f67a..56e7bb5 100644
> > --- a/include/linux/hardirq.h
> > +++ b/include/linux/hardirq.h
> > @@ -32,7 +32,7 @@ static __always_inline void rcu_irq_enter_check_tick(void)
> > */
> > #define __irq_enter() \
> > do {\
> > - account_irq_enter_time(current);\
> > + account_irq_enter_time(current, true); \
> > preempt_count_add(HARDIRQ_OFFSET); \
> > lockdep_hardirq_enter();\
> > } while (0)
> > @@ -63,7 +63,7 @@ void irq_enter_rcu(void);
> > #define __irq_exit() \
> > do {\
> > lockdep_hardirq_exit(); \
> > - account_irq_exit_time(current); \
> > + account_irq_exit_time(current, true); \
> > preempt_count_sub(HARDIRQ_OFFSET); \
> > } while (0)
> >
> > diff --git a/include/linux/vtime.h b/include/linux/vtime.h
> > index 2cdeca0..294188ae1 100644
> > --- a/include/linux/vtime.h
> > +++ b/include/linux/vtime.h
> > @@ -98,21 +98,21 @@ static inline void vtime_flush(struct task_struct *tsk)
> > { }
> >
> >
> > #ifdef CONFIG_IRQ_TIME_ACCOUNTING
> > -extern void irqtime_account_irq(struct task_struct *tsk);
> > +extern void irqtime_account_irq(struct task_struct *tsk, bool hardirq);
> > #else
> > -static inline void irqtime_account_irq(struct task_struct *tsk) { }
> > +static inline void irqtime_account_irq(struct task_struct *tsk, bool
> > hardirq) { }
> > #endif
> >
> > -static inline void account_irq_enter_time(struct task_struct *tsk)
> > +static inline void account_irq_enter_time(struct task_struct *tsk, bool
> > hardirq)
> > {
> > vtime_account_irq_enter(tsk);
> > - irqtime_account_irq(tsk);
> > + irqtime_account_irq(tsk, hardirq);
> > }
> >
> > -static inline void account_irq_exit_time(struct task_struct *tsk)
> > +static inline void account_irq_exit_time(struct task_struct *tsk, bool
> > hardirq)
> > {
> > vtime_account_irq_exit(tsk);
> > - irqtime_account_irq(tsk);
> > + irqtime_account_irq(tsk, hardirq);
> > }
> >
> > #endif /* _LINUX_KERNEL_VTIME_H */
> > diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> > index 5a55d23..166f1d7 100644
> > --- a/kernel/sched/cputime.c
> > +++ b/kernel/sched/cputime.c
> > @@ -47,7 +47,7 @@ static void irqtime_account_delta(struct irqtime
> > *irqtime, u64 delta,
> > * Called before incrementing preempt_count on {soft,}irq_enter
> > * and before decrementing preempt_count on {soft,}irq_exit.
> > */
> > -void irqtime_account_irq(struct task_struct *curr)
> > +void irqtime_account_irq(struct task_struct *curr, bool hardirq)
> > {
> > struct irqtime *irqtime = this_cpu_ptr(_irqtime);
> > s64 delta;
> > @@ -68,7 +68,7 @@ void irqtime_account_irq(struct task_struct *curr)
> > */
> > if (hardirq_count())
> > irqtime_account_delta(irqtime, delta, CPUTIME_IRQ);
> > - else if (in_serving_softirq() && curr != this_cpu_ksoftirqd())
> > + else if (in_serving_softirq() && curr != this_cpu_ksoftirqd() &&
> > !hardirq)
> > irqtime_account_delta(irqtime, delta, CPUTIME_SOFTIRQ);
> > }
>
> In my opinion, we don't need to use the hardirq flag, the code: if
> (hardirq_count())
> already tell us that where the delt time is from.
Considering the scenario in which hardirq happens immediately after
__do_softirq()->local_irq_enable(). The following code shows that
hardirq_count() can not help.
#define __irq_enter() \
do { \
account_irq_enter_time(current); \
preempt_count_add(HARDIRQ_OFFSET); \
lockdep_hardirq_enter(); \
} while (0)
Anything I missed?
Thanks,
Re: Re: WARNING in udf_truncate_extents
> On 10/12/20 6:20 AM, syzbot wrote: >> dashboard link: https://syzkaller.appspot.com/bug?extid=43fc5ba6dcb33e3261ca >> compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ >> c2443155a0fb245c8f17f2c1c72b6ea391e86e81) >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10ce0a8b90 >> >> The issue was bisected to: >> >> commit 2004bfdef945fe55196db6b9cdf321fbc75bb0de >> Author: Bart Van Assche >> Date: Tue Mar 10 04:26:21 2020 + >> >> null_blk: Fix the null_add_dev() error path > > #syz wrong-bisect unknown command "wrong-bisect" > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/2765fd98-7101-832e-2b34-72bd8c5ecf22%40acm.org.
Re: Re: WARNING in udf_truncate_extents
> On 10/12/20 6:20 AM, syzbot wrote: >> dashboard link: https://syzkaller.appspot.com/bug?extid=43fc5ba6dcb33e3261ca >> compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ >> c2443155a0fb245c8f17f2c1c72b6ea391e86e81) >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10ce0a8b90 >> >> The issue was bisected to: >> >> commit 2004bfdef945fe55196db6b9cdf321fbc75bb0de >> Author: Bart Van Assche >> Date: Tue Mar 10 04:26:21 2020 + >> >> null_blk: Fix the null_add_dev() error path > > #syz wrong-bisect unknown command "wrong-bisect"
Re: WARNING in udf_truncate_extents
On 10/12/20 6:20 AM, syzbot wrote: > dashboard link: https://syzkaller.appspot.com/bug?extid=43fc5ba6dcb33e3261ca > compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ > c2443155a0fb245c8f17f2c1c72b6ea391e86e81) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10ce0a8b90 > > The issue was bisected to: > > commit 2004bfdef945fe55196db6b9cdf321fbc75bb0de > Author: Bart Van Assche > Date: Tue Mar 10 04:26:21 2020 + > > null_blk: Fix the null_add_dev() error path #syz wrong-bisect
Re: [PATCH] ptp: ptp_clockmatrix: initialize variables
On 10/12/20 3:01 PM, Richard Cochran wrote: > On Sun, Oct 11, 2020 at 01:09:55PM -0700, t...@redhat.com wrote: >> From: Tom Rix >> >> Clang static analysis reports this representative problem >> >> ptp_clockmatrix.c:1852:2: warning: 5th function call argument >> is an uninitialized value >> snprintf(idtcm->version, sizeof(idtcm->version), "%u.%u.%u", >> ^~~~ >> >> idtcm_display_version_info() calls several idtcm_read_*'s without >> checking a return status. > So why not check the return status? calling function is a print information only function that returns void. I do think not adding error handling is worth it. I could change the return and then the calls if if you like. Tom > > Your patch papers over the issue. > > Thanks, > Richard >
[PATCH v3] usb: cdns3: Rids of duplicate error message
On failure, the platform_get_irq_byname prints an error message
so, patch removes error message related to this function from
core.c file.
A change was suggested during reviewing CDNSP driver by Chunfeng Yun.
Signed-off-by: Pawel Laszczak
---
Changelog:
v3
- changed error condition checking for dev_irq.
v2
- simplified code as sugested by Roger Quadros.
drivers/usb/cdns3/core.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
index a0f73d4711ae..f2dedce3a40e 100644
--- a/drivers/usb/cdns3/core.c
+++ b/drivers/usb/cdns3/core.c
@@ -466,11 +466,8 @@ static int cdns3_probe(struct platform_device *pdev)
cdns->xhci_res[1] = *res;
cdns->dev_irq = platform_get_irq_byname(pdev, "peripheral");
- if (cdns->dev_irq == -EPROBE_DEFER)
- return cdns->dev_irq;
-
if (cdns->dev_irq < 0)
- dev_err(dev, "couldn't get peripheral irq\n");
+ return cdns->dev_irq;
regs = devm_platform_ioremap_resource_byname(pdev, "dev");
if (IS_ERR(regs))
@@ -478,14 +475,9 @@ static int cdns3_probe(struct platform_device *pdev)
cdns->dev_regs = regs;
cdns->otg_irq = platform_get_irq_byname(pdev, "otg");
- if (cdns->otg_irq == -EPROBE_DEFER)
+ if (cdns->otg_irq < 0)
return cdns->otg_irq;
- if (cdns->otg_irq < 0) {
- dev_err(dev, "couldn't get otg irq\n");
- return cdns->otg_irq;
- }
-
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "otg");
if (!res) {
dev_err(dev, "couldn't get otg resource\n");
--
2.17.1
Re: [External] Re: [PATCH] mm: proc: add Sock to /proc/meminfo
On Tue, Oct 13, 2020 at 6:12 AM Cong Wang wrote: > > On Mon, Oct 12, 2020 at 2:53 AM Muchun Song wrote: > > We are not complaining about TCP using too much memory, but how do > > we know that TCP uses a lot of memory. When I firstly face this problem, > > I do not know who uses the 25GB memory and it is not shown in the > > /proc/meminfo. > > If we can know the amount memory of the socket buffer via /proc/meminfo, we > > may not need to spend a lot of time troubleshooting this problem. Not > > everyone > > knows that a lot of memory may be used here. But I believe many people > > should know /proc/meminfo to confirm memory users. > > Well, I'd bet networking people know `ss -m` better than /proc/meminfo, I agree with you. But if someone(not networking people) faces the same problem. He may suspect that there is a memory leak or think that a certain driver allocates memory but has no statistics. He only saw the memory disappeared via /proc/meminfo. > generally speaking. > > The practice here is that if you want some networking-specific counters, > add it to where networking people know better, that is, `ss -m` or > /proc/net/... > > Or maybe the problem you described is not specific to networking at all, > there must be some other places where pages are allocated but not charged. Yeah, it is not charged. The allocation path is as follows. This allocation consumes 25GB memory on our server. And it belongs to the network core. Thanks. __alloc_pages_nodemask+0x11d/0x290 skb_page_frag_refill+0x68/0xf0 sk_page_frag_refill+0x19/0x70 tcp_sendmsg_locked+0x2f4/0xd10 tcp_sendmsg+0x29/0xa0 sock_sendmsg+0x30/0x40 sock_write_iter+0x8f/0x100 __vfs_write+0x10b/0x190 vfs_write+0xb0/0x190 ksys_write+0x5a/0xd0 do_syscall_64+0x5d/0x110 entry_SYSCALL_64_after_hwframe+0x44/0xa9 > If so, adding a general mm counter in /proc/meminfo makes sense, but > it won't be specific to networking. > > Thanks. -- Yours, Muchun
[PATCH] nvmet: fix uninitialized work for zero kato
Hit a warning:
WARNING: CPU: 1 PID: 241 at kernel/workqueue.c:1627
__queue_delayed_work+0x6d/0x90
with trace:
mod_delayed_work_on+0x59/0x90
nvmet_update_cc+0xee/0x100 [nvmet]
nvmet_execute_prop_set+0x72/0x80 [nvmet]
nvmet_tcp_try_recv_pdu+0x2f7/0x770 [nvmet_tcp]
nvmet_tcp_io_work+0x63f/0xb2d [nvmet_tcp]
...
This could be reproduced easily with a keep alive time 0:
nvme connect -t tcp -n NQN -a ADDR -s PORT --keep-alive-tmo=0
The reason is:
Starting an uninitialized work when initiator connects with zero
kato. Althrough keep-alive timer is disabled during allocating a ctrl
(fix in 0d3b6a8d213a), ka_work still has a chance to run
(called by nvmet_start_ctrl to detect dead host).
Initilize ka_work during allocating ctrl, and set a reasonable kato
before scheduling ka_work.
Signed-off-by: zhenwei pi
---
drivers/nvme/target/core.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c
index b7b63330b5ef..3c5b2b065476 100644
--- a/drivers/nvme/target/core.c
+++ b/drivers/nvme/target/core.c
@@ -19,6 +19,8 @@ struct workqueue_struct *buffered_io_wq;
static const struct nvmet_fabrics_ops *nvmet_transports[NVMF_TRTYPE_MAX];
static DEFINE_IDA(cntlid_ida);
+#define NVMET_DEFAULT_KATO 5
+
/*
* This read/write semaphore is used to synchronize access to configuration
* information on a target system that will result in discovery log page
@@ -385,6 +387,11 @@ static void nvmet_keep_alive_timer(struct work_struct
*work)
if (cmd_seen) {
pr_debug("ctrl %d reschedule traffic based keep-alive timer\n",
ctrl->cntlid);
+
+ /* run once, trigger from nvmet_start_ctrl to detect dead link
*/
+ if (!ctrl->kato)
+ return;
+
schedule_delayed_work(>ka_work, ctrl->kato * HZ);
return;
}
@@ -403,15 +410,11 @@ static void nvmet_start_keep_alive_timer(struct
nvmet_ctrl *ctrl)
pr_debug("ctrl %d start keep-alive timer for %d secs\n",
ctrl->cntlid, ctrl->kato);
- INIT_DELAYED_WORK(>ka_work, nvmet_keep_alive_timer);
schedule_delayed_work(>ka_work, ctrl->kato * HZ);
}
static void nvmet_stop_keep_alive_timer(struct nvmet_ctrl *ctrl)
{
- if (unlikely(ctrl->kato == 0))
- return;
-
pr_debug("ctrl %d stop keep-alive\n", ctrl->cntlid);
cancel_delayed_work_sync(>ka_work);
@@ -1107,6 +1110,8 @@ static inline u8 nvmet_cc_iocqes(u32 cc)
static void nvmet_start_ctrl(struct nvmet_ctrl *ctrl)
{
+ u32 kato = ctrl->kato ? ctrl->kato : NVMET_DEFAULT_KATO;
+
lockdep_assert_held(>lock);
if (nvmet_cc_iosqes(ctrl->cc) != NVME_NVM_IOSQES ||
@@ -1126,7 +1131,7 @@ static void nvmet_start_ctrl(struct nvmet_ctrl *ctrl)
* in case a host died before it enabled the controller. Hence, simply
* reset the keep alive timer when the controller is enabled.
*/
- mod_delayed_work(system_wq, >ka_work, ctrl->kato * HZ);
+ mod_delayed_work(system_wq, >ka_work, kato * HZ);
}
static void nvmet_clear_ctrl(struct nvmet_ctrl *ctrl)
@@ -1378,6 +1383,7 @@ u16 nvmet_alloc_ctrl(const char *subsysnqn, const char
*hostnqn,
/* keep-alive timeout in seconds */
ctrl->kato = DIV_ROUND_UP(kato, 1000);
+ INIT_DELAYED_WORK(>ka_work, nvmet_keep_alive_timer);
ctrl->err_counter = 0;
spin_lock_init(>error_lock);
--
2.11.0
Re: [PATCH v11 3/3] ASoC: qcom: sc7180: Add machine driver for sound card registration
On Mon, Sep 14, 2020 at 4:06 PM Cheng-Yi Chiang wrote:
>
> From: Ajit Pandey
>
> Add new driver to register sound card on sc7180 trogdor board and
> do the required configuration for lpass cpu dai and external codecs
> connected over MI2S interfaces.
>
> Signed-off-by: Ajit Pandey
> Signed-off-by: Cheng-Yi Chiang
> ---
> sound/soc/qcom/Kconfig | 12 ++
> sound/soc/qcom/Makefile | 2 +
> sound/soc/qcom/sc7180.c | 266
> 3 files changed, 280 insertions(+)
> create mode 100644 sound/soc/qcom/sc7180.c
>
> diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
> index a607ace8b089..0459185ee243 100644
> --- a/sound/soc/qcom/Kconfig
> +++ b/sound/soc/qcom/Kconfig
> @@ -116,4 +116,16 @@ config SND_SOC_SDM845
> SDM845 SoC-based systems.
> Say Y if you want to use audio device on this SoCs.
>
> +config SND_SOC_SC7180
> + tristate "SoC Machine driver for SC7180 boards"
> + depends on I2C
> + select SND_SOC_QCOM_COMMON
> + select SND_SOC_LPASS_SC7180
> + select SND_SOC_MAX98357A
> + select SND_SOC_RT5682_I2C
> + help
> + To add support for audio on Qualcomm Technologies Inc.
> + SC7180 SoC-based systems.
> + Say Y if you want to use audio device on this SoCs.
> +
> endif #SND_SOC_QCOM
> diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
> index 7972c9479ab0..0cdcbf367ef1 100644
> --- a/sound/soc/qcom/Makefile
> +++ b/sound/soc/qcom/Makefile
> @@ -17,12 +17,14 @@ snd-soc-storm-objs := storm.o
> snd-soc-apq8016-sbc-objs := apq8016_sbc.o
> snd-soc-apq8096-objs := apq8096.o
> snd-soc-sdm845-objs := sdm845.o
> +snd-soc-sc7180-objs := sc7180.o
> snd-soc-qcom-common-objs := common.o
>
> obj-$(CONFIG_SND_SOC_STORM) += snd-soc-storm.o
> obj-$(CONFIG_SND_SOC_APQ8016_SBC) += snd-soc-apq8016-sbc.o
> obj-$(CONFIG_SND_SOC_MSM8996) += snd-soc-apq8096.o
> obj-$(CONFIG_SND_SOC_SDM845) += snd-soc-sdm845.o
> +obj-$(CONFIG_SND_SOC_SC7180) += snd-soc-sc7180.o
> obj-$(CONFIG_SND_SOC_QCOM_COMMON) += snd-soc-qcom-common.o
>
> #DSP lib
> diff --git a/sound/soc/qcom/sc7180.c b/sound/soc/qcom/sc7180.c
> new file mode 100644
> index ..0e90448523b0
> --- /dev/null
> +++ b/sound/soc/qcom/sc7180.c
> @@ -0,0 +1,266 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +//
> +// Copyright (c) 2020, The Linux Foundation. All rights reserved.
> +//
> +// sc7180.c -- ALSA SoC Machine driver for SC7180
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "../codecs/rt5682.h"
> +#include "common.h"
> +#include "lpass.h"
> +
> +#define DEFAULT_MCLK_RATE 1920
> +#define RT5682_PLL1_FREQ (48000 * 512)
> +
> +// This will be defined in include/dt-bindings/sound/sc7180-lpass.h
> +#define LPASS_DP_RX 2
> +
> +struct sc7180_snd_data {
> + struct snd_soc_card card;
> + u32 pri_mi2s_clk_count;
> + struct snd_soc_jack hs_jack;
> + struct snd_soc_jack hdmi_jack;
> +};
> +
> +static void sc7180_jack_free(struct snd_jack *jack)
> +{
> + struct snd_soc_component *component = jack->private_data;
> +
> + snd_soc_component_set_jack(component, NULL, NULL);
> +}
> +
> +static int sc7180_headset_init(struct snd_soc_pcm_runtime *rtd)
> +{
> + struct snd_soc_card *card = rtd->card;
> + struct sc7180_snd_data *pdata = snd_soc_card_get_drvdata(card);
> + struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, 0);
> + struct snd_soc_component *component = codec_dai->component;
> + struct snd_jack *jack;
> + int rval;
> +
> + rval = snd_soc_card_jack_new(
> + card, "Headset Jack",
> + SND_JACK_HEADSET |
> + SND_JACK_HEADPHONE |
> + SND_JACK_BTN_0 | SND_JACK_BTN_1 |
> + SND_JACK_BTN_2 | SND_JACK_BTN_3,
> + >hs_jack, NULL, 0);
> +
> + if (rval < 0) {
> + dev_err(card->dev, "Unable to add Headset Jack\n");
> + return rval;
> + }
> +
> + jack = pdata->hs_jack.jack;
> +
> + snd_jack_set_key(jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
> + snd_jack_set_key(jack, SND_JACK_BTN_1, KEY_VOICECOMMAND);
> + snd_jack_set_key(jack, SND_JACK_BTN_2, KEY_VOLUMEUP);
> + snd_jack_set_key(jack, SND_JACK_BTN_3, KEY_VOLUMEDOWN);
> +
> + jack->private_data = component;
> + jack->private_free = sc7180_jack_free;
> +
> + return snd_soc_component_set_jack(component, >hs_jack, NULL);
> +}
> +
> +static int sc7180_hdmi_init(struct snd_soc_pcm_runtime *rtd)
> +{
> + struct snd_soc_card *card = rtd->card;
> + struct sc7180_snd_data *pdata = snd_soc_card_get_drvdata(card);
> + struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, 0);
> + struct snd_soc_component *component = codec_dai->component;
> + struct snd_jack *jack;
> +
Re: [PATCH v11 2/3] ASoC: qcom: dt-bindings: Add sc7180 machine bindings
On Tue, Sep 15, 2020 at 8:44 PM Cheng-yi Chiang wrote: > > On Tue, Sep 15, 2020 at 1:48 AM Rob Herring wrote: > > > > On Mon, 14 Sep 2020 16:06:18 +0800, Cheng-Yi Chiang wrote: > > > Add devicetree bindings documentation file for sc7180 sound card. > > > > > > Signed-off-by: Cheng-Yi Chiang > > > --- > > > .../bindings/sound/qcom,sc7180.yaml | 130 ++ > > > 1 file changed, 130 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/sound/qcom,sc7180.yaml > > > > > > > > > Please add Acked-by/Reviewed-by tags when posting new versions. However, > > there's no need to repost patches *only* to add the tags. The upstream > > maintainer will do that for acks received on the version they apply. > > > > If a tag was not added on purpose, please state why and what changed. > > > > Hi Rob, > There was a change between v9 and v10 on compatible string so I did > not add your Reviewed-by. > Now it is "qcom,sc7180-sndcard-rt5682-m98357-1mic" following Stephan's > comment in > > https://patchwork.kernel.org/comment/23608881/ > > to make compatible string more specific to board configuration. > I only add the note to the cover letter. Sorry the cover letter became > too long to follow. > I will add the note in patch mail itself for future changes. > Thanks for taking a look again. Hi Rob, Could you please kindly review this patch ? v11 contains the compatible string "qcom,sc7180-sndcard-rt5682-m98357-1mic" following Stephan's suggestion in "[v9,3/3] ASoC: qcom: sc7180: Add machine driver for sound card registration" ( https://patchwork.kernel.org/patch/11770201/#23608881 ) to specify the combination of components. Please let me know if this looks good to you. Thanks!
Re: linux-next: manual merge of the tip tree with the amdgpu tree
Hi all,
On Mon, 12 Oct 2020 15:15:27 +1100 Stephen Rothwell
wrote:
>
> On Wed, 23 Sep 2020 15:13:36 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> >
> > between commit:
> >
> > 59d7115dae02 ("drm/amdkfd: Move process doorbell allocation into kfd
> > device")
> >
> > from the amdgpu tree and commit:
> >
> > c7b6bac9c72c ("drm, iommu: Change type of pasid to u32")
> >
> > from the tip tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
> >
> > diff --cc drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> > index 739db04080d0,922ae138ab85..
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> > @@@ -739,7 -723,8 +739,7 @@@ struct kfd_process
> > /* We want to receive a notification when the mm_struct is destroyed */
> > struct mmu_notifier mmu_notifier;
> >
> > - uint16_t pasid;
> > + u32 pasid;
> > - unsigned int doorbell_index;
> >
> > /*
> > * List of kfd_process_device structures,
>
> This is now a conflict between the tip tree and the drm tree.
This is now a conflict between the drm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpH1OfBBZ5q_.pgp
Description: OpenPGP digital signature
Lieber Freund (Assalamu Alaikum),?
-- Lieber Freund (Assalamu Alaikum), Ich bin vor einer privaten Suche auf Ihren E-Mail-Kontakt gestoßen Ihre Hilfe. Mein Name ist Aisha Al-Qaddafi, eine alleinerziehende Mutter und eine Witwe mit drei Kindern. Ich bin die einzige leibliche Tochter des Spätlibyschen Präsident (verstorbener Oberst Muammar Gaddafi). Ich habe Investmentfonds im Wert von siebenundzwanzig Millionen fünfhunderttausend United State Dollar ($ 27.500.000.00) und ich brauche eine vertrauenswürdige Investition Manager / Partner aufgrund meines aktuellen Flüchtlingsstatus bin ich jedoch Möglicherweise interessieren Sie sich für die Unterstützung von Investitionsprojekten in Ihrem Land Von dort aus können wir in naher Zukunft Geschäftsbeziehungen aufbauen. Ich bin bereit, mit Ihnen über das Verhältnis zwischen Investition und Unternehmensgewinn zu verhandeln Basis für die zukünftige Investition Gewinne zu erzielen. Wenn Sie bereit sind, dieses Projekt in meinem Namen zu bearbeiten, antworten Sie bitte dringend Damit ich Ihnen mehr Informationen über die Investmentfonds geben kann. Ihre dringende Antwort wird geschätzt. schreibe mir an diese email adresse ( ayishagdda...@mail.ru ) zur weiteren Diskussion. Freundliche Grüße Frau Aisha Al-Qaddafi
Re: [PATCH] PM / EM: consult something about cpumask in em_dev_register_perf_domain
>
> Hi,
>
> On Monday 12 Oct 2020 at 20:41:36 (+0800), zhuguangqin...@gmail.com wrote:
> > From: zhuguangqing
> >
> > Hi, Lukasz, Quentin
> > I have three questions to consult about cpumask in energy_model.c.
>
> OK, let's see if we can help :)
>
Thanks for your help and review.
> > 1, The first one is about the meanings of the following two parameters,
> > [1] and [2].
> > [1]: "cpumask_t *cpus" in function em_dev_register_perf_domain():
Pointer
> > to cpumask_t, which in case of a CPU device is obligatory. It can be
taken
> > from i.e. 'policy->cpus'.
> > [2]: "unsigned long cpus[]" in struct em_perf_domain: Cpumask covering
the
> > CPUs of the domain. It's here for performance reasons to avoid potential
> > cache misses during energy calculations in the scheduler and simplifies
> > allocating/freeing that memory region.
> >
> > From the current code, we see [2] is copied from [1]. But from comments,
> > accorinding to my understanding, [2] and [1] have different meanings.
> > [1] can be taken from i.e. 'policy->cpus', according to the comment in
the
> > defination of struct cpufreq_policy, it means Online CPUs only.
Actually,
> > 'policy->cpus' is not always Online CPUs.
> > [2] means each_possible_cpus in the same domain, including phycical
> > hotplug cpus(just possible), logically hotplug cpus(just present) and
> > online cpus.
> >
> >
> > So, the first question is, what are the meanings of [1] and [2]?
> > I guess maybe there are the following 4 possible choices.
> > A), for_each_possible_cpu in the same domain, maybe phycical hotplug
> > B), for_each_present_cpu in the same domain, maybe logically hotplug
> > C), for_each_online_cpu in the same domain, online
> > D), others
>
> So, if the comments are confusing we should update them, but from the EM
> framework perspective, all cpumasks must be the _possible_ CPUs in the
> domain. It's up to the clients (e.g. the scheduler) to deal with hotplug
> and so on, but the EM framework should cover non-online CPUs too.
>
I see, from the EM framework perspective, all cpumasks must be the
_possible_ CPUs in the domain. But up to the clients (e.g. the scheduler),
'policy->cpus' maybe not the _possible_ CPUs. For example, in the function
scmi_cpufreq_init() which calls em_dev_register_perf_domain(),
'policy->cpus'
is got from scmi_get_sharing_cpus() and cpufreq_online(), including CPUs
satisfied the following three conditions at the same time which means
_present_ CPUs according to my understanding.
1) _possible_
2) if (get_cpu_device(cpu))
3) in the same domain
> > 2, The second question is about the function
em_dev_register_perf_domain().
> > If multiple clients register the same performance domain with different
> > *dev or *cpus, how should we handle?
> >
> > int em_dev_register_perf_domain(struct device *dev, unsigned int
nr_states,
> > struct em_data_callback *cb, cpumask_t *cpus)
> >
> > For example, say cpu0 and cpu1 are in the same performance domain,
> > cpu0 is registered first. As part of the init process,
> > em_dev_register_perf_domain() is called, then *dev = cpu0_dev,
> > *cpus = 01b(cpu1 is initially offline). It creates a em_pd for cpu0_dev.
> > After a while, cpu1 is online, em_dev_register_perf_domain() is called
> > again as part of init process for cpu1, then *dev =cpu1_dev,
> > *cpus = 11b(cpu1 is online). In this case, for the current code,
> > cpu1_dev can not get its em_pd.
>
> As per the above, the registration should be done once, with the mask of
> all possible CPUs in the domain. If CPUs 0 and 1 share the same domain, a
> single call to em_dev_register_perf_domain() should be sufficient to
> register both of them at once.
>
I just saw your discussion in https://lkml.org/lkml/2020/2/7/479, it
mentioned
"PM_EM ignores hotplug ATM. Perhaps we should document that somewhere ..."
So, if PM_EM still ignores hotplug now, then the registration should be done
once,
with the mask of all possible CPUs in the domain. If PM_EM consider hotplug
in
the future, then we should consider the case that
em_dev_register_perf_domain()
will be called more than once with different input parameters *dev or/and
*cpus.
And the CPU mask might not be all possible CPUs in the domain.
> > 3, The third question is, how can we ensure cpu_dev as follows is not
> > NULL? If we can't ensure that, maybe we should add a check before using
> > it.
> > /kernel/power/energy_model.c
> > 174) static int em_create_pd(struct device *dev, int nr_states,
> > 175)struct em_data_callback *cb, cpumask_t *cpus)
> > 176) {
> > 199)if (_is_cpu_device(dev))
> > 200)for_each_cpu(cpu, cpus) {
> > 201)cpu_dev = get_cpu_device(cpu);
> > 202)cpu_dev->em_pd = pd;
> > 203)}
>
> And that should not be necessary as we check for the !dev case at the
> top of em_dev_register_perf_domain(). Or were you thinking about
> something else?
>
> Oh I think I read that one
[PATCH] arm64: vdso32: Allow ld.lld to properly link the VDSO
As it stands now, the vdso32 Makefile hardcodes the linker to ld.bfd
using -fuse-ld=bfd with $(CC). This was taken from the arm vDSO
Makefile, as the comment notes, done in commit d2b30cd4b722 ("ARM:
8384/1: VDSO: force use of BFD linker").
Commit fe00e50b2db8 ("ARM: 8858/1: vdso: use $(LD) instead of $(CC) to
link VDSO") changed that Makefile to use $(LD) directly instead of
through $(CC), which matches how the rest of the kernel operates. Since
then, LD=ld.lld means that the arm vDSO will be linked with ld.lld,
which has shown no problems so far.
Allow ld.lld to link this vDSO as we do the regular arm vDSO. To do
this, we need to do a few things:
* Add a LD_COMPAT variable, which defaults to $(CROSS_COMPILE_COMPAT)ld
with gcc and $(LD) if LLVM is 1, which will be ld.lld, or
$(CROSS_COMPILE_COMPAT)ld if not, which matches the logic of the main
Makefile. It is overrideable for further customization and avoiding
breakage.
* Eliminate cc32-ldoption, which matches commit 055efab3120b ("kbuild:
drop support for cc-ldoption").
With those, we can use $(LD_COMPAT) in cmd_ldvdso and change the flags
from compiler linker flags to linker flags directly. We eliminate
-mfloat-abi=soft because it is not handled by the linker.
Link: https://github.com/ClangBuiltLinux/linux/issues/1033
Reported-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
---
NOTE: This patch is currently based on the kbuild tree due to the
--build-id -> --build-id=sha1 change that Bill did. If the arm64
maintainers would prefer to take this patch, I can rebase it (althought
presumably this won't hit mainline until at least 5.11 so it can
probably just stay as is for now).
arch/arm64/kernel/vdso32/Makefile | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/kernel/vdso32/Makefile
b/arch/arm64/kernel/vdso32/Makefile
index 7f96a1a9f68c..1cf00c58805d 100644
--- a/arch/arm64/kernel/vdso32/Makefile
+++ b/arch/arm64/kernel/vdso32/Makefile
@@ -22,16 +22,21 @@ endif
CC_COMPAT ?= $(CC)
CC_COMPAT += $(CC_COMPAT_CLANG_FLAGS)
+
+ifeq ($(LLVM),1)
+LD_COMPAT ?= $(LD)
+else
+LD_COMPAT ?= $(CROSS_COMPILE_COMPAT)ld
+endif
else
CC_COMPAT ?= $(CROSS_COMPILE_COMPAT)gcc
+LD_COMPAT ?= $(CROSS_COMPILE_COMPAT)ld
endif
cc32-option = $(call try-run,\
$(CC_COMPAT) $(1) -c -x c /dev/null -o "$$TMP",$(1),$(2))
cc32-disable-warning = $(call try-run,\
$(CC_COMPAT) -W$(strip $(1)) -c -x c /dev/null -o "$$TMP",-Wno-$(strip
$(1)))
-cc32-ldoption = $(call try-run,\
-$(CC_COMPAT) $(1) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2))
cc32-as-instr = $(call try-run,\
printf "%b\n" "$(1)" | $(CC_COMPAT) $(VDSO_AFLAGS) -c -x assembler -o
"$$TMP" -,$(2),$(3))
@@ -122,14 +127,10 @@ dmbinstr := $(call cc32-as-instr,dmb
ishld,-DCONFIG_AS_DMB_ISHLD=1)
VDSO_CFLAGS += $(dmbinstr)
VDSO_AFLAGS += $(dmbinstr)
-VDSO_LDFLAGS := $(VDSO_CPPFLAGS)
# From arm vDSO Makefile
-VDSO_LDFLAGS += -Wl,-Bsymbolic -Wl,--no-undefined -Wl,-soname=linux-vdso.so.1
-VDSO_LDFLAGS += -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
-VDSO_LDFLAGS += -nostdlib -shared -mfloat-abi=soft
-VDSO_LDFLAGS += -Wl,--hash-style=sysv
-VDSO_LDFLAGS += -Wl,--build-id=sha1
-VDSO_LDFLAGS += $(call cc32-ldoption,-fuse-ld=bfd)
+VDSO_LDFLAGS += -Bsymbolic --no-undefined -soname=linux-vdso.so.1
+VDSO_LDFLAGS += -z max-page-size=4096 -z common-page-size=4096
+VDSO_LDFLAGS += -nostdlib -shared --hash-style=sysv --build-id=sha1
# Borrow vdsomunge.c from the arm vDSO
@@ -189,8 +190,8 @@ quiet_cmd_vdsold_and_vdso_check = LD32$@
cmd_vdsold_and_vdso_check = $(cmd_vdsold); $(cmd_vdso_check)
quiet_cmd_vdsold = LD32$@
- cmd_vdsold = $(CC_COMPAT) -Wp,-MD,$(depfile) $(VDSO_LDFLAGS) \
- -Wl,-T $(filter %.lds,$^) $(filter %.o,$^) -o $@
+ cmd_vdsold = $(LD_COMPAT) $(VDSO_LDFLAGS) \
+ -T $(filter %.lds,$^) $(filter %.o,$^) -o $@
quiet_cmd_vdsocc = CC32$@
cmd_vdsocc = $(CC_COMPAT) -Wp,-MD,$(depfile) $(VDSO_CFLAGS) -c -o $@ $<
quiet_cmd_vdsocc_gettimeofday = CC32$@
base-commit: 172aad81a882443eefe1bd860c4eddc81b14dd5b
--
2.29.0.rc0
Re: linux-next: manual merge of the tip tree with the iommu tree
Hi all,
On Fri, 2 Oct 2020 15:22:24 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> include/linux/iommu.h
>
> between commits:
>
> 23cc3493b5e1 ("iommu/uapi: Rename uapi functions")
> d90573812eea ("iommu/uapi: Handle data and argsz filled by users")
>
> from the iommu tree and commit:
>
> c7b6bac9c72c ("drm, iommu: Change type of pasid to u32")
>
> from the tip tree.
>
> I fixed it up (I used the former version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
This is now a conflict between the iommu tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpvEOlkbU0RA.pgp
Description: OpenPGP digital signature
[tip:efi/core] BUILD SUCCESS 4d0a4388ccdd9482fef6b26f879d0f6099143f80
defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20201012 i386 randconfig-a006-20201012 i386 randconfig-a001-20201012 i386 randconfig-a003-20201012 i386 randconfig-a004-20201012 i386 randconfig-a002-20201012 x86_64 randconfig-a016-20201012 x86_64 randconfig-a015-20201012 x86_64 randconfig-a012-20201012 x86_64 randconfig-a013-20201012 x86_64 randconfig-a014-20201012 x86_64 randconfig-a011-20201012 i386 randconfig-a016-20201012 i386 randconfig-a015-20201012 i386 randconfig-a013-20201012 i386 randconfig-a012-20201012 i386 randconfig-a011-20201012 i386 randconfig-a014-20201012 x86_64 randconfig-a004-20201013 x86_64 randconfig-a002-20201013 x86_64 randconfig-a006-20201013 x86_64 randconfig-a001-20201013 x86_64 randconfig-a003-20201013 x86_64 randconfig-a005-20201013 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a004-20201012 x86_64 randconfig-a002-20201012 x86_64 randconfig-a006-20201012 x86_64 randconfig-a001-20201012 x86_64 randconfig-a003-20201012 x86_64 randconfig-a005-20201012 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[tip:x86/urgent] BUILD SUCCESS 20802fef73a5a98b6e8ed1c0aeca82994d835b13
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent branch HEAD: 20802fef73a5a98b6e8ed1c0aeca82994d835b13 x86/traps: Fix #DE Oops message regression elapsed time: 721m configs tested: 118 configs skipped: 49 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arc nsimosci_hs_smp_defconfig sh sh7770_generic_defconfig arm palmz72_defconfig arm integrator_defconfig armmulti_v7_defconfig arm alldefconfig arm tct_hammer_defconfig mips db1xxx_defconfig armrealview_defconfig mips ip32_defconfig powerpc mpc834x_mds_defconfig armqcom_defconfig shsh7785lcr_defconfig m68kstmark2_defconfig xtensa cadence_csp_defconfig x86_64 allyesconfig mips fuloong2e_defconfig parisc defconfig mips xway_defconfig armxcep_defconfig powerpc tqm8548_defconfig um x86_64_defconfig nios2allyesconfig powerpc g5_defconfig arc nps_defconfig m68km5272c3_defconfig mips loongson3_defconfig h8300 edosk2674_defconfig powerpc pcm030_defconfig arm64alldefconfig arm rpc_defconfig powerpc tqm8555_defconfig arm multi_v4t_defconfig arm pxa_defconfig sh rsk7203_defconfig mipsar7_defconfig armmmp2_defconfig powerpc motionpro_defconfig mipsworkpad_defconfig sh rts7751r2dplus_defconfig powerpc mpc866_ads_defconfig arm at91_dt_defconfig m68k amcore_defconfig sh lboxre2_defconfig nios2 3c120_defconfig mips ip27_defconfig powerpc pq2fads_defconfig m68k allmodconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20201012 i386 randconfig-a006-20201012 i386 randconfig-a001-20201012 i386 randconfig-a003-20201012 i386 randconfig-a004-20201012 i386 randconfig-a002-20201012 x86_64 randconfig-a016-20201012 x86_64 randconfig-a015-20201012 x86_64 randconfig-a012-20201012 x86_64 randconfig-a013-20201012 x86_64 randconfig-a014-20201012 x86_64 randconfig-a011-20201012 i386 randconfig-a016-20201012 i386 randconfig-a015-20201012 i386 randconfig-a013-20201012 i386 randconfig-a012-20201012 i386 randconfig-a011-20201012 i386 randconfig-a014-20201012 riscv
[tip:perf/core] BUILD SUCCESS f91072ed1b7283b13ca57fcfbece5a3b92726143
allmodconfig s390 allyesconfig s390defconfig i386 allyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20201012 i386 randconfig-a006-20201012 i386 randconfig-a001-20201012 i386 randconfig-a003-20201012 i386 randconfig-a004-20201012 i386 randconfig-a002-20201012 x86_64 randconfig-a016-20201012 x86_64 randconfig-a015-20201012 x86_64 randconfig-a012-20201012 x86_64 randconfig-a013-20201012 x86_64 randconfig-a014-20201012 x86_64 randconfig-a011-20201012 i386 randconfig-a016-20201012 i386 randconfig-a015-20201012 i386 randconfig-a013-20201012 i386 randconfig-a012-20201012 i386 randconfig-a011-20201012 i386 randconfig-a014-20201012 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a004-20201012 x86_64 randconfig-a002-20201012 x86_64 randconfig-a006-20201012 x86_64 randconfig-a001-20201012 x86_64 randconfig-a003-20201012 x86_64 randconfig-a005-20201012 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: linux-next: manual merge of the tip tree with the pci tree
Hi all,
On Fri, 25 Sep 2020 15:35:10 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/kernel/apic/msi.c
>
> between commit:
>
> 2705b8e4d46f ("x86/apic/msi: Use Real PCI DMA device when configuring IRTE")
>
> from the pci tree and commit:
>
> 7ca435cf857d ("x86/irq: Cleanup the arch_*_msi_irqs() leftovers")
>
> from the tip tree.
>
> I fixed it up (the latter removed the code updated by the former, so I
> did that) and can carry the fix as necessary. This is now fixed as far as
> linux-next is concerned, but any non trivial conflicts should be mentioned
> to your upstream maintainer when your tree is submitted for merging.
> You may also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.
This is now a conflict between the pci tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpZF1vHdJ78q.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the tip tree with the pci tree
Hi all,
On Fri, 25 Sep 2020 15:21:18 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/pci/controller/vmd.c
>
> between commit:
>
> 42443f036042 ("PCI: vmd: Create IRQ Domain configuration helper")
>
> from the pci tree and commit:
>
> 585dfe8abc44 ("PCI: vmd: Dont abuse vector irqomain as parent")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc drivers/pci/controller/vmd.c
> index 3c4418cbde1c,aa1b12bac9a1..
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@@ -304,50 -298,6 +304,50 @@@ static struct msi_domain_info vmd_msi_d
> .chip = _msi_controller,
> };
>
> +static void vmd_enable_msi_remapping(struct vmd_dev *vmd, bool enable)
> +{
> +u16 reg;
> +
> +pci_read_config_word(vmd->dev, PCI_REG_VMCONFIG, );
> +reg = enable ? (reg & ~0x2) : (reg | 0x2);
> +pci_write_config_word(vmd->dev, PCI_REG_VMCONFIG, reg);
> +}
> +
> +static int vmd_create_irq_domain(struct vmd_dev *vmd)
> +{
> +struct fwnode_handle *fn;
> +
> +fn = irq_domain_alloc_named_id_fwnode("VMD-MSI", vmd->sysdata.domain);
> +if (!fn)
> +return -ENODEV;
> +
> +vmd->irq_domain = pci_msi_create_irq_domain(fn, _msi_domain_info,
> - x86_vector_domain);
> ++NULL);
> +if (!vmd->irq_domain) {
> +irq_domain_free_fwnode(fn);
> +return -ENODEV;
> +}
> +
> +return 0;
> +}
> +
> +static void vmd_remove_irq_domain(struct vmd_dev *vmd)
> +{
> +/*
> + * Some production BIOS won't enable remapping between soft reboots.
> + * Ensure remapping is restored before unloading the driver
> + */
> +if (!vmd->msix_count)
> +vmd_enable_msi_remapping(vmd, true);
> +
> +if (vmd->irq_domain) {
> +struct fwnode_handle *fn = vmd->irq_domain->fwnode;
> +
> +irq_domain_remove(vmd->irq_domain);
> +irq_domain_free_fwnode(fn);
> +}
> +}
> +
> static char __iomem *vmd_cfg_addr(struct vmd_dev *vmd, struct pci_bus *bus,
> unsigned int devfn, int reg, int len)
> {
> @@@ -717,12 -568,24 +717,18 @@@ static int vmd_enable_domain(struct vmd
>
> sd->node = pcibus_to_node(vmd->dev->bus);
>
> -fn = irq_domain_alloc_named_id_fwnode("VMD-MSI", vmd->sysdata.domain);
> -if (!fn)
> -return -ENODEV;
> -
> -vmd->irq_domain = pci_msi_create_irq_domain(fn, _msi_domain_info,
> -NULL);
> -
> -if (!vmd->irq_domain) {
> -irq_domain_free_fwnode(fn);
> -return -ENODEV;
> +if (vmd->msix_count) {
> +ret = vmd_create_irq_domain(vmd);
> +if (ret)
> +return ret;
> }
>
> + /*
> + * Override the irq domain bus token so the domain can be distinguished
> + * from a regular PCI/MSI domain.
> + */
> + irq_domain_update_bus_token(vmd->irq_domain, DOMAIN_BUS_VMD_MSI);
> +
> pci_add_resource(, >resources[0]);
> pci_add_resource_offset(, >resources[1], offset[0]);
> pci_add_resource_offset(, >resources[2], offset[1]);
This is now a conflict between the pci tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpww_O6x__84.pgp
Description: OpenPGP digital signature
Re: [External] Re: [PATCH] mm: proc: add Sock to /proc/meminfo
On Tue, Oct 13, 2020 at 5:47 AM Cong Wang wrote:
>
> On Sun, Oct 11, 2020 at 9:22 PM Muchun Song wrote:
> >
> > On Mon, Oct 12, 2020 at 2:39 AM Cong Wang wrote:
> > >
> > > On Sat, Oct 10, 2020 at 3:39 AM Muchun Song
> > > wrote:
> > > >
> > > > The amount of memory allocated to sockets buffer can become significant.
> > > > However, we do not display the amount of memory consumed by sockets
> > > > buffer. In this case, knowing where the memory is consumed by the kernel
> > >
> > > We do it via `ss -m`. Is it not sufficient? And if not, why not adding it
> > > there
> > > rather than /proc/meminfo?
> >
> > If the system has little free memory, we can know where the memory is via
> > /proc/meminfo. If a lot of memory is consumed by socket buffer, we cannot
> > know it when the Sock is not shown in the /proc/meminfo. If the unaware user
> > can't think of the socket buffer, naturally they will not `ss -m`. The
> > end result
>
> Interesting, we already have a few counters related to socket buffers,
> are you saying these are not accounted in /proc/meminfo either?
Yeah, these are not accounted for in /proc/meminfo.
> If yes, why are page frags so special here? If not, they are more
> important than page frags, so you probably want to deal with them
> first.
>
>
> > is that we still don’t know where the memory is consumed. And we add the
> > Sock to the /proc/meminfo just like the memcg does('sock' item in the cgroup
> > v2 memory.stat). So I think that adding to /proc/meminfo is sufficient.
>
> It looks like actually the socket page frag is already accounted,
> for example, the tcp_sendmsg_locked():
>
> copy = min_t(int, copy, pfrag->size - pfrag->offset);
>
> if (!sk_wmem_schedule(sk, copy))
> goto wait_for_memory;
>
Yeah, it is already accounted for. But it does not represent real memory
usage. This is just the total amount of charged memory.
For example, if a task sends a 10-byte message, it only charges one
page to memcg. But the system may allocate 8 pages. Therefore, it
does not truly reflect the memory allocated by the page frag memory
allocation path.
>
> >
> > >
> > > > static inline void __skb_frag_unref(skb_frag_t *frag)
> > > > {
> > > > - put_page(skb_frag_page(frag));
> > > > + struct page *page = skb_frag_page(frag);
> > > > +
> > > > + if (put_page_testzero(page)) {
> > > > + dec_sock_node_page_state(page);
> > > > + __put_page(page);
> > > > + }
> > > > }
> > >
> > > You mix socket page frag with skb frag at least, not sure this is exactly
> > > what you want, because clearly skb page frags are frequently used
> > > by network drivers rather than sockets.
> > >
> > > Also, which one matches this dec_sock_node_page_state()? Clearly
> > > not skb_fill_page_desc() or __skb_frag_ref().
> >
> > Yeah, we call inc_sock_node_page_state() in the skb_page_frag_refill().
>
> How is skb_page_frag_refill() possibly paired with __skb_frag_unref()?
>
> > So if someone gets the page returned by skb_page_frag_refill(), it must
> > put the page via __skb_frag_unref()/skb_frag_unref(). We use PG_private
> > to indicate that we need to dec the node page state when the refcount of
> > page reaches zero.
>
> skb_page_frag_refill() is called on frags not within an skb, for instance,
> sk_page_frag_refill() uses it for a per-socket or per-process page frag.
> But, __skb_frag_unref() is specifically used for skb frags, which are
> supposed to be filled by skb_fill_page_desc() (page is allocated by driver).
>
> They are different things you are mixing them up, which looks clearly
> wrong or at least misleading.
Yeah, it looks a little strange. I just want to account for page frag
allocations. So I have to use PG_private to distinguish the page
from page frag or others in the __skb_frag_unref(). If the page is
allocated from skb_page_frag_refill, we should decrease the
statistics.
Thanks.
>
> Thanks.
--
Yours,
Muchun
Re: [PATCH] arm/build: Always handle .ARM.exidx and .ARM.extab sections
On Mon, Oct 12, 2020 at 02:26:52PM -0700, Kees Cook wrote:
> On Mon, Oct 12, 2020 at 02:22:03PM -0700, Fāng-ruì Sòng wrote:
> > On Mon, Oct 12, 2020 at 2:11 PM 'Nick Desaulniers' via Clang Built
> > Linux wrote:
> > >
> > > On Mon, Sep 28, 2020 at 3:49 PM Nathan Chancellor
> > > wrote:
> > > >
> > > > After turning on warnings for orphan section placement, enabling
> > > > CONFIG_UNWINDER_FRAME_POINTER instead of CONFIG_UNWINDER_ARM causes
> > > > thousands of warnings when clang + ld.lld are used:
> > > >
> > > > $ scripts/config --file arch/arm/configs/multi_v7_defconfig \
> > > > -d CONFIG_UNWINDER_ARM \
> > > > -e CONFIG_UNWINDER_FRAME_POINTER
> > > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1
> > > > defconfig zImage
> > > > ld.lld: warning: init/built-in.a(main.o):(.ARM.extab) is being placed
> > > > in '.ARM.extab'
> > > > ld.lld: warning: init/built-in.a(main.o):(.ARM.extab.init.text) is
> > > > being placed in '.ARM.extab.init.text'
> > > > ld.lld: warning: init/built-in.a(main.o):(.ARM.extab.ref.text) is being
> > > > placed in '.ARM.extab.ref.text'
> > > > ld.lld: warning: init/built-in.a(do_mounts.o):(.ARM.extab.init.text) is
> > > > being placed in '.ARM.extab.init.text'
> > > > ld.lld: warning: init/built-in.a(do_mounts.o):(.ARM.extab) is being
> > > > placed in '.ARM.extab'
> > > > ld.lld: warning: init/built-in.a(do_mounts_rd.o):(.ARM.extab.init.text)
> > > > is being placed in '.ARM.extab.init.text'
> > > > ld.lld: warning: init/built-in.a(do_mounts_rd.o):(.ARM.extab) is being
> > > > placed in '.ARM.extab'
> > > > ld.lld: warning:
> > > > init/built-in.a(do_mounts_initrd.o):(.ARM.extab.init.text) is being
> > > > placed in '.ARM.extab.init.text'
> > > > ld.lld: warning: init/built-in.a(initramfs.o):(.ARM.extab.init.text) is
> > > > being placed in '.ARM.extab.init.text'
> > > > ld.lld: warning: init/built-in.a(initramfs.o):(.ARM.extab) is being
> > > > placed in '.ARM.extab'
> > > > ld.lld: warning: init/built-in.a(calibrate.o):(.ARM.extab.init.text) is
> > > > being placed in '.ARM.extab.init.text'
> > > > ld.lld: warning: init/built-in.a(calibrate.o):(.ARM.extab) is being
> > > > placed in '.ARM.extab'
> > > >
> > > > These sections are handled by the ARM_UNWIND_SECTIONS define, which is
> > > > only added to the list of sections when CONFIG_ARM_UNWIND is set.
> > > > CONFIG_ARM_UNWIND is a hidden symbol that is only selected when
> > > > CONFIG_UNWINDER_ARM is set so CONFIG_UNWINDER_FRAME_POINTER never
> > > > handles these sections. According to the help text of
> > > > CONFIG_UNWINDER_ARM, these sections should be discarded so that the
> > > > kernel image size is not affected.
> > >
> > > My apologies for taking so long to review this.
> > >
> > > I have a suspicion that these come from forcing on configs that
> > > Kconfig/menuconfig would block, and aren't clang or lld specific, yet
> > > are exposed by the new linker warnings for orphan section placement
> > > (good). That said, we definitely have OEMs in Android land that still
> > > prefer the older unwinder.
> > >
> > > From https://developer.arm.com/documentation/ihi0038/b/ (click
> > > download in top left), section 4.4.1 "Sections" has a note:
> > >
> > > ```
> > > Tables are not required for ABI compliance at the C/Assembler level
> > > but are required for C++.
> > > ```
> > >
> > > Review-by: Nick Desaulniers
> > > Tested-by: Nick Desaulniers
> > >
> > > Please submit to:
> > > https://www.arm.linux.org.uk/developer/patches/add.php
This should go through the tip tree (hence sending it straight to Ingo)
since the patch that this fixes was there. I guess it does not
necessarily matter now that the breakage is in mainline but basing a
set of patches on a non -rc tag is a little taboo I thought so not sure
it is appropriate to go through Russell for now. It is up to the
maintainers though, I will submit it wherever it needs to go.
> > > >
> > > > Fixes: 5a17850e251a ("arm/build: Warn on orphan section placement")
> > > > Link: https://github.com/ClangBuiltLinux/linux/issues/1152
> > > > Reported-by: kernel test robot
> > > > Signed-off-by: Nathan Chancellor
> > > > ---
> > > > arch/arm/kernel/vmlinux.lds.S | 4
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/arch/arm/kernel/vmlinux.lds.S
> > > > b/arch/arm/kernel/vmlinux.lds.S
> > > > index 5f4922e858d0..a2c0d96b0580 100644
> > > > --- a/arch/arm/kernel/vmlinux.lds.S
> > > > +++ b/arch/arm/kernel/vmlinux.lds.S
> > > > @@ -40,6 +40,10 @@ SECTIONS
> > > > ARM_DISCARD
> > > > #ifndef CONFIG_SMP_ON_UP
> > > > *(.alt.smp.init)
> > > > +#endif
> > > > +#ifndef CONFIG_ARM_UNWIND
> > > > + *(.ARM.exidx*)
> > >
> > > I don't think we need the wildcard, as without this line, I see:
> > >
> > > ld.lld: warning: :(.ARM.exidx) is being placed in '.ARM.exidx'
> >
> > We may need the wildcard if there are -ffunction-sections
Re: [PATCH v4 1/5] arm64: Add framework to turn IPI as NMI
On Mon, Oct 12, 2020 at 05:49:09PM +0530, Sumit Garg wrote:
> Hi Masa,
>
> On Sat, 10 Oct 2020 at 20:43, Masayoshi Mizuma wrote:
> >
> > On Sat, Oct 10, 2020 at 10:34:04AM +0100, Marc Zyngier wrote:
> > > On Sat, 10 Oct 2020 02:58:55 +0100,
> > > Masayoshi Mizuma wrote:
> > >
> > > [...]
> > >
> > > > > +void ipi_nmi_setup(int cpu)
> > > > > +{
> > > > > + if (!ipi_desc)
> > > > > + return;
> > > >
> > > > ipi_nmi_setup() may be called twice for CPU0:
> > > >
> > > > set_smp_ipi_range => set_smp_ipi_nmi => ipi_nmi_setup
> > > > => ipi_setup => ipi_nmi_setup
> > > >
> > > > Actually, I got the following error message via the second
> > > > ipi_nmi_setup():
> > > >
> > > > GICv3: Pseudo-NMIs enabled using relaxed ICC_PMR_EL1 synchronisation
> > > > GICv3: Cannot set NMI property of enabled IRQ 8
> > > > genirq: Failed to setup NMI delivery: irq 8
> > > >
>
> Ah, thanks for catching this which I missed during my testing.
>
> > > > Why don't we have a check to prevent that? Like as:
> > > >
> > > >if (cpumask_test_cpu(cpu, ipi_desc->percpu_enabled))
> > > >return;
> > >
> > > That's definitely the wrong thing to do. prepare_nmi_setup() shouldn't
> > > be called twice, and papering over it isn't acceptable.
> >
> > Got it. How about moving ipi_nmi_setup() from ipi_setup() to
> > secondary_start_kernel() ? so that CPU0 can call ipi_nmi_setup() only
> > from set_smp_ipi_nmi().
> >
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -245,6 +245,7 @@ asmlinkage notrace void secondary_start_kernel(void)
> > notify_cpu_starting(cpu);
> >
> > ipi_setup(cpu);
> > + ipi_nmi_setup(cpu);
> >
> > store_cpu_topology(cpu);
> > numa_add_cpu(cpu);
> > @@ -966,8 +967,6 @@ static void ipi_setup(int cpu)
> >
> > for (i = 0; i < nr_ipi; i++)
> > enable_percpu_irq(ipi_irq_base + i, 0);
> > -
> > - ipi_nmi_setup(cpu);
> > }
> >
> > #ifdef CONFIG_HOTPLUG_CPU
> >
>
> IMO, it would be more consistent to keep invocation of ipi_nmi_setup()
> from ipi_setup(). So let me remove other invocation from
> set_smp_ipi_nmi():
>
> diff --git a/arch/arm64/kernel/ipi_nmi.c b/arch/arm64/kernel/ipi_nmi.c
> index d3aa430..000e457 100644
> --- a/arch/arm64/kernel/ipi_nmi.c
> +++ b/arch/arm64/kernel/ipi_nmi.c
> @@ -87,7 +87,4 @@ void __init set_smp_ipi_nmi(int ipi)
> ipi_desc = irq_to_desc(ipi);
> irq_set_status_flags(ipi, IRQ_HIDDEN);
> ipi_id = ipi;
> -
> - /* Setup the boot CPU immediately */
> - ipi_nmi_setup(smp_processor_id());
> }
>
> Do let me know if this works for you?
Yes, make sense to me.
Thanks!
Masa
[PATCH] MIPS: Add set_memory_node()
Commit e7ae8d174eec ("MIPS: replace add_memory_region with memblock")
replaced add_memory_region(, , BOOT_MEM_RAM) with memblock_add(). But
it doesn't work well on some platforms which have NUMA like Loongson64.
Because memblock_add() calls memblock_add_range() and sets memory at
MAX_NUMNODES. As mm/memblock.c says, assign the region to a NUMA node
later by using memblock_set_node(). This patch provides a NUMA port
set_memory_node() and provides Loongson64 specific function.
The one of examples as follows,
cmdline + "mem=220M@2M"
arch/mips/kernel/setup.c:
parse_early_param();
+ __memblock_dump_all();
if (usermem)
Without this patch:
...
[0.00] MEMBLOCK configuration:
[0.00] memory size = 0x0dc0 reserved size =
0x03d74000
[0.00] memory.cnt = 0x1
[0.00] memory[0x0] [0x0020-0x0ddf],
0x0dc0 bytes flags: 0x0
...
and stopped starting.
With this patch:
...
[0.00] MEMBLOCK configuration:
[0.00] memory size = 0x0dc0 reserved size =
0x03d74000
[0.00] memory.cnt = 0x1
[0.00] memory[0x0] [0x0020-0x0ddf],
0x0dc0 bytes on node 0 flags: 0x0
...
and started well.
Signed-off-by: Jinyang He
---
arch/mips/include/asm/bootinfo.h | 4
arch/mips/kernel/setup.c | 12
arch/mips/loongson64/numa.c | 8
arch/mips/sgi-ip27/ip27-memory.c | 5 +
4 files changed, 29 insertions(+)
diff --git a/arch/mips/include/asm/bootinfo.h b/arch/mips/include/asm/bootinfo.h
index aa03b12..29e2d9c 100644
--- a/arch/mips/include/asm/bootinfo.h
+++ b/arch/mips/include/asm/bootinfo.h
@@ -92,6 +92,10 @@ extern unsigned long mips_machtype;
extern void detect_memory_region(phys_addr_t start, phys_addr_t sz_min,
phys_addr_t sz_max);
+#ifdef CONFIG_NUMA
+extern void set_memory_node(phys_addr_t start, phys_addr_t size);
+#endif
+
extern void prom_init(void);
extern void prom_free_prom_memory(void);
extern void prom_cleanup(void);
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index fb05b66..c1e282d 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -362,6 +362,9 @@ static int __init early_parse_mem(char *p)
start = memparse(p + 1, );
memblock_add(start, size);
+#ifdef CONFIG_NUMA
+ set_memory_node(start, size);
+#endif
return 0;
}
@@ -388,12 +391,18 @@ static int __init early_parse_memmap(char *p)
if (*p == '@') {
start_at = memparse(p+1, );
memblock_add(start_at, mem_size);
+#ifdef CONFIG_NUMA
+ set_memory_node(start_at, mem_size);
+#endif
} else if (*p == '#') {
pr_err("\"memmap=nn#ss\" (force ACPI data) invalid on MIPS\n");
return -EINVAL;
} else if (*p == '$') {
start_at = memparse(p+1, );
memblock_add(start_at, mem_size);
+#ifdef CONFIG_NUMA
+ set_memory_node(start_at, mem_size);
+#endif
memblock_reserve(start_at, mem_size);
} else {
pr_err("\"memmap\" invalid format!\n");
@@ -509,6 +518,9 @@ static void __init check_kernel_sections_mem(void)
if (!memblock_is_region_memory(start, size)) {
pr_info("Kernel sections are not in the memory maps\n");
memblock_add(start, size);
+#ifdef CONFIG_NUMA
+ set_memory_node(start, size);
+#endif
}
}
diff --git a/arch/mips/loongson64/numa.c b/arch/mips/loongson64/numa.c
index cf9459f..d428058 100644
--- a/arch/mips/loongson64/numa.c
+++ b/arch/mips/loongson64/numa.c
@@ -234,6 +234,14 @@ void __init mem_init(void)
mem_init_print_info(NULL);
}
+void __init set_memory_node(phys_addr_t start, phys_addr_t size)
+{
+ u64 node_id;
+
+ node_id = (start >> 44) & 3;
+ memblock_set_node(start, size, , node_id);
+}
+
/* All PCI device belongs to logical Node-0 */
int pcibus_to_node(struct pci_bus *bus)
{
diff --git a/arch/mips/sgi-ip27/ip27-memory.c b/arch/mips/sgi-ip27/ip27-memory.c
index d411e0a..f0ed2d4 100644
--- a/arch/mips/sgi-ip27/ip27-memory.c
+++ b/arch/mips/sgi-ip27/ip27-memory.c
@@ -427,3 +427,8 @@ void __init mem_init(void)
setup_zero_pages(); /* This comes from node 0 */
mem_init_print_info(NULL);
}
+
+void __init set_memory_node(phys_addr_t start, phys_addr_t size)
+{
+
+}
--
2.1.0
Re: [PATCH] sched/cputime: correct account of irqtime
Pingfan Liu 于2020年10月12日周一 下午9:54写道：
>
> __do_softirq() may be interrupted by hardware interrupts. In this case,
> irqtime_account_irq() will account the time slice as CPUTIME_SOFTIRQ by
> mistake.
>
> By passing irqtime_account_irq() an extra param about either hardirq or
> softirq, irqtime_account_irq() can handle the above case.
>
> Signed-off-by: Pingfan Liu
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Juri Lelli
> Cc: Vincent Guittot
> Cc: Dietmar Eggemann
> Cc: Steven Rostedt
> Cc: Ben Segall
> Cc: Mel Gorman
> Cc: Thomas Gleixner
> Cc: Andy Lutomirski
> Cc: Will Deacon
> Cc: "Paul E. McKenney"
> Cc: Frederic Weisbecker
> Cc: Allen Pais
> Cc: Romain Perier
> To: linux-kernel@vger.kernel.org
> ---
> include/linux/hardirq.h | 4 ++--
> include/linux/vtime.h | 12 ++--
> kernel/sched/cputime.c | 4 ++--
> kernel/softirq.c| 6 +++---
> 4 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/include/linux/hardirq.h b/include/linux/hardirq.h
> index 754f67a..56e7bb5 100644
> --- a/include/linux/hardirq.h
> +++ b/include/linux/hardirq.h
> @@ -32,7 +32,7 @@ static __always_inline void rcu_irq_enter_check_tick(void)
> */
> #define __irq_enter() \
> do {\
> - account_irq_enter_time(current);\
> + account_irq_enter_time(current, true); \
> preempt_count_add(HARDIRQ_OFFSET); \
> lockdep_hardirq_enter();\
> } while (0)
> @@ -63,7 +63,7 @@ void irq_enter_rcu(void);
> #define __irq_exit() \
> do {\
> lockdep_hardirq_exit(); \
> - account_irq_exit_time(current); \
> + account_irq_exit_time(current, true); \
> preempt_count_sub(HARDIRQ_OFFSET); \
> } while (0)
>
> diff --git a/include/linux/vtime.h b/include/linux/vtime.h
> index 2cdeca0..294188ae1 100644
> --- a/include/linux/vtime.h
> +++ b/include/linux/vtime.h
> @@ -98,21 +98,21 @@ static inline void vtime_flush(struct task_struct *tsk) {
> }
>
>
> #ifdef CONFIG_IRQ_TIME_ACCOUNTING
> -extern void irqtime_account_irq(struct task_struct *tsk);
> +extern void irqtime_account_irq(struct task_struct *tsk, bool hardirq);
> #else
> -static inline void irqtime_account_irq(struct task_struct *tsk) { }
> +static inline void irqtime_account_irq(struct task_struct *tsk, bool
> hardirq) { }
> #endif
>
> -static inline void account_irq_enter_time(struct task_struct *tsk)
> +static inline void account_irq_enter_time(struct task_struct *tsk, bool
> hardirq)
> {
> vtime_account_irq_enter(tsk);
> - irqtime_account_irq(tsk);
> + irqtime_account_irq(tsk, hardirq);
> }
>
> -static inline void account_irq_exit_time(struct task_struct *tsk)
> +static inline void account_irq_exit_time(struct task_struct *tsk, bool
> hardirq)
> {
> vtime_account_irq_exit(tsk);
> - irqtime_account_irq(tsk);
> + irqtime_account_irq(tsk, hardirq);
> }
>
> #endif /* _LINUX_KERNEL_VTIME_H */
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index 5a55d23..166f1d7 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -47,7 +47,7 @@ static void irqtime_account_delta(struct irqtime *irqtime,
> u64 delta,
> * Called before incrementing preempt_count on {soft,}irq_enter
> * and before decrementing preempt_count on {soft,}irq_exit.
> */
> -void irqtime_account_irq(struct task_struct *curr)
> +void irqtime_account_irq(struct task_struct *curr, bool hardirq)
> {
> struct irqtime *irqtime = this_cpu_ptr(_irqtime);
> s64 delta;
> @@ -68,7 +68,7 @@ void irqtime_account_irq(struct task_struct *curr)
> */
> if (hardirq_count())
> irqtime_account_delta(irqtime, delta, CPUTIME_IRQ);
> - else if (in_serving_softirq() && curr != this_cpu_ksoftirqd())
> + else if (in_serving_softirq() && curr != this_cpu_ksoftirqd() &&
> !hardirq)
> irqtime_account_delta(irqtime, delta, CPUTIME_SOFTIRQ);
> }
In my opinion, we don't need to use the hardirq flag, the code: if
(hardirq_count())
already tell us that where the delt time is from.
Thanks
> EXPORT_SYMBOL_GPL(irqtime_account_irq);
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index bf88d7f6..da59ea39 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -270,7 +270,7 @@ asmlinkage __visible void __softirq_entry
> __do_softirq(void)
> current->flags &= ~PF_MEMALLOC;
>
> pending = local_softirq_pending();
> - account_irq_enter_time(current);
> + account_irq_enter_time(current, false);
>
> __local_bh_disable_ip(_RET_IP_, SOFTIRQ_OFFSET);
> in_hardirq = lockdep_softirq_start();
> @@ -321,7 +321,7 @@ asmlinkage __visible void
Re: [f2fs-dev] [f2fs bug] infinite loop in f2fs_get_meta_page_nofail()
On 10/13, Chao Yu wrote: > Jaegeuk, > > I guess you missed sending last applied patch to mailing list? I was testing locally and supposed to post it soon before pull request. Putting it in -dev can give some soak time in -next. No worries. Thanks, > > Thanks, > > On 2020/10/9 22:56, jaeg...@kernel.org wrote: > > On 10/09, Chao Yu wrote: > > > On 2020/10/9 12:32, jaeg...@kernel.org wrote: > > > > On 10/09, Chao Yu wrote: > > > > > On 2020/10/9 9:50, jaeg...@kernel.org wrote: > > > > > > On 10/09, Chao Yu wrote: > > > > > > > On 2020/10/8 5:53, jaeg...@kernel.org wrote: > > > > > > > > On 10/07, Eric Biggers wrote: > > > > > > > > > [moved linux-fsdevel to Bcc] > > > > > > > > > > > > > > > > > > On Wed, Oct 07, 2020 at 02:18:19AM -0700, syzbot wrote: > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > syzbot found the following issue on: > > > > > > > > > > > > > > > > > > > > HEAD commit:a804ab08 Add linux-next specific files for > > > > > > > > > > 20201006 > > > > > > > > > > git tree: linux-next > > > > > > > > > > console output: > > > > > > > > > > https://syzkaller.appspot.com/x/log.txt?x=17fe30bf90 > > > > > > > > > > kernel config: > > > > > > > > > > https://syzkaller.appspot.com/x/.config?x=26c1b4cc4a62ccb > > > > > > > > > > dashboard link: > > > > > > > > > > https://syzkaller.appspot.com/bug?extid=ee250ac8137be41d7b13 > > > > > > > > > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > > > > > > > > > syz repro: > > > > > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=1336413b90 > > > > > > > > > > C reproducer: > > > > > > > > > > https://syzkaller.appspot.com/x/repro.c?x=12f7392b90 > > > > > > > > > > > > > > > > > > > > The issue was bisected to: > > > > > > > > > > > > > > > > > > > > commit eede846af512572b1f30b34f9889d7df64c017d4 > > > > > > > > > > Author: Jaegeuk Kim > > > > > > > > > > Date: Fri Oct 2 21:17:35 2020 + > > > > > > > > > > > > > > > > > > > > f2fs: f2fs_get_meta_page_nofail should not be failed > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jaegeuk, it looks like the loop you added in the above commit > > > > > > > > > doesn't terminate > > > > > > > > > if the requested page is beyond the end of the device. > > > > > > > > > > > > > > > > Yes, that will go infinite loop. Otherwise, it will trigger a > > > > > > > > panic during > > > > > > > > the device reboot. Let me think how to avoid that before trying > > > > > > > > to get the > > > > > > > > wrong lba access. > > > > > > > > > > > > > > Delivering f2fs_get_sum_page()'s return value needs a lot of > > > > > > > codes change, I think > > > > > > > we can just zeroing sum_page in error case, as we have already > > > > > > > shutdown f2fs via > > > > > > > calling f2fs_stop_checkpoint(), then f2fs_cp_error() will stop > > > > > > > all updates to > > > > > > > filesystem data including summary pages. > > > > > > > > > > > > That sounds like one solution tho, I'm afraid of getting another > > > > > > panic by > > > > > > wrong zero'ed summary page. > > > > > > > > > > What case do you mean? maybe I missed some corner cases? > > > > > > > > I sent v2 to fix syzbot issue, which fixes wrong use of > > > > f2fs_get_meta_page_nofail. > > > > > > I agreed to fix that case, however we may encounter deadloop in other > > > places where we call f2fs_get_meta_page_nofail()? like the case that > > > filesystem will always see EIO after we shutdown device via dmflakey? > > > > We may need another option to deal with this. At least, however, it's > > literally > > _nofail function which should guarantee no error, instead of hiding the > > error > > with zero'ed page. > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Eric > > > > > > > > > > > > > > > > > > > > > > > > ___ > > > > > > > > Linux-f2fs-devel mailing list > > > > > > > > linux-f2fs-de...@lists.sourceforge.net > > > > > > > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > > > > > > > . > > > > > > > > > > > > > > . > > > > > > > > > > . > > > > > > . > >
Re: [PATCH 4/5] RISC-V: Protect .init.text & .init.data
Atish Patra 於 2020年10月13日 週二 上午9:28寫道：
>
> On Mon, Oct 12, 2020 at 4:26 PM Atish Patra wrote:
> >
> > On Mon, Oct 12, 2020 at 6:15 AM Greentime Hu
> > wrote:
> > >
> > > Atish Patra 於 2020年10月10日 週六 上午5:13寫道：
> > > >
> > > > Currently, .init.text & .init.data are intermixed which makes it
> > > > impossible
> > > > apply different permissions to them. .init.data shouldn't need exec
> > > > permissions while .init.text shouldn't have write permission.
> > > >
> > > > Keep them in separate sections so that different permissions are
> > > > applied to
> > > > each section. This improves the kernel protection under
> > > > CONFIG_STRICT_KERNEL_RWX. We also need to restore the permissions for
> > > > the
> > > > entire _init section after it is freed so that those pages can be used
> > > > for
> > > > other purpose.
> > > >
> > > > Signed-off-by: Atish Patra
> > > > ---
> > > > arch/riscv/include/asm/sections.h | 2 ++
> > > > arch/riscv/include/asm/set_memory.h | 2 ++
> > > > arch/riscv/kernel/setup.c | 4
> > > > arch/riscv/kernel/vmlinux.lds.S | 10 +-
> > > > arch/riscv/mm/init.c| 6 ++
> > > > arch/riscv/mm/pageattr.c| 6 ++
> > > > 6 files changed, 29 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/riscv/include/asm/sections.h
> > > > b/arch/riscv/include/asm/sections.h
> > > > index d60802bfafbc..730d2c4a844d 100644
> > > > --- a/arch/riscv/include/asm/sections.h
> > > > +++ b/arch/riscv/include/asm/sections.h
> > > > @@ -10,6 +10,8 @@
> > > > #include
> > > > extern char _start[];
> > > > extern char _start_kernel[];
> > > > +extern char __init_data_begin[], __init_data_end[];
> > > > +extern char __init_text_begin[], __init_text_end[];
> > > >
> > > > extern bool init_mem_is_free;
> > > >
> > > > diff --git a/arch/riscv/include/asm/set_memory.h
> > > > b/arch/riscv/include/asm/set_memory.h
> > > > index 4cc3a4e2afd3..913429c9c1ae 100644
> > > > --- a/arch/riscv/include/asm/set_memory.h
> > > > +++ b/arch/riscv/include/asm/set_memory.h
> > > > @@ -15,6 +15,7 @@ int set_memory_ro(unsigned long addr, int numpages);
> > > > int set_memory_rw(unsigned long addr, int numpages);
> > > > int set_memory_x(unsigned long addr, int numpages);
> > > > int set_memory_nx(unsigned long addr, int numpages);
> > > > +int set_memory_default(unsigned long addr, int numpages);
> > > > void protect_kernel_text_data(void);
> > > > #else
> > > > static inline int set_memory_ro(unsigned long addr, int numpages) {
> > > > return 0; }
> > > > @@ -22,6 +23,7 @@ static inline int set_memory_rw(unsigned long addr,
> > > > int numpages) { return 0; }
> > > > static inline int set_memory_x(unsigned long addr, int numpages) {
> > > > return 0; }
> > > > static inline int set_memory_nx(unsigned long addr, int numpages) {
> > > > return 0; }
> > > > static inline void protect_kernel_text_data(void) {};
> > > > +static inline int set_memory_default(unsigned long addr, int numpages)
> > > > { return 0; }
> > > > #endif
> > > >
> > > > int set_direct_map_invalid_noflush(struct page *page);
> > > > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> > > > index 4176a2affd1d..b8a35ef0eab0 100644
> > > > --- a/arch/riscv/kernel/setup.c
> > > > +++ b/arch/riscv/kernel/setup.c
> > > > @@ -129,6 +129,10 @@ bool init_mem_is_free = false;
> > > >
> > > > void free_initmem(void)
> > > > {
> > > > + unsigned long init_begin = (unsigned long)__init_begin;
> > > > + unsigned long init_end = (unsigned long)__init_end;
> > > > +
> > > > + set_memory_default(init_begin, (init_end - init_begin) >>
> > > > PAGE_SHIFT);
> > > > free_initmem_default(POISON_FREE_INITMEM);
> > > > init_mem_is_free = true;
> > > > }
> > > > diff --git a/arch/riscv/kernel/vmlinux.lds.S
> > > > b/arch/riscv/kernel/vmlinux.lds.S
> > > > index 0807633f0dc8..15b9882588ae 100644
> > > > --- a/arch/riscv/kernel/vmlinux.lds.S
> > > > +++ b/arch/riscv/kernel/vmlinux.lds.S
> > > > @@ -30,8 +30,8 @@ SECTIONS
> > > > . = ALIGN(PAGE_SIZE);
> > > >
> > > > __init_begin = .;
> > > > + __init_text_begin = .;
> > > > INIT_TEXT_SECTION(PAGE_SIZE)
> > > > - INIT_DATA_SECTION(16)
> > > > . = ALIGN(8);
> > > > __soc_early_init_table : {
> > > > __soc_early_init_table_start = .;
> > > > @@ -48,11 +48,19 @@ SECTIONS
> > > > {
> > > > EXIT_TEXT
> > > > }
> > > > +
> > > > + __init_text_end = .;
> > > > + . = ALIGN(SECTION_ALIGN);
> > > > + /* Start of init data section */
> > > > + __init_data_begin = .;
> > > > + INIT_DATA_SECTION(16)
> > > > .exit.data :
> > > > {
> > > > EXIT_DATA
> > > > }
> > > > PERCPU_SECTION(L1_CACHE_BYTES)
> > > > +
> > > > + __init_data_end = .;
> > > > __init_end = .;
> > > >
> > > > . =
linux-next: build failure after merge of the vfio tree
Hi all,
After merging the vfio tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Caused by commit
cc0ee20bd969 ("vfio/fsl-mc: trigger an interrupt via eventfd")
ac93ab2bf69a ("vfio/fsl-mc: Add support for device reset")
I have used the vfio tree from next-20201012 for today.
--
Cheers,
Stephen Rothwell
pgpNWyudAdAjW.pgp
Description: OpenPGP digital signature
Re: [f2fs-dev] [PATCH v3] f2fs: handle errors of f2fs_get_meta_page_nofail be failed
First problem is we hit BUG_ON() in f2fs_get_sum_page given EIO on
f2fs_get_meta_page_nofail().
Quick fix was not to give any error with infinite loop, but syzbot caught
a case where it goes to that loop from fuzzed image. In turned out we abused
f2fs_get_meta_page_nofail() like in the below call stack.
- f2fs_fill_super
- f2fs_build_segment_manager
- build_sit_entries
- get_current_sit_page
INFO: task syz-executor178:6870 can't die for more than 143 seconds.
task:syz-executor178 state:R
stack:26960 pid: 6870 ppid: 6869 flags:0x4006
Call Trace:
Showing all locks held in the system:
1 lock held by khungtaskd/1179:
#0: 8a554da0 (rcu_read_lock){}-{1:2}, at:
debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6242
1 lock held by systemd-journal/3920:
1 lock held by in:imklog/6769:
#0: 88809eebc130 (>f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100
fs/file.c:930
1 lock held by syz-executor178/6870:
#0: 8880925120e0 (>s_umount_key#47/1){+.+.}-{3:3}, at:
alloc_super+0x201/0xaf0 fs/super.c:229
Actually, we didn't have to use _nofail in this case, since we could return
error to mount(2) already with the error handler.
As a result, this patch tries to 1) remove _nofail callers as much as possible,
2) deal with error case in last remaining caller, f2fs_get_sum_page().
Reported-by: syzbot+ee250ac8137be41d7...@syzkaller.appspotmail.com
Signed-off-by: Jaegeuk Kim
---
Change log from v2:
- avoid _nofail and add error handler
fs/f2fs/checkpoint.c | 2 +-
fs/f2fs/f2fs.h | 2 +-
fs/f2fs/node.c | 2 +-
fs/f2fs/segment.c| 12 +---
4 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index f18386d30f031..023462e80e58d 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -107,7 +107,7 @@ struct page *f2fs_get_meta_page(struct f2fs_sb_info *sbi,
pgoff_t index)
return __get_meta_page(sbi, index, true);
}
-struct page *f2fs_get_meta_page_nofail(struct f2fs_sb_info *sbi, pgoff_t index)
+struct page *f2fs_get_meta_page_retry(struct f2fs_sb_info *sbi, pgoff_t index)
{
struct page *page;
int count = 0;
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index ae46d44bd5211..adda53d20a399 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -3422,7 +3422,7 @@ unsigned int f2fs_usable_blks_in_seg(struct f2fs_sb_info
*sbi,
void f2fs_stop_checkpoint(struct f2fs_sb_info *sbi, bool end_io);
struct page *f2fs_grab_meta_page(struct f2fs_sb_info *sbi, pgoff_t index);
struct page *f2fs_get_meta_page(struct f2fs_sb_info *sbi, pgoff_t index);
-struct page *f2fs_get_meta_page_nofail(struct f2fs_sb_info *sbi, pgoff_t
index);
+struct page *f2fs_get_meta_page_retry(struct f2fs_sb_info *sbi, pgoff_t index);
struct page *f2fs_get_tmp_page(struct f2fs_sb_info *sbi, pgoff_t index);
bool f2fs_is_valid_blkaddr(struct f2fs_sb_info *sbi,
block_t blkaddr, int type);
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 93fb34d636eb5..d5d8ce077f295 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -109,7 +109,7 @@ static void clear_node_page_dirty(struct page *page)
static struct page *get_current_nat_page(struct f2fs_sb_info *sbi, nid_t nid)
{
- return f2fs_get_meta_page_nofail(sbi, current_nat_addr(sbi, nid));
+ return f2fs_get_meta_page(sbi, current_nat_addr(sbi, nid));
}
static struct page *get_next_nat_page(struct f2fs_sb_info *sbi, nid_t nid)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 13ecd2c2c361b..05ab5ae2b5f7f 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -2379,7 +2379,9 @@ int f2fs_npages_for_summary_flush(struct f2fs_sb_info
*sbi, bool for_ra)
*/
struct page *f2fs_get_sum_page(struct f2fs_sb_info *sbi, unsigned int segno)
{
- return f2fs_get_meta_page_nofail(sbi, GET_SUM_BLOCK(sbi, segno));
+ if (unlikely(f2fs_cp_error(sbi)))
+ return ERR_PTR(-EIO);
+ return f2fs_get_meta_page_retry(sbi, GET_SUM_BLOCK(sbi, segno));
}
void f2fs_update_meta_page(struct f2fs_sb_info *sbi,
@@ -2669,7 +2671,11 @@ static void change_curseg(struct f2fs_sb_info *sbi, int
type, bool flush)
__next_free_blkoff(sbi, curseg, 0);
sum_page = f2fs_get_sum_page(sbi, new_segno);
- f2fs_bug_on(sbi, IS_ERR(sum_page));
+ if (IS_ERR(sum_page)) {
+ /* GC won't be able to use stale summary pages by cp_error */
+ memset(curseg->sum_blk, 0, SUM_ENTRY_SIZE);
+ return;
+ }
sum_node = (struct f2fs_summary_block *)page_address(sum_page);
memcpy(curseg->sum_blk, sum_node, SUM_ENTRY_SIZE);
f2fs_put_page(sum_page, 1);
@@ -3964,7 +3970,7 @@ int f2fs_lookup_journal_in_cursum(struct f2fs_journal
*journal, int type,
static struct page *get_current_sit_page(struct f2fs_sb_info *sbi,
unsigned int segno)
{
- return f2fs_get_meta_page_nofail(sbi,
Re: [ANNOUNCE] libtraceevent.git
On Tue, Oct 13, 2020 at 3:17 AM Steven Rostedt wrote: > > > [ Removing the powertop mailing list because it's rejecting everything ] > > On Mon, 12 Oct 2020 11:41:20 -0700 > Tony Jones wrote: > > > On Mon, Oct 12, 2020 at 11:19:50AM -0400, Steven Rostedt wrote: > > > > > Once it's shown that it works for all the package maintainers, I will tag > > > it which should create the tarballs automatically on the above link. > > > > Hi. > > > > It builds fine for me after manually creating the tarball from git. > > Once there is an official versioned tarball I'll push it into > > openSUSE. > > > > I presume some perf Makefile changes will be forthcoming to use it, > > rather than continuing to force build it out of TRACE_EVENT_DIR > > > > Zamir found this issue with the Documentation man pages: > > Note, I'm not sure the proper way to fix this. I think this is the last > issue I need to resolve before making the tag. > If anyone interested in, the discussion of this document compiling is in the thread "libtraceevent: make doc-install tries different file names than generated". With the patch Steve mentioned, I can package this in RPM already. And it's pending review in Fedora now. https://bugzilla.redhat.com/show_bug.cgi?id=1887470 So, for me, there is no more issue for Fedora packaging. Thanks.
Re: [PATCH] optee: remove address tag in check_mem_type()
Hello Jens, Jens Wiklander writes: > On Mon, Oct 12, 2020 at 11:26 AM Volodymyr Babchuk > wrote: >> >> Before passing 'start' to find_vma() we need to remove >> tags from it to get sane results. >> >> Signed-off-by: Volodymyr Babchuk >> --- >> drivers/tee/optee/call.c | 2 ++ >> 1 file changed, 2 insertions(+) > > Would you mind giving a bit more background to this? For example in > which contexts this function does or doesn't work as expected? Do you > have any special use cases that don't work, etc? This is not a new > regression, it's rather a problem we've always had, right? Yes, sorry. I had to clarify in the commit description. Issue was found on Android. Android uses pointer tagging [1], so MSB of user pointers contain tags. As a result, passing raw user address to find_vma() leads to NULL result, as it only traverses RB tree and does not alter passed address in any way. Code in mm/gup.c already strips tags and maybe, it is better to call untagged_addr() inside of find_vma(). I'm not sure. Probably, we need some help from MM maintainers. Anyways, this patched fixed issue with register_shm failing in our use case. [1] https://source.android.com/devices/tech/debug/tagged-pointers -- Volodymyr Babchuk at EPAM
Re: [LKP] Re: [hugetlbfs] c0d0381ade: vm-scalability.throughput -33.4% regression
On 10/12/20 6:59 PM, Xing Zhengjun wrote: > > > On 10/13/2020 1:40 AM, Mike Kravetz wrote: >> On 10/11/20 10:29 PM, Xing Zhengjun wrote: >>> Hi Mike, >>> >>> I re-test it in v5.9-rc8, the regression still existed. It is almost >>> the same as 34ae204f1851. Do you have time to look at it? Thanks. >>> >> >> Thank you for testing. >> >> Just curious, did you apply the series in this thread or just test v5.9-rc8? >> If just testing v5.9-rc8, no changes to this code were added after >> 34ae204f1851, >> so results being the same are expected. >> > > I just test v5.9-rc8. Where can I find the series patches you mentioned here? > Or just wait for the next mainline release? > My apologies. I missed that you were not cc'ed on this thred: https://lore.kernel.org/linux-mm/20200706202615.32111-1-mike.krav...@oracle.com/ As mentioned, there will likely be another revision to the way locking is handled. The new scheme will try to consider performance as is done in the above link. I suggest you wait for next revision. If you do not mind, I will cc you when the new code is posted. -- Mike Kravetz
Re: [RT] 5.9-rt14 softirq_ctrl.lock vs listening_hash[i].lock lockdep splat
On Mon, 2020-10-12 at 20:34 +0200, Mike Galbraith wrote:
> On Mon, 2020-10-12 at 18:45 +0200, Sebastian Andrzej Siewior wrote:
> > On 2020-10-10 06:31:57 [+0200], Mike Galbraith wrote:
> >
> > so this then. Do you have more of these?
>
> Nope
Well, I do have a gripe from 5.6-rt, which I just took a moment to
confirm in virgin source, but that kernel is probably EOL.
[ 24.613988] ==
[ 24.613988] WARNING: possible circular locking dependency detected
[ 24.613989] 5.6.19-rt12-rt #3 Tainted: GE
[ 24.613990] --
[ 24.613991] ksoftirqd/0/10 is trying to acquire lock:
[ 24.613992] 94a639fd6a48 (>q.lock){+...}, at:
sch_direct_xmit+0x81/0x2f0
[ 24.613998]
but task is already holding lock:
[ 24.613998] 94a639fd6a80 (&(>running)->seqcount){+...}, at:
br_dev_queue_push_xmit+0x79/0x160 [bridge]
[ 24.614007]
which lock already depends on the new lock.
[ 24.614008]
the existing dependency chain (in reverse order) is:
[ 24.614009]
-> #1 (&(>running)->seqcount){+...}:
[ 24.614010]__dev_queue_xmit+0xc86/0xda0
[ 24.614012]br_dev_queue_push_xmit+0x79/0x160 [bridge]
[ 24.614017]br_forward_finish+0x10a/0x1b0 [bridge]
[ 24.614021]__br_forward+0x17d/0x340 [bridge]
[ 24.614024]br_dev_xmit+0x432/0x560 [bridge]
[ 24.614029]dev_hard_start_xmit+0xc5/0x3f0
[ 24.614030]__dev_queue_xmit+0x973/0xda0
[ 24.614031]ip6_finish_output2+0x290/0x980
[ 24.614033]ip6_output+0x6d/0x260
[ 24.614034]mld_sendpack+0x1d9/0x360
[ 24.614035]mld_ifc_timer_expire+0x1f7/0x370
[ 24.614036]call_timer_fn+0x98/0x390
[ 24.614038]run_timer_softirq+0x591/0x720
[ 24.614040]__do_softirq+0xca/0x561
[ 24.614042]run_ksoftirqd+0x45/0x70
[ 24.614043]smpboot_thread_fn+0x266/0x320
[ 24.614045]kthread+0x11c/0x140
[ 24.614047]ret_from_fork+0x24/0x50
[ 24.614049]
-> #0 (>q.lock){+...}:
[ 24.614050]__lock_acquire+0x115a/0x1440
[ 24.614052]lock_acquire+0x93/0x230
[ 24.614053]rt_spin_lock+0x78/0xd0
[ 24.614055]sch_direct_xmit+0x81/0x2f0
[ 24.614056]__dev_queue_xmit+0xcd7/0xda0
[ 24.614057]br_dev_queue_push_xmit+0x79/0x160 [bridge]
[ 24.614062]br_forward_finish+0x10a/0x1b0 [bridge]
[ 24.614067]__br_forward+0x17d/0x340 [bridge]
[ 24.614072]br_dev_xmit+0x432/0x560 [bridge]
[ 24.614076]dev_hard_start_xmit+0xc5/0x3f0
[ 24.614077]__dev_queue_xmit+0x973/0xda0
[ 24.614078]ip6_finish_output2+0x290/0x980
[ 24.614079]ip6_output+0x6d/0x260
[ 24.614080]mld_sendpack+0x1d9/0x360
[ 24.614081]mld_ifc_timer_expire+0x1f7/0x370
[ 24.614082]call_timer_fn+0x98/0x390
[ 24.614084]run_timer_softirq+0x591/0x720
[ 24.614085]__do_softirq+0xca/0x561
[ 24.614086]run_ksoftirqd+0x45/0x70
[ 24.614087]smpboot_thread_fn+0x266/0x320
[ 24.614089]kthread+0x11c/0x140
[ 24.614090]ret_from_fork+0x24/0x50
[ 24.614091]
other info that might help us debug this:
[ 24.614092] Possible unsafe locking scenario:
[ 24.614092]CPU0CPU1
[ 24.614093]
[ 24.614093] lock(&(>running)->seqcount);
[ 24.614094]lock(>q.lock);
[ 24.614095]lock(&(>running)->seqcount);
[ 24.614096] lock(>q.lock);
[ 24.614097]
*** DEADLOCK ***
[ 24.614097] 20 locks held by ksoftirqd/0/10:
[ 24.614098] #0: a2485fc0 (rcu_read_lock){}, at:
rt_spin_lock+0x5/0xd0
[ 24.614101] #1: 94a65ec1b5a0 (per_cpu_ptr(_lock.lock, cpu)){},
at: __local_bh_disable_ip+0xda/0x1c0
[ 24.614103] #2: a2485fc0 (rcu_read_lock){}, at:
__local_bh_disable_ip+0x106/0x1c0
[ 24.614105] #3: a2485fc0 (rcu_read_lock){}, at:
rt_spin_lock+0x5/0xd0
[ 24.614107] #4: 94a65ec1c1e0 (>expiry_lock){+...}, at:
run_timer_softirq+0x3e3/0x720
[ 24.614110] #5: b3bd40077d70 ((>mc_ifc_timer)){+...}, at:
call_timer_fn+0x5/0x390
[ 24.614113] #6: a2485fc0 (rcu_read_lock){}, at:
mld_sendpack+0x5/0x360
[ 24.614116] #7: a2485fc0 (rcu_read_lock){}, at:
__local_bh_disable_ip+0x106/0x1c0
[ 24.614118] #8: a2485fa0 (rcu_read_lock_bh){}, at:
ip6_finish_output2+0x7a/0x980
[ 24.614121] #9: a2485fc0 (rcu_read_lock){}, at:
__local_bh_disable_ip+0x106/0x1c0
[ 24.614124] #10: a2485fa0 (rcu_read_lock_bh){}, at:
__dev_queue_xmit+0x63/0xda0
[ 24.614126] #11: a2485fc0 (rcu_read_lock){}, at:
br_dev_xmit+0x5/0x560 [bridge]
[ 24.614133] #12: a2485fc0
Re: [PATCH v2 1/2] Documentation: x86: Rename resctrl_ui.rst and add two errata to the file
Hi, Randy, On Mon, Oct 12, 2020 at 07:54:32PM -0700, Randy Dunlap wrote: > On 10/12/20 7:46 PM, Fenghua Yu wrote: > > diff --git a/Documentation/conf.py b/Documentation/conf.py > > index c50310d9..b5b2be8eec22 100644 > > --- a/Documentation/conf.py > > +++ b/Documentation/conf.py > > @@ -36,7 +36,7 @@ needs_sphinx = '1.3' > > # Add any Sphinx extension module names here, as strings. They can be > > # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom > > # ones. > > -extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', > > +extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', > >'kfigure', 'sphinx.ext.ifconfig', 'automarkup', > >'maintainers_include', 'sphinx.ext.autosectionlabel' ] > > Hi, > I don't see this change described in the patch description. > Should it be here? My bad. I forgot to remove this change. I will remove it in v3. Thank you for your review! -Fenghua
about prandom vs __this_cpu_read()
Linus, the latest prandom series I sent you changes __this_cpu_read() to this_cpu_read() since LKP returned the following trace on i386: [9.061912] dump_stack+0x54/0x6e [9.061912] check_preemption_disabled+0xb1/0xc0 [9.061912] __this_cpu_preempt_check+0xf/0x11 [9.065516] __igt_reserve+0x91/0x580 [9.065516] igt_reserve+0x5b/0xc0 [9.065516] test_drm_mm_init+0x78/0xa9 I got another report that it breaks on ARC (trivial fix consists in adding irqflags.h in prandom.h) but that made me wonder, we're using this to access and update the net_rand_noise variable only, wouldn't it be better to use the faster raw_cpu_read()/raw_cpu_write() there, considering we don't care about concurrent accesses since they simply add even more impredictability to the noise ? If so, I'll update this branch and will send you another PR. Thanks, Willy
Re: [PATCH v2 1/2] Documentation: x86: Rename resctrl_ui.rst and add two errata to the file
On 10/12/20 7:46 PM, Fenghua Yu wrote:
> Intel Memory Bandwidth Monitoring (MBM) counters may report system
> memory bandwidth incorrectly on some Intel processors. The errata are
> reported in erratum SKX99 [1], erratum BDF102 [2] and RDT reference
> manual [3].
>
> To work around the errata, MBM total and local readings are corrected
> using a correction factor table.
>
> Since the correction factor table is not publicly documented anywhere,
> the table and the errata are documented in Documentation/x86/resctrl.rst
> for future reference. The resctrl.rst file is renamed from
> Documentation/x86/resctrl_ui.rst because the file won't contain user
> interface only anymore.
>
> 1. Erratum SKX99 in Intel Xeon Processor Scalable Family Specification
>Update:
> http://web.archive.org/web/20200716124958/https://www.intel.com/content/www/us/en/processors/xeon/scalable/xeon-scalable-spec-update.html
> 2. Erratum BDF102 in Intel Xeon E5-2600 v4 Processor Product Family
>Specification Update:
> http://web.archive.org/web/20191125200531/https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e5-v4-spec-update.pdf
> 3. The errata in Intel Resource Director Technology (Intel RDT) on 2nd
>Generation Intel Xeon Scalable Processors Reference Manual:
> https://software.intel.com/content/www/us/en/develop/articles/intel-resource-director-technology-rdt-reference-manual.html
>
> Suggested-by: Borislav Petkov
> Signed-off-by: Fenghua Yu
> ---
> Change Log:
> v2:
> - Document the correction factor table and errata in resctrl.rst (Boris).
> - Change the documentation URLs to stable archive.org (Tony).
>
> Documentation/conf.py | 2 +-
> Documentation/x86/index.rst | 2 +-
> .../x86/{resctrl_ui.rst => resctrl.rst} | 82 +++
> 3 files changed, 84 insertions(+), 2 deletions(-)
> rename Documentation/x86/{resctrl_ui.rst => resctrl.rst} (92%)
>
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index c50310d9..b5b2be8eec22 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -36,7 +36,7 @@ needs_sphinx = '1.3'
> # Add any Sphinx extension module names here, as strings. They can be
> # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
> # ones.
> -extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain',
> +extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
>'kfigure', 'sphinx.ext.ifconfig', 'automarkup',
>'maintainers_include', 'sphinx.ext.autosectionlabel' ]
Hi,
I don't see this change described in the patch description.
Should it be here?
thanks.
--
~Randy
[PATCH v2] ASoC: fsl_spdif: Add support for higher sample rates
Add 88200Hz and 176400Hz sample rates support for TX.
Add 88200Hz, 176400Hz, 192000Hz sample rates support for RX.
Signed-off-by: Viorel Suman
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
---
changes in v2
- reorder the signed-off
- add acked-by Nicolin
sound/soc/fsl/fsl_spdif.c | 16 +---
sound/soc/fsl/fsl_spdif.h | 9 -
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index 4d14f4076ead..1c030142556a 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -459,10 +459,18 @@ static int spdif_set_sample_rate(struct snd_pcm_substream
*substream,
rate = SPDIF_TXRATE_48000;
csfs = IEC958_AES3_CON_FS_48000;
break;
+ case 88200:
+ rate = SPDIF_TXRATE_88200;
+ csfs = IEC958_AES3_CON_FS_88200;
+ break;
case 96000:
rate = SPDIF_TXRATE_96000;
csfs = IEC958_AES3_CON_FS_96000;
break;
+ case 176400:
+ rate = SPDIF_TXRATE_176400;
+ csfs = IEC958_AES3_CON_FS_176400;
+ break;
case 192000:
rate = SPDIF_TXRATE_192000;
csfs = IEC958_AES3_CON_FS_192000;
@@ -857,7 +865,7 @@ static int fsl_spdif_rxrate_info(struct snd_kcontrol
*kcontrol,
uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
uinfo->count = 1;
uinfo->value.integer.min = 16000;
- uinfo->value.integer.max = 96000;
+ uinfo->value.integer.max = 192000;
return 0;
}
@@ -1175,7 +1183,8 @@ static u32 fsl_spdif_txclk_caldiv(struct fsl_spdif_priv
*spdif_priv,
struct clk *clk, u64 savesub,
enum spdif_txrate index, bool round)
{
- static const u32 rate[] = { 32000, 44100, 48000, 96000, 192000 };
+ static const u32 rate[] = { 32000, 44100, 48000, 88200, 96000, 176400,
+ 192000, };
bool is_sysclk = clk_is_match(clk, spdif_priv->sysclk);
u64 rate_ideal, rate_actual, sub;
u32 arate;
@@ -1235,7 +1244,8 @@ static u32 fsl_spdif_txclk_caldiv(struct fsl_spdif_priv
*spdif_priv,
static int fsl_spdif_probe_txclk(struct fsl_spdif_priv *spdif_priv,
enum spdif_txrate index)
{
- static const u32 rate[] = { 32000, 44100, 48000, 96000, 192000 };
+ static const u32 rate[] = { 32000, 44100, 48000, 88200, 96000, 176400,
+ 192000, };
struct platform_device *pdev = spdif_priv->pdev;
struct device *dev = >dev;
u64 savesub = 10, ret;
diff --git a/sound/soc/fsl/fsl_spdif.h b/sound/soc/fsl/fsl_spdif.h
index e6c61e07bc1a..d5f1dfd58740 100644
--- a/sound/soc/fsl/fsl_spdif.h
+++ b/sound/soc/fsl/fsl_spdif.h
@@ -163,7 +163,9 @@ enum spdif_txrate {
SPDIF_TXRATE_32000 = 0,
SPDIF_TXRATE_44100,
SPDIF_TXRATE_48000,
+ SPDIF_TXRATE_88200,
SPDIF_TXRATE_96000,
+ SPDIF_TXRATE_176400,
SPDIF_TXRATE_192000,
};
#define SPDIF_TXRATE_MAX (SPDIF_TXRATE_192000 + 1)
@@ -177,15 +179,20 @@ enum spdif_txrate {
#define FSL_SPDIF_RATES_PLAYBACK (SNDRV_PCM_RATE_32000 | \
SNDRV_PCM_RATE_44100 | \
SNDRV_PCM_RATE_48000 | \
+SNDRV_PCM_RATE_88200 | \
SNDRV_PCM_RATE_96000 | \
+SNDRV_PCM_RATE_176400 | \
SNDRV_PCM_RATE_192000)
#define FSL_SPDIF_RATES_CAPTURE(SNDRV_PCM_RATE_16000 | \
SNDRV_PCM_RATE_32000 | \
SNDRV_PCM_RATE_44100 | \
SNDRV_PCM_RATE_48000 | \
+SNDRV_PCM_RATE_88200 | \
SNDRV_PCM_RATE_64000 | \
-SNDRV_PCM_RATE_96000)
+SNDRV_PCM_RATE_96000 | \
+SNDRV_PCM_RATE_176400 | \
+SNDRV_PCM_RATE_192000)
#define FSL_SPDIF_FORMATS_PLAYBACK (SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S20_3LE | \
--
2.27.0
[PATCH v4 3/3] KEYS: trusted: Reserve TPM for seal and unseal operations
When TPM 2.0 trusted keys code was moved to the trusted keys subsystem,
the operations were unwrapped from tpm_try_get_ops() and tpm_put_ops(),
which are used to take temporarily the ownership of the TPM chip. The
ownership is only taken inside tpm_send(), but this is not sufficient,
as in the key load TPM2_CC_LOAD, TPM2_CC_UNSEAL and TPM2_FLUSH_CONTEXT
need to be done as a one single atom.
Fix this issue by introducting trusted_tpm_load() and trusted_tpm_new(),
which wrap these operations, and take the TPM chip ownership before
sending anything. Use tpm_transmit_cmd() to send TPM commands instead
of tpm_send(), reverting back to the old behaviour.
Fixes: 2e19e10131a0 ("KEYS: trusted: Move TPM2 trusted keys code")
Reported-by: "James E.J. Bottomley"
Cc: sta...@vger.kernel.org
Cc: David Howells
Cc: Mimi Zohar
Cc: Sumit Garg
Signed-off-by: Jarkko Sakkinen
Reported-by: kernel test robot
---
drivers/char/tpm/tpm.h| 4 --
include/linux/tpm.h | 5 +-
security/keys/trusted-keys/trusted_tpm1.c | 78 +++
security/keys/trusted-keys/trusted_tpm2.c | 6 +-
4 files changed, 60 insertions(+), 33 deletions(-)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 947d1db0a5cc..283f78211c3a 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -164,8 +164,6 @@ extern const struct file_operations tpmrm_fops;
extern struct idr dev_nums_idr;
ssize_t tpm_transmit(struct tpm_chip *chip, u8 *buf, size_t bufsiz);
-ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf,
-size_t min_rsp_body_length, const char *desc);
int tpm_get_timeouts(struct tpm_chip *);
int tpm_auto_startup(struct tpm_chip *chip);
@@ -194,8 +192,6 @@ static inline void tpm_msleep(unsigned int delay_msec)
int tpm_chip_start(struct tpm_chip *chip);
void tpm_chip_stop(struct tpm_chip *chip);
struct tpm_chip *tpm_find_get_ops(struct tpm_chip *chip);
-__must_check int tpm_try_get_ops(struct tpm_chip *chip);
-void tpm_put_ops(struct tpm_chip *chip);
struct tpm_chip *tpm_chip_alloc(struct device *dev,
const struct tpm_class_ops *ops);
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index 8f4ff39f51e7..804a3f69bbd9 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -397,6 +397,10 @@ static inline u32 tpm2_rc_value(u32 rc)
#if defined(CONFIG_TCG_TPM) || defined(CONFIG_TCG_TPM_MODULE)
extern int tpm_is_tpm2(struct tpm_chip *chip);
+extern __must_check int tpm_try_get_ops(struct tpm_chip *chip);
+extern void tpm_put_ops(struct tpm_chip *chip);
+extern ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf,
+ size_t min_rsp_body_length, const char *desc);
extern int tpm_pcr_read(struct tpm_chip *chip, u32 pcr_idx,
struct tpm_digest *digest);
extern int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
@@ -410,7 +414,6 @@ static inline int tpm_is_tpm2(struct tpm_chip *chip)
{
return -ENODEV;
}
-
static inline int tpm_pcr_read(struct tpm_chip *chip, int pcr_idx,
struct tpm_digest *digest)
{
diff --git a/security/keys/trusted-keys/trusted_tpm1.c
b/security/keys/trusted-keys/trusted_tpm1.c
index 7a937c3c5283..20ca18e17437 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -950,6 +950,51 @@ static struct trusted_key_payload
*trusted_payload_alloc(struct key *key)
return p;
}
+static int trusted_tpm_load(struct tpm_chip *chip,
+ struct trusted_key_payload *payload,
+ struct trusted_key_options *options)
+{
+ int ret;
+
+ if (tpm_is_tpm2(chip)) {
+ ret = tpm_try_get_ops(chip);
+ if (!ret) {
+ ret = tpm2_unseal_trusted(chip, payload, options);
+ tpm_put_ops(chip);
+ }
+ } else {
+ ret = key_unseal(payload, options);
+ }
+
+ return ret;
+}
+
+static int trusted_tpm_new(struct tpm_chip *chip,
+ struct trusted_key_payload *payload,
+ struct trusted_key_options *options)
+{
+ int ret;
+
+ ret = tpm_get_random(chip, payload->key, payload->key_len);
+ if (ret < 0)
+ return ret;
+
+ if (ret != payload->key_len)
+ return -EIO;
+
+ if (tpm_is_tpm2(chip)) {
+ ret = tpm_try_get_ops(chip);
+ if (!ret) {
+ ret = tpm2_seal_trusted(chip, payload, options);
+ tpm_put_ops(chip);
+ }
+ } else {
+ ret = key_seal(payload, options);
+ }
+
+ return ret;
+}
+
/*
* trusted_instantiate - create a new trusted key
*
@@ -968,12 +1013,6 @@ static int trusted_instantiate(struct key *key,
char *datablob;
int
[PATCH v4 2/3] KEYS: trusted: Fix migratable=1 failing
Consider the following transcript:
$ keyctl add trusted kmk "new 32 blobauth=helloworld keyhandle=8000
migratable=1" @u
add_key: Invalid argument
The documentation has the following description:
migratable= 0|1 indicating permission to reseal to new PCR values,
default 1 (resealing allowed)
The consequence is that "migratable=1" should succeed. Fix this by
allowing this condition to pass instead of return -EINVAL.
[*] Documentation/security/keys/trusted-encrypted.rst
Cc: sta...@vger.kernel.org
Cc: "James E.J. Bottomley"
Cc: Mimi Zohar
Cc: David Howells
Fixes: d00a1c72f7f4 ("keys: add new trusted key-type")
Signed-off-by: Jarkko Sakkinen
---
security/keys/trusted-keys/trusted_tpm1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/keys/trusted-keys/trusted_tpm1.c
b/security/keys/trusted-keys/trusted_tpm1.c
index c7b1701cdac5..7a937c3c5283 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -801,7 +801,7 @@ static int getoptions(char *c, struct trusted_key_payload
*pay,
case Opt_migratable:
if (*args[0].from == '0')
pay->migratable = 0;
- else
+ else if (*args[0].from != '1')
return -EINVAL;
break;
case Opt_pcrlock:
--
2.25.1
[PATCH v4 1/3] KEYS: trusted: Fix incorrect handling of tpm_get_random()
When tpm_get_random() was introduced, it defined the following API for the
return value:
1. A positive value tells how many bytes of random data was generated.
2. A negative value on error.
However, in the call sites the API was used incorrectly, i.e. as it would
only return negative values and otherwise zero. Returning he positive read
counts to the user space does not make any possible sense.
Fix this by returning -EIO when tpm_get_random() returns a positive value.
Fixes: 41ab999c80f1 ("tpm: Move tpm_get_random api into the TPM device driver")
Cc: sta...@vger.kernel.org
Cc: Mimi Zohar
Cc: "James E.J. Bottomley"
Cc: David Howells
Cc: Kent Yoder
Signed-off-by: Jarkko Sakkinen
---
security/keys/trusted-keys/trusted_tpm1.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/security/keys/trusted-keys/trusted_tpm1.c
b/security/keys/trusted-keys/trusted_tpm1.c
index b9fe02e5f84f..c7b1701cdac5 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -403,9 +403,12 @@ static int osap(struct tpm_buf *tb, struct osapsess *s,
int ret;
ret = tpm_get_random(chip, ononce, TPM_NONCE_SIZE);
- if (ret != TPM_NONCE_SIZE)
+ if (ret < 0)
return ret;
+ if (ret != TPM_NONCE_SIZE)
+ return -EIO;
+
tpm_buf_reset(tb, TPM_TAG_RQU_COMMAND, TPM_ORD_OSAP);
tpm_buf_append_u16(tb, type);
tpm_buf_append_u32(tb, handle);
@@ -496,8 +499,12 @@ static int tpm_seal(struct tpm_buf *tb, uint16_t keytype,
goto out;
ret = tpm_get_random(chip, td->nonceodd, TPM_NONCE_SIZE);
+ if (ret < 0)
+ return ret;
+
if (ret != TPM_NONCE_SIZE)
- goto out;
+ return -EIO;
+
ordinal = htonl(TPM_ORD_SEAL);
datsize = htonl(datalen);
pcrsize = htonl(pcrinfosize);
@@ -601,9 +608,12 @@ static int tpm_unseal(struct tpm_buf *tb,
ordinal = htonl(TPM_ORD_UNSEAL);
ret = tpm_get_random(chip, nonceodd, TPM_NONCE_SIZE);
+ if (ret < 0)
+ return ret;
+
if (ret != TPM_NONCE_SIZE) {
pr_info("trusted_key: tpm_get_random failed (%d)\n", ret);
- return ret;
+ return -EIO;
}
ret = TSS_authhmac(authdata1, keyauth, TPM_NONCE_SIZE,
enonce1, nonceodd, cont, sizeof(uint32_t),
@@ -1013,8 +1023,12 @@ static int trusted_instantiate(struct key *key,
case Opt_new:
key_len = payload->key_len;
ret = tpm_get_random(chip, payload->key, key_len);
+ if (ret < 0)
+ goto out;
+
if (ret != key_len) {
pr_info("trusted_key: key_create failed (%d)\n", ret);
+ ret = -EIO;
goto out;
}
if (tpm2)
--
2.25.1
Re: [PATCH v17 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP
Hi all, would you please help to review my latest patch v17, thanks very much! Best Regards, Xin
[PATCH v2 2/2] x86/resctrl: Correct MBM total and local values
Intel Memory Bandwidth Monitoring (MBM) counters may report system
memory bandwidth incorrectly on some Intel processors. The errata
SKX99 for Skylake server, BDF102 for Broadwell server, and the
correction factor table are documented in Documentation/x86/resctrl.rst.
Intel MBM counters track metrics according to the assigned Resource
Monitor ID (RMID) for that logical core. The IA32_QM_CTR register
(MSR 0xC8E), used to report these metrics, may report incorrect system
bandwidth for certain RMID values.
Due to the errata, system memory bandwidth may not match what is reported.
To work around the errata, MBM total and local readings are corrected
using the correction factor table. If rmid > rmid threshold, MBM total
and local values should be multiplied by the correction factor.
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
Change Log:
v2:
- Add "const" for mbm_cf_table[] (Boris).
- Add verbs to corrected_mbm_counter() and intel_rdt_mbm_quirk() (Boris).
- Describe the errata in the commit message (Boris).
- Fix checkpatch.pl warning on "/* FALLTHROUGH */" (Boris).
arch/x86/kernel/cpu/resctrl/core.c | 4 ++
arch/x86/kernel/cpu/resctrl/internal.h | 1 +
arch/x86/kernel/cpu/resctrl/monitor.c | 83 +-
3 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/resctrl/core.c
b/arch/x86/kernel/cpu/resctrl/core.c
index 9e1712e8aef7..b3bdc477599e 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -893,6 +893,10 @@ static __init void __check_quirks_intel(void)
set_rdt_options("!cmt,!mbmtotal,!mbmlocal,!l3cat");
else
set_rdt_options("!l3cat");
+ fallthrough;
+ case INTEL_FAM6_BROADWELL_X:
+ intel_rdt_mbm_apply_quirk();
+ break;
}
}
diff --git a/arch/x86/kernel/cpu/resctrl/internal.h
b/arch/x86/kernel/cpu/resctrl/internal.h
index 80fa997fae60..35ececc0b48b 100644
--- a/arch/x86/kernel/cpu/resctrl/internal.h
+++ b/arch/x86/kernel/cpu/resctrl/internal.h
@@ -616,6 +616,7 @@ void mon_event_read(struct rmid_read *rr, struct
rdt_resource *r,
void mbm_setup_overflow_handler(struct rdt_domain *dom,
unsigned long delay_ms);
void mbm_handle_overflow(struct work_struct *work);
+void intel_rdt_mbm_apply_quirk(void);
bool is_mba_sc(struct rdt_resource *r);
void setup_default_ctrlval(struct rdt_resource *r, u32 *dc, u32 *dm);
u32 delay_bw_map(unsigned long bw, struct rdt_resource *r);
diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c
b/arch/x86/kernel/cpu/resctrl/monitor.c
index 54dffe574e67..88e9bf96a9db 100644
--- a/arch/x86/kernel/cpu/resctrl/monitor.c
+++ b/arch/x86/kernel/cpu/resctrl/monitor.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "internal.h"
struct rmid_entry {
@@ -64,6 +65,69 @@ unsigned int rdt_mon_features;
*/
unsigned int resctrl_cqm_threshold;
+#define CF(cf) ((unsigned long)(1048576 * (cf) + 0.5))
+
+/*
+ * The correction factor table is documented in Documentation/x86/resctrl.rst.
+ * If rmid > rmid threshold, MBM total and local values should be multiplied
+ * by the correction factor.
+ *
+ * The original table is modified for better code:
+ *
+ * 1. The threshold 0 is changed to rmid count - 1 so don't do correction
+ *for the case.
+ * 2. MBM total and local correction table indexed by core counter which is
+ *equal to (x86_cache_max_rmid + 1) / 8 - 1 and is from 0 up to 27.
+ * 3. The correction factor is normalized to 2^20 (1048576) so it's faster
+ *to calculate corrected value by shifting:
+ *corrected_value = (original_value * correction_factor) >> 20
+ */
+static const struct mbm_correction_factor_table {
+ u32 rmidthreshold;
+ u64 cf;
+} mbm_cf_table[] = {
+ {7, CF(1.00)},
+ {15,CF(1.00)},
+ {15,CF(0.969650)},
+ {31,CF(1.00)},
+ {31,CF(1.07)},
+ {31,CF(0.969650)},
+ {47,CF(1.142857)},
+ {63,CF(1.00)},
+ {63,CF(1.185115)},
+ {63,CF(1.066553)},
+ {79,CF(1.454545)},
+ {95,CF(1.00)},
+ {95,CF(1.230769)},
+ {95,CF(1.142857)},
+ {95,CF(1.07)},
+ {127, CF(1.00)},
+ {127, CF(1.254863)},
+ {127, CF(1.185255)},
+ {151, CF(1.00)},
+ {127, CF(1.07)},
+ {167, CF(1.00)},
+ {159, CF(1.454334)},
+ {183, CF(1.00)},
+ {127, CF(0.969744)},
+ {191, CF(1.280246)},
+ {191, CF(1.230921)},
+ {215, CF(1.00)},
+ {191, CF(1.143118)},
+};
+
+static u32 mbm_cf_rmidthreshold = UINT_MAX;
+static u64 mbm_cf;
+
+static inline u64 get_corrected_mbm_count(u32 rmid, unsigned long val)
+{
+ /* Correct MBM value. */
+ if (rmid > mbm_cf_rmidthreshold)
+ val = (val * mbm_cf) >>
Re: [PATCHv3] selftests: rtnetlink: load fou module for kci_test_encap_fou() test
On Mon, Oct 12, 2020 at 11:28 PM Jakub Kicinski wrote: > > On Mon, 12 Oct 2020 13:56:15 +0800 Po-Hsu Lin wrote: > > Is there any update on this patch? > > You received feedback. Don't remove modules after tests, something else > could be using them. Hello Jakub, I have my feedback regarding your input [1], so I guess it's not persuasive enough? Thanks [1] https://marc.info/?l=linux-kernel=159954826414645=2
Re: [PATCH v7 4/4] MAINTAINERS: Add entry for TEE based Trusted Keys
On Wed, Oct 07, 2020 at 03:37:48PM +0530, Sumit Garg wrote: > Add MAINTAINERS entry for TEE based Trusted Keys framework. > > Signed-off-by: Sumit Garg > Acked-by: Jarkko Sakkinen > --- > MAINTAINERS | 8 > 1 file changed, 8 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 48aff80..eb3d889 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9663,6 +9663,14 @@ F: include/keys/trusted-type.h > F: include/keys/trusted_tpm.h > F: security/keys/trusted-keys/ > > +KEYS-TRUSTED-TEE > +M: Sumit Garg > +L: linux-integr...@vger.kernel.org > +L: keyri...@vger.kernel.org > +S: Supported > +F: include/keys/trusted_tee.h > +F: security/keys/trusted-keys/trusted_tee.c > + > KEYS/KEYRINGS > M: David Howells > M: Jarkko Sakkinen > -- > 2.7.4 I'm sorry but I think I have changed my mind on this. This has been spinning for a while and sometimes conclusions change over the time. I don't think that we really need a separate subsystem tag. I'd be for a new M-entry or R-entry to the existing subsystem tag. It's essential to have ack from someone with ARM and TEE knowledge but this way too heavy for the purpose. I also see it the most manageable if the trusted keys PR's come from a single source. /Jarkko
Re: [PATCH v3 3/3] KEYS: trusted: Reserve TPM for seal and unseal operations
On Mon, Oct 12, 2020 at 05:58:04PM -0700, James Bottomley wrote:
> On Tue, 2020-10-13 at 03:28 +0300, Jarkko Sakkinen wrote:
> [...]
> > diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> > index 8f4ff39f51e7..f0ebce14d2f8 100644
> > --- a/include/linux/tpm.h
> > +++ b/include/linux/tpm.h
> > @@ -397,6 +397,10 @@ static inline u32 tpm2_rc_value(u32 rc)
> > #if defined(CONFIG_TCG_TPM) || defined(CONFIG_TCG_TPM_MODULE)
> >
> > extern int tpm_is_tpm2(struct tpm_chip *chip);
> > +extern __must_check int tpm_try_get_ops(struct tpm_chip *chip);
> > +extern void tpm_put_ops(struct tpm_chip *chip);
> > +extern ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct
> > tpm_buf *buf,
> > + size_t min_rsp_body_length, const char
> > *desc);
> > extern int tpm_pcr_read(struct tpm_chip *chip, u32 pcr_idx,
> > struct tpm_digest *digest);
> > extern int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
> > @@ -410,7 +414,18 @@ static inline int tpm_is_tpm2(struct tpm_chip
> > *chip)
> > {
> > return -ENODEV;
> > }
> > -
> > +static inline int tpm_try_get_ops(struct tpm_chip *chip)
> > +{
> > + return -ENODEV;
> > +}
> > +static inline void tpm_put_ops(struct tpm_chip *chip)
> > +{
> > +}
> > +static inline ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct
> > tpm_buf *buf,
> > + size_t min_rsp_body_length,
> > const char *desc)
> > +{
> > + return -ENODEV;
> > +}
> > static inline int tpm_pcr_read(struct tpm_chip *chip, int pcr_idx,
>
> I don't think we want this, do we? That's only for API access which
> should be available when the TPM isn't selected. Given that get/put
> are TPM critical operations, they should only appear when inside code
> where the TPM has already been selected. If they appear outside TPM
> selected code, I think we want the compile to fail, which is why we
> don't want these backup definitions.
>
> James
OK, I'll change it.
Thanks.
/Jarkko
[PATCH v2 0/2] x86/resctrl: Workaround MBM errata
Intel Memory Bandwidth Monitoring (MBM) counters may report system
memory bandwidth incorrectly on some Intel processors. The errata are
reported in erratum SKX99 [1], erratum BDF102 [2] and RDT reference
manual [3].
The errata are worked around using a correction factor table. Since
the correction factor table is not publicly documented anywhere, it's
documented in Documentation/x86/resctrl.rst along with the errata.
1. Erratum SKX99 in Intel Xeon Processor Scalable Family Specification
Update:
http://web.archive.org/web/20200716124958/https://www.intel.com/content/www/us/en/processors/xeon/scalable/xeon-scalable-spec-update.html
2. Erratum BDF102 in Intel Xeon E5-2600 v4 Processor Product Family
Specification Update:
http://web.archive.org/web/20191125200531/https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e5-v4-spec-update.pdf
3. The errata in Intel Resource Director Technology (Intel RDT) on 2nd
Generation Intel Xeon Scalable Processors Reference Manual:
https://software.intel.com/content/www/us/en/develop/articles/intel-resource-director-technology-rdt-reference-manual.html
Change Log:
v2:
- Document the errata and the correction table in resctrl.rst (Boris).
- Address various comments on patch 2 (Boris).
- Change the documentation URLs to stable archive.org (Tony).
Fenghua Yu (2):
Documentation: x86: Rename resctrl_ui.rst and add two errata to the
file
x86/resctrl: Correct MBM total and local values
Documentation/conf.py | 2 +-
Documentation/x86/index.rst | 2 +-
.../x86/{resctrl_ui.rst => resctrl.rst} | 82 ++
arch/x86/kernel/cpu/resctrl/core.c| 4 +
arch/x86/kernel/cpu/resctrl/internal.h| 1 +
arch/x86/kernel/cpu/resctrl/monitor.c | 83 ++-
6 files changed, 170 insertions(+), 4 deletions(-)
rename Documentation/x86/{resctrl_ui.rst => resctrl.rst} (92%)
--
2.28.0
Re: [GIT PULL] RCU changes for v5.10
On Mon, Oct 12, 2020 at 05:14:42PM -0700, Linus Torvalds wrote: > On Mon, Oct 12, 2020 at 4:54 PM Paul E. McKenney wrote: > > > > In CONFIG_PREEMPT_NONE=y kernels, RCU has no way to tell whether or > > not its caller holds a raw spinlock, which some callers do. > > Only kfree_rcu()? (And apparently eventually call_rcu())? Yes. The other RCU APIs either only use raw spinlocks themselves on the one hand or must be called from schedulable contexts on the other. > And since we have lockdep, and it warns about it, and raw spinlocks > are really really rare, do we really need to then disable this simple > optimization for everybody else? > > We have been very successful with "don't do that then" rules. > > Eg, you cannot do normal memory allocations inside a spinlock (or you > have to mark them with GFP_ATOMIC, and not all allocations can be > marked as such), and this has been the case basically forever. And we > have debug code and tools that will check that. > > Why is it impossible to just say "you can't do kfree_rcu() while > holding a raw spinlock"? > > Particularly for something like kfree_rcu() and particularly if it's > just about raw spinlocks, it would seem to be very natural to just say > "just delay freeing it until after you've released the raw spinlock". > > Because I sure hope that you don't find raw spinlock users in random > places. It should be stuff like core scheduling, RCU itself, etc. True enough, but core stuff does use RCU, some of it while holding raw spinlocks. And you are right that "just don't do that, defer it instead" is often very effective. In fact, I defer wakeups within RCU in order to avoid deadlocks with the scheduler. It is simple in concept, and it does work, but it is also a disproportionate source of bugs. Most of which rcutorture finds in the safety and comfort of my own system, thankfully, but some do escape. Maybe I am overreacting, but I have been burned often enough that I feel the need to avoid this. Plus I did oversimplify. CONFIG_PREEMPT_COUNT also allows the call_rcu() portion to avoid deadlocks with the current non-lockless memory allocator. So if the answer from you on global CONFIG_PREEMPT_COUNT=y and from the MM guys on lockless allocation is irrevocably "@#$@#$ NO!" or the current-day bowdlerized equivalent, I will take the scheduling delays in the shorts and defer allocation. > > Making CONFIG_PREEMPT_COUNT unconditional allows > > RCU to make this determination. > > I understand _that_ part, but the thing I find objectionable is how a > small piece of code seems to want to change the rules we have had in > the kernel since basically day #1. > > (Ok, so the preempt count itself is much more recent than "day #1", > but the basic non-counting spinlocks do go back to very early in the > SMP stages). Understood, a count-free CONFIG_PREEMPT_NONE has been in place in the Linux kernel for an extremely long time. And I also understand that adding CONFIG_PREEMPT_COUNT=y everywhere is a pervasive change that is not to be taken lightly. Thanx, Paul
[PATCH v2 1/2] Documentation: x86: Rename resctrl_ui.rst and add two errata to the file
Intel Memory Bandwidth Monitoring (MBM) counters may report system
memory bandwidth incorrectly on some Intel processors. The errata are
reported in erratum SKX99 [1], erratum BDF102 [2] and RDT reference
manual [3].
To work around the errata, MBM total and local readings are corrected
using a correction factor table.
Since the correction factor table is not publicly documented anywhere,
the table and the errata are documented in Documentation/x86/resctrl.rst
for future reference. The resctrl.rst file is renamed from
Documentation/x86/resctrl_ui.rst because the file won't contain user
interface only anymore.
1. Erratum SKX99 in Intel Xeon Processor Scalable Family Specification
Update:
http://web.archive.org/web/20200716124958/https://www.intel.com/content/www/us/en/processors/xeon/scalable/xeon-scalable-spec-update.html
2. Erratum BDF102 in Intel Xeon E5-2600 v4 Processor Product Family
Specification Update:
http://web.archive.org/web/20191125200531/https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e5-v4-spec-update.pdf
3. The errata in Intel Resource Director Technology (Intel RDT) on 2nd
Generation Intel Xeon Scalable Processors Reference Manual:
https://software.intel.com/content/www/us/en/develop/articles/intel-resource-director-technology-rdt-reference-manual.html
Suggested-by: Borislav Petkov
Signed-off-by: Fenghua Yu
---
Change Log:
v2:
- Document the correction factor table and errata in resctrl.rst (Boris).
- Change the documentation URLs to stable archive.org (Tony).
Documentation/conf.py | 2 +-
Documentation/x86/index.rst | 2 +-
.../x86/{resctrl_ui.rst => resctrl.rst} | 82 +++
3 files changed, 84 insertions(+), 2 deletions(-)
rename Documentation/x86/{resctrl_ui.rst => resctrl.rst} (92%)
diff --git a/Documentation/conf.py b/Documentation/conf.py
index c50310d9..b5b2be8eec22 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -36,7 +36,7 @@ needs_sphinx = '1.3'
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
-extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain',
+extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
'kfigure', 'sphinx.ext.ifconfig', 'automarkup',
'maintainers_include', 'sphinx.ext.autosectionlabel' ]
diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
index 265d9e9a093b..49d2fd9f0e5b 100644
--- a/Documentation/x86/index.rst
+++ b/Documentation/x86/index.rst
@@ -25,7 +25,7 @@ x86-specific Documentation
pti
mds
microcode
- resctrl_ui
+ resctrl
tsx_async_abort
usb-legacy-support
i386/index
diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl.rst
similarity index 92%
rename from Documentation/x86/resctrl_ui.rst
rename to Documentation/x86/resctrl.rst
index e59b7b93a9b4..8b8ca6de5e1f 100644
--- a/Documentation/x86/resctrl_ui.rst
+++ b/Documentation/x86/resctrl.rst
@@ -1209,3 +1209,85 @@ View the llc occupancy snapshot::
# cat /sys/fs/resctrl/p1/mon_data/mon_L3_00/llc_occupancy
11234000
+
+Intel RDT Errata
+
+
+Intel MBM Counters May Report System Memory Bandwidth Incorrectly
+-
+
+Errata SKX99 for Skylake server and BDF102 for Broadwell server.
+
+Problem: Intel Memory Bandwidth Monitoring (MBM) counters track metrics
+according to the assigned Resource Monitor ID (RMID) for that logical core.
+The IA32_QM_CTR register(MSR 0xC8E), used to report these metrics, may
+report incorrect system bandwidth for certain RMID values.
+
+Implication: Due to the errata, system memory bandwidth may not match
+what is reported.
+
+Workaround: The kernel works around the errata.
+
+MBM total and local readings are corrected by the following correction
+factor table for the errata:
+
++---+---+---+-+
+|core count|rmid count |rmid threshold |correction factor|
++---+---+---+-+
+|1 |8 |0 |1.00 |
++---+---+---+-+
+|2 |16 |0 |1.00 |
++---+---+---+-+
+|3 |24 |15 |0.969650 |
++---+---+---+-+
+|4 |32 |0 |1.00 |
++---+---+---+-+
+|6 |48 |31 |0.969650 |
++---+---+---+-+
+|7 |56 |47 |1.142857 |
Re: [PATCH 00/35] Enhance memory utilization with DMEMFS
On Mon, Oct 12, 2020 at 7:57 PM Zengtao (B) wrote: > > > > -Original Message- > > From: yulei.ker...@gmail.com [mailto:yulei.ker...@gmail.com] > > Sent: Thursday, October 08, 2020 3:54 PM > > To: a...@linux-foundation.org; naoya.horigu...@nec.com; > > v...@zeniv.linux.org.uk; pbonz...@redhat.com > > Cc: linux-fsde...@vger.kernel.org; k...@vger.kernel.org; > > linux-kernel@vger.kernel.org; xiaoguangrong.e...@gmail.com; > > kernel...@gmail.com; lihaiwei.ker...@gmail.com; Yulei Zhang > > Subject: [PATCH 00/35] Enhance memory utilization with DMEMFS > > > > From: Yulei Zhang > > > > In current system each physical memory page is assocaited with > > a page structure which is used to track the usage of this page. > > But due to the memory usage rapidly growing in cloud environment, > > we find the resource consuming for page structure storage becomes > > highly remarkable. So is it an expense that we could spare? > > > > This patchset introduces an idea about how to save the extra > > memory through a new virtual filesystem -- dmemfs. > > > > Dmemfs (Direct Memory filesystem) is device memory or reserved > > memory based filesystem. This kind of memory is special as it > > is not managed by kernel and most important it is without 'struct page'. > > Therefore we can leverage the extra memory from the host system > > to support more tenants in our cloud service. > > > > We uses a kernel boot parameter 'dmem=' to reserve the system > > memory when the host system boots up, the details can be checked > > in /Documentation/admin-guide/kernel-parameters.txt. > > > > Theoretically for each 4k physical page it can save 64 bytes if > > we drop the 'struct page', so for guest memory with 320G it can > > save about 5G physical memory totally. > > Sounds interesting, but seems your patch only support x86, have you > considered aarch64? > > Regards > Zengtao Thanks, so far we only verify it on x86 server, may extend to arm platform in the future.
Re: [PATCH v4 04/17] x86/acrn: Introduce hypercall interfaces
On Mon 12.Oct'20 at 12:49:16 -0400, Arvind Sankar wrote:
On Mon, Oct 12, 2020 at 04:44:31PM +0800, Shuo A Liu wrote:
On Wed 30.Sep'20 at 12:14:03 -0700, Nick Desaulniers wrote:
>On Wed, Sep 30, 2020 at 10:13 AM Peter Zijlstra wrote:
>>
>> On Wed, Sep 30, 2020 at 11:10:36AM -0500, Segher Boessenkool wrote:
>>
>> > Since this variable is a local register asm, on entry to the asm the
>> > compiler guarantees that the value lives in the assigned register (the
>> > "r8" hardware register in this case). This all works completely fine.
>> > This is the only guaranteed behaviour for local register asm (well,
>> > together with analogous behaviour for outputs).
>>
>> Right, that's what they're trying to achieve. The hypervisor calling
>> convention needs that variable in %r8 (which is somewhat unfortunate).
>>
>> AFAIK this is the first such use in the kernel, but at least the gcc-4.9
>> (our oldest supported version) claims to support this.
>>
>> So now we need to know if clang will actually do this too..
>
>Does clang support register local storage? Let's use godbolt.org to find out:
>https://godbolt.org/z/YM45W5
>Looks like yes. You can even check different GCC versions via the
>dropdown in the top right.
>
>The -ffixed-* flags are less well supported in Clang; they need to be
>reimplemented on a per-backend basis. aarch64 is relatively well
>supported, but other arches not so much IME.
>
>Do we need register local storage here?
>
>static inline long bar(unsigned long hcall_id)
>{
> long result;
> asm volatile("movl %1, %%r8d\n\t"
> "vmcall\n\t"
>: "=a" (result)
>: "ir" (hcall_id)
>: );
> return result;
>}
Yeah, this approach is also mentioned in the changelog. I will change to
this way to follow your preference. With an addtional "r8" clobber what
Arvind mentioned.
Thanks
shuo
Btw, I noticed that arch/x86/xen/hypercall.h uses register-local
variables already for its hypercalls for quite some time, so this
wouldn't be unprecedented. [0]
Do these calls also need a memory clobber? The KVM/xen hypercall functions
all have one.
Yes. it's needed. I will add it. Thanks
Thanks.
[0] e74359028d548 ("xen64: fix calls into hypercall page")
Re: [PATCH] ASoC: fsl_spdif: Add support for higher sample rates
On Tue, Oct 13, 2020 at 3:09 AM Nicolin Chen wrote: > > Hi Shengjiu, > > On Mon, Oct 12, 2020 at 04:49:42PM +0800, Shengjiu Wang wrote: > > Add 88200Hz and 176400Hz sample rates support for TX. > > Add 88200Hz, 176400Hz, 192000Hz sample rates support for RX. > > > > Signed-off-by: Shengjiu Wang > > Signed-off-by: Viorel Suman > > Probably should put your own Signed-off at the bottom? will update in v2. > > Anyway: > Acked-by: Nicolin Chen
[PATCH] thunderbolt: Add the missed ida_simple_remove() in ring_request_msix()
ring_request_msix() misses to call ida_simple_remove() in an error path.
Add the missed function call to fix it.
Fixes: 046bee1f9ab8 ("thunderbolt: Add MSI-X support")
Signed-off-by: Jing Xiangfeng
---
drivers/thunderbolt/nhi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
index 5f7489fa1327..7732e7a9942f 100644
--- a/drivers/thunderbolt/nhi.c
+++ b/drivers/thunderbolt/nhi.c
@@ -406,8 +406,10 @@ static int ring_request_msix(struct tb_ring *ring, bool
no_suspend)
ring->vector = ret;
ring->irq = pci_irq_vector(ring->nhi->pdev, ring->vector);
- if (ring->irq < 0)
+ if (ring->irq < 0) {
+ ida_simple_remove(>msix_ida, ret);
return ring->irq;
+ }
irqflags = no_suspend ? IRQF_NO_SUSPEND : 0;
return request_irq(ring->irq, ring_msix, irqflags, "thunderbolt", ring);
--
2.17.1
Re: [PATCH 00/13] mm: clean up some lru related pieces
On Fri, 18 Sep 2020, Hugh Dickins wrote: > On Fri, 18 Sep 2020, Yu Zhao wrote: > > On Fri, Sep 18, 2020 at 01:46:59PM -0700, Hugh Dickins wrote: > > > On Thu, 17 Sep 2020, Yu Zhao wrote: > > > > > > > Hi Andrew, > > > > > > > > I see you have taken this: > > > > mm: use add_page_to_lru_list()/page_lru()/page_off_lru() > > > > Do you mind dropping it? > > > > > > > > Michal asked to do a bit of additional work. So I thought I probably > > > > should create a series to do more cleanups I've been meaning to. > > > > > > > > This series contains the change in the patch above and goes a few > > > > more steps farther. It's intended to improve readability and should > > > > not have any performance impacts. There are minor behavior changes in > > > > terms of debugging and error reporting, which I have all highlighted > > > > in the individual patches. All patches were properly tested on 5.8 > > > > running Chrome OS, with various debug options turned on. > > > > > > > > Michal, > > > > > > > > Do you mind taking a looking at the entire series? > > > > > > > > Thank you. > > > > > > > > Yu Zhao (13): > > > > mm: use add_page_to_lru_list() > > > > mm: use page_off_lru() > > > > mm: move __ClearPageLRU() into page_off_lru() > > > > mm: shuffle lru list addition and deletion functions > > > > mm: don't pass enum lru_list to lru list addition functions > > > > mm: don't pass enum lru_list to trace_mm_lru_insertion() > > > > mm: don't pass enum lru_list to del_page_from_lru_list() > > > > mm: rename page_off_lru() to __clear_page_lru_flags() > > > > mm: inline page_lru_base_type() > > > > mm: VM_BUG_ON lru page flags > > > > mm: inline __update_lru_size() > > > > mm: make lruvec_lru_size() static > > > > mm: enlarge the int parameter of update_lru_size() > > > > > > > > include/linux/memcontrol.h | 14 ++-- > > > > include/linux/mm_inline.h | 115 ++--- > > > > include/linux/mmzone.h | 2 - > > > > include/linux/vmstat.h | 2 +- > > > > include/trace/events/pagemap.h | 11 ++-- > > > > mm/compaction.c| 2 +- > > > > mm/memcontrol.c| 10 +-- > > > > mm/mlock.c | 2 +- > > > > mm/swap.c | 53 ++- > > > > mm/vmscan.c| 28 +++- > > > > 10 files changed, 95 insertions(+), 144 deletions(-) > > > > > > > > -- > > > > 2.28.0.681.g6f77f65b4e-goog > > > > > > Sorry, Yu, I may be out-of-line in sending this: but as you know, > > > Alex Shi has a long per-memcg lru_lock series playing in much the > > > same area (particularly conflicting in mm/swap.c and mm/vmscan.c): > > > a patchset that makes useful changes, that I'm very keen to help > > > into mmotm a.s.a.p (but not before I've completed diligence). > > > > > > We've put a lot of effort into its testing, I'm currently reviewing > > > it patch by patch (my general silence indicating that I'm busy on that, > > > but slow as ever): so I'm a bit discouraged to have its stability > > > potentially undermined by conflicting cleanups at this stage. > > > > > > If there's general agreement that your cleanups are safe and welcome > > > (Michal's initial reaction sheds some doubt on that), great: I hope > > > that Andrew can fast-track them into mmotm, then Alex rebase on top > > > of them, and I then re-test and re-review. > > > > > > But if that quick agreement is not forthcoming, may I ask you please > > > to hold back, and resend based on top of Alex's next posting? > > > > The per-memcg lru lock series seems a high priority, and I have > > absolutely no problem accommodate your request. > > Many thanks! > > > > > In return, may I ask you or Alex to review this series after you > > have finished with per-memcg lru lock (to make sure that I resolve > > all the conflicts correctly at least)? > > Fair enough: I promise to do so. > > And your rebasing will necessarily lead you to review some parts > of Alex's patchset, which will help us all too. > > Andrew, Yu asked at the start: > > > > I see you have taken this: > > > > mm: use add_page_to_lru_list()/page_lru()/page_off_lru() > > > > Do you mind dropping it? > Dropping that for now will help too. Andrew, please drop Yu Zhao's mm-use-add_page_to_lru_list-page_lru-page_off_lru.patch from the mmotm tree. Yu wants to replace it by this cleanup series, and he has graciously agreed to rebase his series on top of Alex Shi's per-memcg lru_lock series; but mm-use-add_page_to_lru_list-page_lru-page_off_lru.patch is getting in the way of adding them to mmotm. The three of us are all hoping that Alex's v19 series can go into mmotm when the merge window closes, then I'll review Yu's series rebased on top of it. Thanks, Hugh
Re: [f2fs-dev] [f2fs bug] infinite loop in f2fs_get_meta_page_nofail()
Jaegeuk, I guess you missed sending last applied patch to mailing list? Thanks, On 2020/10/9 22:56, jaeg...@kernel.org wrote: On 10/09, Chao Yu wrote: On 2020/10/9 12:32, jaeg...@kernel.org wrote: On 10/09, Chao Yu wrote: On 2020/10/9 9:50, jaeg...@kernel.org wrote: On 10/09, Chao Yu wrote: On 2020/10/8 5:53, jaeg...@kernel.org wrote: On 10/07, Eric Biggers wrote: [moved linux-fsdevel to Bcc] On Wed, Oct 07, 2020 at 02:18:19AM -0700, syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:a804ab08 Add linux-next specific files for 20201006 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=17fe30bf90 kernel config: https://syzkaller.appspot.com/x/.config?x=26c1b4cc4a62ccb dashboard link: https://syzkaller.appspot.com/bug?extid=ee250ac8137be41d7b13 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1336413b90 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12f7392b90 The issue was bisected to: commit eede846af512572b1f30b34f9889d7df64c017d4 Author: Jaegeuk Kim Date: Fri Oct 2 21:17:35 2020 + f2fs: f2fs_get_meta_page_nofail should not be failed Jaegeuk, it looks like the loop you added in the above commit doesn't terminate if the requested page is beyond the end of the device. Yes, that will go infinite loop. Otherwise, it will trigger a panic during the device reboot. Let me think how to avoid that before trying to get the wrong lba access. Delivering f2fs_get_sum_page()'s return value needs a lot of codes change, I think we can just zeroing sum_page in error case, as we have already shutdown f2fs via calling f2fs_stop_checkpoint(), then f2fs_cp_error() will stop all updates to filesystem data including summary pages. That sounds like one solution tho, I'm afraid of getting another panic by wrong zero'ed summary page. What case do you mean? maybe I missed some corner cases? I sent v2 to fix syzbot issue, which fixes wrong use of f2fs_get_meta_page_nofail. I agreed to fix that case, however we may encounter deadloop in other places where we call f2fs_get_meta_page_nofail()? like the case that filesystem will always see EIO after we shutdown device via dmflakey? We may need another option to deal with this. At least, however, it's literally _nofail function which should guarantee no error, instead of hiding the error with zero'ed page. Thanks, Thanks, Thoughts? Thanks, - Eric ___ Linux-f2fs-devel mailing list linux-f2fs-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel . . . .
Re: [PATCH 1/2] f2fs: add F2FS_IOC_GET_COMPRESS_OPTION ioctl
On 10/12/20 7:24 PM, Daeho Jeong wrote: > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h > index 53fe2853579c..a33c90cf979b 100644 > --- a/fs/f2fs/f2fs.h > +++ b/fs/f2fs/f2fs.h > @@ -433,6 +433,8 @@ static inline bool __has_cursum_space(struct f2fs_journal > *journal, > _IOR(F2FS_IOCTL_MAGIC, 19, __u64) > #define F2FS_IOC_SEC_TRIM_FILE _IOW(F2FS_IOCTL_MAGIC, 20, > \ > struct f2fs_sectrim_range) > +#define F2FS_IOC_GET_COMPRESS_OPTION _IOR(F2FS_IOCTL_MAGIC, 21, \ > + struct f2fs_comp_option) Hi, F2FS_IOCTL_MAGIC should be listed in Documentation/userspace-api/ioctl/ioctl-number.rst. Please add it there. thanks. -- ~Randy
[PATCH 2/2] f2fs: add F2FS_IOC_SET_COMPRESS_OPTION ioctl
From: Daeho Jeong
Added a new F2FS_IOC_SET_COMPRESS_OPTION ioctl to change file
compression option of a file.
Signed-off-by: Daeho Jeong
---
fs/f2fs/f2fs.h | 2 ++
fs/f2fs/file.c | 56 ++
2 files changed, 58 insertions(+)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index a33c90cf979b..5ee8a4859b62 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -435,6 +435,8 @@ static inline bool __has_cursum_space(struct f2fs_journal
*journal,
struct f2fs_sectrim_range)
#define F2FS_IOC_GET_COMPRESS_OPTION _IOR(F2FS_IOCTL_MAGIC, 21, \
struct f2fs_comp_option)
+#define F2FS_IOC_SET_COMPRESS_OPTION _IOW(F2FS_IOCTL_MAGIC, 22, \
+ struct f2fs_comp_option)
/*
* should be same as XFS_IOC_GOINGDOWN.
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 7e64259f6f5e..6c265c66ddd4 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -3963,6 +3963,59 @@ static int f2fs_ioc_get_compress_option(struct file
*filp, unsigned long arg)
return 0;
}
+static int f2fs_ioc_set_compress_option(struct file *filp, unsigned long arg)
+{
+ struct inode *inode = file_inode(filp);
+ struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+ struct f2fs_comp_option option;
+ int ret;
+ int writecount;
+
+ if (!f2fs_sb_has_compression(sbi))
+ return -EOPNOTSUPP;
+
+ if (!f2fs_compressed_file(inode) || IS_IMMUTABLE(inode))
+ return -EINVAL;
+
+ if (f2fs_readonly(sbi->sb))
+ return -EROFS;
+
+ if (copy_from_user(, (struct f2fs_comp_option __user *)arg,
+ sizeof(option)))
+ return -EFAULT;
+
+ if (option.log_cluster_size < MIN_COMPRESS_LOG_SIZE ||
+ option.log_cluster_size > MAX_COMPRESS_LOG_SIZE ||
+ option.algorithm >= COMPRESS_MAX)
+ return -EINVAL;
+
+ ret = mnt_want_write_file(filp);
+ if (ret)
+ return ret;
+
+ inode_lock(inode);
+
+ writecount = atomic_read(>i_writecount);
+ if ((filp->f_mode & FMODE_WRITE && writecount != 1) ||
+ (!(filp->f_mode & FMODE_WRITE) && writecount)) {
+ ret = -EBUSY;
+ goto out;
+ }
+
+ if (get_dirty_pages(inode) || inode->i_size) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ F2FS_I(inode)->i_compress_algorithm = option.algorithm;
+ F2FS_I(inode)->i_log_cluster_size = option.log_cluster_size;
+ F2FS_I(inode)->i_cluster_size = 1 << option.log_cluster_size;
+ f2fs_mark_inode_dirty_sync(inode, true);
+out:
+ inode_unlock(inode);
+ return ret;
+}
+
long f2fs_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
if (unlikely(f2fs_cp_error(F2FS_I_SB(file_inode(filp)
@@ -4053,6 +4106,8 @@ long f2fs_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
return f2fs_sec_trim_file(filp, arg);
case F2FS_IOC_GET_COMPRESS_OPTION:
return f2fs_ioc_get_compress_option(filp, arg);
+ case F2FS_IOC_SET_COMPRESS_OPTION:
+ return f2fs_ioc_set_compress_option(filp, arg);
default:
return -ENOTTY;
}
@@ -4224,6 +4279,7 @@ long f2fs_compat_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
case F2FS_IOC_RESERVE_COMPRESS_BLOCKS:
case F2FS_IOC_SEC_TRIM_FILE:
case F2FS_IOC_GET_COMPRESS_OPTION:
+ case F2FS_IOC_SET_COMPRESS_OPTION:
break;
default:
return -ENOIOCTLCMD;
--
2.28.0.1011.ga647a8990f-goog
[PATCH 1/2] f2fs: add F2FS_IOC_GET_COMPRESS_OPTION ioctl
From: Daeho Jeong
Added a new F2FS_IOC_GET_COMPRESS_OPTION ioctl to get file compression
option of a file.
Signed-off-by: Daeho Jeong
---
fs/f2fs/f2fs.h | 7 +++
fs/f2fs/file.c | 30 ++
2 files changed, 37 insertions(+)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 53fe2853579c..a33c90cf979b 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -433,6 +433,8 @@ static inline bool __has_cursum_space(struct f2fs_journal
*journal,
_IOR(F2FS_IOCTL_MAGIC, 19, __u64)
#define F2FS_IOC_SEC_TRIM_FILE _IOW(F2FS_IOCTL_MAGIC, 20, \
struct f2fs_sectrim_range)
+#define F2FS_IOC_GET_COMPRESS_OPTION _IOR(F2FS_IOCTL_MAGIC, 21, \
+ struct f2fs_comp_option)
/*
* should be same as XFS_IOC_GOINGDOWN.
@@ -481,6 +483,11 @@ struct f2fs_sectrim_range {
u64 flags;
};
+struct f2fs_comp_option {
+ u8 algorithm;
+ u8 log_cluster_size;
+};
+
/* for inline stuff */
#define DEF_INLINE_RESERVED_SIZE 1
static inline int get_extra_isize(struct inode *inode);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index ef5a844de53f..7e64259f6f5e 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -3936,6 +3936,33 @@ static int f2fs_sec_trim_file(struct file *filp,
unsigned long arg)
return ret;
}
+static int f2fs_ioc_get_compress_option(struct file *filp, unsigned long arg)
+{
+ struct inode *inode = file_inode(filp);
+ struct f2fs_comp_option option;
+
+ if (!f2fs_sb_has_compression(F2FS_I_SB(inode)))
+ return -EOPNOTSUPP;
+
+ inode_lock(inode);
+
+ if (!f2fs_compressed_file(inode)) {
+ inode_unlock(inode);
+ return -EINVAL;
+ }
+
+ option.algorithm = F2FS_I(inode)->i_compress_algorithm;
+ option.log_cluster_size = F2FS_I(inode)->i_log_cluster_size;
+
+ inode_unlock(inode);
+
+ if (copy_to_user((struct f2fs_comp_option __user *)arg, ,
+ sizeof(option)))
+ return -EFAULT;
+
+ return 0;
+}
+
long f2fs_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
if (unlikely(f2fs_cp_error(F2FS_I_SB(file_inode(filp)
@@ -4024,6 +4051,8 @@ long f2fs_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
return f2fs_reserve_compress_blocks(filp, arg);
case F2FS_IOC_SEC_TRIM_FILE:
return f2fs_sec_trim_file(filp, arg);
+ case F2FS_IOC_GET_COMPRESS_OPTION:
+ return f2fs_ioc_get_compress_option(filp, arg);
default:
return -ENOTTY;
}
@@ -4194,6 +4223,7 @@ long f2fs_compat_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
case F2FS_IOC_RELEASE_COMPRESS_BLOCKS:
case F2FS_IOC_RESERVE_COMPRESS_BLOCKS:
case F2FS_IOC_SEC_TRIM_FILE:
+ case F2FS_IOC_GET_COMPRESS_OPTION:
break;
default:
return -ENOIOCTLCMD;
--
2.28.0.1011.ga647a8990f-goog
[PATCH 0/2] net: dsa: mv88e6xxx: serdes link without phy
This small series gets my hardware into a working state. The key points are to make sure we don't force the link and that we ask the MAC for the link status. I also have updated my dts to say `phy-mode = "1000base-x";` and `managed = "in-band-status";` Chris Packham (2): net: dsa: mv88e6xxx: Don't force link when using in-band-status net: dsa: mv88e6xxx: Support serdes ports on MV88E6097 drivers/net/dsa/mv88e6xxx/chip.c | 68 +++- 1 file changed, 66 insertions(+), 2 deletions(-) -- 2.28.0
[PATCH 1/2] net: dsa: mv88e6xxx: Don't force link when using in-band-status
When a port is configured with 'managed = "in-band-status"' don't force
the link up, the switch MAC will detect the link status correctly.
Signed-off-by: Chris Packham
---
drivers/net/dsa/mv88e6xxx/chip.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index f0dbc05e30a4..1ef392ee52c5 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -767,8 +767,11 @@ static void mv88e6xxx_mac_link_up(struct dsa_switch *ds,
int port,
goto error;
}
- if (ops->port_set_link)
- err = ops->port_set_link(chip, port, LINK_FORCED_UP);
+ if (ops->port_set_link) {
+ int link = mode == MLO_AN_INBAND ? LINK_UNFORCED :
LINK_FORCED_UP;
+
+ err = ops->port_set_link(chip, port, link);
+ }
}
error:
mv88e6xxx_reg_unlock(chip);
--
2.28.0
[PATCH 2/2] net: dsa: mv88e6xxx: Support serdes ports on MV88E6097
Implement serdes_power, serdes_get_lane and serdes_pcs_get_state ops for
the MV88E6097 so that ports 8 & 9 can be supported as serdes ports and
directly connected to other network interfaces or to SFPs without a PHY.
Signed-off-by: Chris Packham
---
This should be usable for all variants of the 88E6185 that have
tri-speed capable ports (which is why I used the mv88e6185 prefix
instead of mv88e6097). But my hardware only has a 88e6097 so I've only
connected up the ops for that chip.
drivers/net/dsa/mv88e6xxx/chip.c | 61
1 file changed, 61 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 1ef392ee52c5..1c6cd5c43eb1 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3436,6 +3436,64 @@ static int mv88e6xxx_set_eeprom(struct dsa_switch *ds,
return err;
}
+static int mv88e6185_serdes_power(struct mv88e6xxx_chip *chip, int port, u8
lane,
+ bool up)
+{
+ /* The serdes power can't be controlled on this switch chip but we need
+* to supply this function to avoid returning -EOPNOTSUPP in
+* mv88e6xxx_serdes_power_up/mv88e6xxx_serdes_power_down
+*/
+ return 0;
+}
+
+static u8 mv88e6185_serdes_get_lane(struct mv88e6xxx_chip *chip, int port)
+{
+ switch (chip->ports[port].cmode) {
+ case MV88E6185_PORT_STS_CMODE_SERDES:
+ case MV88E6185_PORT_STS_CMODE_1000BASE_X:
+ return port;
+ default:
+ return 0;
+ }
+}
+
+static int mv88e6185_serdes_pcs_get_state(struct mv88e6xxx_chip *chip, int
port,
+ u8 lane, struct phylink_link_state
*state)
+{
+ int err;
+ u16 status;
+
+ err = mv88e6xxx_port_read(chip, port, MV88E6XXX_PORT_STS, );
+ if (err)
+ return err;
+
+ state->link = !!(status & MV88E6XXX_PORT_STS_LINK);
+
+ if (state->link) {
+ state->duplex = status & MV88E6XXX_PORT_STS_DUPLEX ?
DUPLEX_FULL : DUPLEX_HALF;
+
+ switch (status & MV88E6XXX_PORT_STS_SPEED_MASK) {
+ case MV88E6XXX_PORT_STS_SPEED_1000:
+ state->speed = SPEED_1000;
+ break;
+ case MV88E6XXX_PORT_STS_SPEED_100:
+ state->speed = SPEED_100;
+ break;
+ case MV88E6XXX_PORT_STS_SPEED_10:
+ state->speed = SPEED_10;
+ break;
+ default:
+ dev_err(chip->dev, "invalid PHY speed\n");
+ return -EINVAL;
+ }
+ } else {
+ state->duplex = DUPLEX_UNKNOWN;
+ state->speed = SPEED_UNKNOWN;
+ }
+
+ return 0;
+}
+
static const struct mv88e6xxx_ops mv88e6085_ops = {
/* MV88E6XXX_FAMILY_6097 */
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
@@ -3534,6 +3592,9 @@ static const struct mv88e6xxx_ops mv88e6097_ops = {
.set_egress_port = mv88e6095_g1_set_egress_port,
.watchdog_ops = _watchdog_ops,
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
+ .serdes_power = mv88e6185_serdes_power,
+ .serdes_get_lane = mv88e6185_serdes_get_lane,
+ .serdes_pcs_get_state = mv88e6185_serdes_pcs_get_state,
.pot_clear = mv88e6xxx_g2_pot_clear,
.reset = mv88e6352_g1_reset,
.rmu_disable = mv88e6085_g1_rmu_disable,
--
2.28.0
Re: [PATCH v5 1/5] counter: Internalize sysfs interface code
On 9/26/20 9:18 PM, William Breathitt Gray wrote:
This is a reimplementation of the Generic Counter driver interface.
I'll follow up if I find any problems while testing but here are some
comments I had from looking over the patch.
diff --git a/drivers/counter/counter-core.c b/drivers/counter/counter-core.c
new file mode 100644
index ..987c6e8277eb
--- /dev/null
+++ b/drivers/counter/counter-core.c
+/**
+ * counter_register - register Counter to the system
+ * @counter: pointer to Counter to register
+ *
+ * This function registers a Counter to the system. A sysfs "counter" directory
+ * will be created and populated with sysfs attributes correlating with the
+ * Counter Signals, Synapses, and Counts respectively.
+ */
+int counter_register(struct counter_device *const counter)
+{
+ struct device *const dev = >dev;
+ int err;
+
+ /* Acquire unique ID */
+ counter->id = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
+ if (counter->id < 0)
+ return counter->id;
+
+ /* Configure device structure for Counter */
+ dev->type = _device_type;
+ dev->bus = _bus_type;
+ if (counter->parent) {
+ dev->parent = counter->parent;
+ dev->of_node = counter->parent->of_node;
+ }
+ dev_set_name(dev, "counter%d", counter->id);
+ device_initialize(dev);> + dev_set_drvdata(dev, counter);
+
+ /* Add Counter sysfs attributes */
+ err = counter_sysfs_add(counter);
+ if (err)
+ goto err_free_id;
+
+ /* Add device to system */
+ err = device_add(dev);
+ if (err) {
+ put_device(dev);
+ goto err_free_id;
+ }
+
+ return 0;
+
+err_free_id:
+ /* get_device/put_device combo used to free managed resources */
+ get_device(dev);
+ put_device(dev);
I've never seen this in a driver before, so it makes me think this is
not the "right way" to do this. After device_initialize() is called, we
already should have a reference to dev, so only device_put() is needed.
+ ida_simple_remove(_ida, counter->id);
In the case of error after device_initialize() is called, won't this
result in ida_simple_remove() being called twice, once here and once in
the release callback?
+ return err;
+}
+EXPORT_SYMBOL_GPL(counter_register);
+
+/**
+ * counter_unregister - unregister Counter from the system
+ * @counter: pointer to Counter to unregister
+ *
+ * The Counter is unregistered from the system; all allocated memory is freed.
+ */
+void counter_unregister(struct counter_device *const counter)
+{
+ if (!counter)
+ return;
+
+ device_unregister(>dev);
+}
+EXPORT_SYMBOL_GPL(counter_unregister);
+
+static void devm_counter_unreg(struct device *dev, void *res)
To be consistent, it would be nice to spell out unregister.
+{
+ counter_unregister(*(struct counter_device **)res);
+}
+
diff --git a/drivers/counter/counter-sysfs.c b/drivers/counter/counter-sysfs.c
new file mode 100644
index ..e66ed99dd5ea
--- /dev/null
+++ b/drivers/counter/counter-sysfs.c
+/**
+ * counter_sysfs_add - Adds Counter sysfs attributes to the device structure
+ * @counter: Pointer to the Counter device structure
+ *
+ * Counter sysfs attributes are created and added to the respective device
+ * structure for later registration to the system. Resource-managed memory
+ * allocation is performed by this function, and this memory should be freed
+ * when no longer needed (automatically by a device_unregister call, or
+ * manually by a devres_release_all call).
+ */
+int counter_sysfs_add(struct counter_device *const counter)
+{
+ struct device *const dev = >dev;
+ const size_t num_groups = counter->num_signals + counter->num_counts +
+ 1;
It is OK to go past 80 columns, especially for just for a few characters.
+ struct counter_attribute_group *groups;
+ size_t i, j;
+ int err;
+ struct attribute_group *group;
+ struct counter_attribute *p;
+
+ /* Allocate space for attribute groups (signals, counts, and ext) */
+ groups = devm_kcalloc(dev, num_groups, sizeof(*groups), GFP_KERNEL);
+ if (!groups)
+ return -ENOMEM;
+
+ /* Initialize attribute lists */
+ for (i = 0; i < num_groups; i++)
+ INIT_LIST_HEAD([i].attr_list);
+
+ /* Register Counter device attributes */
+ err = counter_device_register(counter, groups);
This function name is a bit misleading. At first I though we were registering
a new counter device (struct device). Maybe counter_sysfs_create_attrs()
would be a better name? (I wouldn't mind having all functions in this
file having a "counter_sysfs_" prefix for that matter.)
diff --git a/drivers/counter/ti-eqep.c b/drivers/counter/ti-eqep.c
index 1ff07faef27f..938085dead80 100644
--- a/drivers/counter/ti-eqep.c
+++
[PATCH] mailbox: qcom-apcs-ipc: use PLATFORM_DEVID_AUTO to register device
On MSM8916, only one qcom-apcs-msm8916-clk device is needed, as there is
only one APCS clock. However, on MSM8939 three APCS clocks need to be
registered for cluster0 (little cores), cluster1 (big cores) and CCI
(Cache Coherent Interconnect). That said, we will need to register 3
qcom-apcs-msm8916-clk devices. Let's use PLATFORM_DEVID_AUTO rather
than PLATFORM_DEVID_NONE for platform_device_register_data() call.
Otherwise, the second APCS clock registration will fail due to duplicate
device name.
[0.519657] sysfs: cannot create duplicate filename
'/bus/platform/devices/qcom-apcs-msm8916-clk'
...
[0.661158] qcom_apcs_ipc b111000.mailbox: failed to register APCS clk
Signed-off-by: Shawn Guo
---
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c
b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
index 077e5c6a9ef7..3d100a004760 100644
--- a/drivers/mailbox/qcom-apcs-ipc-mailbox.c
+++ b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
@@ -128,7 +128,7 @@ static int qcom_apcs_ipc_probe(struct platform_device *pdev)
if (apcs_data->clk_name) {
apcs->clk = platform_device_register_data(>dev,
apcs_data->clk_name,
- PLATFORM_DEVID_NONE,
+ PLATFORM_DEVID_AUTO,
NULL, 0);
if (IS_ERR(apcs->clk))
dev_err(>dev, "failed to register APCS clk\n");
--
2.17.1
[PATCH] mips: ralink: enable zboot support
Some of these ralink devices come with an ancient u-boot which can't extract LZMA properly when image gets too big. Enable zboot support to get a self-extracting kernel instead of relying on broken u-boot support. Signed-off-by: Chuanhong Guo --- arch/mips/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index f52fa211a4cf..534ecff2e2c5 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -618,6 +618,7 @@ config RALINK select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN select SYS_SUPPORTS_MIPS16 + select SYS_SUPPORTS_ZBOOT select SYS_HAS_EARLY_PRINTK select CLKDEV_LOOKUP select ARCH_HAS_RESET_CONTROLLER -- 2.26.2
RE: [PATCH V2 4/4] misc: vop: mapping kernel memory to user space as noncached
Hi David, thanks for your information. Hi Christoph, please see my comments below. > Subject: RE: [PATCH V2 4/4] misc: vop: mapping kernel memory to user space > as noncached > > From: Christoph Hellwig > > Sent: 29 September 2020 11:29 > ... > > You can't call remap_pfn_range on memory returned from > > dma_alloc_coherent (which btw is not marked uncached on many > platforms). > > > > You need to use the dma_mmap_coherent helper instead. > I tried to use dma_mmap_coherent helper here, but I met the same problem as David said. Since the user space calls mmap() to map all the device page and vring size at one time. va = mmap(NULL, MIC_DEVICE_PAGE_END + vr_size * num_vq, PROT_READ, MAP_SHARED, fd, 0); But the physical addresses of device page and multiple vrings are not consecutive, so we called multiple remap_pfn_range before. When changing to use dma_mmap_coherent, it will return error because vma_pages(the size user space want to map) are bigger than the actual size we do multiple map(one non-continuous memory size at a time). David believes that we could modify the vm_start address before call the multiple dma_mmap_coherent to avoid the vma_pages check error and map multiple discontinuous memory. Do you have any suggestions? Best regards Sherry > H. I've a driver that does that. > Fortunately it only has to work on x86 where it doesn't matter. > However I can't easily convert it. > The 'problem' is that the mmap() request can cover multiple dma buffers and > need not start at the beginning of one. > > Basically we have a PCIe card that has an inbuilt iommu to convert internal > 32bit addresses to 64bit PCIe ones. > This has 512 16kB pages. > So we do a number of dma_alloc_coherent() for 16k blocks. > The user process then does an mmap() for part of the buffer. > This request is 4k aligned so we do multiple remap_pfn_range() calls to map > the disjoint physical (and kernel virtual) buffers into contiguous user > memory. > > So both ends see contiguous addresses even though the physical addresses > are non-contiguous. > > I guess I could modify the vm_start address and then restore it at the end. > > I found this big discussion: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.k > ernel.org%2Fpatchwork%2Fpatch%2F351245%2Fdata=02%7C01%7Csh > erry.sun%40nxp.com%7C876724689688440581a708d8648dceb3%7C686ea1d > 3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637369907516376294sdat > a=amSClQfVGhI0%2F3bZfo8HF7UmCktkPluArWW22YlQzMQ%3Dreser > ved=0 > about these functions. > > The bit about VIPT caches is problematic. > I don't think you can change the kernel address during mmap. > What you need to do is defer allocating the user address until you know the > kernel address. > Otherwise you get into problems is you try to mmap the same memory into > two processes. > This is a general problem even for mmap() of files. > ISTR SYSV on some sparc systems having to use uncached maps. > > If you might want to mmap two kernel buffers (dma or not) into adjacent > user addresses then you need some way of allocating the second buffer to > follow the first one in the VIVT cache. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, > MK1 1PT, UK Registration No: 1397386 (Wales)
[PATCH] vfio/platform: Replace spin_lock_irqsave by spin_lock in hard IRQ
It is redundant to do irqsave and irqrestore in hardIRQ context.
Signed-off-by: Tian Tao
---
drivers/vfio/platform/vfio_platform_irq.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/platform/vfio_platform_irq.c
b/drivers/vfio/platform/vfio_platform_irq.c
index c5b09ec..24fd6c5 100644
--- a/drivers/vfio/platform/vfio_platform_irq.c
+++ b/drivers/vfio/platform/vfio_platform_irq.c
@@ -139,10 +139,9 @@ static int vfio_platform_set_irq_unmask(struct
vfio_platform_device *vdev,
static irqreturn_t vfio_automasked_irq_handler(int irq, void *dev_id)
{
struct vfio_platform_irq *irq_ctx = dev_id;
- unsigned long flags;
int ret = IRQ_NONE;
- spin_lock_irqsave(_ctx->lock, flags);
+ spin_lock(_ctx->lock);
if (!irq_ctx->masked) {
ret = IRQ_HANDLED;
@@ -152,7 +151,7 @@ static irqreturn_t vfio_automasked_irq_handler(int irq,
void *dev_id)
irq_ctx->masked = true;
}
- spin_unlock_irqrestore(_ctx->lock, flags);
+ spin_unlock(_ctx->lock);
if (ret == IRQ_HANDLED)
eventfd_signal(irq_ctx->trigger, 1);
--
2.7.4
Re: [LKP] Re: [hugetlbfs] c0d0381ade: vm-scalability.throughput -33.4% regression
On 10/13/2020 1:40 AM, Mike Kravetz wrote: On 10/11/20 10:29 PM, Xing Zhengjun wrote: Hi Mike, I re-test it in v5.9-rc8, the regression still existed. It is almost the same as 34ae204f1851. Do you have time to look at it? Thanks. Thank you for testing. Just curious, did you apply the series in this thread or just test v5.9-rc8? If just testing v5.9-rc8, no changes to this code were added after 34ae204f1851, so results being the same are expected. I just test v5.9-rc8. Where can I find the series patches you mentioned here? Or just wait for the next mainline release? There are some functional issues with this new hugetlb locking model that are currently being worked. It is likely to result in significantly different code. The performance issues discovered here will be taken into account with the new code. However, as previously mentioned additional synchronization is required for functional correctness. As a result, there will be some regression in this code. -- Zhengjun Xing
Re: [PATCH v7 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
On Wed, Oct 07, 2020 at 03:37:46PM +0530, Sumit Garg wrote:
> Add support for TEE based trusted keys where TEE provides the functionality
> to seal and unseal trusted keys using hardware unique key.
>
> Refer to Documentation/tee.txt for detailed information about TEE.
>
> Signed-off-by: Sumit Garg
> ---
> include/keys/trusted_tee.h| 55 ++
> security/keys/trusted-keys/Makefile | 1 +
> security/keys/trusted-keys/trusted_core.c | 4 +
> security/keys/trusted-keys/trusted_tee.c | 278
> ++
> 4 files changed, 338 insertions(+)
> create mode 100644 include/keys/trusted_tee.h
> create mode 100644 security/keys/trusted-keys/trusted_tee.c
>
> diff --git a/include/keys/trusted_tee.h b/include/keys/trusted_tee.h
> new file mode 100644
> index 000..2e2bb15
> --- /dev/null
> +++ b/include/keys/trusted_tee.h
> @@ -0,0 +1,55 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2019-2020 Linaro Ltd.
> + *
> + * Author:
> + * Sumit Garg
> + */
> +
> +#ifndef __TEE_TRUSTED_KEY_H
> +#define __TEE_TRUSTED_KEY_H
> +
> +#include
> +
> +#define DRIVER_NAME "tee-trusted-key"
> +
> +/*
> + * Get random data for symmetric key
> + *
> + * [out] memref[0]Random data
> + */
> +#define TA_CMD_GET_RANDOM0x0
> +
> +/*
> + * Seal trusted key using hardware unique key
> + *
> + * [in] memref[0]Plain key
> + * [out] memref[1]Sealed key datablob
> + */
> +#define TA_CMD_SEAL 0x1
> +
> +/*
> + * Unseal trusted key using hardware unique key
> + *
> + * [in] memref[0]Sealed key datablob
> + * [out] memref[1]Plain key
> + */
> +#define TA_CMD_UNSEAL0x2
> +
> +/**
> + * struct trusted_key_private - TEE Trusted key private data
> + * @dev: TEE based Trusted key device.
> + * @ctx: TEE context handler.
> + * @session_id: Trusted key TA session identifier.
> + * @shm_pool:Memory pool shared with TEE device.
> + */
> +struct trusted_key_private {
> + struct device *dev;
> + struct tee_context *ctx;
> + u32 session_id;
> + struct tee_shm *shm_pool;
> +};
> +
> +extern struct trusted_key_ops tee_trusted_key_ops;
> +
> +#endif
> diff --git a/security/keys/trusted-keys/Makefile
> b/security/keys/trusted-keys/Makefile
> index 49e3bcf..012dd78 100644
> --- a/security/keys/trusted-keys/Makefile
> +++ b/security/keys/trusted-keys/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
> trusted-y += trusted_core.o
> trusted-y += trusted_tpm1.o
> trusted-y += trusted_tpm2.o
> +trusted-y += trusted_tee.o
> diff --git a/security/keys/trusted-keys/trusted_core.c
> b/security/keys/trusted-keys/trusted_core.c
> index 71a5e27..74a3d80 100644
> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -8,6 +8,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -28,6 +29,9 @@ static struct trusted_key_source trusted_key_sources[] = {
> #if defined(CONFIG_TCG_TPM)
> { "tpm", _trusted_key_ops },
> #endif
> +#if defined(CONFIG_TEE)
> + { "tee", _trusted_key_ops },
> +#endif
> };
> static struct trusted_key_ops *trusted_key_ops;
>
> diff --git a/security/keys/trusted-keys/trusted_tee.c
> b/security/keys/trusted-keys/trusted_tee.c
> new file mode 100644
> index 000..b414d52
> --- /dev/null
> +++ b/security/keys/trusted-keys/trusted_tee.c
> @@ -0,0 +1,278 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019-2020 Linaro Ltd.
> + *
> + * Author:
> + * Sumit Garg
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +static struct trusted_key_private pvt_data;
> +
> +/*
> + * Have the TEE seal(encrypt) the symmetric key
> + */
> +static int tee_trusted_seal(struct trusted_key_payload *p, char *datablob)
Use trusted_tee_* prefix.
> +{
> + int ret = 0;
"int ret;"
It is never used uninitialized.
> + struct tee_ioctl_invoke_arg inv_arg;
> + struct tee_param param[4];
> + struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL;
> +
> + memset(_arg, 0, sizeof(inv_arg));
> + memset(, 0, sizeof(param));
> +
> + reg_shm_in = tee_shm_register(pvt_data.ctx, (unsigned long)p->key,
> + p->key_len, TEE_SHM_DMA_BUF |
> + TEE_SHM_KERNEL_MAPPED);
> + if (IS_ERR(reg_shm_in)) {
> + dev_err(pvt_data.dev, "key shm register failed\n");
> + return PTR_ERR(reg_shm_in);
> + }
> +
> + reg_shm_out = tee_shm_register(pvt_data.ctx, (unsigned long)p->blob,
> +sizeof(p->blob), TEE_SHM_DMA_BUF |
> +TEE_SHM_KERNEL_MAPPED);
> + if (IS_ERR(reg_shm_out)) {
> + dev_err(pvt_data.dev, "blob shm register failed\n");
> + ret =
Re: [LKP] [fs] b6509f6a8c: will-it-scale.per_thread_ops -12.6% regression
On 10/12/2020 4:18 PM, Mel Gorman wrote: On Mon, Oct 12, 2020 at 02:20:26PM +0800, Xing Zhengjun wrote: Hi Mel, It is a revert commit caused the regression, Do you have a plan to fix it? Thanks. I re-test it in v5.9-rc8, the regression still existed. The revert caused a *performance* regression but the original performance gain caused a functional failure. The overall performance should be unchanged. I have not revisited the topic since. Thanks for the explanation. We will stop tracking it. -- Zhengjun Xing
Re: [Question Resend] About z3fold page migration
Matthew Wilcox wrote: > On Mon, Oct 12, 2020 at 02:00:17PM +, linmiaohe wrote: >> Hi all: >> >> Many thanks for brilliant z3fold code. I am reading it and have some >> questions about it. It's very nice of you if you can explain it for me. >> 1.page->private is used in z3fold but PagePrivate flag is never set, >> should we SetPagePrivate for it? > >No. SetPagePrivate and page->private are related in interesting and >complicated ways. I'm working on some documentation for it at the moment, but >the short answer is: no. I can't wait to read your document. PagePrivate confuses me now. > >> 2.Since PagePrivate flag is never set, why we ClearPagePrivate in >> free_z3fold_page and z3fold_page_migrate? > >That's probably a bug. > > >> 3.Should we add page to the unbuddied list in z3fold_page_putback() >> when zhdr->refcount does not reach 0 since we remove it from unbuddied list >> in z3fold_page_isolate? Or When we will add page to the unbuddied list after >> z3fold_page_putback? > >This one I do not know the answer to. > Many thanks for your reply. Enjoy your day! ;)
Re: [PATCH v2 1/2] extcon: add driver for TI TUSB320
Hi Michael, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on chanwoo-extcon/extcon-next] [also build test WARNING on v5.9 next-20201012] [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/Michael-Auchter/extcon-add-driver-for-TI-TUSB320/20201012-232733 base: https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git extcon-next config: s390-randconfig-r022-20201013 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project a324d8f964bf421fa7d8b882b0f64ead28c4149c) 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 s390 cross compiling tool for clang build # apt-get install binutils-s390x-linux-gnu # https://github.com/0day-ci/linux/commit/5065d684df89cf11f57743f3c1440e6bd09054ea git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Michael-Auchter/extcon-add-driver-for-TI-TUSB320/20201012-232733 git checkout 5065d684df89cf11f57743f3c1440e6bd09054ea # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) ^ include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32' ___constant_swab32(x) : \ ^ include/uapi/linux/swab.h:19:12: note: expanded from macro '___constant_swab32' (((__u32)(x) & (__u32)0x00ffUL) << 24) |\ ^ In file included from drivers/extcon/extcon-usbc-tusb320.c:13: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/s390/include/asm/io.h:72: include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) ^ include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32' ___constant_swab32(x) : \ ^ include/uapi/linux/swab.h:20:12: note: expanded from macro '___constant_swab32' (((__u32)(x) & (__u32)0xff00UL) << 8) |\ ^ In file included from drivers/extcon/extcon-usbc-tusb320.c:13: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/s390/include/asm/io.h:72: include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) ^ include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32' ___constant_swab32(x) : \ ^ include/uapi/linux/swab.h:21:12: note: expanded from macro '___constant_swab32' (((__u32)(x) & (__u32)0x00ffUL) >> 8) |\ ^ In file included from drivers/extcon/extcon-usbc-tusb320.c:13: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/s390/include/asm/io.h:72: include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
Re: [PATCH v7 1/4] KEYS: trusted: Add generic trusted keys framework
On Wed, Oct 07, 2020 at 03:37:45PM +0530, Sumit Garg wrote: > Current trusted keys framework is tightly coupled to use TPM device as > an underlying implementation which makes it difficult for implementations > like Trusted Execution Environment (TEE) etc. to provide trusted keys > support in case platform doesn't posses a TPM device. > > Add a generic trusted keys framework where underlying implementations > can be easily plugged in. Create struct trusted_key_ops to achieve this, > which contains necessary functions of a backend. > > Also, add a module parameter in order to select a particular trust source > in case a platform support multiple trust sources. > > Suggested-by: Jarkko Sakkinen > Signed-off-by: Sumit Garg This is exactly kind of place where I think static_call() should be taken into use, which is a v5.10 feature [1]. For background and context, I'd read [2]. The other thing that I see that does not make much else than additional complexity, is trusted_tpm.ko. We can do with one trusted.ko. I'd also *guess* that the static_call() mechanism does not work accross module boundaries. [1] https://lore.kernel.org/lkml/20201012155542.ga3557...@gmail.com/ [2] https://lwn.net/Articles/815908/ /Jarkko
[PATCH 5/6] mremap: Check if it's possible to split original vma
If original VMA can't be split at the desired address, do_munmap() will
fail and leave both new-copied VMA and old VMA. De-facto it's
MREMAP_DONTUNMAP behaviour, which is unexpected.
Currently, it may fail such way for hugetlbfs and dax device mappings.
Minimize such unpleasant situations to OOM by checking .may_split()
before attempting to create a VMA copy.
Signed-off-by: Dmitry Safonov
---
mm/mremap.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index 898e9818ba6d..3c4047c23673 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -343,7 +343,7 @@ static unsigned long move_vma(struct vm_area_struct *vma,
unsigned long excess = 0;
unsigned long hiwater_vm;
int split = 0;
- int err;
+ int err = 0;
bool need_rmap_locks;
/*
@@ -353,6 +353,15 @@ static unsigned long move_vma(struct vm_area_struct *vma,
if (mm->map_count >= sysctl_max_map_count - 3)
return -ENOMEM;
+ if (vma->vm_ops && vma->vm_ops->may_split) {
+ if (vma->vm_start != old_addr)
+ err = vma->vm_ops->may_split(vma, old_addr);
+ if (!err && vma->vm_end != old_addr + old_len)
+ err = vma->vm_ops->may_split(vma, old_addr + old_len);
+ if (err)
+ return err;
+ }
+
/*
* Advise KSM to break any KSM pages in the area to be moved:
* it would be confusing if they were to turn up at the new
--
2.28.0
