[RFC PATCH v4 0/4] objtool and cross compilation
rfc v1 - rfc v2: - rebased onto tip/objtool/core - reformatted couple of lines rfc v2 - rfc v3: - reused __*_ENDIAN_BITFIELD and dropped unneeded byteswap if __KERNEL__ is defined following David's suggestions, - re-splitted changes and made x86 instruction decoder a separate patch, - extra patch to add -Wno-nested-externs build flag to enable BUILD_BUG() usage, - added a safer and more readable leXX_to_cpu macro in x86 instruction decoder, - simplified includes. Switched to using leXX_to_cpu/cpu_to_leXX in the objtool and x86 instruction decoder since is included in the objtool already. rfc v3 - rfc v4: - patch 4: objtool: fix x86 orc generation on big endian cross compiles - introduced "bswap_if_needed()" macro for multi-byte values conversion, which are read from / about to be written to a target native endianness ELF file. - patch 2: x86/insn: instruction decoder and big endian cross compiles - changed subject prefix from objtool to x86/insn - reformated leXX_to_cpu macro make it easier to read Currently objtool seems to be the only tool from all the build tools needed for x86 build which breaks x86 cross compilation on big endian systems. But besides x86 cross compilation, endianness awareness is also needed for big endian architectures objtool support in general. We have working prototype of objtool support and orc unwinder for s390 made originally by Martin Schwidefsky. I'm trying to bring it in shape again and refactor to share more code with "generic" part. But first things first. This patch series points to endianness problems which should be addressed. Recent "other architectures support" patches currently moved only some problematic parts into x86 arch specific folder. Besides that even though big endian stuff is only needed for the objtool arch/x86/lib/insn.c and arch/x86/include/asm/insn.h are shared across the kernel source and the tools, so changes are applied to both. Any suggestions how to make patches more acceptable are welcome. Martin Schwidefsky (2): x86/insn: instruction decoder and big endian cross compiles objtool: correct rebuilding of reloc sections Vasily Gorbik (2): objtool: allow nested externs to enable BUILD_BUG() objtool: fix x86 orc generation on big endian cross compiles arch/x86/include/asm/insn.h | 33 ++ arch/x86/include/asm/orc_types.h | 10 ++ arch/x86/lib/insn.c | 101 -- tools/arch/x86/include/asm/insn.h | 33 ++ tools/arch/x86/include/asm/orc_types.h| 10 ++ tools/arch/x86/lib/insn.c | 101 -- tools/objtool/Makefile| 2 +- .../arch/x86/include/arch_endianness.h| 9 ++ tools/objtool/check.c | 5 +- tools/objtool/elf.c | 34 +++--- tools/objtool/endianness.h| 38 +++ tools/objtool/orc_dump.c | 5 +- tools/objtool/orc_gen.c | 3 + tools/objtool/special.c | 6 +- 14 files changed, 260 insertions(+), 130 deletions(-) create mode 100644 tools/objtool/arch/x86/include/arch_endianness.h create mode 100644 tools/objtool/endianness.h -- ⢋⡀⣀⠹ ⠠⣶⡦⠀ ⣿⣿⣿⠏⣴⣮⣴⣧⠈⢿⣿⣿ ⣿⣿⡏⢰⣿⠖⣠⣿⡆⠈⣿⣿ ⣿⢛⣵⣄⠙⣶⣶⡟⣅⣠⠹⣿ ⣿⣜⣛⠻⢎⣉⣉⣀⠿⣫⣵⣿
[RFC PATCH v4 3/4] objtool: correct rebuilding of reloc sections
From: Martin Schwidefsky
Currently relocations generated in elf_rebuild_rel_reloc_section/
elf_rebuild_rela_reloc_section functions are broken if the objtool is
built and run on big endian system. E.g. the following errors pop up
during x86 cross compilation:
x86_64-9.1.0-ld: fs/efivarfs/inode.o: bad reloc symbol index (0x200 >=
0x22) for offset 0 in section `.orc_unwind_ip'
x86_64-9.1.0-ld: final link failed: bad value
To address that convert those functions to do things similar to
elf_write_reloc(), reuse gelf_update_rel/gelf_update_rela libelf library
functions.
Signed-off-by: Martin Schwidefsky
Co-developed-by: Vasily Gorbik
Signed-off-by: Vasily Gorbik
---
tools/objtool/elf.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 4e1d7460574b..5c0341b0cde3 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -829,25 +829,27 @@ static int elf_rebuild_rel_reloc_section(struct section
*sec, int nr)
{
struct reloc *reloc;
int idx = 0, size;
- GElf_Rel *relocs;
+ void *buf;
/* Allocate a buffer for relocations */
- size = nr * sizeof(*relocs);
- relocs = malloc(size);
- if (!relocs) {
+ size = nr * sizeof(GElf_Rel);
+ buf = malloc(size);
+ if (!buf) {
perror("malloc");
return -1;
}
- sec->data->d_buf = relocs;
+ sec->data->d_buf = buf;
sec->data->d_size = size;
+ sec->data->d_type = ELF_T_REL;
sec->sh.sh_size = size;
idx = 0;
list_for_each_entry(reloc, &sec->reloc_list, list) {
- relocs[idx].r_offset = reloc->offset;
- relocs[idx].r_info = GELF_R_INFO(reloc->sym->idx, reloc->type);
+ reloc->rel.r_offset = reloc->offset;
+ reloc->rel.r_info = GELF_R_INFO(reloc->sym->idx, reloc->type);
+ gelf_update_rel(sec->data, idx, &reloc->rel);
idx++;
}
@@ -858,26 +860,28 @@ static int elf_rebuild_rela_reloc_section(struct section
*sec, int nr)
{
struct reloc *reloc;
int idx = 0, size;
- GElf_Rela *relocs;
+ void *buf;
/* Allocate a buffer for relocations with addends */
- size = nr * sizeof(*relocs);
- relocs = malloc(size);
- if (!relocs) {
+ size = nr * sizeof(GElf_Rela);
+ buf = malloc(size);
+ if (!buf) {
perror("malloc");
return -1;
}
- sec->data->d_buf = relocs;
+ sec->data->d_buf = buf;
sec->data->d_size = size;
+ sec->data->d_type = ELF_T_RELA;
sec->sh.sh_size = size;
idx = 0;
list_for_each_entry(reloc, &sec->reloc_list, list) {
- relocs[idx].r_offset = reloc->offset;
- relocs[idx].r_addend = reloc->addend;
- relocs[idx].r_info = GELF_R_INFO(reloc->sym->idx, reloc->type);
+ reloc->rela.r_offset = reloc->offset;
+ reloc->rela.r_addend = reloc->addend;
+ reloc->rela.r_info = GELF_R_INFO(reloc->sym->idx, reloc->type);
+ gelf_update_rela(sec->data, idx, &reloc->rela);
idx++;
}
--
⢋⡀⣀⠹
⠠⣶⡦⠀
⣿⣿⣿⠏⣴⣮⣴⣧⠈⢿⣿⣿
⣿⣿⡏⢰⣿⠖⣠⣿⡆⠈⣿⣿
⣿⢛⣵⣄⠙⣶⣶⡟⣅⣠⠹⣿
⣿⣜⣛⠻⢎⣉⣉⣀⠿⣫⣵⣿
[RFC PATCH v4 4/4] objtool: fix x86 orc generation on big endian cross compiles
Correct objtool orc generation endianness problems to enable fully
functional x86 cross compiles on big endian hardware.
Introduces bswap_if_needed macro which does a byte swap if target
endianness doesn't match the host, i.e. cross compilation for little
endian on big endian and vice versa. To be used for multi-byte values
conversion, which are read from / about to be written to a target native
endianness ELF file.
Signed-off-by: Vasily Gorbik
diff --git a/arch/x86/include/asm/orc_types.h b/arch/x86/include/asm/orc_types.h
index fdbffec4cfde..5a2baf28a1dc 100644
--- a/arch/x86/include/asm/orc_types.h
+++ b/arch/x86/include/asm/orc_types.h
@@ -40,6 +40,8 @@
#define ORC_REG_MAX15
#ifndef __ASSEMBLY__
+#include
+
/*
* This struct is more or less a vastly simplified version of the DWARF Call
* Frame Information standard. It contains only the necessary parts of DWARF
@@ -51,10 +53,18 @@
struct orc_entry {
s16 sp_offset;
s16 bp_offset;
+#if defined(__LITTLE_ENDIAN_BITFIELD)
unsignedsp_reg:4;
unsignedbp_reg:4;
unsignedtype:2;
unsignedend:1;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+ unsignedbp_reg:4;
+ unsignedsp_reg:4;
+ unsignedunused:5;
+ unsignedend:1;
+ unsignedtype:2;
+#endif
} __packed;
#endif /* __ASSEMBLY__ */
diff --git a/tools/arch/x86/include/asm/orc_types.h
b/tools/arch/x86/include/asm/orc_types.h
index fdbffec4cfde..5a2baf28a1dc 100644
--- a/tools/arch/x86/include/asm/orc_types.h
+++ b/tools/arch/x86/include/asm/orc_types.h
@@ -40,6 +40,8 @@
#define ORC_REG_MAX15
#ifndef __ASSEMBLY__
+#include
+
/*
* This struct is more or less a vastly simplified version of the DWARF Call
* Frame Information standard. It contains only the necessary parts of DWARF
@@ -51,10 +53,18 @@
struct orc_entry {
s16 sp_offset;
s16 bp_offset;
+#if defined(__LITTLE_ENDIAN_BITFIELD)
unsignedsp_reg:4;
unsignedbp_reg:4;
unsignedtype:2;
unsignedend:1;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+ unsignedbp_reg:4;
+ unsignedsp_reg:4;
+ unsignedunused:5;
+ unsignedend:1;
+ unsignedtype:2;
+#endif
} __packed;
#endif /* __ASSEMBLY__ */
diff --git a/tools/objtool/arch/x86/include/arch_endianness.h
b/tools/objtool/arch/x86/include/arch_endianness.h
new file mode 100644
index ..7c362527da20
--- /dev/null
+++ b/tools/objtool/arch/x86/include/arch_endianness.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+#ifndef _ARCH_ENDIANNESS_H
+#define _ARCH_ENDIANNESS_H
+
+#include
+
+#define __TARGET_BYTE_ORDER __LITTLE_ENDIAN
+
+#endif /* _ARCH_ENDIANNESS_H */
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 2df9f769412e..fd892b77e98f 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -13,6 +13,7 @@
#include "special.h"
#include "warn.h"
#include "arch_elf.h"
+#include "endianness.h"
#include
#include
@@ -1370,7 +1371,7 @@ static int read_unwind_hints(struct objtool_file *file)
cfa = &insn->cfi.cfa;
if (hint->type == UNWIND_HINT_TYPE_RET_OFFSET) {
- insn->ret_offset = hint->sp_offset;
+ insn->ret_offset = bswap_if_needed(hint->sp_offset);
continue;
}
@@ -1382,7 +1383,7 @@ static int read_unwind_hints(struct objtool_file *file)
return -1;
}
- cfa->offset = hint->sp_offset;
+ cfa->offset = bswap_if_needed(hint->sp_offset);
insn->cfi.type = hint->type;
insn->cfi.end = hint->end;
}
diff --git a/tools/objtool/endianness.h b/tools/objtool/endianness.h
new file mode 100644
index ..ebece3191b58
--- /dev/null
+++ b/tools/objtool/endianness.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+#ifndef _OBJTOOL_ENDIANNESS_H
+#define _OBJTOOL_ENDIANNESS_H
+
+#include
+#include
+#include "arch_endianness.h"
+
+#ifndef __TARGET_BYTE_ORDER
+#error undefined arch __TARGET_BYTE_ORDER
+#endif
+
+#if __BYTE_ORDER != __TARGET_BYTE_ORDER
+#define __NEED_BSWAP 1
+#else
+#define __NEED_BSWAP 0
+#endif
+
+/*
+ * Does a byte swap if target endianness doesn't match the host, i.e. cross
+ * compilation for little endian on big endian and vice versa.
+ * To be used for multi-byte values conversion, which are read from / about
+ * to be written to a target native endianness ELF file.
+ */
+#define bswap_if_needed(val) \
+({ \
+ __typeof__(val) __ret; \
+ switch (sizeof(val)) {
[RFC PATCH v4 2/4] x86/insn: instruction decoder and big endian cross compiles
From: Martin Schwidefsky
x86 instruction decoder code is shared across the kernel source and the
tools. Currently objtool seems to be the only tool from build tools needed
which breaks x86 cross compilation on big endian systems. Make the x86
instruction decoder build host endianness agnostic to support x86 cross
compilation and enable objtool to implement endianness awareness for
big endian architectures support.
Signed-off-by: Martin Schwidefsky
Co-developed-by: Vasily Gorbik
Signed-off-by: Vasily Gorbik
---
arch/x86/include/asm/insn.h | 33 ++
arch/x86/lib/insn.c | 101 ++
tools/arch/x86/include/asm/insn.h | 33 ++
tools/arch/x86/lib/insn.c | 101 ++
4 files changed, 160 insertions(+), 108 deletions(-)
diff --git a/arch/x86/include/asm/insn.h b/arch/x86/include/asm/insn.h
index 5c1ae3eff9d4..004e27bdf121 100644
--- a/arch/x86/include/asm/insn.h
+++ b/arch/x86/include/asm/insn.h
@@ -7,9 +7,12 @@
* Copyright (C) IBM Corporation, 2009
*/
+#include
/* insn_attr_t is defined in inat.h */
#include
+#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN :
defined(__LITTLE_ENDIAN)
+
struct insn_field {
union {
insn_value_t value;
@@ -20,6 +23,36 @@ struct insn_field {
unsigned char nbytes;
};
+static inline void insn_field_set(struct insn_field *p, insn_value_t v,
+ unsigned char n)
+{
+ p->value = v;
+ p->nbytes = n;
+}
+
+#else
+
+struct insn_field {
+ insn_value_t value;
+ union {
+ insn_value_t little;
+ insn_byte_t bytes[4];
+ };
+ /* !0 if we've run insn_get_xxx() for this field */
+ unsigned char got;
+ unsigned char nbytes;
+};
+
+static inline void insn_field_set(struct insn_field *p, insn_value_t v,
+ unsigned char n)
+{
+ p->value = v;
+ p->little = __cpu_to_le32(v);
+ p->nbytes = n;
+}
+
+#endif
+
struct insn {
struct insn_field prefixes; /*
* Prefixes
diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
index 404279563891..520b31fc1f1a 100644
--- a/arch/x86/lib/insn.c
+++ b/arch/x86/lib/insn.c
@@ -5,6 +5,7 @@
* Copyright (C) IBM Corporation, 2002, 2004, 2009
*/
+#include
#ifdef __KERNEL__
#include
#else
@@ -15,15 +16,28 @@
#include
+#define leXX_to_cpu(t, r) \
+({ \
+ __typeof__(t) v;\
+ switch (sizeof(t)) {\
+ case 4: v = le32_to_cpu(r); break; \
+ case 2: v = le16_to_cpu(r); break; \
+ case 1: v = r; break; \
+ default:\
+ BUILD_BUG(); break; \
+ } \
+ v; \
+})
+
/* Verify next sizeof(t) bytes can be on the same instruction */
#define validate_next(t, insn, n) \
((insn)->next_byte + sizeof(t) + n <= (insn)->end_kaddr)
#define __get_next(t, insn)\
- ({ t r = *(t*)insn->next_byte; insn->next_byte += sizeof(t); r; })
+ ({ t r = *(t*)insn->next_byte; insn->next_byte += sizeof(t);
leXX_to_cpu(t, r); })
#define __peek_nbyte_next(t, insn, n) \
- ({ t r = *(t*)((insn)->next_byte + n); r; })
+ ({ t r = *(t*)((insn)->next_byte + n); leXX_to_cpu(t, r); })
#define get_next(t, insn) \
({ if (unlikely(!validate_next(t, insn, 0))) goto err_out;
__get_next(t, insn); })
@@ -157,8 +171,7 @@ void insn_get_prefixes(struct insn *insn)
b = peek_next(insn_byte_t, insn);
attr = inat_get_opcode_attribute(b);
if (inat_is_rex_prefix(attr)) {
- insn->rex_prefix.value = b;
- insn->rex_prefix.nbytes = 1;
+ insn_field_set(&insn->rex_prefix, b, 1);
insn->next_byte++;
if (X86_REX_W(b))
/* REX.W overrides opnd_size */
@@ -295,8 +308,7 @@ void insn_get_modrm(struct insn *insn)
if (inat_has_modrm(insn->attr)) {
mod = get_next(insn_byte_t, insn);
- modrm->value = mod;
- modrm->nbytes = 1;
+ insn_field_set(modrm, mod, 1);
if (inat_is_group(insn->attr)) {
pfx_id = insn_last_prefix_id(insn);
insn->attr = inat_get_group_attribute(mod, pfx_id,
@@ -334,7 +346,7 @@ int insn_rip_relative(struct i
[RFC PATCH v4 1/4] objtool: allow nested externs to enable BUILD_BUG()
Currently BUILD_BUG() macro is expanded to smth like the following:
do {
extern void __compiletime_assert_0(void)
__attribute__((error("BUILD_BUG failed")));
if (!(!(1)))
__compiletime_assert_0();
} while (0);
If used in a function body this obviously would produce build errors
with -Wnested-externs and -Werror.
Build objtool with -Wno-nested-externs to enable BUILD_BUG() usage.
Signed-off-by: Vasily Gorbik
---
tools/objtool/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index 33d1e3ca8efd..4ea9a833dde7 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -37,7 +37,7 @@ INCLUDES := -I$(srctree)/tools/include \
-I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
-I$(srctree)/tools/arch/$(SRCARCH)/include \
-I$(srctree)/tools/objtool/arch/$(SRCARCH)/include
-WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
+WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
-Wno-nested-externs
CFLAGS := -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES)
$(LIBELF_FLAGS)
LDFLAGS += $(LIBELF_LIBS) $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS)
--
⢋⡀⣀⠹
⠠⣶⡦⠀
⣿⣿⣿⠏⣴⣮⣴⣧⠈⢿⣿⣿
⣿⣿⡏⢰⣿⠖⣠⣿⡆⠈⣿⣿
⣿⢛⣵⣄⠙⣶⣶⡟⣅⣠⠹⣿
⣿⣜⣛⠻⢎⣉⣉⣀⠿⣫⣵⣿
Re: virtiofs: WARN_ON(out_sgs + in_sgs != total_sgs)
On Fri, Oct 02, 2020 at 10:44:37PM -0400, Qian Cai wrote: > On Fri, 2020-10-02 at 12:28 -0400, Qian Cai wrote: > > Running some fuzzing on virtiofs from a non-privileged user could trigger a > > warning in virtio_fs_enqueue_req(): > > > > WARN_ON(out_sgs + in_sgs != total_sgs); > > Okay, I can reproduce this after running for a few hours: > > out_sgs = 3, in_sgs = 2, total_sgs = 6 Thanks. I can also reproduce it simply by calling. ioctl(fd, 0x5a004000, buf); I think following WARN_ON() is not correct. WARN_ON(out_sgs + in_sgs != total_sgs) toal_sgs should actually be max sgs. It looks at ap->num_pages and counts one sg for each page. And it assumes that same number of pages will be used both for input and output. But there are no such guarantees. With above ioctl() call, I noticed we are using 2 pages for input (out_sgs) and one page for output (in_sgs). So out_sgs=4, in_sgs=3 and total_sgs=8 and warning triggers. I think total sgs is actually max number of sgs and warning should probably be. WARN_ON(out_sgs + in_sgs > total_sgs) Stefan, WDYT? I will send a patch for this. Thanks Vivek > > and this time from flush_bg_queue() instead of fuse_simple_request(). > > From the log, the last piece of code is: > > ftruncate(fd=186, length=4) > > which is a test file on virtiofs: > > [main] testfile fd:186 filename:trinity-testfile3 flags:2 fopened:1 > fcntl_flags:2000 global:1 > [main] start: 0x7f47c1199000 size:4KB name: trinity-testfile3 global:1 > > > [ 9863.468502] WARNING: CPU: 16 PID: 286083 at fs/fuse/virtio_fs.c:1152 > virtio_fs_enqueue_req+0xd36/0xde0 [virtiofs] > [ 9863.474442] Modules linked in: dlci 8021q garp mrp bridge stp llc > ieee802154_socket ieee802154 vsock_loopback vmw_vsock_virtio_transport_common > vmw_vsock_vmci_transport vsock mpls_router vmw_vmci ip_tunnel as > [ 9863.474555] ata_piix fuse serio_raw libata e1000 sunrpc dm_mirror > dm_region_hash dm_log dm_mod > [ 9863.535805] CPU: 16 PID: 286083 Comm: trinity-c5 Kdump: loaded Not tainted > 5.9.0-rc7-next-20201002+ #2 > [ 9863.544368] Hardware name: Red Hat KVM, BIOS > 1.14.0-1.module+el8.3.0+7638+07cf13d2 04/01/2014 > [ 9863.550129] RIP: 0010:virtio_fs_enqueue_req+0xd36/0xde0 [virtiofs] > [ 9863.552998] Code: 60 09 23 d9 e9 44 fa ff ff e8 56 09 23 d9 e9 70 fa ff ff > 48 89 cf 48 89 4c 24 08 e8 44 09 23 d9 48 8b 4c 24 08 e9 7c fa ff ff <0f> 0b > 48 c7 c7 c0 85 60 c0 44 89 e1 44 89 fa 44 89 ee e8 e3 b7 > [ 9863.561720] RSP: 0018:888a696ef6f8 EFLAGS: 00010202 > [ 9863.565420] RAX: RBX: 88892e030008 RCX: > > [ 9863.568735] RDX: 0005 RSI: RDI: > 888a696ef8ac > [ 9863.572037] RBP: 888a49d03d30 R08: ed114d2ddf18 R09: > 888a696ef8a0 > [ 9863.575383] R10: 888a696ef8bf R11: ed114d2ddf17 R12: > 0006 > [ 9863.578668] R13: 0003 R14: 0002 R15: > 0002 > [ 9863.581971] FS: 7f47c12f5740() GS:888a7f80() > knlGS: > [ 9863.585752] CS: 0010 DS: ES: CR0: 80050033 > [ 9863.590232] CR2: CR3: 000a63570005 CR4: > 00770ee0 > [ 9863.594698] DR0: 7f6642e43000 DR1: DR2: > > [ 9863.598521] DR3: DR6: 0ff0 DR7: > 0600 > [ 9863.601861] PKRU: 5540 > [ 9863.603173] Call Trace: > [ 9863.604382] ? virtio_fs_probe+0x13e0/0x13e0 [virtiofs] > [ 9863.606838] ? is_bpf_text_address+0x21/0x30 > [ 9863.608869] ? kernel_text_address+0x125/0x140 > [ 9863.610962] ? __kernel_text_address+0xe/0x30 > [ 9863.613117] ? unwind_get_return_address+0x5f/0xa0 > [ 9863.615427] ? create_prof_cpu_mask+0x20/0x20 > [ 9863.617435] ? _raw_write_lock_irqsave+0xe0/0xe0 > [ 9863.619627] virtio_fs_wake_pending_and_unlock+0x1ea/0x610 [virtiofs] > [ 9863.622638] ? queue_request_and_unlock+0x115/0x280 [fuse] > [ 9863.625224] flush_bg_queue+0x24c/0x3e0 [fuse] > [ 9863.627325] fuse_simple_background+0x3d7/0x6c0 [fuse] > [ 9863.629735] fuse_send_writepage+0x173/0x420 [fuse] > [ 9863.632031] fuse_flush_writepages+0x1fe/0x330 [fuse] > [ 9863.634463] ? make_kgid+0x13/0x20 > [ 9863.636064] ? fuse_change_attributes_common+0x2de/0x940 [fuse] > [ 9863.638850] fuse_do_setattr+0xe84/0x13c0 [fuse] > [ 9863.641024] ? migrate_swap_stop+0x8d1/0x920 > [ 9863.643041] ? fuse_flush_times+0x390/0x390 [fuse] > [ 9863.645347] ? avc_has_perm_noaudit+0x390/0x390 > [ 9863.647465] fuse_setattr+0x197/0x400 [fuse] > [ 9863.649466] notify_change+0x744/0xda0 > [ 9863.651247] ? __down_timeout+0x2a0/0x2a0 > [ 9863.653125] ? do_truncate+0xe2/0x180 > [ 9863.654854] do_truncate+0xe2/0x180 > [ 9863.656509] ? __x64_sys_openat2+0x1c0/0x1c0 > [ 9863.658512] ? alarm_setitimer+0xa0/0x110 > [ 9863.660418] do_sys_ftruncate+0x1ee/0x2c0 > [ 9863.662311] do_syscall_64+0x33/0x40 > [ 9863.663980] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 9863.666384] RIP: 0033:0x7f47c0c0878
Re: [PATCH v39 11/24] x86/sgx: Add SGX enclave driver
On Sat, Oct 03, 2020 at 04:39:25PM +0200, Greg KH wrote:
> On Sat, Oct 03, 2020 at 07:50:46AM +0300, Jarkko Sakkinen wrote:
> > Intel Software Guard eXtensions (SGX) is a set of CPU instructions that can
> > be used by applications to set aside private regions of code and data. The
> > code outside the SGX hosted software entity is prevented from accessing the
> > memory inside the enclave by the CPU. We call these entities enclaves.
> >
> > Add a driver that provides an ioctl API to construct and run enclaves.
> > Enclaves are constructed from pages residing in reserved physical memory
> > areas. The contents of these pages can only be accessed when they are
> > mapped as part of an enclave, by a hardware thread running inside the
> > enclave.
> >
> > The starting state of an enclave consists of a fixed measured set of
> > pages that are copied to the EPC during the construction process by
> > using the opcode ENCLS leaf functions and Software Enclave Control
> > Structure (SECS) that defines the enclave properties.
> >
> > Enclaves are constructed by using ENCLS leaf functions ECREATE, EADD and
> > EINIT. ECREATE initializes SECS, EADD copies pages from system memory to
> > the EPC and EINIT checks a given signed measurement and moves the enclave
> > into a state ready for execution.
> >
> > An initialized enclave can only be accessed through special Thread Control
> > Structure (TCS) pages by using ENCLU (ring-3 only) leaf EENTER. This leaf
> > function converts a thread into enclave mode and continues the execution in
> > the offset defined by the TCS provided to EENTER. An enclave is exited
> > through syscall, exception, interrupts or by explicitly calling another
> > ENCLU leaf EEXIT.
> >
> > The mmap() permissions are capped by the contained enclave page
> > permissions. The mapped areas must also be populated, i.e. each page
> > address must contain a page. This logic is implemented in
> > sgx_encl_may_map().
> >
> > Cc: linux-security-mod...@vger.kernel.org
> > Cc: linux...@kvack.org
> > Cc: Andrew Morton
> > Cc: Matthew Wilcox
> > Acked-by: Jethro Beekman
> > Tested-by: Jethro Beekman
> > Tested-by: Haitao Huang
> > Tested-by: Chunyang Hui
> > Tested-by: Jordan Hand
> > Tested-by: Nathaniel McCallum
> > Tested-by: Seth Moore
> > Tested-by: Darren Kenny
> > Reviewed-by: Darren Kenny
> > Co-developed-by: Sean Christopherson
> > Signed-off-by: Sean Christopherson
> > Co-developed-by: Suresh Siddha
> > Signed-off-by: Suresh Siddha
> > Signed-off-by: Jarkko Sakkinen
> > ---
> > arch/x86/kernel/cpu/sgx/Makefile | 2 +
> > arch/x86/kernel/cpu/sgx/driver.c | 173
> > arch/x86/kernel/cpu/sgx/driver.h | 29 +++
> > arch/x86/kernel/cpu/sgx/encl.c | 331 +++
> > arch/x86/kernel/cpu/sgx/encl.h | 85
> > arch/x86/kernel/cpu/sgx/main.c | 11 +
> > 6 files changed, 631 insertions(+)
> > create mode 100644 arch/x86/kernel/cpu/sgx/driver.c
> > create mode 100644 arch/x86/kernel/cpu/sgx/driver.h
> > create mode 100644 arch/x86/kernel/cpu/sgx/encl.c
> > create mode 100644 arch/x86/kernel/cpu/sgx/encl.h
> >
> > diff --git a/arch/x86/kernel/cpu/sgx/Makefile
> > b/arch/x86/kernel/cpu/sgx/Makefile
> > index 79510ce01b3b..3fc451120735 100644
> > --- a/arch/x86/kernel/cpu/sgx/Makefile
> > +++ b/arch/x86/kernel/cpu/sgx/Makefile
> > @@ -1,2 +1,4 @@
> > obj-y += \
> > + driver.o \
> > + encl.o \
> > main.o
> > diff --git a/arch/x86/kernel/cpu/sgx/driver.c
> > b/arch/x86/kernel/cpu/sgx/driver.c
> > new file mode 100644
> > index ..f54da5f19c2b
> > --- /dev/null
> > +++ b/arch/x86/kernel/cpu/sgx/driver.c
> > @@ -0,0 +1,173 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
>
> You use gpl-only header files in this file, so how in the world can it
> be bsd-3 licensed?
>
> Please get your legal department to agree with this, after you explain
> to them how you are mixing gpl2-only code in with this file.
I'll do what I already stated that I will do. Should I do something
more?
> > +// Copyright(c) 2016-18 Intel Corporation.
>
> Dates are hard to get right :(
Will fix.
>
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include "driver.h"
> > +#include "encl.h"
> > +
> > +u64 sgx_encl_size_max_32;
> > +u64 sgx_encl_size_max_64;
> > +u32 sgx_misc_reserved_mask;
> > +u64 sgx_attributes_reserved_mask;
> > +u64 sgx_xfrm_reserved_mask = ~0x3;
> > +u32 sgx_xsave_size_tbl[64];
> > +
> > +static int sgx_open(struct inode *inode, struct file *file)
> > +{
> > + struct sgx_encl *encl;
> > + int ret;
> > +
> > + encl = kzalloc(sizeof(*encl), GFP_KERNEL);
> > + if (!encl)
> > + return -ENOMEM;
> > +
> > + atomic_set(&encl->flags, 0);
> > + kref_init(&encl->refcount);
> > + xa_init(&encl->page_array);
> > + mutex_init(&encl->lock);
> > + INIT_LIST_HEAD(&encl->mm_list);
> > + spin_lock_init(&encl->mm_lock);
> > +
> > + ret = i
Re: [PATCH] USB: serial: option: Add Telit FT980-KS composition
On 10/4/2020 21:16, Lars Melin wrote: On 10/4/2020 20:29, Leonid Bloch wrote: On 10/4/20 1:58 PM, Lars Melin wrote: On 10/4/2020 16:57, Leonid Bloch wrote: This commit adds the following Telit FT980-KS composition: 0x1054: rndis, diag, adb, nmea, modem, modem, aux AT commands can be sent to /dev/ttyUSB5. Please submit a verbose lsusb listing for the device, I can't imagine that the adb interface should be handled by the option serial driver so there will never be a ttyUSB5. Please see below. Thanks, Leonid. ``` Bus 001 Device 005: ID 1bc7:1054 Telit Wireless Solutions Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1bc7 Telit Wireless Solutions idProduct 0x1054 bcdDevice 4.14 iManufacturer 1 Telit Wireless Solutions iProduct 2 FT980-KS iSerial 3 cb42f61 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x013d bNumInterfaces 8 bConfigurationValue 1 iConfiguration 4 RNDIS_DIAG_ADB_NMEA_DUN_DUN_SER bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 239 Miscellaneous Device bFunctionSubClass 4 bFunctionProtocol 1 iFunction 7 RNDIS Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 239 Miscellaneous Device bInterfaceSubClass 4 bInterfaceProtocol 1 iInterface 5 RNDIS Communications Control ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 01 ** UNRECOGNIZED: 04 24 02 00 ** UNRECOGNIZED: 05 24 06 00 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 6 RNDIS Ethernet Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0f EP 15 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 48 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9
Re: [PATCH 1/1] efi/libstub/x86: simplify efi_is_native()
On Sun, Oct 04, 2020 at 04:14:11PM +0200, Ard Biesheuvel wrote:
> On Sat, 3 Oct 2020 at 21:44, Arvind Sankar wrote:
> >
> > On Sat, Oct 03, 2020 at 01:28:18PM -0400, Brian Gerst wrote:
> > > On Sat, Oct 3, 2020 at 2:05 AM Heinrich Schuchardt
> > > wrote:
> > > >
> > > > CONFIG_EFI_MIXED depends on CONFIG_X86_64=y.
> > > > There is no need to check CONFIG_X86_64 again.
> > > >
> > > > Signed-off-by: Heinrich Schuchardt
> > > > ---
> > > > arch/x86/include/asm/efi.h | 2 --
> > > > 1 file changed, 2 deletions(-)
> > > >
> > > > diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> > > > index b9c2667ac46c..ab28bf1c74cf 100644
> > > > --- a/arch/x86/include/asm/efi.h
> > > > +++ b/arch/x86/include/asm/efi.h
> > > > @@ -223,8 +223,6 @@ static inline bool efi_is_64bit(void)
> > > >
> > > > static inline bool efi_is_native(void)
> > > > {
> > > > - if (!IS_ENABLED(CONFIG_X86_64))
> > > > - return true;
> > > > return efi_is_64bit();
> > > > }
> > >
> > > This would then return false for native 32-bit.
> > >
> > > --
> > > Brian Gerst
> >
> > 32-bit doesn't use this implementation: it's #define'd to true in
> > drivers/firmware/efi/libstub/efistub.h.
> >
>
> Yes, and the reason this [now redundant] test exists is because this
> did not use to be the case before
>
> de8c55208c386 efi/libstub: Fix mixed mode boot issue after macro refactor
Heh, my fault for not cleaning it up then :)
>
> So for this patch
>
> Acked-by: Ard Biesheuvel
>
> I'll queue this up
Re: [EXT] Re: [PATCH v4 03/13] task_isolation: userspace hard isolation from kernel
On Thu, 2020-10-01 at 15:56 +0200, Frederic Weisbecker wrote:
> External Email
>
> ---
> ---
> On Wed, Jul 22, 2020 at 02:49:49PM +, Alex Belits wrote:
> > +/*
> > + * Description of the last two tasks that ran isolated on a given
> > CPU.
> > + * This is intended only for messages about isolation breaking. We
> > + * don't want any references to actual task while accessing this
> > from
> > + * CPU that caused isolation breaking -- we know nothing about
> > timing
> > + * and don't want to use locking or RCU.
> > + */
> > +struct isol_task_desc {
> > + atomic_t curr_index;
> > + atomic_t curr_index_wr;
> > + boolwarned[2];
> > + pid_t pid[2];
> > + pid_t tgid[2];
> > + charcomm[2][TASK_COMM_LEN];
> > +};
> > +static DEFINE_PER_CPU(struct isol_task_desc, isol_task_descs);
>
> So that's quite a huge patch that would have needed to be split up.
> Especially this tracing engine.
>
> Speaking of which, I agree with Thomas that it's unnecessary. It's
> too much
> code and complexity. We can use the existing trace events and perform
> the
> analysis from userspace to find the source of the disturbance.
The idea behind this is that isolation breaking events are supposed to
be known to the applications while applications run normally, and they
should not require any analysis or human intervention to be handled.
A process may exit isolation because some leftover delayed work, for
example, a timer or a workqueue, is still present on a CPU, or because
a page fault or some other exception, normally handled silently, is
caused by the task. It is also possible to direct an interrupt to a CPU
that is running an isolated task -- currently it's perfectly valid to
set interrupt smp affinity to a CPU running isolated task, and then
interrupt will cause breaking isolation. While it's probably not the
best way of handling interrupts, I would rather not prohibit this
explicitly.
There is also a matter of avoiding race conditions on entering
isolation. Once CPU entered isolation, other CPUs should avoid
disturbing it when they know that CPU is running a task in isolated
mode. However for a short time after entering isolation other CPUs may
be unaware of this, and will still send IPIs to it. Preventing this
scenario completely would be very costly in terms of what other CPUs
will have to do before notifying others, so similar to how EINTR works,
we can simply specify that this is allowed, and task is supposed to re-
enter isolation after this. It's still a bad idea to specify that
isolation breaking can continue happening while application is running
in isolated mode, however allowing some "grace period" after entering
is acceptable as long as application is aware of this happening.
In libtmc I have moved this handling of isolation breaking into a
separate thread, intended to become a separate daemon if necessary. In
part it was done because initial implementation of isolation made it
very difficult to avoid repeating delayed work on isolated CPUs, so
something had to watch for it from non-isolated CPU. It's possible that
now, when delayed work does not appear on isolated CPUs out of nowhere,
the need in isolation manager thread will disappear, and task itself
will be able to handle all isolation breaking, like original
implementation by Chris was supposed to.
However in either case it's still useful for the task, or isolation
manager, to get a description of the isolation-breaking event. This is
what those things are intended for. Now they only produce log messages
because this is where initially all description of isolation-breaking
events went, however I would prefer to make logging optional but always
let applications read those events descriptions, regardless of any
tracing mechanism being used. I was more focused on making the
reporting mechanism properly detect the cause of isolation breaking
because that functionality was not quite working in earlier work by
Chris and Yuri, so I have kept logging as the only output, but made it
suitable for producing events that applications will be able to
receive. Application, or isolation manager, will receive clear and
unambiguous reporting, so there will be no need for any additional
analysis or guesswork.
After adding a proper "low-level" isolation flags, I got the idea that
we might have a better yet reporting mechanism. Early isolation
breaking detection on kernel entry may set a flag that says that
isolation breaking happened, however its cause is unknown. Or, more
likely, only some general information about isolation breaking is
available, like a type of exception. Then, once a known isolation-
breaking reporting mechanism is called from interrupt, syscall, IPI or
exception processing, the flag is cleared, and reporting is supposed to
be done. However if then kernel returns to userspace on isolated task
but isolation breaking is not reported yet, an isolation breaking
reporting w
Re: [PATCH v39 11/24] x86/sgx: Add SGX enclave driver
On Sun, Oct 04, 2020 at 05:32:57PM +0300, Jarkko Sakkinen wrote: > On Sat, Oct 03, 2020 at 04:39:25PM +0200, Greg KH wrote: > > You use gpl-only header files in this file, so how in the world can it > > be bsd-3 licensed? > > > > Please get your legal department to agree with this, after you explain > > to them how you are mixing gpl2-only code in with this file. > > I'll do what I already stated that I will do. Should I do something > more? And forward this message to the aformentioned entity. /Jarkko
Re: [EXT] Re: [PATCH v4 03/13] task_isolation: userspace hard isolation from kernel
On Thu, 2020-10-01 at 16:40 +0200, Frederic Weisbecker wrote:
> External Email
>
> ---
> ---
> On Wed, Jul 22, 2020 at 02:49:49PM +, Alex Belits wrote:
> > +/**
> > + * task_isolation_kernel_enter() - clear low-level task isolation
> > flag
> > + *
> > + * This should be called immediately after entering kernel.
> > + */
> > +static inline void task_isolation_kernel_enter(void)
> > +{
> > + unsigned long flags;
> > +
> > + /*
> > +* This function runs on a CPU that ran isolated task.
> > +*
> > +* We don't want this CPU running code from the rest of kernel
> > +* until other CPUs know that it is no longer isolated.
> > +* When CPU is running isolated task until this point anything
> > +* that causes an interrupt on this CPU must end up calling
> > this
> > +* before touching the rest of kernel. That is, this function
> > or
> > +* fast_task_isolation_cpu_cleanup() or stop_isolation()
> > calling
> > +* it. If any interrupt, including scheduling timer, arrives,
> > it
> > +* will still end up here early after entering kernel.
> > +* From this point interrupts are disabled until all CPUs will
> > see
> > +* that this CPU is no longer running isolated task.
> > +*
> > +* See also fast_task_isolation_cpu_cleanup().
> > +*/
> > + smp_rmb();
>
> I'm a bit confused what this read memory barrier is ordering. Also
> against
> what it pairs.
My bad, I have kept it after there were left no write accesses from
other CPUs.
>
> > + if((this_cpu_read(ll_isol_flags) & FLAG_LL_TASK_ISOLATION) ==
> > 0)
> > + return;
> > +
> > + local_irq_save(flags);
> > +
> > + /* Clear low-level flags */
> > + this_cpu_write(ll_isol_flags, 0);
> > +
> > + /*
> > +* If something happened that requires a barrier that would
> > +* otherwise be called from remote CPUs by CPU kick procedure,
> > +* this barrier runs instead of it. After this barrier, CPU
> > +* kick procedure would see the updated ll_isol_flags, so it
> > +* will run its own IPI to trigger a barrier.
> > +*/
> > + smp_mb();
> > + /*
> > +* Synchronize instructions -- this CPU was not kicked while
> > +* in isolated mode, so it might require synchronization.
> > +* There might be an IPI if kick procedure happened and
> > +* ll_isol_flags was already updated while it assembled a CPU
> > +* mask. However if this did not happen, synchronize everything
> > +* here.
> > +*/
> > + instr_sync();
>
> It's the first time I meet an instruction barrier. I should get
> information
> about that but what is it ordering here?
Against barriers in instruction cache flushing (flush_icache_range()
and such).
> > + local_irq_restore(flags);
> > +}
>
> Thanks.
Re: [PATCH v4] staging: qlge: fix build breakage with dumping enabled
On Sat, Oct 03, 2020 at 02:53:48PM +0900, Benjamin Poirier wrote:
On 2020-10-03 07:59 +0800, Coiby Xu wrote:
This fixes commit 0107635e15ac
("staging: qlge: replace pr_err with netdev_err") which introduced an
build breakage of missing `struct ql_adapter *qdev` for some functions
and a warning of type mismatch with dumping enabled, i.e.,
$ make CFLAGS_MODULE="-DQL_ALL_DUMP -DQL_OB_DUMP -DQL_CB_DUMP \
-DQL_IB_DUMP -DQL_REG_DUMP -DQL_DEV_DUMP" M=drivers/staging/qlge
qlge_dbg.c: In function ‘ql_dump_ob_mac_rsp’:
qlge_dbg.c:2051:13: error: ‘qdev’ undeclared (first use in this function); did
you mean ‘cdev’?
2051 | netdev_err(qdev->ndev, "%s\n", __func__);
| ^~~~
qlge_dbg.c: In function ‘ql_dump_routing_entries’:
qlge_dbg.c:1435:10: warning: format ‘%s’ expects argument of type ‘char *’, but
argument 3 has type ‘int’ [-Wformat=]
1435 |"%s: Routing Mask %d = 0x%.08x\n",
| ~^
| |
| char *
| %d
1436 |i, value);
|~
||
|int
qlge_dbg.c:1435:37: warning: format ‘%x’ expects a matching ‘unsigned int’
argument [-Wformat=]
1435 |"%s: Routing Mask %d = 0x%.08x\n",
| ^
| |
| unsigned int
Note that now ql_dump_rx_ring/ql_dump_tx_ring won't check if the passed
parameter is a null pointer.
Fixes: 0107635e15ac ("staging: qlge: replace pr_err with netdev_err")
Reported-by: Benjamin Poirier
Suggested-by: Benjamin Poirier
Signed-off-by: Coiby Xu
---
Reviewed-by: Benjamin Poirier
Thank you! Btw, I guess when this patch is picked, the "Reviewed-by" tag
will also be included. So I needn't to send another patch, am I right?
--
Best regards,
Coiby
Re: [EXT] Re: [PATCH v4 10/13] task_isolation: don't interrupt CPUs with tick_nohz_full_kick_cpu()
On Thu, 2020-10-01 at 16:44 +0200, Frederic Weisbecker wrote:
> External Email
>
> ---
> ---
> On Wed, Jul 22, 2020 at 02:57:33PM +, Alex Belits wrote:
> > From: Yuri Norov
> >
> > For nohz_full CPUs the desirable behavior is to receive interrupts
> > generated by tick_nohz_full_kick_cpu(). But for hard isolation it's
> > obviously not desirable because it breaks isolation.
> >
> > This patch adds check for it.
> >
> > Signed-off-by: Yuri Norov
> > [abel...@marvell.com: updated, only exclude CPUs running isolated
> > tasks]
> > Signed-off-by: Alex Belits
> > ---
> > kernel/time/tick-sched.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > index 6e4cd8459f05..2f82a6daf8fc 100644
> > --- a/kernel/time/tick-sched.c
> > +++ b/kernel/time/tick-sched.c
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -268,7 +269,8 @@ static void tick_nohz_full_kick(void)
> > */
> > void tick_nohz_full_kick_cpu(int cpu)
> > {
> > - if (!tick_nohz_full_cpu(cpu))
> > + smp_rmb();
>
> What is it ordering?
ll_isol_flags will be read in task_isolation_on_cpu(), that accrss
should be ordered against writing in
task_isolation_kernel_enter(), fast_task_isolation_cpu_cleanup()
and task_isolation_start().
Since task_isolation_on_cpu() is often called for multiple CPUs in a
sequence, it would be wasteful to include a barrier inside it.
> > + if (!tick_nohz_full_cpu(cpu) || task_isolation_on_cpu(cpu))
> > return;
>
> You can't simply ignore an IPI. There is always a reason for a
> nohz_full CPU
> to be kicked. Something triggered a tick dependency. It can be posix
> cpu timers
> for example, or anything.
I realize that this is unusual, however the idea is that while the task
is running in isolated mode in userspace, we assume that from this CPUs
point of view whatever is happening in kernel, can wait until CPU is
back in kernel, and when it first enters kernel from this mode, it
should "catch up" with everything that happened in its absence.
task_isolation_kernel_enter() is supposed to do that, so by the time
anything should be done involving the rest of the kernel, CPU is back
to normal.
It is application's responsibility to avoid triggering things that
break its isolation, so the application assumes that everything that
involves entering kernel will not be available while it is isolated. If
isolation will be broken, or application will request return from
isolation, everything will go back to normal environment with all
functionality available.
> >
> > irq_work_queue_on(&per_cpu(nohz_full_kick_work, cpu), cpu);
> > --
> > 2.26.2
> >
Re: [Linux-kernel-mentees] [PATCH] fs: fix KMSAN uninit-value bug by initializing nd in do_file_open_root
On 20-09-2020 01:47, Anant Thazhemadam wrote: > On 19-09-2020 17:03, Anant Thazhemadam wrote: >> On 19-09-2020 22:25, Al Viro wrote: >>> On Sat, Sep 19, 2020 at 05:17:27PM +0100, Al Viro wrote: >>> Lovely... That would get an empty path and non-directory for a starting point, but it should end up with LAST_ROOT in nd->last_type. Which should not be able to reach the readers of those fields... Which kernel had that been on? >>> Yecchhh... I see what's going on; I suspect that this ought to be enough. >>> Folks, could somebody test it on the original reproducer setup? >> Sure. I can do that. > Looks like this patch actually fixes this bug. > I made syzbot test the patch, and no issues were triggered! > > Note: syzbot tested the patch with the KMSAN kernel, which > was recently rebased on v5.9-rc4. > > Thanks, > Anant Ping. Has the patch that was tested been applied to any tree yet? If yes, could someone please let me know the commit details, so we can close the issue? (Unfortunately, I was unable to find it. :( ) Thanks, Anant
[PATCH v6] ipvs: inspect reply packets from DR/TUN real servers
Just like for MASQ, inspect the reply packets coming from DR/TUN
real servers and alter the connection's state and timeout
according to the protocol.
It's ipvs's duty to do traffic statistic if packets get hit,
no matter what mode it is.
---
Changes in v1: support DR/TUN mode statistic
Changes in v2: ip_vs_conn_out_get handles DR/TUN mode's conn
Changes in v3: fix checkpatch
Changes in v4, v5: restructure and optimise this feature
Changes in v6: rewrite subject and patch description
Signed-off-by: longguang.yue
---
net/netfilter/ipvs/ip_vs_conn.c | 18 +++---
net/netfilter/ipvs/ip_vs_core.c | 17 ++---
2 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index a90b8eac16ac..af08ca2d9174 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -401,6 +401,8 @@ struct ip_vs_conn *ip_vs_ct_in_get(const struct
ip_vs_conn_param *p)
struct ip_vs_conn *ip_vs_conn_out_get(const struct ip_vs_conn_param *p)
{
unsigned int hash;
+ __be16 sport;
+ const union nf_inet_addr *saddr;
struct ip_vs_conn *cp, *ret=NULL;
/*
@@ -411,10 +413,20 @@ struct ip_vs_conn *ip_vs_conn_out_get(const struct
ip_vs_conn_param *p)
rcu_read_lock();
hlist_for_each_entry_rcu(cp, &ip_vs_conn_tab[hash], c_list) {
- if (p->vport == cp->cport && p->cport == cp->dport &&
- cp->af == p->af &&
+ if (p->vport != cp->cport)
+ continue;
+
+ if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ) {
+ sport = cp->vport;
+ saddr = &cp->vaddr;
+ } else {
+ sport = cp->dport;
+ saddr = &cp->daddr;
+ }
+
+ if (p->cport == sport && cp->af == p->af &&
ip_vs_addr_equal(p->af, p->vaddr, &cp->caddr) &&
- ip_vs_addr_equal(p->af, p->caddr, &cp->daddr) &&
+ ip_vs_addr_equal(p->af, p->caddr, saddr) &&
p->protocol == cp->protocol &&
cp->ipvs == p->ipvs) {
if (!__ip_vs_conn_get(cp))
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index e3668a6e54e4..494ea1fcf4d8 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -875,7 +875,7 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
unsigned int verdict = NF_DROP;
if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
- goto ignore_cp;
+ goto after_nat;
/* Ensure the checksum is correct */
if (!skb_csum_unnecessary(skb) && ip_vs_checksum_complete(skb, ihl)) {
@@ -900,7 +900,7 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
if (ip_vs_route_me_harder(cp->ipvs, af, skb, hooknum))
goto out;
-
+after_nat:
/* do the statistics and put it back */
ip_vs_out_stats(cp, skb);
@@ -909,8 +909,6 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
ip_vs_notrack(skb);
else
ip_vs_update_conntrack(skb, cp, 0);
-
-ignore_cp:
verdict = NF_ACCEPT;
out:
@@ -1276,6 +1274,9 @@ handle_response(int af, struct sk_buff *skb, struct
ip_vs_proto_data *pd,
{
struct ip_vs_protocol *pp = pd->pp;
+ if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
+ goto after_nat;
+
IP_VS_DBG_PKT(11, af, pp, skb, iph->off, "Outgoing packet");
if (skb_ensure_writable(skb, iph->len))
@@ -1316,6 +1317,7 @@ handle_response(int af, struct sk_buff *skb, struct
ip_vs_proto_data *pd,
IP_VS_DBG_PKT(10, af, pp, skb, iph->off, "After SNAT");
+after_nat:
ip_vs_out_stats(cp, skb);
ip_vs_set_state(cp, IP_VS_DIR_OUTPUT, skb, pd);
skb->ipvs_property = 1;
@@ -1413,8 +1415,6 @@ ip_vs_out(struct netns_ipvs *ipvs, unsigned int hooknum,
struct sk_buff *skb, in
ipvs, af, skb, &iph);
if (likely(cp)) {
- if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
- goto ignore_cp;
return handle_response(af, skb, pd, cp, &iph, hooknum);
}
@@ -1475,14 +1475,9 @@ ip_vs_out(struct netns_ipvs *ipvs, unsigned int hooknum,
struct sk_buff *skb, in
}
}
-out:
IP_VS_DBG_PKT(12, af, pp, skb, iph.off,
"ip_vs_out: packet continues traversal as normal");
return NF_ACCEPT;
-
-ignore_cp:
- __ip_vs_conn_put(cp);
- goto out;
}
/*
--
2.20.1 (Apple Git-117)
Re: [PATCH 1/2] usb: serial: qmi_wwan: add Cellient MPL200 card
Wilken Gottwalt writes:
> Add usb ids of the Cellient MPL200 card.
>
> Signed-off-by: Wilken Gottwalt
> ---
> drivers/net/usb/qmi_wwan.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index 07c42c0719f5..0bf2b19d5d54 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
This is not a 'usb: serial' driver. Please resend with a less confusing
subject prefix.
> @@ -1432,6 +1432,7 @@ static const struct usb_device_id products[] = {
> {QMI_GOBI_DEVICE(0x1199, 0x901b)}, /* Sierra Wireless MC7770 */
> {QMI_GOBI_DEVICE(0x12d1, 0x14f1)}, /* Sony Gobi 3000 Composite */
> {QMI_GOBI_DEVICE(0x1410, 0xa021)}, /* Foxconn Gobi 3000 Modem
> device (Novatel E396) */
> + {QMI_FIXED_INTF(0x2692, 0x9025, 4)},/* Cellient MPL200 (rebranded
> Qualcomm 0x05c6) */
>
> { } /* END */
> };
This table is supposed to be organized by device type. The last section
is for Gobi2k and Gobi3k devices. Please try to put new devices into
the correct section.
Thanks
Bjørn
[PATCH v6] ipvs: adjust the debug info in function set_tcp_state
Outputting client,virtual,dst addresses info when tcp state changes,
which makes the connection debug more clear
---
v5,v6: fix indentation and add changelogs
v3,v4: fix checkpatch
v2: IP_VS_DBG_BUF outputs src,virtual,dst of ip_vs_conn
v1: fix the inverse of src and dst address
Signed-off-by: longguang.yue
---
net/netfilter/ipvs/ip_vs_proto_tcp.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_proto_tcp.c
b/net/netfilter/ipvs/ip_vs_proto_tcp.c
index dc2e7da2742a..7da51390cea6 100644
--- a/net/netfilter/ipvs/ip_vs_proto_tcp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_tcp.c
@@ -539,8 +539,8 @@ set_tcp_state(struct ip_vs_proto_data *pd, struct
ip_vs_conn *cp,
if (new_state != cp->state) {
struct ip_vs_dest *dest = cp->dest;
- IP_VS_DBG_BUF(8, "%s %s [%c%c%c%c] %s:%d->"
- "%s:%d state: %s->%s conn->refcnt:%d\n",
+ IP_VS_DBG_BUF(8, "%s %s [%c%c%c%c] c:%s:%d v:%s:%d "
+ "d:%s:%d state: %s->%s conn->refcnt:%d\n",
pd->pp->name,
((state_off == TCP_DIR_OUTPUT) ?
"output " : "input "),
@@ -548,10 +548,12 @@ set_tcp_state(struct ip_vs_proto_data *pd, struct
ip_vs_conn *cp,
th->fin ? 'F' : '.',
th->ack ? 'A' : '.',
th->rst ? 'R' : '.',
- IP_VS_DBG_ADDR(cp->daf, &cp->daddr),
- ntohs(cp->dport),
IP_VS_DBG_ADDR(cp->af, &cp->caddr),
ntohs(cp->cport),
+ IP_VS_DBG_ADDR(cp->af, &cp->vaddr),
+ ntohs(cp->vport),
+ IP_VS_DBG_ADDR(cp->daf, &cp->daddr),
+ ntohs(cp->dport),
tcp_state_name(cp->state),
tcp_state_name(new_state),
refcount_read(&cp->refcnt));
--
2.20.1 (Apple Git-117)
[PATCH rdma-next v5 2/4] tools/testing/scatterlist: Rejuvenate bit-rotten test
From: Tvrtko Ursulin
A couple small tweaks are needed to make the test build and run
on current kernels.
Signed-off-by: Tvrtko Ursulin
Cc: Maor Gottlieb
Signed-off-by: Leon Romanovsky
---
tools/testing/scatterlist/Makefile | 3 ++-
tools/testing/scatterlist/linux/mm.h | 35
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/tools/testing/scatterlist/Makefile
b/tools/testing/scatterlist/Makefile
index cbb003d9305e..c65233876622 100644
--- a/tools/testing/scatterlist/Makefile
+++ b/tools/testing/scatterlist/Makefile
@@ -14,7 +14,7 @@ targets: include $(TARGETS)
main: $(OFILES)
clean:
- $(RM) $(TARGETS) $(OFILES) scatterlist.c linux/scatterlist.h
linux/highmem.h linux/kmemleak.h asm/io.h
+ $(RM) $(TARGETS) $(OFILES) scatterlist.c linux/scatterlist.h
linux/highmem.h linux/kmemleak.h linux/slab.h asm/io.h
@rmdir asm
scatterlist.c: ../../../lib/scatterlist.c
@@ -28,4 +28,5 @@ include: ../../../include/linux/scatterlist.h
@touch asm/io.h
@touch linux/highmem.h
@touch linux/kmemleak.h
+ @touch linux/slab.h
@cp $< linux/scatterlist.h
diff --git a/tools/testing/scatterlist/linux/mm.h
b/tools/testing/scatterlist/linux/mm.h
index 6f9ac14aa800..6ae907f375d2 100644
--- a/tools/testing/scatterlist/linux/mm.h
+++ b/tools/testing/scatterlist/linux/mm.h
@@ -114,6 +114,12 @@ static inline void *kmalloc(unsigned int size, unsigned
int flags)
return malloc(size);
}
+static inline void *
+kmalloc_array(unsigned int n, unsigned int size, unsigned int flags)
+{
+ return malloc(n * size);
+}
+
#define kfree(x) free(x)
#define kmemleak_alloc(a, b, c, d)
@@ -122,4 +128,33 @@ static inline void *kmalloc(unsigned int size, unsigned
int flags)
#define PageSlab(p) (0)
#define flush_kernel_dcache_page(p)
+#define MAX_ERRNO 4095
+
+#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned
long)-MAX_ERRNO)
+
+static inline void * __must_check ERR_PTR(long error)
+{
+ return (void *) error;
+}
+
+static inline long __must_check PTR_ERR(__force const void *ptr)
+{
+ return (long) ptr;
+}
+
+static inline bool __must_check IS_ERR(__force const void *ptr)
+{
+ return IS_ERR_VALUE((unsigned long)ptr);
+}
+
+static inline int __must_check PTR_ERR_OR_ZERO(__force const void *ptr)
+{
+ if (IS_ERR(ptr))
+ return PTR_ERR(ptr);
+ else
+ return 0;
+}
+
+#define IS_ENABLED(x) (0)
+
#endif
--
2.26.2
[PATCH rdma-next v5 0/4] Dynamicaly allocate SG table from the pages
From: Leon Romanovsky Changelog: v5: * Use sg_init_table to allocate table and avoid changes is __sg_alloc_table * Fix offset issue v4: https://lore.kernel.org/lkml/20200927064647.3106737-1-l...@kernel.org * Fixed formatting in first patch. * Added fix (clear tmp_netnts) in first patch to fix i915 failure. * Added test patches v3: https://lore.kernel.org/linux-rdma/20200922083958.2150803-1-l...@kernel.org/ * Squashed Christopher's suggestion to avoid introduced new API, but extend existing one. v2: https://lore.kernel.org/linux-rdma/20200916140726.839377-1-l...@kernel.org * Fixed indentations and comments * Deleted sg_alloc_next() * Squashed lib/scatterlist patches into one v1: https://lore.kernel.org/lkml/20200910134259.1304543-1-l...@kernel.org * Changed _sg_chain to be __sg_chain * Added dependency on ARCH_NO_SG_CHAIN * Removed struct sg_append v0: * https://lore.kernel.org/lkml/20200903121853.1145976-1-l...@kernel.org -- >From Maor: This series extends __sg_alloc_table_from_pages to allow chaining of new pages to already initialized SG table. This allows for the drivers to utilize the optimization of merging contiguous pages without a need to pre allocate all the pages and hold them in a very large temporary buffer prior to the call to SG table initialization. The second patch changes the Infiniband driver to use the new API. It removes duplicate functionality from the code and benefits the optimization of allocating dynamic SG table from pages. In huge pages system of 2MB page size, without this change, the SG table would contain x512 SG entries. E.g. for 100GB memory registration: Number of entries Size Before26214400 600.0MB After512001.2MB Thanks Maor Gottlieb (2): lib/scatterlist: Add support in dynamic allocation of SG table from pages RDMA/umem: Move to allocate SG table from pages Tvrtko Ursulin (2): tools/testing/scatterlist: Rejuvenate bit-rotten test tools/testing/scatterlist: Show errors in human readable form drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 15 ++- drivers/infiniband/core/umem.c | 94 ++- include/linux/scatterlist.h | 38 +++--- lib/scatterlist.c | 125 tools/testing/scatterlist/Makefile | 3 +- tools/testing/scatterlist/linux/mm.h| 35 ++ tools/testing/scatterlist/main.c| 53 ++--- 8 files changed, 225 insertions(+), 150 deletions(-) -- 2.26.2
[PATCH rdma-next v5 1/4] lib/scatterlist: Add support in dynamic allocation of SG table from pages
From: Maor Gottlieb
Extend __sg_alloc_table_from_pages to support dynamic allocation of
SG table from pages. It should be used by drivers that can't supply
all the pages at one time.
This function returns the last populated SGE in the table. Users should
pass it as an argument to the function from the second call and forward.
As before, nents will be equal to the number of populated SGEs (chunks).
With this new extension, drivers can benefit the optimization of merging
contiguous pages without a need to allocate all pages in advance and
hold them in a large buffer.
E.g. with the Infiniband driver that allocates a single page for hold the
pages. For 1TB memory registration, the temporary buffer would consume only
4KB, instead of 2GB.
Signed-off-by: Maor Gottlieb
Reviewed-by: Christoph Hellwig
Signed-off-by: Leon Romanovsky
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 12 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 15 ++-
include/linux/scatterlist.h | 38 +++---
lib/scatterlist.c | 125
tools/testing/scatterlist/main.c| 9 +-
5 files changed, 142 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 12b30075134a..f2eaed6aca3d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -403,6 +403,7 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object
*obj,
unsigned int max_segment = i915_sg_segment_size();
struct sg_table *st;
unsigned int sg_page_sizes;
+ struct scatterlist *sg;
int ret;
st = kmalloc(sizeof(*st), GFP_KERNEL);
@@ -410,13 +411,12 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object
*obj,
return ERR_PTR(-ENOMEM);
alloc_table:
- ret = __sg_alloc_table_from_pages(st, pvec, num_pages,
- 0, num_pages << PAGE_SHIFT,
- max_segment,
- GFP_KERNEL);
- if (ret) {
+ sg = __sg_alloc_table_from_pages(st, pvec, num_pages, 0,
+num_pages << PAGE_SHIFT, max_segment,
+NULL, 0, GFP_KERNEL);
+ if (IS_ERR(sg)) {
kfree(st);
- return ERR_PTR(ret);
+ return ERR_CAST(sg);
}
ret = i915_gem_gtt_prepare_pages(obj, st);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index ab524ab3b0b4..f22acd398b1f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -419,6 +419,7 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
int ret = 0;
static size_t sgl_size;
static size_t sgt_size;
+ struct scatterlist *sg;
if (vmw_tt->mapped)
return 0;
@@ -441,13 +442,15 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
if (unlikely(ret != 0))
return ret;
- ret = __sg_alloc_table_from_pages
- (&vmw_tt->sgt, vsgt->pages, vsgt->num_pages, 0,
-(unsigned long) vsgt->num_pages << PAGE_SHIFT,
-dma_get_max_seg_size(dev_priv->dev->dev),
-GFP_KERNEL);
- if (unlikely(ret != 0))
+ sg = __sg_alloc_table_from_pages(&vmw_tt->sgt, vsgt->pages,
+ vsgt->num_pages, 0,
+ (unsigned long) vsgt->num_pages << PAGE_SHIFT,
+ dma_get_max_seg_size(dev_priv->dev->dev),
+ NULL, 0, GFP_KERNEL);
+ if (IS_ERR(sg)) {
+ ret = PTR_ERR(sg);
goto out_sg_alloc_fail;
+ }
if (vsgt->num_pages > vmw_tt->sgt.nents) {
uint64_t over_alloc =
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 45cf7b69d852..36c47e7e66a2 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -165,6 +165,22 @@ static inline void sg_set_buf(struct scatterlist *sg,
const void *buf,
#define for_each_sgtable_dma_sg(sgt, sg, i)\
for_each_sg((sgt)->sgl, sg, (sgt)->nents, i)
+static inline void __sg_chain(struct scatterlist *chain_sg,
+ struct scatterlist *sgl)
+{
+ /*
+* offset and length are unused for chain entry. Clear them.
+*/
+ chain_sg->offset = 0;
+ chain_sg->length = 0;
+
+ /*
+* Set lowest bit to indicate a link pointer, and make sure to clear
+* the termination bit if it happens to be set.
+*/
+ chain_sg->page_link = ((unsigned long) sgl | SG_CHAIN) & ~SG_END;
+}
+
/**
*
[PATCH rdma-next v5 3/4] tools/testing/scatterlist: Show errors in human readable form
From: Tvrtko Ursulin
Instead of just asserting dump some more useful info about what the test
saw versus what it expected to see.
Signed-off-by: Tvrtko Ursulin
Cc: Maor Gottlieb
Signed-off-by: Leon Romanovsky
---
tools/testing/scatterlist/main.c | 44
1 file changed, 34 insertions(+), 10 deletions(-)
diff --git a/tools/testing/scatterlist/main.c b/tools/testing/scatterlist/main.c
index 4899359a31ac..b2c7e9f7b8d3 100644
--- a/tools/testing/scatterlist/main.c
+++ b/tools/testing/scatterlist/main.c
@@ -5,6 +5,15 @@
#define MAX_PAGES (64)
+struct test {
+ int alloc_ret;
+ unsigned num_pages;
+ unsigned *pfn;
+ unsigned size;
+ unsigned int max_seg;
+ unsigned int expected_segments;
+};
+
static void set_pages(struct page **pages, const unsigned *array, unsigned num)
{
unsigned int i;
@@ -17,17 +26,32 @@ static void set_pages(struct page **pages, const unsigned
*array, unsigned num)
#define pfn(...) (unsigned []){ __VA_ARGS__ }
+static void fail(struct test *test, struct sg_table *st, const char *cond)
+{
+ unsigned int i;
+
+ fprintf(stderr, "Failed on '%s'!\n\n", cond);
+
+ printf("size = %u, max segment = %u, expected nents = %u\nst->nents =
%u, st->orig_nents= %u\n",
+ test->size, test->max_seg, test->expected_segments, st->nents,
+ st->orig_nents);
+
+ printf("%u input PFNs:", test->num_pages);
+ for (i = 0; i < test->num_pages; i++)
+ printf(" %x", test->pfn[i]);
+ printf("\n");
+
+ exit(1);
+}
+
+#define VALIDATE(cond, st, test) \
+ if (!(cond)) \
+ fail((test), (st), #cond);
+
int main(void)
{
const unsigned int sgmax = SCATTERLIST_MAX_SEGMENT;
- struct test {
- int alloc_ret;
- unsigned num_pages;
- unsigned *pfn;
- unsigned size;
- unsigned int max_seg;
- unsigned int expected_segments;
- } *test, tests[] = {
+ struct test *test, tests[] = {
{ -EINVAL, 1, pfn(0), PAGE_SIZE, PAGE_SIZE + 1, 1 },
{ -EINVAL, 1, pfn(0), PAGE_SIZE, 0, 1 },
{ -EINVAL, 1, pfn(0), PAGE_SIZE, sgmax + 1, 1 },
@@ -66,8 +90,8 @@ int main(void)
if (test->alloc_ret)
continue;
- assert(st.nents == test->expected_segments);
- assert(st.orig_nents == test->expected_segments);
+ VALIDATE(st.nents == test->expected_segments, &st, test);
+ VALIDATE(st.orig_nents == test->expected_segments, &st, test);
sg_free_table(&st);
}
--
2.26.2
Re: [PATCH v4 2/2] hwmon: pmbus: max20730: adjust the vout reading given voltage divider
On Sun, Oct 04, 2020 at 03:14:45AM +, Chu Lin wrote:
> Problem:
> We use voltage dividers so that the voltage presented at the voltage
> sense pins is confusing. We might need to convert these readings to more
> meaningful readings given the voltage divider.
>
> Solution:
> Read the voltage divider resistance from dts and convert the voltage
> reading to a more meaningful reading.
>
> Testing:
> max20730 with voltage divider
>
> Signed-off-by: Chu Lin
> ---
> ChangeLog v1 -> v2
> hwmon: pmbus: max20730:
> - Don't do anything to the ret if an error is returned from pmbus_read_word
> - avoid overflow when doing multiplication
>
> ChangeLog v2 -> v3
> dt-bindings: hwmon: max20730:
> - Provide the binding documentation in yaml format
> hwmon: pmbus: max20730:
> - No change
>
> ChangeLog v3 -> v4
> dt-bindings: hwmon: max20730:
> - Fix highefficiency to high efficiency in description
> - Fix presents to present in vout-voltage-divider
> - Add additionalProperties: false
> hwmon: pmbus: max20730:
> - No change
You claim that there have been no changes since v2 of this patch,
yet you dropped my Reviewed-by: tag. Any reason ?
Guenter
>
> drivers/hwmon/pmbus/max20730.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/hwmon/pmbus/max20730.c b/drivers/hwmon/pmbus/max20730.c
> index a151a2b588a5..fbf2f1e6c969 100644
> --- a/drivers/hwmon/pmbus/max20730.c
> +++ b/drivers/hwmon/pmbus/max20730.c
> @@ -31,6 +31,7 @@ struct max20730_data {
> struct pmbus_driver_info info;
> struct mutex lock; /* Used to protect against parallel writes */
> u16 mfr_devset1;
> + u32 vout_voltage_divider[2];
> };
>
> #define to_max20730_data(x) container_of(x, struct max20730_data, info)
> @@ -114,6 +115,14 @@ static int max20730_read_word_data(struct i2c_client
> *client, int page,
> max_c = max_current[data->id][(data->mfr_devset1 >> 5) & 0x3];
> ret = val_to_direct(max_c, PSC_CURRENT_OUT, info);
> break;
> + case PMBUS_READ_VOUT:
> + ret = pmbus_read_word_data(client, page, phase, reg);
> + if (ret > 0 && data->vout_voltage_divider[0] &&
> data->vout_voltage_divider[1]) {
> + u64 temp = DIV_ROUND_CLOSEST_ULL((u64)ret *
> data->vout_voltage_divider[1],
> +
> data->vout_voltage_divider[0]);
> + ret = clamp_val(temp, 0, 0x);
> + }
> + break;
> default:
> ret = -ENODATA;
> break;
> @@ -364,6 +373,15 @@ static int max20730_probe(struct i2c_client *client,
> data->id = chip_id;
> mutex_init(&data->lock);
> memcpy(&data->info, &max20730_info[chip_id], sizeof(data->info));
> + if (of_property_read_u32_array(client->dev.of_node,
> "vout-voltage-divider",
> +data->vout_voltage_divider,
> +ARRAY_SIZE(data->vout_voltage_divider))
> != 0)
> + memset(data->vout_voltage_divider, 0,
> sizeof(data->vout_voltage_divider));
> + if (data->vout_voltage_divider[1] < data->vout_voltage_divider[0]) {
> + dev_err(dev,
> + "The total resistance of voltage divider is less than
> output resistance\n");
> + return -ENODEV;
> + }
>
> ret = i2c_smbus_read_word_data(client, MAX20730_MFR_DEVSET1);
> if (ret < 0)
> --
> 2.28.0.806.g8561365e88-goog
>
[PATCH rdma-next v5 4/4] RDMA/umem: Move to allocate SG table from pages
From: Maor Gottlieb
Remove the implementation of ib_umem_add_sg_table and instead
call to __sg_alloc_table_from_pages which already has the logic to
merge contiguous pages.
Besides that it removes duplicated functionality, it reduces the
memory consumption of the SG table significantly. Prior to this
patch, the SG table was allocated in advance regardless consideration
of contiguous pages.
In huge pages system of 2MB page size, without this change, the SG table
would contain x512 SG entries.
E.g. for 100GB memory registration:
Number of entries Size
Before26214400 600.0MB
After512001.2MB
Signed-off-by: Maor Gottlieb
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/umem.c | 94 +-
1 file changed, 12 insertions(+), 82 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index c1ab6a4f2bc3..e9fecbdf391b 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -61,73 +61,6 @@ static void __ib_umem_release(struct ib_device *dev, struct
ib_umem *umem, int d
sg_free_table(&umem->sg_head);
}
-/* ib_umem_add_sg_table - Add N contiguous pages to scatter table
- *
- * sg: current scatterlist entry
- * page_list: array of npage struct page pointers
- * npages: number of pages in page_list
- * max_seg_sz: maximum segment size in bytes
- * nents: [out] number of entries in the scatterlist
- *
- * Return new end of scatterlist
- */
-static struct scatterlist *ib_umem_add_sg_table(struct scatterlist *sg,
- struct page **page_list,
- unsigned long npages,
- unsigned int max_seg_sz,
- int *nents)
-{
- unsigned long first_pfn;
- unsigned long i = 0;
- bool update_cur_sg = false;
- bool first = !sg_page(sg);
-
- /* Check if new page_list is contiguous with end of previous page_list.
-* sg->length here is a multiple of PAGE_SIZE and sg->offset is 0.
-*/
- if (!first && (page_to_pfn(sg_page(sg)) + (sg->length >> PAGE_SHIFT) ==
- page_to_pfn(page_list[0])))
- update_cur_sg = true;
-
- while (i != npages) {
- unsigned long len;
- struct page *first_page = page_list[i];
-
- first_pfn = page_to_pfn(first_page);
-
- /* Compute the number of contiguous pages we have starting
-* at i
-*/
- for (len = 0; i != npages &&
- first_pfn + len == page_to_pfn(page_list[i]) &&
- len < (max_seg_sz >> PAGE_SHIFT);
-len++)
- i++;
-
- /* Squash N contiguous pages from page_list into current sge */
- if (update_cur_sg) {
- if ((max_seg_sz - sg->length) >= (len << PAGE_SHIFT)) {
- sg_set_page(sg, sg_page(sg),
- sg->length + (len << PAGE_SHIFT),
- 0);
- update_cur_sg = false;
- continue;
- }
- update_cur_sg = false;
- }
-
- /* Squash N contiguous pages into next sge or first sge */
- if (!first)
- sg = sg_next(sg);
-
- (*nents)++;
- sg_set_page(sg, first_page, len << PAGE_SHIFT, 0);
- first = false;
- }
-
- return sg;
-}
-
/**
* ib_umem_find_best_pgsz - Find best HW page size to use for this MR
*
@@ -217,7 +150,7 @@ struct ib_umem *ib_umem_get(struct ib_device *device,
unsigned long addr,
struct mm_struct *mm;
unsigned long npages;
int ret;
- struct scatterlist *sg;
+ struct scatterlist *sg = NULL;
unsigned int gup_flags = FOLL_WRITE;
/*
@@ -272,15 +205,9 @@ struct ib_umem *ib_umem_get(struct ib_device *device,
unsigned long addr,
cur_base = addr & PAGE_MASK;
- ret = sg_alloc_table(&umem->sg_head, npages, GFP_KERNEL);
- if (ret)
- goto vma;
-
if (!umem->writable)
gup_flags |= FOLL_FORCE;
- sg = umem->sg_head.sgl;
-
while (npages) {
cond_resched();
ret = pin_user_pages_fast(cur_base,
@@ -292,15 +219,19 @@ struct ib_umem *ib_umem_get(struct ib_device *device,
unsigned long addr,
goto umem_release;
cur_base += ret * PAGE_SIZE;
- npages -= ret;
-
- sg = ib_umem_add_sg_table(sg, page_list, ret,
- dma_get_max_seg_size(device->dma_device),
- &umem->sg_nent
Re: [PATCH] drm/bridge: ti-sn65dsi86: Add retries for link training
On 10/2/20 4:03 PM, Douglas Anderson wrote:
> On some panels hooked up to the ti-sn65dsi86 bridge chip we found that
> link training was failing. Specifically, we'd see:
>
> ti_sn65dsi86 2-002d: [drm:ti_sn_bridge_enable] *ERROR* Link training
> failed, link is off (-5)
>
> The panel was hooked up to a logic analyzer and it was found that, as
> part of link training, the bridge chip was writing a 0x1 to DPCD
> address 00600h and the panel responded NACK. As can be seen in header
> files, the write of 0x1 to DPCD address 0x600h means we were trying to
> write the value DP_SET_POWER_D0 to the register DP_SET_POWER. The
> panel vendor says that a NACK in this case is not unexpected and means
> "not ready, try again".
>
> In testing, we found that this panel would respond with a NACK in
> about 1/25 times. Adding the retry logic worked fine and the most
> number of tries needed was 3. Just to be safe, we'll add 10 tries
> here and we'll add a little blurb to the logs if we ever need more
> than 5.
>
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 40 +++
> 1 file changed, 29 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index ecdf9b01340f..6e12cda69b54 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -106,6 +106,8 @@
> #define SN_NUM_GPIOS 4
> #define SN_GPIO_PHYSICAL_OFFSET 1
>
> +#define SN_LINK_TRAINING_TRIES 10
> +
> /**
> * struct ti_sn_bridge - Platform data for ti-sn65dsi86 driver.
> * @dev: Pointer to our device.
> @@ -673,6 +675,7 @@ static int ti_sn_link_training(struct ti_sn_bridge
> *pdata, int dp_rate_idx,
> {
> unsigned int val;
> int ret;
> + int i;
>
> /* set dp clk frequency value */
> regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG,
> @@ -689,19 +692,34 @@ static int ti_sn_link_training(struct ti_sn_bridge
> *pdata, int dp_rate_idx,
> goto exit;
> }
>
> - /* Semi auto link training mode */
> - regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
> - ret = regmap_read_poll_timeout(pdata->regmap, SN_ML_TX_MODE_REG, val,
> -val == ML_TX_MAIN_LINK_OFF ||
> -val == ML_TX_NORMAL_MODE, 1000,
> -500 * 1000);
> - if (ret) {
> - *last_err_str = "Training complete polling failed";
> - } else if (val == ML_TX_MAIN_LINK_OFF) {
> - *last_err_str = "Link training failed, link is off";
> - ret = -EIO;
> + /*
> + * We'll try to link train several times. As part of link training
> + * the bridge chip will write DP_SET_POWER_D0 to DP_SET_POWER. If
> + * the panel isn't ready quite it might respond NAK here which means
> + * we need to try again.
> + */
> + for (i = 0; i < SN_LINK_TRAINING_TRIES; i++) {
> + /* Semi auto link training mode */
> + regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
> + ret = regmap_read_poll_timeout(pdata->regmap,
> SN_ML_TX_MODE_REG, val,
> + val == ML_TX_MAIN_LINK_OFF ||
> + val == ML_TX_NORMAL_MODE, 1000,
> + 500 * 1000);
> + if (ret) {
> + *last_err_str = "Training complete polling failed";
> + } else if (val == ML_TX_MAIN_LINK_OFF) {
> + *last_err_str = "Link training failed, link is off";
> + ret = -EIO;
> + continue;
> + }
> +
> + break;
> }
>
> + /* If we saw quite a few retries, add a note about it */
> + if (!ret && i > SN_LINK_TRAINING_TRIES / 2)
> + DRM_DEV_INFO(pdata->dev, "Link training needed %d retries\n",
> i);
> +
> exit:
> /* Disable the PLL if we failed */
> if (ret)
Apologies for the previous HTML email, I was trying a new mail client
and... will not be switching to it.
Anyway.. again, this time in text..
Tested on the Lenovo C630, and haven’t seen the message, although I
hadn’t seen the described issue before either.
Tested-By: Steev Klimaszewski
Re: [PATCH v4] hwmon (pmbus/max20730): add device monitoring via debugfs
On Tue, Sep 22, 2020 at 07:15:38PM +, Ugur Usug wrote:
> Add debugfs interface support for accessing device specific registers
> (MFR_VOUT_MIN,
> MFR_DEVSET1 and MFR_DEVSET2) and others including OPERATION, ON_OFF_CONFIG,
> SMB_ALERT_MASK, VOUT_MODE, VOUT_COMMAND and VOUT_MAX.
>
> This patch changes following items in max20730_debugfs_read():
> - the EINVAL returns to "Invalid" or "Not supported"
> - strcpy() and strnlen() calls to strlcpy() calls
> - VOUT_MODE, VOUT_COMMAND and VOUT_MAX raw outputs to unit volts
> - terminating '\0' characters to the simple_read_from_buffer() return
>
> Signed-off-by: Ugur Usug
Applied.
Thanks,
Guenter
> ---
> drivers/hwmon/pmbus/max20730.c | 363
> -
> 1 file changed, 362 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwmon/pmbus/max20730.c b/drivers/hwmon/pmbus/max20730.c
> index a151a2b..3175c9b 100644
> --- a/drivers/hwmon/pmbus/max20730.c
> +++ b/drivers/hwmon/pmbus/max20730.c
> @@ -8,6 +8,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -26,16 +27,367 @@ enum chips {
> max20743
> };
>
> +enum {
> + MAX20730_DEBUGFS_VOUT_MIN = 0,
> + MAX20730_DEBUGFS_FREQUENCY,
> + MAX20730_DEBUGFS_PG_DELAY,
> + MAX20730_DEBUGFS_INTERNAL_GAIN,
> + MAX20730_DEBUGFS_BOOT_VOLTAGE,
> + MAX20730_DEBUGFS_OUT_V_RAMP_RATE,
> + MAX20730_DEBUGFS_OC_PROTECT_MODE,
> + MAX20730_DEBUGFS_SS_TIMING,
> + MAX20730_DEBUGFS_IMAX,
> + MAX20730_DEBUGFS_OPERATION,
> + MAX20730_DEBUGFS_ON_OFF_CONFIG,
> + MAX20730_DEBUGFS_SMBALERT_MASK,
> + MAX20730_DEBUGFS_VOUT_MODE,
> + MAX20730_DEBUGFS_VOUT_COMMAND,
> + MAX20730_DEBUGFS_VOUT_MAX,
> + MAX20730_DEBUGFS_NUM_ENTRIES
> +};
> +
> struct max20730_data {
> enum chips id;
> struct pmbus_driver_info info;
> struct mutex lock; /* Used to protect against parallel writes */
> u16 mfr_devset1;
> + u16 mfr_devset2;
> + u16 mfr_voutmin;
> };
>
> #define to_max20730_data(x) container_of(x, struct max20730_data, info)
>
> +#define VOLT_FROM_REG(val) DIV_ROUND_CLOSEST((val), 1 << 9)
> +
> +#define PMBUS_SMB_ALERT_MASK 0x1B
> +
> +#define MAX20730_MFR_VOUT_MIN0xd1
> #define MAX20730_MFR_DEVSET1 0xd2
> +#define MAX20730_MFR_DEVSET2 0xd3
> +
> +#define MAX20730_MFR_VOUT_MIN_MASK GENMASK(9, 0)
> +#define MAX20730_MFR_VOUT_MIN_BIT_POS0
> +
> +#define MAX20730_MFR_DEVSET1_RGAIN_MASK (BIT(13) | BIT(14))
> +#define MAX20730_MFR_DEVSET1_OTP_MASK(BIT(11) | BIT(12))
> +#define MAX20730_MFR_DEVSET1_VBOOT_MASK (BIT(8) | BIT(9))
> +#define MAX20730_MFR_DEVSET1_OCP_MASK(BIT(5) | BIT(6))
> +#define MAX20730_MFR_DEVSET1_FSW_MASKGENMASK(4, 2)
> +#define MAX20730_MFR_DEVSET1_TSTAT_MASK (BIT(0) | BIT(1))
> +
> +#define MAX20730_MFR_DEVSET1_RGAIN_BIT_POS 13
> +#define MAX20730_MFR_DEVSET1_OTP_BIT_POS 11
> +#define MAX20730_MFR_DEVSET1_VBOOT_BIT_POS 8
> +#define MAX20730_MFR_DEVSET1_OCP_BIT_POS 5
> +#define MAX20730_MFR_DEVSET1_FSW_BIT_POS 2
> +#define MAX20730_MFR_DEVSET1_TSTAT_BIT_POS 0
> +
> +#define MAX20730_MFR_DEVSET2_IMAX_MASK GENMASK(10, 8)
> +#define MAX20730_MFR_DEVSET2_VRATE (BIT(6) | BIT(7))
> +#define MAX20730_MFR_DEVSET2_OCPM_MASK BIT(5)
> +#define MAX20730_MFR_DEVSET2_SS_MASK (BIT(0) | BIT(1))
> +
> +#define MAX20730_MFR_DEVSET2_IMAX_BIT_POS8
> +#define MAX20730_MFR_DEVSET2_VRATE_BIT_POS 6
> +#define MAX20730_MFR_DEVSET2_OCPM_BIT_POS5
> +#define MAX20730_MFR_DEVSET2_SS_BIT_POS 0
> +
> +#define DEBUG_FS_DATA_MAX16
> +
> +struct max20730_debugfs_data {
> + struct i2c_client *client;
> + int debugfs_entries[MAX20730_DEBUGFS_NUM_ENTRIES];
> +};
> +
> +#define to_psu(x, y) container_of((x), \
> + struct max20730_debugfs_data, debugfs_entries[(y)])
> +
> +#ifdef CONFIG_DEBUG_FS
> +static ssize_t max20730_debugfs_read(struct file *file, char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + int ret, len;
> + int *idxp = file->private_data;
> + int idx = *idxp;
> + struct max20730_debugfs_data *psu = to_psu(idxp, idx);
> + const struct pmbus_driver_info *info;
> + const struct max20730_data *data;
> + char tbuf[DEBUG_FS_DATA_MAX] = { 0 };
> + u16 val;
> +
> + info = pmbus_get_driver_info(psu->client);
> + data = to_max20730_data(info);
> +
> + switch (idx) {
> + case MAX20730_DEBUGFS_VOUT_MIN:
> + ret = VOLT_FROM_REG(data->mfr_voutmin * 1);
> + len = snprintf(tbuf, DEBUG_FS_DATA_MAX, "%d.%d\n",
> +ret / 1, ret % 1);
> + break;
> + case MAX20730_DEBUGFS_FREQUENCY:
> + val = (data->mfr_devset1 & MAX20730_MFR_DEVSET1_FSW_MASK)
> +
Re: [PATCH 3/4] rcu/tree: Make struct kernel_param_ops definitions const
On Sat, Oct 03, 2020 at 05:18:08PM -0700, Joe Perches wrote:
> These should be const, so make it so.
>
> Signed-off-by: Joe Perches
Queued for testing and review, thank you!
Thanx, Paul
> ---
> kernel/rcu/tree.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index f78ee759af9c..c4732bb80818 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -552,12 +552,12 @@ static int param_set_next_fqs_jiffies(const char *val,
> const struct kernel_param
> return ret;
> }
>
> -static struct kernel_param_ops first_fqs_jiffies_ops = {
> +static const struct kernel_param_ops first_fqs_jiffies_ops = {
> .set = param_set_first_fqs_jiffies,
> .get = param_get_ulong,
> };
>
> -static struct kernel_param_ops next_fqs_jiffies_ops = {
> +static const struct kernel_param_ops next_fqs_jiffies_ops = {
> .set = param_set_next_fqs_jiffies,
> .get = param_get_ulong,
> };
> --
> 2.26.0
>
[PATCH v2] USB: serial: option: Add Telit FT980-KS composition
This commit adds the following Telit FT980-KS composition:
0x1054: rndis, diag, adb, nmea, modem, modem, aux
AT commands can be sent to /dev/ttyUSB2.
Signed-off-by: Leonid Bloch
---
The full composition is not tested, and it is the default one according
to Telit support. What is tested, is that this commit makes
/dev/ttyUSB{0..4} appear upon connecting the FT980-KS, and allows
sending AT commands to /dev/ttyUSB2.
Changes since v1:
* Interface #3 (ADB) is blacklisted.
* NCTRL flag is set to the diag interface.
These changes (relative to v1) also allow ModemManager to recognize the
device.
drivers/usb/serial/option.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 0c6f160a214a..fe76710167f8 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1186,6 +1186,8 @@ static const struct usb_device_id option_ids[] = {
.driver_info = NCTRL(2) | RSVD(3) },
{ USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1053, 0xff),/*
Telit FN980 (ECM) */
.driver_info = NCTRL(0) | RSVD(1) },
+ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1054, 0xff),/*
Telit FT980-KS */
+ .driver_info = NCTRL(2) | RSVD(3) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910),
.driver_info = NCTRL(0) | RSVD(1) | RSVD(3) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910_DUAL_MODEM),
--
2.28.0
[PATCH] media: zoran.rst: place it at the right place this time
I was too quick moving zoran.rst... it ends that the original
patch didn't do the right thing and forgot to update the files
that references it.
Fix it.
Fixes: 6b90346919d4 ("media: zoran: move documentation file to the right place")
Signed-off-by: Mauro Carvalho Chehab
---
.../driver-api/media/drivers/{v4l-drivers => }/zoran.rst| 0
MAINTAINERS | 2 +-
drivers/staging/media/zoran/Kconfig | 2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename Documentation/driver-api/media/drivers/{v4l-drivers => }/zoran.rst
(100%)
diff --git a/Documentation/driver-api/media/drivers/v4l-drivers/zoran.rst
b/Documentation/driver-api/media/drivers/zoran.rst
similarity index 100%
rename from Documentation/driver-api/media/drivers/v4l-drivers/zoran.rst
rename to Documentation/driver-api/media/drivers/zoran.rst
diff --git a/MAINTAINERS b/MAINTAINERS
index ba5eb1dff9c2..7a12633747c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19247,7 +19247,7 @@ L: linux-me...@vger.kernel.org
S: Maintained
W: http://mjpeg.sourceforge.net/driver-zoran/
Q: https://patchwork.linuxtv.org/project/linux-media/list/
-F: Documentation/media/v4l-drivers/zoran.rst
+F: Documentation/driver-api/media/drivers/zoran.rst
F: drivers/staging/media/zoran/
ZPOOL COMPRESSED PAGE STORAGE API
diff --git a/drivers/staging/media/zoran/Kconfig
b/drivers/staging/media/zoran/Kconfig
index 492507030276..7874842033ca 100644
--- a/drivers/staging/media/zoran/Kconfig
+++ b/drivers/staging/media/zoran/Kconfig
@@ -8,7 +8,7 @@ config VIDEO_ZORAN
36057/36067 PCI controller chipset. This includes the Iomega
Buz, Pinnacle DC10+ and the Linux Media Labs LML33. There is
a driver homepage at
Re: [PATCH] USB: serial: option: Add Telit FT980-KS composition
Lars, Thank you for your review! The changes which you have suggested also made ModemManager to recognize the device (which it didn't do before). Please check out the v2. Cheers, Leonid. ___ On 10/4/20 5:32 PM, Lars Melin wrote: On 10/4/2020 21:16, Lars Melin wrote: On 10/4/2020 20:29, Leonid Bloch wrote: On 10/4/20 1:58 PM, Lars Melin wrote: On 10/4/2020 16:57, Leonid Bloch wrote: This commit adds the following Telit FT980-KS composition: 0x1054: rndis, diag, adb, nmea, modem, modem, aux AT commands can be sent to /dev/ttyUSB5. Please submit a verbose lsusb listing for the device, I can't imagine that the adb interface should be handled by the option serial driver so there will never be a ttyUSB5. Please see below. Thanks, Leonid. ``` Bus 001 Device 005: ID 1bc7:1054 Telit Wireless Solutions Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1bc7 Telit Wireless Solutions idProduct 0x1054 bcdDevice 4.14 iManufacturer 1 Telit Wireless Solutions iProduct 2 FT980-KS iSerial 3 cb42f61 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x013d bNumInterfaces 8 bConfigurationValue 1 iConfiguration 4 RNDIS_DIAG_ADB_NMEA_DUN_DUN_SER bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 239 Miscellaneous Device bFunctionSubClass 4 bFunctionProtocol 1 iFunction 7 RNDIS Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 239 Miscellaneous Device bInterfaceSubClass 4 bInterfaceProtocol 1 iInterface 5 RNDIS Communications Control ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 01 ** UNRECOGNIZED: 04 24 02 00 ** UNRECOGNIZED: 05 24 06 00 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 6 RNDIS Ethernet Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0f EP 15 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 48 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5
Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
On Sun, Oct 4, 2020 at 2:51 PM Jason Gunthorpe wrote: > > On Sat, Oct 03, 2020 at 11:40:22AM +0200, Daniel Vetter wrote: > > > > That leaves the only interesting places as vb2_dc_get_userptr() and > > > vb2_vmalloc_get_userptr() which both completely fail to follow the > > > REQUIRED behavior in the function's comment about checking PTEs. It > > > just DMA maps them. Badly broken. > > > > > > Guessing this hackery is for some embedded P2P DMA transfer? > > > > Yeah, see also the follow_pfn trickery in > > videobuf_dma_contig_user_get(), I think this is fully intentional and > > userspace abi we can't break :-/ > > We don't need to break uABI, it just needs to work properly in the > kernel: > > vma = find_vma_intersection() > dma_buf = dma_buf_get_from_vma(vma) > sg = dma_buf_p2p_dma_map(dma_buf) > [.. do dma ..] > dma_buf_unmap(sg) > dma_buf_put(dma_buf) > > It is as we discussed before, dma buf needs to be discoverable from a > VMA, at least for users doing this kind of stuff. I'm not a big fan of magic behaviour like this, there's more to dma-buf buffer sharing than just "how do I get at the backing storage". Thus far we've done everything rather explicitly. Plus with exynos and habanalabs converted there's only v4l left over, and that has a proper dma-buf import path already. > > Yup this should be done with dma_buf instead, and v4l has that. But > > old uapi and all that. This is why I said we might need a new > > VM_DYNAMIC_PFNMAP or so, to make follow_pfn not resolve this in the > > case where the driver manages the underlying iomem range (or whatever > > it is) dynamically and moves buffer objects around, like drm drivers > > do. But I looked, and we've run out of vma->vm_flags :-( > > A VM flag doesn't help - we need to introduce some kind of lifetime, > and that has to be derived from the VMA. It needs data not just a flag I don't want to make it work, I just want to make it fail. Rough idea I have in mind is to add a follow_pfn_longterm, for all callers which aren't either synchronized through mmap_sem or an mmu_notifier. If this really breaks anyone's use-case we can add a tainting kernel option which re-enables this (we've done something similar for phys_addr_t based buffer sharing in fbdev, entirely unfixable since the other driver has to just blindly trust that what userspace passes around is legit). This here isn't unfixable, but if v4l people want to keep it without a big "security hole here" sticker, they should do the work, not me :-) > > The other problem is that I also have no real working clue about all > > the VM_* flags and what they all mean, and whether drm drivers set the > > right ones in all cases (they probably don't, but oh well). > > Documentation for this stuff in headers is a bit thin at times. > > Yah, I don't really know either :\ > > The comment above vm_normal_page() is a bit helpful. Don't know what > VM_IO/VM_PFNMAP mean in their 3 combinations > > There are very few places that set VM_PFNMAP without VM_IO.. Best I could find is: - mk68 seems to outright reject pagefaults on VM_IO vma - some places set VM_IO together with VM_MIXEDMAP instead of VM_PFNMAP. There's some comments that this makes cow possible, but I guess that's for the old pfn remap vma (remap_file_pages, which is removed now). But really no clue. VM_IO | VM_MIXEDMAP kinda makes me wonder whether follow_pfn gets the page refcounting all right or horribly wrong in some cases ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] dt-bindings: Another round of adding missing 'additionalProperties'
On 02-10-20, 18:41, Rob Herring wrote: > .../phy/amlogic,meson-g12a-usb2-phy.yaml | 2 ++ > .../bindings/phy/qcom,ipq806x-usb-phy-hs.yaml | 2 ++ > .../bindings/phy/qcom,ipq806x-usb-phy-ss.yaml | 2 ++ > .../bindings/phy/qcom,qusb2-phy.yaml | 1 + > .../bindings/phy/qcom-usb-ipq4019-phy.yaml| 2 ++ For phy changes: Acked-By: Vinod Koul -- ~Vinod
Re: [PATCH 2/2] driver core: platform: provide devm_platform_iounremap_resource
hi Greg:
> Please resend, I can't take patches off of a random web site.
> Now lore.kernel.org I could take them from :)
Please refer to the attachments and links on lore.kernel.org.
https://lore.kernel.org/lkml/20200920113808.3-1-vichy@gmail.com
https://lore.kernel.org/lkml/20200920113808.3-2-vichy@gmail.com
Appreciate your help,
From b141d537904b71b802770d9c0fc3787b98c5cf71 Mon Sep 17 00:00:00 2001
From: pierre Kuo
Date: Tue, 18 Aug 2020 23:05:00 +0800
Subject: [PATCH 1/2] lib: devres: provide devm_iounremap_resource()
Driver doesn't have a single helper function to release memroy
allocated by devm_ioremap_resource(). That mean it needs respectively
to call devm_release_mem_region() and devm_iounmap() for memory release.
This patch creates a helper, devm_iounremap_resource(), to combine above
operations.
Signed-off-by: pierre Kuo
---
include/linux/device.h | 2 ++
lib/devres.c | 25 +
2 files changed, 27 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 9e6ea8931a52..33ec7e54c1a9 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -240,6 +240,8 @@ void devm_free_pages(struct device *dev, unsigned long addr);
void __iomem *devm_ioremap_resource(struct device *dev,
const struct resource *res);
+void devm_iounremap_resource(struct device *dev,
+ const struct resource *res, void __iomem *addr);
void __iomem *devm_ioremap_resource_wc(struct device *dev,
const struct resource *res);
diff --git a/lib/devres.c b/lib/devres.c
index ebb1573d9ae3..cdda0cd0a263 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -113,6 +113,31 @@ void devm_iounmap(struct device *dev, void __iomem *addr)
}
EXPORT_SYMBOL(devm_iounmap);
+/**
+ * devm_iounremap_resource() - release mem region, and unremap address
+ * @dev: generic device to handle the resource for
+ * @res: resource of mem region to be release
+ * @addr: address to unmap
+ *
+ * Release memory region and unmap address.
+ */
+void devm_iounremap_resource(struct device *dev,
+ const struct resource *res, void __iomem *addr)
+{
+ resource_size_t size;
+
+ BUG_ON(!dev);
+ if (!res || resource_type(res) != IORESOURCE_MEM) {
+ dev_err(dev, "invalid resource\n");
+ return;
+ }
+
+ size = resource_size(res);
+ devm_release_mem_region(dev, res->start, size);
+ devm_iounmap(dev, addr);
+}
+EXPORT_SYMBOL(devm_iounremap_resource);
+
static void __iomem *
__devm_ioremap_resource(struct device *dev, const struct resource *res,
enum devm_ioremap_type type)
--
2.17.1
From 33afa315c3c941b303e9b3152552010ad266ebbf Mon Sep 17 00:00:00 2001
From: pierre Kuo
Date: Wed, 19 Aug 2020 15:57:05 +0800
Subject: [PATCH 2/2] driver core: platform: provide
devm_platform_iounremap_resource
Combine platform_get_resource() and devm_iounremap_resource() to release
the iomem allocated by devm_platform_get_and_ioremap_resource().
Signed-off-by: pierre Kuo
---
drivers/base/platform.c | 24
include/linux/platform_device.h | 4
2 files changed, 28 insertions(+)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index e5d8a0503b4f..e2655c00873f 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -84,6 +84,30 @@ devm_platform_get_and_ioremap_resource(struct platform_device *pdev,
}
EXPORT_SYMBOL_GPL(devm_platform_get_and_ioremap_resource);
+/**
+ * devm_platform_iounremap_resource - call devm_iounremap_resource() for a
+ * platform device with memory that addr points to.
+ *
+ * @pdev: platform device to use both for memory resource lookup as well as
+ *resource management
+ * @index: resource index
+ * @addr: address to be unmap.
+ */
+void
+devm_platform_iounremap_resource(struct platform_device *pdev,
+ unsigned int index, void __iomem *addr)
+{
+ struct resource *r;
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, index);
+ if (!r)
+ dev_err(&pdev->dev,
+ "MEM resource index %d not found\n", index);
+ else
+ devm_iounremap_resource(&pdev->dev, r, addr);
+}
+EXPORT_SYMBOL_GPL(devm_platform_iounremap_resource);
+
/**
* devm_platform_ioremap_resource - call devm_ioremap_resource() for a platform
*device
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 77a2aada106d..75da15937679 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -67,6 +67,10 @@ devm_platform_ioremap_resource_wc(struct platform_device *pdev,
extern void __iomem *
devm_platform_ioremap_resource_byname(struct platform_device *pdev,
const char *name);
+extern void
+devm_platform_iounremap_resource(struct platform_device *pdev,
+ unsigned int index,
+ void __iomem *addr);
extern int platform_get_irq(struct platform_device *, unsigned int);
extern int platform_get_irq_optional(struct platform_device *, unsigned int);
extern int platform_irq_count(struct platform_device *);
--
2.17.
Re: [sched/fair] fcf0553db6: netperf.Throughput_Mbps -30.8% regression
On Sun, Oct 04, 2020 at 09:27:16PM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -30.8% regression of netperf.Throughput_Mbps due to commit:
>
>
> commit: fcf0553db6f4c79387864f6e4ab4a891601f395e ("sched/fair: Remove
> meaningless imbalance calculation")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
This commit was the start of a series that made large changes to load
balancing. The series was not bisect-safe and has since been reconciled
with the NUMA balancing. Any workload with a potential load balancing
problem has to be checked against the latest kernel to see if the problem
persists there. If it does, then tip/sched/core should be checked or
5.10-rc1 when it comes out as tip has a few more LB changes pending.
--
Mel Gorman
SUSE Labs
Re: [PATCH 2/2] driver core: platform: provide devm_platform_iounremap_resource
On Mon, Oct 05, 2020 at 12:21:12AM +0800, pierre kuo wrote: > hi Greg: > > Please resend, I can't take patches off of a random web site. > > Now lore.kernel.org I could take them from :) > > Please refer to the attachments and links on lore.kernel.org. > > https://lore.kernel.org/lkml/20200920113808.3-1-vichy@gmail.com > https://lore.kernel.org/lkml/20200920113808.3-2-vichy@gmail.com Why are you adding new functions but not actually calling them anywhere? We don't like adding infrastructure that no one uses, that's just wasteful. Please redo the series and include some conversions as well, so that we can see if these new functions are even needed or not. thanks, greg k-h
Re: [PATCH] Revert "Bluetooth: Update resolving list when updating whitelist"
Hi Greg,
> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it
> breaks all bluetooth connections on my machine.
>
> Cc: Marcel Holtmann
> Cc: Sathish Narsimman
> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating
> whitelist")
> Signed-off-by: Greg Kroah-Hartman
> ---
> net/bluetooth/hci_request.c | 41 ++---
> 1 file changed, 2 insertions(+), 39 deletions(-)
>
> This has been bugging me for since 5.9-rc1, when all bluetooth devices
> stopped working on my desktop system. I finally got the time to do
> bisection today, and it came down to this patch. Reverting it on top of
> 5.9-rc7 restored bluetooth devices and now my input devices properly
> work.
>
> As it's almost 5.9-final, any chance this can be merged now to fix the
> issue?
can you be specific what breaks since our guys and I also think the
ChromeOS guys have been testing these series of patches heavily.
>>>
>>> My bluetooth trackball does not connect at all. With this reverted, it
>>> all "just works".
>>>
>>> Same I think for a Bluetooth headset, can check that again if you really
>>> need me to, but the trackball is reliable here.
>>>
When you run btmon does it indicate any errors?
>>>
>>> How do I run it and where are the errors displayed?
>>
>> you can do btmon -w trace.log and just let it run like tcdpump.
>
> Ok, attached.
>
> The device is not connecting, and then I open the gnome bluetooth dialog
> and it scans for devices in the area, but does not connect to my
> existing devices at all.
>
> Any ideas?
the trace file is from -rc7 or from -rc7 with this patch reverted?
I asked, because I see no hint that anything goes wrong. However I have a
suspicion if you bisected it to this patch.
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index e0269192f2e5..94c0daa9f28d 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -732,7 +732,7 @@ static int add_to_white_list(struct hci_request *req,
return -1;
/* White list can not be used with RPAs */
- if (!allow_rpa && !use_ll_privacy(hdev) &&
+ if (!allow_rpa &&
hci_find_irk_by_addr(hdev, ¶ms->addr, params->addr_type)) {
return -1;
}
@@ -812,7 +812,7 @@ static u8 update_white_list(struct hci_request *req)
}
/* White list can not be used with RPAs */
- if (!allow_rpa && !use_ll_privacy(hdev) &&
+ if (!allow_rpa &&
hci_find_irk_by_addr(hdev, &b->bdaddr, b->bdaddr_type)) {
return 0x00;
}
If you just do the above, does thing work for you again?
My suspicion is that the use_ll_privacy check is the wrong one here. It only
checks if hardware feature is available, not if it is also enabled.
Regards
Marcel
Re: [EXT] Re: [PATCH v4 11/13] task_isolation: net: don't flush backlog on CPUs running isolated tasks
On Thu, 2020-10-01 at 16:47 +0200, Frederic Weisbecker wrote:
> External Email
>
> ---
> ---
> On Wed, Jul 22, 2020 at 02:58:24PM +, Alex Belits wrote:
> > From: Yuri Norov
> >
> > If CPU runs isolated task, there's no any backlog on it, and
> > so we don't need to flush it.
>
> What guarantees that we have no backlog on it?
I believe, the logic was that it is not supposed to have backlog
because it could not be produced while the CPU was in userspace,
because one has to enter kernel to receive (by interrupt) or send (by
syscall) anything.
Now, looking at this patch. I don't think, it can be guaranteed that
there was no backlog before it entered userspace. Then backlog
processing will be delayed until exit from isolation. It won't be
queued, and flush_work() will not wait when no worker is assigned, so
there won't be a deadlock, however this delay may not be such a great
idea.
So it may be better to flush backlog before entering isolation, and in
flush_all_backlogs() instead of skipping all CPUs in isolated mode,
check if their per-CPU softnet_data->input_pkt_queue and softnet_data-
>process_queue are empty, and if they are not, call backlog anyway.
Then, if for whatever reason backlog will appear after flushing (we
can't guarantee that nothing preempted us then), it will cause one
isolation breaking event, and if nothing will be queued before re-
entering isolation, there will be no backlog until exiting isolation.
>
> > Currently flush_all_backlogs()
> > enqueues corresponding work on all CPUs including ones that run
> > isolated tasks. It leads to breaking task isolation for nothing.
> >
> > In this patch, backlog flushing is enqueued only on non-isolated
> > CPUs.
> >
> > Signed-off-by: Yuri Norov
> > [abel...@marvell.com: use safe task_isolation_on_cpu()
> > implementation]
> > Signed-off-by: Alex Belits
> > ---
> > net/core/dev.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 90b59fc50dc9..83a282f7453d 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -74,6 +74,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -5624,9 +5625,13 @@ static void flush_all_backlogs(void)
> >
> > get_online_cpus();
> >
> > - for_each_online_cpu(cpu)
> > + smp_rmb();
>
> What is it ordering?
Same as with other calls to task_isolation_on_cpu(cpu), it orders
access to ll_isol_flags.
> > + for_each_online_cpu(cpu) {
> > + if (task_isolation_on_cpu(cpu))
> > + continue;
> > queue_work_on(cpu, system_highpri_wq,
> > per_cpu_ptr(&flush_works, cpu));
> > + }
> >
> > for_each_online_cpu(cpu)
> > flush_work(per_cpu_ptr(&flush_works, cpu));
>
> Thanks.
Re: remove set_fs for riscv v2
On Sat, 26 Sep 2020 12:13:41 PDT (-0700), Arnd Bergmann wrote: On Sat, Sep 26, 2020 at 7:50 PM Palmer Dabbelt wrote: I'm OK taking it, but there's a few things I'd like to sort out. IIRC I put it on a temporary branch over here https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/log/?h=riscv-remove_set_fs under the assumption it might get lost otherwise, but let me know if that's not what you were looking for. Arnd: Are you OK with the asm-generic stuff? I couldn't find anything in my mail history, so sorry if I just missed it. For some reason I had missed that __copy_from_user() change earlier, but I had a closer look now and this is all very good, feel free to add an Acked-by: Arnd Bergmann Thanks. These (along with the rest of Christoph's patch set, and a merge from base.set_fs) are on my for-next.
Re: [PATCH 1/4] media: zoran: move documentation file to the right place
On Sat, Oct 03, 2020 at 10:41:54AM +0200, Mauro Carvalho Chehab wrote:
> The zoran revert patch misplaced the Zoran doc file. Move it to
> the right place.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/driver-api/media/drivers/index.rst | 1 +
> .../{media => driver-api/media/drivers}/v4l-drivers/zoran.rst| 0
> 2 files changed, 1 insertion(+)
> rename Documentation/{media =>
> driver-api/media/drivers}/v4l-drivers/zoran.rst (100%)
>
> diff --git a/Documentation/driver-api/media/drivers/index.rst
> b/Documentation/driver-api/media/drivers/index.rst
> index 5f340cfdb4cc..eb7011782863 100644
> --- a/Documentation/driver-api/media/drivers/index.rst
> +++ b/Documentation/driver-api/media/drivers/index.rst
> @@ -25,6 +25,7 @@ Video4Linux (V4L) drivers
> sh_mobile_ceu_camera
> tuners
> vimc-devel
> + zoran
>
>
> Digital TV drivers
> diff --git a/Documentation/media/v4l-drivers/zoran.rst
> b/Documentation/driver-api/media/drivers/v4l-drivers/zoran.rst
> similarity index 100%
> rename from Documentation/media/v4l-drivers/zoran.rst
> rename to Documentation/driver-api/media/drivers/v4l-drivers/zoran.rst
> --
> 2.26.2
>
Hello
Acked-by: Corentin Labbe
Thanks
Re: [PATCH] media: zoran.rst: place it at the right place this time
On Sun, Oct 04, 2020 at 06:00:30PM +0200, Mauro Carvalho Chehab wrote:
> I was too quick moving zoran.rst... it ends that the original
> patch didn't do the right thing and forgot to update the files
> that references it.
>
> Fix it.
>
> Fixes: 6b90346919d4 ("media: zoran: move documentation file to the right
> place")
> Signed-off-by: Mauro Carvalho Chehab
> ---
> .../driver-api/media/drivers/{v4l-drivers => }/zoran.rst| 0
> MAINTAINERS | 2 +-
> drivers/staging/media/zoran/Kconfig | 2 +-
> 3 files changed, 2 insertions(+), 2 deletions(-)
> rename Documentation/driver-api/media/drivers/{v4l-drivers => }/zoran.rst
> (100%)
>
> diff --git a/Documentation/driver-api/media/drivers/v4l-drivers/zoran.rst
> b/Documentation/driver-api/media/drivers/zoran.rst
> similarity index 100%
> rename from Documentation/driver-api/media/drivers/v4l-drivers/zoran.rst
> rename to Documentation/driver-api/media/drivers/zoran.rst
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ba5eb1dff9c2..7a12633747c8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19247,7 +19247,7 @@ L:linux-me...@vger.kernel.org
> S: Maintained
> W: http://mjpeg.sourceforge.net/driver-zoran/
> Q: https://patchwork.linuxtv.org/project/linux-media/list/
> -F: Documentation/media/v4l-drivers/zoran.rst
> +F: Documentation/driver-api/media/drivers/zoran.rst
> F: drivers/staging/media/zoran/
>
> ZPOOL COMPRESSED PAGE STORAGE API
> diff --git a/drivers/staging/media/zoran/Kconfig
> b/drivers/staging/media/zoran/Kconfig
> index 492507030276..7874842033ca 100644
> --- a/drivers/staging/media/zoran/Kconfig
> +++ b/drivers/staging/media/zoran/Kconfig
> @@ -8,7 +8,7 @@ config VIDEO_ZORAN
> 36057/36067 PCI controller chipset. This includes the Iomega
> Buz, Pinnacle DC10+ and the Linux Media Labs LML33. There is
> a driver homepage at
[RFC PATCH 0/3] GPIO support on the Etron EJ168/EJ188/EJ198 xHCI controllers
Hello,
I have a "Belkin F9K115v2" (wifi router) [0]. It comes with an Etron
EJ168 xHCI controllers soldered to the board. One of the LEDs on this
device is connected to one of the four GPIO lines provided by the
Etron xHCI controller.
The goal of this series to add support for the GPIO controller on the
Etron EJ168/EJ188/EJ198 controllers.
Unfortunately there's no (public) datasheet available. I have Cc'ed
Etron and I'm hoping that they can either provide a datasheet or at
least some code-review feedback.
Instead I used the GPL tarball [0] for this device. Inside this
tarball the relevant "reference" code is in:
linux/kernels/mips-linux-2.6.31/drivers/usb/host/etxhci-pci.c
Unfortunately it uses magic numbers for the registers instead of
human-readable names. The register names are what I came up with.
For reference, I have tested this on a patched OpenWrt build with the
following .dts changes (I am showing these here so it will be easier
to review the whole series):
&pcie1 {
status = "okay";
xhci: usb-controller@0,0,0 {
compatible = "pci1b6f,7023";
reg = <0x0 0x0 0x0 0x0 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
gpio-controller;
#gpio-cells = <2>;
xhci_port0: port@1 {
reg = <1>;
#trigger-source-cells = <0>;
};
};
};
leds {
compatible = "gpio-leds";
usb3 {
label = "green:usb3";
gpios = <&xhci 2 GPIO_ACTIVE_LOW>;
trigger-sources = <&xhci_port0>;
linux,default-trigger = "usbport";
};
};
In general I followed [2] because it says:
PCI drivers should have a really good reason for not using the
pci_register_driver() [...] The main reason [...] is because one
PCI device implements several different HW services.
My understanding that my driver fits into this category.
I am sending this as RFC because this is my first self-written GPIO
driver as well as my first PCI device driver. Any feedback is welcome!
Best regards,
Martin
[0] https://openwrt.org/toh/belkin/f9k1115v2
[1] https://www.belkin.com/support/dl/F9K1115v2.03.97-GPL-10.2.85.tar.gz
[2]
https://www.kernel.org/doc/html/latest/PCI/pci.html#how-to-find-pci-devices-manually
Martin Blumenstingl (3):
PCI: Add the IDs for Etron EJ168 and EJ188
dt-bindings: gpio: Add binding documentation for Etron
EJ168/EJ188/EJ198
gpio: ej1x8: Add GPIO driver for Etron Tech Inc. EJ168/EJ188/EJ198
.../devicetree/bindings/gpio/etron,ej1x8.yaml | 48 +++
drivers/gpio/Kconfig | 9 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-ej1x8.c | 311 ++
include/linux/pci_ids.h | 4 +
5 files changed, 373 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/etron,ej1x8.yaml
create mode 100644 drivers/gpio/gpio-ej1x8.c
--
2.28.0
[RFC PATCH 1/3] PCI: Add the IDs for Etron EJ168 and EJ188
Add the vendor ID for Etron Technology, Inc. as well as the device IDs for the two USB xHCI controllers EJ168 and EJ188. Signed-off-by: Martin Blumenstingl --- include/linux/pci_ids.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 1ab1e24bcbce..1c8370aa4b95 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2587,6 +2587,10 @@ #define PCI_VENDOR_ID_REDHAT 0x1b36 +#define PCI_VENDOR_ID_ETRON0x1b6f +#define PCI_DEVICE_ID_ETRON_EJ168 0x7023 +#define PCI_DEVICE_ID_ETRON_EJ188 0x7052 + #define PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS0x1c36 #define PCI_VENDOR_ID_CIRCUITCO0x1cc8 -- 2.28.0
[RFC PATCH 2/3] dt-bindings: gpio: Add binding documentation for Etron EJ168/EJ188/EJ198
Etron EJ168/EJ188/EJ198 are USB xHCI host controllers which embed a GPIO
controller.
Signed-off-by: Martin Blumenstingl
---
.../devicetree/bindings/gpio/etron,ej1x8.yaml | 48 +++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/etron,ej1x8.yaml
diff --git a/Documentation/devicetree/bindings/gpio/etron,ej1x8.yaml
b/Documentation/devicetree/bindings/gpio/etron,ej1x8.yaml
new file mode 100644
index ..fa554045bdb5
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/etron,ej1x8.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/etron,ej1x8.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO controller embedded into the EJ168/EJ188/EJ198 xHCI controllers
+
+maintainers:
+ - Martin Blumenstingl
+
+properties:
+ compatible:
+enum:
+ - pci1b6f,7023
+ - pci1b6f,7052
+
+ reg:
+maxItems: 1
+
+ "#gpio-cells":
+const: 2
+
+ gpio-controller: true
+
+required:
+ - compatible
+ - reg
+ - "#gpio-cells"
+ - gpio-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ pcie {
+#address-cells = <3>;
+#size-cells = <2>;
+
+gpio@0,0,0 {
+ compatible = "pci1b6f,7023";
+ reg = <0x0 0x0 0x0 0x0 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+};
+ };
+
+...
--
2.28.0
[RFC PATCH 3/3] gpio: ej1x8: Add GPIO driver for Etron Tech Inc. EJ168/EJ188/EJ198
EJ168/EJ188/EJ198 are USB xHCI controllers. They also contain four GPIO
lines which are used on some systems to toggle an LED based on whether a
USB device is connected.
There is no public datasheet available for this hardware. All
information in this driver is taken from the
"F9K1115v2.03.97-GPL-10.2.85-20140313" GPL code dump of the Belkin
F9K1115v2. This board comes with an EJ168 USB xHCI controller and the
USB 3.0 LED is connected to one of the GPIOs. Inside the GPL source
archive the related code can be found in:
linux/kernels/mips-linux-2.6.31/drivers/usb/host/etxhci-pci.c
Signed-off-by: Martin Blumenstingl
---
drivers/gpio/Kconfig | 9 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-ej1x8.c | 311 ++
3 files changed, 321 insertions(+)
create mode 100644 drivers/gpio/gpio-ej1x8.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8030fd91a3cc..88820b04ffa5 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -215,6 +215,15 @@ config GPIO_EIC_SPRD
help
Say yes here to support Spreadtrum EIC device.
+config GPIO_EJ1X8
+ tristate "Etron Tech Inc. EJ168/EJ188/EJ198 GPIO driver"
+ depends on OF_GPIO && PCI
+ help
+ Selecting this option will enable the GPIO pins present on
+ the Etron Tech Inc. EJ168/EJ188/EJ198 USB xHCI controllers.
+
+ If unsure, say N.
+
config GPIO_EM
tristate "Emma Mobile GPIO"
depends on (ARCH_EMEV2 || COMPILE_TEST) && OF_GPIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4f9abff4f2dc..6d5e345b1f2d 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_GPIO_DAVINCI)+= gpio-davinci.o
obj-$(CONFIG_GPIO_DLN2)+= gpio-dln2.o
obj-$(CONFIG_GPIO_DWAPB) += gpio-dwapb.o
obj-$(CONFIG_GPIO_EIC_SPRD)+= gpio-eic-sprd.o
+obj-$(CONFIG_GPIO_EJ1X8) += gpio-ej1x8.o
obj-$(CONFIG_GPIO_EM) += gpio-em.o
obj-$(CONFIG_GPIO_EP93XX) += gpio-ep93xx.o
obj-$(CONFIG_GPIO_EXAR)+= gpio-exar.o
diff --git a/drivers/gpio/gpio-ej1x8.c b/drivers/gpio/gpio-ej1x8.c
new file mode 100644
index ..c673e62c34f8
--- /dev/null
+++ b/drivers/gpio/gpio-ej1x8.c
@@ -0,0 +1,311 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (C) 2020 Martin Blumenstingl
*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define EJ1X8_GPIO_INIT0x44
+#define EJ1X8_GPIO_WRITE 0x68
+#define EJ1X8_GPIO_READ0x6c
+
+#define EJ1X8_GPIO_CTRL0x18005020
+#define EJ1X8_GPIO_CTRL_READ_ALL_MASK GENMASK(7, 0)
+#define EJ1X8_GPIO_CTRL_WRITE_ALL_MASK GENMASK(23, 16)
+#define EJ1X8_GPIO_CTRL_OUT_LOW0x0
+#define EJ1X8_GPIO_CTRL_OUT_HIGH 0x1
+#define EJ1X8_GPIO_CTRL_IN 0x2
+#define EJ1X8_GPIO_CTRL_MASK 0x3
+
+#define EJ1X8_GPIO_MODE0x18005022
+#define EJ1X8_GPIO_MODE_READ_WRITE_ALL_MASKGENMASK(23, 16)
+#define EJ1X8_GPIO_MODE_DISABLE0x0
+#define EJ1X8_GPIO_MODE_ENABLE 0x1
+#define EJ1X8_GPIO_MODE_MASK 0x3
+
+static LIST_HEAD(ej1x8_gpios);
+
+struct ej1x8_gpio {
+ spinlock_t lock;
+ struct pci_dev *pci_dev;
+ struct gpio_chipchip;
+ struct list_headlist_head;
+};
+
+static u8 ej1x8_gpio_shift(unsigned int gpio, u8 mask)
+{
+ return (gpio * fls(mask));
+}
+
+static u8 ej1x8_gpio_mask(unsigned int gpio, u8 mask)
+{
+ return mask << ej1x8_gpio_shift(gpio, mask);
+}
+
+static int ej1x8_gpio_read(struct gpio_chip *gc, u32 reg, u32 *value)
+{
+ struct ej1x8_gpio *ej1x8 = gpiochip_get_data(gc);
+ int err;
+
+ err = pci_write_config_dword(ej1x8->pci_dev, EJ1X8_GPIO_WRITE, reg);
+ if (err) {
+ dev_err(gc->parent, "Failed to select 0x%08x register\n", reg);
+ return err;
+ }
+
+ usleep_range(1000, 1);
+
+ err = pci_read_config_dword(ej1x8->pci_dev, EJ1X8_GPIO_READ, value);
+ if (err) {
+ dev_err(gc->parent, "Failed to read 0x%08x register\n", reg);
+ return err;
+ }
+
+ return 0;
+}
+
+static int ej1x8_gpio_write(struct gpio_chip *gc, u32 reg, u32 value)
+{
+ struct ej1x8_gpio *ej1x8 = gpiochip_get_data(gc);
+ int err;
+
+ err = pci_write_config_dword(ej1x8->pci_dev, EJ1X8_GPIO_WRITE,
+reg | value | BIT(24));
+ i
Re: [PATCH v2 2/6] fpga: m10bmc-sec: create max10 bmc security engine
On 10/2/20 8:15 PM, Randy Dunlap wrote: > On 10/2/20 6:24 PM, Russ Weight wrote: >> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig >> index c534cc80f398..2380d36b08c7 100644 >> --- a/drivers/fpga/Kconfig >> +++ b/drivers/fpga/Kconfig >> @@ -235,4 +235,15 @@ config IFPGA_SEC_MGR >>region and for the BMC. Select this option to enable >>updates for secure FPGA devices. >> >> +config IFPGA_M10_BMC_SECURE >> +tristate "Intel MAX10 BMC security engine" >> +depends on MFD_INTEL_M10_BMC && IFPGA_SEC_MGR >> +help >> + Secure update support for the Intel MAX10 board management >> + controller. >> + >> + This is a subdriver of the Intel MAX10 board management controller >> + (BMC) and provides support for secure updates for the BMC image, >> + the FPGA image, the Root Entry Hashes, etc. >> + >> endif # FPGA > Dagnabit, I need a bot to do this. > > Clean up the indentation in the Kconfig file. > > From Documentation/process/coding-style.rst, section 10: > > Lines under a ``config`` definition > are indented with one tab, while help text is indented an additional two > spaces. > > checkpatch should have found that issue. Did it not? Sorry - I thought I had addressed the indentation errors after the first submission. I'll fix it. I am running checkpatch.pl --strict, and I did not see a warning/error for this. > > > thanks.
[PATCH 7/7] btrfs: Promote to unsigned long long before multiplying
On 32-bit systems, these shifts will overflow for files larger than 4GB.
Add helper functions to avoid this problem coming back.
Cc: sta...@vger.kernel.org
Fixes: 73ff61dbe5ed ("Btrfs: fix device replace of a missing RAID 5/6 device")
Fixes: be50a8ddaae1 ("Btrfs: Simplify scrub_setup_recheck_block()'s argument")
Fixes: ff023aac3119 ("Btrfs: add code to scrub to copy read data to another
disk")
Fixes: b5d67f64f9bc ("Btrfs: change scrub to support big blocks")
Fixes: a2de733c78fa ("btrfs: scrub")
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/btrfs/scrub.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 354ab9985a34..ccbaf9c6e87a 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -1262,12 +1262,17 @@ static inline void scrub_stripe_index_and_offset(u64
logical, u64 map_type,
}
}
+static u64 sblock_length(struct scrub_block *sblock)
+{
+ return (u64)sblock->page_count * PAGE_SIZE;
+}
+
static int scrub_setup_recheck_block(struct scrub_block *original_sblock,
struct scrub_block *sblocks_for_recheck)
{
struct scrub_ctx *sctx = original_sblock->sctx;
struct btrfs_fs_info *fs_info = sctx->fs_info;
- u64 length = original_sblock->page_count * PAGE_SIZE;
+ u64 length = sblock_length(original_sblock);
u64 logical = original_sblock->pagev[0]->logical;
u64 generation = original_sblock->pagev[0]->generation;
u64 flags = original_sblock->pagev[0]->flags;
@@ -1610,6 +1615,11 @@ static void scrub_write_block_to_dev_replace(struct
scrub_block *sblock)
}
}
+static u64 sbio_length(struct scrub_bio *sbio)
+{
+ return (u64)sbio->page_count * PAGE_SIZE;
+}
+
static int scrub_write_page_to_dev_replace(struct scrub_block *sblock,
int page_num)
{
@@ -1659,10 +1669,9 @@ static int scrub_add_page_to_wr_bio(struct scrub_ctx
*sctx,
bio->bi_iter.bi_sector = sbio->physical >> 9;
bio->bi_opf = REQ_OP_WRITE;
sbio->status = 0;
- } else if (sbio->physical + sbio->page_count * PAGE_SIZE !=
+ } else if (sbio->physical + sbio_length(sbio) !=
spage->physical_for_dev_replace ||
- sbio->logical + sbio->page_count * PAGE_SIZE !=
- spage->logical) {
+ sbio->logical + sbio_length(sbio) != spage->logical) {
scrub_wr_submit(sctx);
goto again;
}
@@ -2005,10 +2014,8 @@ static int scrub_add_page_to_rd_bio(struct scrub_ctx
*sctx,
bio->bi_iter.bi_sector = sbio->physical >> 9;
bio->bi_opf = REQ_OP_READ;
sbio->status = 0;
- } else if (sbio->physical + sbio->page_count * PAGE_SIZE !=
- spage->physical ||
- sbio->logical + sbio->page_count * PAGE_SIZE !=
- spage->logical ||
+ } else if (sbio->physical + sbio_length(sbio) != spage->physical ||
+ sbio->logical + sbio_length(sbio) != spage->logical ||
sbio->dev != spage->dev) {
scrub_submit(sctx);
goto again;
@@ -2094,7 +2101,7 @@ static void scrub_missing_raid56_pages(struct scrub_block
*sblock)
{
struct scrub_ctx *sctx = sblock->sctx;
struct btrfs_fs_info *fs_info = sctx->fs_info;
- u64 length = sblock->page_count * PAGE_SIZE;
+ u64 length = sblock_length(sblock);
u64 logical = sblock->pagev[0]->logical;
struct btrfs_bio *bbio = NULL;
struct bio *bio;
--
2.28.0
[PATCH 5/7] btrfs: Promote to unsigned long long before shifting
On 32-bit systems, this shift will overflow for files larger than 4GB.
Cc: sta...@vger.kernel.org
Fixes: df480633b891 ("btrfs: extent-tree: Switch to new delalloc space reserve
and release")
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/btrfs/ioctl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index ac45f022b495..4d3b7e4ae53a 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1277,7 +1277,7 @@ static int cluster_pages_for_defrag(struct inode *inode,
page_cnt = min_t(u64, (u64)num_pages, (u64)file_end - start_index + 1);
ret = btrfs_delalloc_reserve_space(BTRFS_I(inode), &data_reserved,
- start_index << PAGE_SHIFT,
+ (loff_t)start_index << PAGE_SHIFT,
page_cnt << PAGE_SHIFT);
if (ret)
return ret;
@@ -1367,7 +1367,7 @@ static int cluster_pages_for_defrag(struct inode *inode,
btrfs_mod_outstanding_extents(BTRFS_I(inode), 1);
spin_unlock(&BTRFS_I(inode)->lock);
btrfs_delalloc_release_space(BTRFS_I(inode), data_reserved,
- start_index << PAGE_SHIFT,
+ (loff_t)start_index << PAGE_SHIFT,
(page_cnt - i_done) << PAGE_SHIFT, true);
}
@@ -1395,7 +1395,7 @@ static int cluster_pages_for_defrag(struct inode *inode,
put_page(pages[i]);
}
btrfs_delalloc_release_space(BTRFS_I(inode), data_reserved,
- start_index << PAGE_SHIFT,
+ (loff_t)start_index << PAGE_SHIFT,
page_cnt << PAGE_SHIFT, true);
btrfs_delalloc_release_extents(BTRFS_I(inode), page_cnt << PAGE_SHIFT);
extent_changeset_free(data_reserved);
--
2.28.0
[PATCH 6/7] btrfs: Promote to unsigned long long before shifting
On 32-bit systems, this shift will overflow for files larger than 4GB.
Cc: sta...@vger.kernel.org
Fixes: 53b381b3abeb ("Btrfs: RAID5 and RAID6")
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/btrfs/raid56.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index 255490f42b5d..5ee0a53301bd 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -1089,7 +1089,7 @@ static int rbio_add_io_page(struct btrfs_raid_bio *rbio,
u64 disk_start;
stripe = &rbio->bbio->stripes[stripe_nr];
- disk_start = stripe->physical + (page_index << PAGE_SHIFT);
+ disk_start = stripe->physical + ((loff_t)page_index << PAGE_SHIFT);
/* if the device is missing, just fail this stripe */
if (!stripe->dev->bdev)
--
2.28.0
[PATCH 4/7] ocfs2: Promote to unsigned long long before shifting
On 32-bit systems, this shift will overflow for files larger than 4GB.
Cc: sta...@vger.kernel.org
Fixes: 35edec1d52c0 ("ocfs2: update truncate handling of partial clusters")
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/ocfs2/alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
index 4c1b90442d6f..26eff79ecb50 100644
--- a/fs/ocfs2/alloc.c
+++ b/fs/ocfs2/alloc.c
@@ -6867,7 +6867,7 @@ static void ocfs2_zero_cluster_pages(struct inode *inode,
loff_t start,
ocfs2_map_and_dirty_page(inode, handle, from, to, page, 1,
&phys);
- start = (page->index + 1) << PAGE_SHIFT;
+ start = (page->index + 1ULL) << PAGE_SHIFT;
}
out:
if (pages)
--
2.28.0
[PATCH 2/7] buffer: Promote to unsigned long long before shifting
On 32-bit systems, this shift will overflow for files larger than 4GB.
Cc: sta...@vger.kernel.org
Fixes: 5417169026c3 ("[FS] Implement block_page_mkwrite.")
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 50bbc99e3d96..66f4765e60ee 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -2515,7 +2515,7 @@ int block_page_mkwrite(struct vm_area_struct *vma, struct
vm_fault *vmf,
}
/* page is wholly or partially inside EOF */
- if (((page->index + 1) << PAGE_SHIFT) > size)
+ if (((page->index + 1ULL) << PAGE_SHIFT) > size)
end = size & ~PAGE_MASK;
else
end = PAGE_SIZE;
--
2.28.0
[PATCH 3/7] ceph: Promote to unsigned long long before shifting
On 32-bit systems, this shift will overflow for files larger than 4GB.
Cc: sta...@vger.kernel.org
Fixes: 61f68816211e ("ceph: check caps in filemap_fault and page_mkwrite")
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/ceph/addr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
index 6ea761c84494..970e5a094035 100644
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -1522,7 +1522,7 @@ static vm_fault_t ceph_filemap_fault(struct vm_fault *vmf)
struct ceph_inode_info *ci = ceph_inode(inode);
struct ceph_file_info *fi = vma->vm_file->private_data;
struct page *pinned_page = NULL;
- loff_t off = vmf->pgoff << PAGE_SHIFT;
+ loff_t off = (loff_t)vmf->pgoff << PAGE_SHIFT;
int want, got, err;
sigset_t oldset;
vm_fault_t ret = VM_FAULT_SIGBUS;
--
2.28.0
[PATCH 1/7] 9P: Cast to loff_t before multiplying
On 32-bit systems, this multiplication will overflow for files larger
than 4GB.
Cc: sta...@vger.kernel.org
Fixes: fb89b45cdfdc ("9P: introduction of a new cache=mmap model.")
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/9p/vfs_file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
index 3576123d8299..6d97b6b4d34b 100644
--- a/fs/9p/vfs_file.c
+++ b/fs/9p/vfs_file.c
@@ -612,9 +612,9 @@ static void v9fs_mmap_vm_close(struct vm_area_struct *vma)
struct writeback_control wbc = {
.nr_to_write = LONG_MAX,
.sync_mode = WB_SYNC_ALL,
- .range_start = vma->vm_pgoff * PAGE_SIZE,
+ .range_start = (loff_t)vma->vm_pgoff * PAGE_SIZE,
/* absolute end, byte at end included */
- .range_end = vma->vm_pgoff * PAGE_SIZE +
+ .range_end = (loff_t)vma->vm_pgoff * PAGE_SIZE +
(vma->vm_end - vma->vm_start - 1),
};
--
2.28.0
[PATCH 0/7] Fix a pile of 4GB file problems on 32-bit
I caught a bug in my own code where I forgot to cast to loff_t before shifting. So I thought I'd grep around and see if I could find any other occurrences. I found a few that were clearly bugs, and they're fixed below. There are other places where we don't cast, and I think they're OK. For example, some places we have a 'nr_pages' being shifted by PAGE_SHIFT, and that's probably OK because it's probably a single I/O. Also, I didn't touch AFFS or ROMFS or some other filesystems which probably have never seen a 4GB file in their lives. Might be worth fixing to be sure nobody copies bad code from them, but not worth cc'ing stable for. I didn't look for SECTOR_SHIFT or SECTOR_SIZE (or bare 9/512), just PAGE_SIZE and PAGE_SHIFT. I can't find a GCC warning to enable for this pattern, so I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97287 Matthew Wilcox (Oracle) (7): 9P: Cast to loff_t before multiplying buffer: Promote to unsigned long long before shifting ceph: Promote to unsigned long long before shifting ocfs2: Promote to unsigned long long before shifting btrfs: Promote to unsigned long long before shifting btrfs: Promote to unsigned long long before shifting btrfs: Promote to unsigned long long before multiplying fs/9p/vfs_file.c | 4 ++-- fs/btrfs/ioctl.c | 6 +++--- fs/btrfs/raid56.c | 2 +- fs/btrfs/scrub.c | 25 - fs/buffer.c | 2 +- fs/ceph/addr.c| 2 +- fs/ocfs2/alloc.c | 2 +- 7 files changed, 25 insertions(+), 18 deletions(-) -- 2.28.0
Re: [PATCH v2 2/6] fpga: m10bmc-sec: create max10 bmc security engine
On 10/4/20 11:01 AM, Russ Weight wrote: > > > On 10/2/20 8:15 PM, Randy Dunlap wrote: >> On 10/2/20 6:24 PM, Russ Weight wrote: >>> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig >>> index c534cc80f398..2380d36b08c7 100644 >>> --- a/drivers/fpga/Kconfig >>> +++ b/drivers/fpga/Kconfig >>> @@ -235,4 +235,15 @@ config IFPGA_SEC_MGR >>> region and for the BMC. Select this option to enable >>> updates for secure FPGA devices. >>> >>> +config IFPGA_M10_BMC_SECURE >>> +tristate "Intel MAX10 BMC security engine" >>> + depends on MFD_INTEL_M10_BMC && IFPGA_SEC_MGR >>> +help >>> + Secure update support for the Intel MAX10 board management >>> + controller. >>> + >>> + This is a subdriver of the Intel MAX10 board management controller >>> + (BMC) and provides support for secure updates for the BMC image, >>> + the FPGA image, the Root Entry Hashes, etc. >>> + >>> endif # FPGA >> Dagnabit, I need a bot to do this. >> >> Clean up the indentation in the Kconfig file. >> >> From Documentation/process/coding-style.rst, section 10: >> >> Lines under a ``config`` definition >> are indented with one tab, while help text is indented an additional two >> spaces. >> >> checkpatch should have found that issue. Did it not? > Sorry - I thought I had addressed the indentation errors after the first > submission. > I'll fix it. > > I am running checkpatch.pl --strict, and I did not see a warning/error for > this. OK, I looked at checkpatch.pl and I don't see any checks for that. I'll just work on a pseudo-bot then. thanks. -- ~Randy
Re: [RFC][PATCHSET] epoll cleanups
On Sat, Oct 3, 2020 at 7:36 PM Al Viro wrote: > > Locking and especially control flow in fs/eventpoll.c is > overcomplicated. As the result, the code has been hard to follow > and easy to fuck up while modifying. Scanning through the patches they all look superficially ok to me, but I'm wondering how much test coverage you have (because I'm wondering how much test coverage we have in general for epoll). But I'm certainly not in the least against trying to make the epoll code more straightforward and understandable. Linus
Re: [PATCH 01/10] fpga: fpga-mgr: Add devm_fpga_mgr_register() API
On 10/3/20 10:14 PM, Moritz Fischer wrote:
> Add a devm_fpga_mgr_register() API that can be used to register a FPGA
> Manager that was created using devm_fpga_mgr_create().
>
> Introduce a struct fpga_mgr_devres that makes the devres
> allocation a little bit more readable and gets reused for
> devm_fpga_mgr_create() devm_fpga_mgr_register().
>
> Signed-off-by: Moritz Fischer
> ---
> drivers/fpga/fpga-mgr.c | 76 ++-
> include/linux/fpga/fpga-mgr.h | 2 +
> 2 files changed, 68 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index f38bab01432e..774ac98fb69c 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -21,6 +21,10 @@
> static DEFINE_IDA(fpga_mgr_ida);
> static struct class *fpga_mgr_class;
>
> +struct fpga_mgr_devres {
> + struct fpga_manager *mgr;
> +};
> +
> /**
> * fpga_image_info_alloc - Allocate a FPGA image info struct
> * @dev: owning device
> @@ -651,21 +655,21 @@ struct fpga_manager *devm_fpga_mgr_create(struct device
> *dev, const char *name,
> const struct fpga_manager_ops *mops,
> void *priv)
> {
> - struct fpga_manager **ptr, *mgr;
> + struct fpga_mgr_devres *dr;
>
> - ptr = devres_alloc(devm_fpga_mgr_release, sizeof(*ptr), GFP_KERNEL);
> - if (!ptr)
> + dr = devres_alloc(devm_fpga_mgr_release, sizeof(*dr), GFP_KERNEL);
> + if (!dr)
> return NULL;
>
> - mgr = fpga_mgr_create(dev, name, mops, priv);
> - if (!mgr) {
> - devres_free(ptr);
> - } else {
> - *ptr = mgr;
> - devres_add(dev, ptr);
> + dr->mgr = fpga_mgr_create(dev, name, mops, priv);
> + if (!dr->mgr) {
> + devres_free(dr);
> + return NULL;
> }
>
> - return mgr;
> + devres_add(dev, dr);
> +
> + return dr->mgr;
> }
> EXPORT_SYMBOL_GPL(devm_fpga_mgr_create);
>
> @@ -722,6 +726,58 @@ void fpga_mgr_unregister(struct fpga_manager *mgr)
> }
> EXPORT_SYMBOL_GPL(fpga_mgr_unregister);
>
> +static int fpga_mgr_devres_match(struct device *dev, void *priv,
> + void *match_data)
> +{
> + struct fpga_mgr_devres *dr = priv;
> +
> + return match_data == dr->mgr;
> +}
> +
> +static void devm_fpga_mgr_unregister(struct device *dev, void *priv)
> +{
> + struct fpga_mgr_devres *dr = priv;
> +
> + fpga_mgr_unregister(dr->mgr);
> +}
> +
> +/**
> + * devm_fpga_mgr_register - resource managed variant of fpga_mgr_register()
> + * @dev: managing device for this FPGA manager
> + * @mgr: fpga manager struct
> + *
> + * This is the devres variant of fpga_mgr_register() for which the unregister
> + * function will be called automatically when the managing device is
> detached.
> + */
> +int devm_fpga_mgr_register(struct device *dev, struct fpga_manager *mgr)
> +{
> + struct fpga_mgr_devres *dr;
> + int err;
nit
int ret;
Fine if it isn't changed.
Reviewed-by: Tom Rix
> +
> + /* Make sure that the struct fpga_manager * that is passed in is
> + * managed itself.
> + */
> + if (WARN_ON(!devres_find(dev, devm_fpga_mgr_release,
> + fpga_mgr_devres_match, mgr)))
> + return -EINVAL;
> +
> + dr = devres_alloc(devm_fpga_mgr_unregister, sizeof(*dr), GFP_KERNEL);
> + if (!dr)
> + return -ENOMEM;
> +
> + err = fpga_mgr_register(mgr);
> + if (err) {
> + devres_free(dr);
> + return err;
> + }
> +
> + dr->mgr = mgr;
> + devres_add(dev, dr);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(devm_fpga_mgr_register);
> +
> static void fpga_mgr_dev_release(struct device *dev)
> {
> }
> diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
> index e8ca62b2cb5b..2bc3030a69e5 100644
> --- a/include/linux/fpga/fpga-mgr.h
> +++ b/include/linux/fpga/fpga-mgr.h
> @@ -198,6 +198,8 @@ void fpga_mgr_free(struct fpga_manager *mgr);
> int fpga_mgr_register(struct fpga_manager *mgr);
> void fpga_mgr_unregister(struct fpga_manager *mgr);
>
> +int devm_fpga_mgr_register(struct device *dev, struct fpga_manager *mgr);
> +
> struct fpga_manager *devm_fpga_mgr_create(struct device *dev, const char
> *name,
> const struct fpga_manager_ops *mops,
> void *priv);
Re: [PATCH 02/10] fpga: fpga-mgr: altera-ps-spi: Simplify registration
On 10/3/20 10:14 PM, Moritz Fischer wrote: > Simplify registration by using new devm_fpga_mgr_register() API. > > Signed-off-by: Moritz Fischer > --- > drivers/fpga/altera-ps-spi.c | 14 +- > 1 file changed, 1 insertion(+), 13 deletions(-) Looks fine Reviewed-by: Tom Rix
Re: [PATCH 03/10] fpga: fpga-mgr: dfl-fme-mgr: Simplify registration
On 10/3/20 10:14 PM, Moritz Fischer wrote:
> Simplify registration using new devm_fpga_mgr_register() API.
>
> Signed-off-by: Moritz Fischer
> ---
> drivers/fpga/dfl-fme-mgr.c | 12 +---
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c
> index b3f7eee3c93f..3fc2be87d059 100644
> --- a/drivers/fpga/dfl-fme-mgr.c
> +++ b/drivers/fpga/dfl-fme-mgr.c
> @@ -316,16 +316,7 @@ static int fme_mgr_probe(struct platform_device *pdev)
> mgr->compat_id = compat_id;
> platform_set_drvdata(pdev, mgr);
Is this call is still needed ?
Tom
>
> - return fpga_mgr_register(mgr);
> -}
> -
> -static int fme_mgr_remove(struct platform_device *pdev)
> -{
> - struct fpga_manager *mgr = platform_get_drvdata(pdev);
> -
> - fpga_mgr_unregister(mgr);
> -
> - return 0;
> + return devm_fpga_mgr_register(dev, mgr);
> }
>
> static struct platform_driver fme_mgr_driver = {
> @@ -333,7 +324,6 @@ static struct platform_driver fme_mgr_driver = {
> .name= DFL_FPGA_FME_MGR,
> },
> .probe = fme_mgr_probe,
> - .remove = fme_mgr_remove,
> };
>
> module_platform_driver(fme_mgr_driver);
Re: [PATCH 04/10] fpga: fpga-mgr: ice40-spi: Simplify registration
On 10/3/20 10:14 PM, Moritz Fischer wrote: > Simplify registration using new devm_fpga_mgr_register() API. > > Signed-off-by: Moritz Fischer > --- > drivers/fpga/ice40-spi.c | 14 +- > 1 file changed, 1 insertion(+), 13 deletions(-) LOTM Reviewed-by: Tom Rix
Re: [PATCH 05/10] fpga: fpga-mgr: machxo2-spi: Simplify registration
On 10/3/20 10:14 PM, Moritz Fischer wrote: > Simplify registration using new devm_fpga_mgr_register() API. > > Signed-off-by: Moritz Fischer > --- > drivers/fpga/machxo2-spi.c | 14 +- > 1 file changed, 1 insertion(+), 13 deletions(-) LOTM Reviewed-by: Tom Rix
Re: [PATCH 06/10] fpga: fpga-mgr: socfpga: Simplify registration
On 10/3/20 10:14 PM, Moritz Fischer wrote: > Simplify registration using new devm_fpga_mgr_register() API. > > Signed-off-by: Moritz Fischer > --- > drivers/fpga/socfpga.c | 14 +- > 1 file changed, 1 insertion(+), 13 deletions(-) LOTM Reviewed-by: Tom Rix
Re: [PATCH 07/10] fpga: fpga-mgr: ts73xx: Simplify registration
On 10/3/20 10:14 PM, Moritz Fischer wrote: > Simplify registration using new devm_fpga_mgr_register() API. > > Signed-off-by: Moritz Fischer > --- > drivers/fpga/ts73xx-fpga.c | 14 +- > 1 file changed, 1 insertion(+), 13 deletions(-) LOTM Reviewed-by: Tom Rix
Re: [PATCH 08/10] fpga: fpga-mgr: xilinx-spi: Simplify registration
On 10/3/20 10:14 PM, Moritz Fischer wrote: > Simplify registration using new devm_fpga_mgr_register() API. > > Signed-off-by: Moritz Fischer > --- > drivers/fpga/xilinx-spi.c | 14 +- > 1 file changed, 1 insertion(+), 13 deletions(-) LOTM Reviewed-by: Tom Rix
Re: [PATCH 1/2] usb: serial: qmi_wwan: add Cellient MPL200 card
On Sun, 04 Oct 2020 17:29:38 +0200
Bjørn Mork wrote:
> Wilken Gottwalt writes:
>
> > Add usb ids of the Cellient MPL200 card.
> >
> > Signed-off-by: Wilken Gottwalt
> > ---
> > drivers/net/usb/qmi_wwan.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> > index 07c42c0719f5..0bf2b19d5d54 100644
> > --- a/drivers/net/usb/qmi_wwan.c
> > +++ b/drivers/net/usb/qmi_wwan.c
>
> This is not a 'usb: serial' driver. Please resend with a less confusing
> subject prefix.
>
> > @@ -1432,6 +1432,7 @@ static const struct usb_device_id products[] = {
> > {QMI_GOBI_DEVICE(0x1199, 0x901b)}, /* Sierra Wireless MC7770 */
> > {QMI_GOBI_DEVICE(0x12d1, 0x14f1)}, /* Sony Gobi 3000 Composite */
> > {QMI_GOBI_DEVICE(0x1410, 0xa021)}, /* Foxconn Gobi 3000 Modem
> > device (Novatel
> > E396) */
> > + {QMI_FIXED_INTF(0x2692, 0x9025, 4)},/* Cellient MPL200 (rebranded
> > Qualcomm
> > 0x05c6) */
> > { } /* END */
> > };
>
>
> This table is supposed to be organized by device type. The last section
> is for Gobi2k and Gobi3k devices. Please try to put new devices into
> the correct section.
Oh sorry, looks like I got it mixed up a bit. It was my first attempt to submit
a patch set. Which is the best way to resubmit an update if the other part of
the patch set gets accepted? The documentation about re-/submitting patch sets
is a bit thin.
Will
Re: [PATCH 09/10] fpga: fpga-mgr: zynqmp: Simplify registration
On 10/3/20 10:14 PM, Moritz Fischer wrote: > Simplify registration using new devm_fpga_mgr_register() API. > > Signed-off-by: Moritz Fischer > --- > drivers/fpga/zynqmp-fpga.c | 21 + > 1 file changed, 1 insertion(+), 20 deletions(-) LOTM Reviewed-by: Tom Rix
[PATCH] crypto: jitterentropy - bind statically into kernel
The RISC-V architecture is about to implement the callback random_get_entropy with a function that is not exported to modules. Thus, the Jitter RNG is changed to be only bound statically into the kernel removing the option to compile it as module. Reported-by: Christoph Hellwig Signed-off-by: Stephan Mueller --- crypto/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/Kconfig b/crypto/Kconfig index 094ef56ab7b4..5b20087b117f 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1853,7 +1853,7 @@ config CRYPTO_DRBG endif # if CRYPTO_DRBG_MENU config CRYPTO_JITTERENTROPY - tristate "Jitterentropy Non-Deterministic Random Number Generator" + bool "Jitterentropy Non-Deterministic Random Number Generator" select CRYPTO_RNG help The Jitterentropy RNG is a noise that is intended -- 2.26.2
Re: [PATCH 10/10] fpga: fpga-mgr: altera-pr-ip: Simplify registration
On 10/3/20 10:14 PM, Moritz Fischer wrote:
> Simplify registration using new devm_fpga_mgr_register() API.
> Remove the now obsolete altera_pr_unregister() function.
>
> Signed-off-by: Moritz Fischer
> ---
>
> We should take another look at this, IIRC correctly the point of
> splitting this up into a separate driver was to make it useable by a
> different (pci?) driver later on.
>
> It doesn't seem like this happened, and I think we should just make this
> a platform driver?
>
> ---
> drivers/fpga/altera-pr-ip-core-plat.c | 10 --
> drivers/fpga/altera-pr-ip-core.c | 14 +-
> include/linux/fpga/altera-pr-ip-core.h | 1 -
> 3 files changed, 1 insertion(+), 24 deletions(-)
>
> diff --git a/drivers/fpga/altera-pr-ip-core-plat.c
> b/drivers/fpga/altera-pr-ip-core-plat.c
> index 99b9cc0e70f0..b008a6b8d2d3 100644
> --- a/drivers/fpga/altera-pr-ip-core-plat.c
> +++ b/drivers/fpga/altera-pr-ip-core-plat.c
> @@ -28,15 +28,6 @@ static int alt_pr_platform_probe(struct platform_device
> *pdev)
> return alt_pr_register(dev, reg_base);
> }
>
> -static int alt_pr_platform_remove(struct platform_device *pdev)
> -{
> - struct device *dev = &pdev->dev;
> -
> - alt_pr_unregister(dev);
> -
> - return 0;
> -}
> -
> static const struct of_device_id alt_pr_of_match[] = {
> { .compatible = "altr,a10-pr-ip", },
> {},
> @@ -46,7 +37,6 @@ MODULE_DEVICE_TABLE(of, alt_pr_of_match);
>
> static struct platform_driver alt_pr_platform_driver = {
> .probe = alt_pr_platform_probe,
> - .remove = alt_pr_platform_remove,
> .driver = {
> .name = "alt_a10_pr_ip",
> .of_match_table = alt_pr_of_match,
> diff --git a/drivers/fpga/altera-pr-ip-core.c
> b/drivers/fpga/altera-pr-ip-core.c
> index 2cf25fd5e897..dfdf21ed34c4 100644
> --- a/drivers/fpga/altera-pr-ip-core.c
> +++ b/drivers/fpga/altera-pr-ip-core.c
> @@ -195,22 +195,10 @@ int alt_pr_register(struct device *dev, void __iomem
> *reg_base)
> if (!mgr)
> return -ENOMEM;
>
> - dev_set_drvdata(dev, mgr);
> -
> - return fpga_mgr_register(mgr);
> + return devm_fpga_mgr_register(dev, mgr);
> }
> EXPORT_SYMBOL_GPL(alt_pr_register);
>
> -void alt_pr_unregister(struct device *dev)
> -{
> - struct fpga_manager *mgr = dev_get_drvdata(dev);
> -
> - dev_dbg(dev, "%s\n", __func__);
> -
> - fpga_mgr_unregister(mgr);
> -}
> -EXPORT_SYMBOL_GPL(alt_pr_unregister);
Similar to the others, except for removing this symbol.
A patch should do one logical thing.
I'd rather this be split out of the patchset.
Tom
> -
> MODULE_AUTHOR("Matthew Gerlach ");
> MODULE_DESCRIPTION("Altera Partial Reconfiguration IP Core");
> MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/fpga/altera-pr-ip-core.h
> b/include/linux/fpga/altera-pr-ip-core.h
> index 0b08ac20ab16..a6b4c07858cc 100644
> --- a/include/linux/fpga/altera-pr-ip-core.h
> +++ b/include/linux/fpga/altera-pr-ip-core.h
> @@ -13,6 +13,5 @@
> #include
>
> int alt_pr_register(struct device *dev, void __iomem *reg_base);
> -void alt_pr_unregister(struct device *dev);
>
> #endif /* _ALT_PR_IP_CORE_H */
Re: [mm, thp] 85b9f46e8e: vm-scalability.throughput -8.7% regression
On Sun, 4 Oct 2020, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -8.7% regression of vm-scalability.throughput due to commit:
>
>
> commit: 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 ("mm, thp: track fallbacks
> due to failed memcg charges separately")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
>
> in testcase: vm-scalability
> on test machine: 104 threads Skylake with 192G memory
> with following parameters:
>
> runtime: 300s
> size: 1T
> test: lru-shm
> cpufreq_governor: performance
> ucode: 0x2006906
>
> test-description: The motivation behind this suite is to exercise functions
> and regions of the mm/ of the Linux kernel which are of interest to us.
> test-url: https://git.kernel.org/cgit/linux/kernel/git/wfg/vm-scalability.git/
>
>
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot
>
>
> Details are as below:
> -->
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml # job file is attached in this email
> bin/lkp run job.yaml
>
> =
> compiler/cpufreq_governor/kconfig/rootfs/runtime/size/tbox_group/test/testcase/ucode:
>
> gcc-9/performance/x86_64-rhel-8.3/debian-10.4-x86_64-20200603.cgz/300s/1T/lkp-skl-fpga01/lru-shm/vm-scalability/0x2006906
>
> commit:
> dcdf11ee14 ("mm, shmem: add vmstat for hugepage fallback")
> 85b9f46e8e ("mm, thp: track fallbacks due to failed memcg charges
> separately")
>
> dcdf11ee14413332 85b9f46e8ea451633ccd60a7d8c
> ---
>fail:runs %reproductionfail:runs
>| | |
> 1:4 24% 2:4
> perf-profile.calltrace.cycles-pp.sync_regs.error_entry.do_access
> 3:4 53% 5:4
> perf-profile.calltrace.cycles-pp.error_entry.do_access
> 9:4 -27% 8:4
> perf-profile.children.cycles-pp.error_entry
> 4:4 -10% 4:4
> perf-profile.self.cycles-pp.error_entry
> %stddev %change %stddev
> \ |\
> 477291-9.1% 434041vm-scalability.median
> 49791027-8.7% 45476799vm-scalability.throughput
> 223.67+1.6% 227.36vm-scalability.time.elapsed_time
> 223.67+1.6% 227.36
> vm-scalability.time.elapsed_time.max
> 50364 ± 6% +24.1% 62482 ± 10%
> vm-scalability.time.involuntary_context_switches
> 2237+7.8% 2412
> vm-scalability.time.percent_of_cpu_this_job_got
> 3084 +18.2% 3646vm-scalability.time.system_time
> 1921-4.2% 1839vm-scalability.time.user_time
> 13.68+2.2 15.86mpstat.cpu.all.sys%
> 28535 ± 30% -47.0% 15114 ± 79% numa-numastat.node0.other_node
> 142734 ± 11% -19.4% 115000 ± 17% numa-meminfo.node0.AnonPages
> 11168 ± 3% +8.8% 12150 ± 5% numa-meminfo.node1.PageTables
> 76.00-1.6% 74.75vmstat.cpu.id
> 3626-1.9% 3555vmstat.system.cs
>2214928 ±166% -96.6% 75321 ± 7% cpuidle.C1.usage
> 200981 ± 7% -18.0% 164861 ± 7% cpuidle.POLL.time
> 52675 ± 3% -16.7% 43866 ± 10% cpuidle.POLL.usage
> 35659 ± 11% -19.4% 28754 ± 17% numa-vmstat.node0.nr_anon_pages
>1248014 ± 3% +10.9%1384236numa-vmstat.node1.nr_mapped
> 2722 ± 4% +10.6% 3011 ± 5%
> numa-vmstat.node1.nr_page_table_pages
I'm not sure that I'm reading this correctly, but I suspect that this just
happens because of NUMA: memory affinity will obviously impact
vm-scalability.throughput quite substantially, but I don't think the
bisected commit can be to be blame. Commit 85b9f46e8ea4 ("mm, thp: track
fallbacks due to failed memcg charges separately") simply adds new
count_vm_event() calls in a couple areas to track thp fallback due to
memcg limits separate from fragmentation.
It's likely a question about the testing methodology in general: for
memory intensive benchmarks, I suggest it is configured in a manner that
we can expect consistent memory access latency at the hardware level when
running on a NUMA system.
Re: scripts/gdb: issues when loading modules after lx-symbols
On 01.10.20 16:31, Stefano Garzarella wrote: > Hi, > I had some issues with gdb scripts and kernel modules in Linux 5.9-rc7. > > If the modules are already loaded, and I do 'lx-symbols', all work fine. > But, if I load a kernel module after 'lx-symbols', I had this issue: > > [ 5093.393940] invalid opcode: [#1] SMP PTI > [ 5093.395134] CPU: 0 PID: 576 Comm: modprobe Not tainted > 5.9.0-rc7-ste-00010-gf0b671d9608d-dirty #2 > [ 5093.397566] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS > 1.13.0-2.fc32 04/01/2014 > [ 5093.400761] RIP: 0010:do_init_module+0x1/0x270 > [ 5093.402553] Code: ff ff e9 cf fe ff ff 0f 0b 49 c7 c4 f2 ff ff ff e9 c1 fe > ff ff e8 5f b2 65 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 cc <1f> 44 > 00 00 55 ba 10 00 00 00 be c0 0c 00 00 48 89 e5 41 56 41 55 > [ 5093.409505] RSP: 0018:c9563d18 EFLAGS: 00010246 > [ 5093.412056] RAX: RBX: c010a0c0 RCX: > 4ee3 > [ 5093.414472] RDX: 4ee2 RSI: ea0001efe188 RDI: > c010a0c0 > [ 5093.416349] RBP: c9563e50 R08: R09: > 0002 > [ 5093.418044] R10: 0096 R11: 08a4 R12: > 88807a0d1280 > [ 5093.424721] R13: c010a110 R14: 88807a0d1300 R15: > c9563e70 > [ 5093.427138] FS: 7f018f632740() GS:88807dc0() > knlGS: > [ 5093.430037] CS: 0010 DS: ES: CR0: 80050033 > [ 5093.432279] CR2: 55fbe282b239 CR3: 7922a006 CR4: > 00170ef0 > [ 5093.435096] DR0: DR1: DR2: > > [ 5093.436765] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 5093.439689] Call Trace: > [ 5093.440954] ? load_module+0x24b6/0x27d0 > [ 5093.443212] ? __kernel_read+0xd6/0x150 > [ 5093.445140] __do_sys_finit_module+0xd3/0xf0 > [ 5093.446877] __x64_sys_finit_module+0x1a/0x20 > [ 5093.449098] do_syscall_64+0x38/0x50 > [ 5093.450877] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 5093.456153] RIP: 0033:0x7f018f75c43d > [ 5093.457728] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 > f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d > 01 f0 ff ff 73 01 c3 48 8b 0d 2b 6a 0c 00 f7 d8 64 89 01 48 > [ 5093.466349] RSP: 002b:7ffd7f080368 EFLAGS: 0246 ORIG_RAX: > 0139 > [ 5093.470613] RAX: ffda RBX: 557e5c96f9c0 RCX: > 7f018f75c43d > [ 5093.474747] RDX: RSI: 557e5c964288 RDI: > 0003 > [ 5093.478049] RBP: 0004 R08: R09: > > [ 5093.481298] R10: 0003 R11: 0246 R12: > > [ 5093.483725] R13: 557e5c964288 R14: 557e5c96f950 R15: > 557e5c9775c0 > [ 5093.485778] Modules linked in: virtio_vdpa(+) vdpa sunrpc kvm_intel kvm > irqbypass virtio_blk virtio_rng rng_core [last unloaded: virtio_vdpa] > [ 5093.488695] ---[ end trace 23712ecebc11f53c ]--- > > Guest kernel: Linux 5.9-rc7 > gdb: GNU gdb (GDB) Fedora 9.1-6.fc32 > I tried with QEMU 4.2.1 and the latest master branch: same issue. > > > I did some digging, and skipping the gdb 'add-symbol-file' command in > symbol.py > avoid the issue, but of course I don't have the symbols loaded: > > diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py > index 1be9763cf8bb..eadfaa4d4907 100644 > --- a/scripts/gdb/linux/symbols.py > +++ b/scripts/gdb/linux/symbols.py > @@ -129,7 +129,7 @@ lx-symbols command.""" > filename=module_file, > addr=module_addr, > sections=self._section_arguments(module)) > -gdb.execute(cmdline, to_string=True) > +#gdb.execute(cmdline, to_string=True) > if module_name not in self.loaded_modules: > self.loaded_modules.append(module_name) > else: > > I tried several modules and this happens every time after '(gdb) lx-symbols'. > > Do you have any hints? > I assume you are debugging a kernel inside QEMU/KVM, right? Does it work without -enable-kvm? Debugging guests in KVM mode at least was unstable for a long time. I avoided setting soft-BPs - which is what the script does for the sake of tracking modules loading -, falling back to hw-BPs, as I had no time to debug that further. /Maybe/ that's the issue here. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH net-next] netfilter: nf_tables_offload: Remove unused macro FLOW_SETUP_BLOCK
On Fri, Sep 18, 2020 at 09:17:29PM +0800, YueHaibing wrote:
> commit 9a32669fecfb ("netfilter: nf_tables_offload: support indr block call")
> left behind this.
Applied.
Re: [PATCH RESEND] drm/bridge: tc358764: restore connector support
Hi Marek.
On Wed, Sep 30, 2020 at 01:40:42PM +0200, Marek Szyprowski wrote:
> This patch restores DRM connector registration in the TC358764 bridge
> driver and restores usage of the old drm_panel_* API, thus allows dynamic
> panel registration. This fixes panel operation on Exynos5250-based
> Arndale board.
>
> This is equivalent to the revert of the following commits:
> 1644127f83bc "drm/bridge: tc358764: add drm_panel_bridge support"
> 385ca38da29c "drm/bridge: tc358764: drop drm_connector_(un)register"
> and removal of the calls to drm_panel_attach()/drm_panel_detach(), which
> were no-ops and has been removed in meanwhile.
>
> Signed-off-by: Marek Szyprowski
> Reviewed-by: Andrzej Hajda
Thanks for providing the revert so we can have this fixed in upstream.
So far I have had no time to dive deeper into what is going wrong but
and the revert is the right cause of action for now.
I expect Andrzej to pick it up as he has already reviewed it.
Sam
> ---
> As I've reported and Andrzej Hajda pointed, the reverted patches break
> operation of the panel on the Arndale board. Noone suggested how to fix
> the regression, I've decided to send a revert until a new solution is
> found.
>
> The issues with tc358764 might be automatically resolved once the Exynos
> DSI itself is converted to DRM bridge:
> https://patchwork.kernel.org/cover/11770683/
> but that approach has also its own issues so far.
>
> Resend reason: added Sam Ravnborg to CC:
>
> Best regards,
> Marek Szyprowski
> ---
> drivers/gpu/drm/bridge/tc358764.c | 107 +-
> 1 file changed, 92 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358764.c
> b/drivers/gpu/drm/bridge/tc358764.c
> index d89394bc5aa4..c1e35bdf9232 100644
> --- a/drivers/gpu/drm/bridge/tc358764.c
> +++ b/drivers/gpu/drm/bridge/tc358764.c
> @@ -153,9 +153,10 @@ static const char * const tc358764_supplies[] = {
> struct tc358764 {
> struct device *dev;
> struct drm_bridge bridge;
> + struct drm_connector connector;
> struct regulator_bulk_data supplies[ARRAY_SIZE(tc358764_supplies)];
> struct gpio_desc *gpio_reset;
> - struct drm_bridge *panel_bridge;
> + struct drm_panel *panel;
> int error;
> };
>
> @@ -209,6 +210,12 @@ static inline struct tc358764 *bridge_to_tc358764(struct
> drm_bridge *bridge)
> return container_of(bridge, struct tc358764, bridge);
> }
>
> +static inline
> +struct tc358764 *connector_to_tc358764(struct drm_connector *connector)
> +{
> + return container_of(connector, struct tc358764, connector);
> +}
> +
> static int tc358764_init(struct tc358764 *ctx)
> {
> u32 v = 0;
> @@ -271,11 +278,43 @@ static void tc358764_reset(struct tc358764 *ctx)
> usleep_range(1000, 2000);
> }
>
> +static int tc358764_get_modes(struct drm_connector *connector)
> +{
> + struct tc358764 *ctx = connector_to_tc358764(connector);
> +
> + return drm_panel_get_modes(ctx->panel, connector);
> +}
> +
> +static const
> +struct drm_connector_helper_funcs tc358764_connector_helper_funcs = {
> + .get_modes = tc358764_get_modes,
> +};
> +
> +static const struct drm_connector_funcs tc358764_connector_funcs = {
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy = drm_connector_cleanup,
> + .reset = drm_atomic_helper_connector_reset,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static void tc358764_disable(struct drm_bridge *bridge)
> +{
> + struct tc358764 *ctx = bridge_to_tc358764(bridge);
> + int ret = drm_panel_disable(bridge_to_tc358764(bridge)->panel);
> +
> + if (ret < 0)
> + dev_err(ctx->dev, "error disabling panel (%d)\n", ret);
> +}
> +
> static void tc358764_post_disable(struct drm_bridge *bridge)
> {
> struct tc358764 *ctx = bridge_to_tc358764(bridge);
> int ret;
>
> + ret = drm_panel_unprepare(ctx->panel);
> + if (ret < 0)
> + dev_err(ctx->dev, "error unpreparing panel (%d)\n", ret);
> tc358764_reset(ctx);
> usleep_range(1, 15000);
> ret = regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> @@ -296,28 +335,71 @@ static void tc358764_pre_enable(struct drm_bridge
> *bridge)
> ret = tc358764_init(ctx);
> if (ret < 0)
> dev_err(ctx->dev, "error initializing bridge (%d)\n", ret);
> + ret = drm_panel_prepare(ctx->panel);
> + if (ret < 0)
> + dev_err(ctx->dev, "error preparing panel (%d)\n", ret);
> +}
> +
> +static void tc358764_enable(struct drm_bridge *bridge)
> +{
> + struct tc358764 *ctx = bridge_to_tc358764(bridge);
> + int ret = drm_panel_enable(ctx->panel);
> +
> + if (ret < 0)
> + dev_err(ctx->dev, "error enabling panel (%d)\n", ret);
> }
>
> static int tc358764_attach(struct drm_bridge *bridge,
>
[PATCH 12/14] drm/msm: drop struct_mutex in madvise path
From: Rob Clark
The obj->lock is sufficient for what we need.
This *does* have the implication that userspace can try to shoot
themselves in the foot by racing madvise(DONTNEED) with submit. But
the result will be about the same if they did madvise(DONTNEED) before
the submit ioctl, ie. they might not get want they want if they race
with shrinker. But iova fault handling is robust enough, and userspace
is only shooting it's own foot.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 11 ++--
drivers/gpu/drm/msm/msm_gem.c | 6 ++--
drivers/gpu/drm/msm/msm_gem.h | 38 ++
drivers/gpu/drm/msm/msm_gem_shrinker.c | 4 +--
4 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index e766c1f45045..d2488816ce48 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -906,14 +906,9 @@ static int msm_ioctl_gem_madvise(struct drm_device *dev,
void *data,
return -EINVAL;
}
- ret = mutex_lock_interruptible(&dev->struct_mutex);
- if (ret)
- return ret;
-
obj = drm_gem_object_lookup(file, args->handle);
if (!obj) {
- ret = -ENOENT;
- goto unlock;
+ return -ENOENT;
}
ret = msm_gem_madvise(obj, args->madv);
@@ -922,10 +917,8 @@ static int msm_ioctl_gem_madvise(struct drm_device *dev,
void *data,
ret = 0;
}
- drm_gem_object_put_locked(obj);
+ drm_gem_object_put(obj);
-unlock:
- mutex_unlock(&dev->struct_mutex);
return ret;
}
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 5e75d644ce41..9cdac4f7228c 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -639,8 +639,6 @@ int msm_gem_madvise(struct drm_gem_object *obj, unsigned
madv)
mutex_lock(&msm_obj->lock);
- WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
-
if (msm_obj->madv != __MSM_MADV_PURGED)
msm_obj->madv = madv;
@@ -657,7 +655,7 @@ void msm_gem_purge(struct drm_gem_object *obj, enum
msm_gem_lock subclass)
struct msm_gem_object *msm_obj = to_msm_bo(obj);
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
- WARN_ON(!is_purgeable(msm_obj));
+ WARN_ON(!is_purgeable(msm_obj, subclass));
WARN_ON(obj->import_attach);
mutex_lock_nested(&msm_obj->lock, subclass);
@@ -749,7 +747,7 @@ void msm_gem_active_get(struct drm_gem_object *obj, struct
msm_gpu *gpu)
struct msm_drm_private *priv = obj->dev->dev_private;
might_sleep();
- WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED);
+ WARN_ON(msm_gem_madv(msm_obj, OBJ_LOCK_NORMAL) != MSM_MADV_WILLNEED);
if (!atomic_fetch_inc(&msm_obj->active_count)) {
mutex_lock(&priv->mm_lock);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index e98a8004813b..bb8aa6b1b254 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -97,18 +97,6 @@ static inline bool is_active(struct msm_gem_object *msm_obj)
return atomic_read(&msm_obj->active_count);
}
-static inline bool is_purgeable(struct msm_gem_object *msm_obj)
-{
- WARN_ON(!mutex_is_locked(&msm_obj->base.dev->struct_mutex));
- return (msm_obj->madv == MSM_MADV_DONTNEED) && msm_obj->sgt &&
- !msm_obj->base.dma_buf && !msm_obj->base.import_attach;
-}
-
-static inline bool is_vunmapable(struct msm_gem_object *msm_obj)
-{
- return (msm_obj->vmap_count == 0) && msm_obj->vaddr;
-}
-
/* The shrinker can be triggered while we hold objA->lock, and need
* to grab objB->lock to purge it. Lockdep just sees these as a single
* class of lock, so we use subclasses to teach it the difference.
@@ -125,6 +113,32 @@ enum msm_gem_lock {
OBJ_LOCK_SHRINKER,
};
+/* Use this helper to read msm_obj->madv when msm_obj->lock not held: */
+static inline unsigned
+msm_gem_madv(struct msm_gem_object *msm_obj, enum msm_gem_lock subclass)
+{
+ unsigned madv;
+
+ mutex_lock_nested(&msm_obj->lock, subclass);
+ madv = msm_obj->madv;
+ mutex_unlock(&msm_obj->lock);
+
+ return madv;
+}
+
+static inline bool
+is_purgeable(struct msm_gem_object *msm_obj, enum msm_gem_lock subclass)
+{
+ return (msm_gem_madv(msm_obj, subclass) == MSM_MADV_DONTNEED) &&
+ msm_obj->sgt && !msm_obj->base.dma_buf &&
+ !msm_obj->base.import_attach;
+}
+
+static inline bool is_vunmapable(struct msm_gem_object *msm_obj)
+{
+ return (msm_obj->vmap_count == 0) && msm_obj->vaddr;
+}
+
void msm_gem_purge(struct drm_gem_object *obj, enum msm_gem_lock subclass);
void msm_gem_vunmap(struct drm_gem_object *obj, enum msm_gem_lock subclass);
diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c
b/drivers/gpu/d
[PATCH 05/14] drm/msm: Document and rename preempt_lock
From: Rob Clark
Before adding another lock, give ring->lock a more descriptive name.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 ++--
drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 12 ++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 ++--
drivers/gpu/drm/msm/msm_ringbuffer.c | 2 +-
drivers/gpu/drm/msm/msm_ringbuffer.h | 7 ++-
5 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index c941c8138f25..543437a2186e 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -36,7 +36,7 @@ void a5xx_flush(struct msm_gpu *gpu, struct msm_ringbuffer
*ring,
OUT_RING(ring, upper_32_bits(shadowptr(a5xx_gpu, ring)));
}
- spin_lock_irqsave(&ring->lock, flags);
+ spin_lock_irqsave(&ring->preempt_lock, flags);
/* Copy the shadow to the actual register */
ring->cur = ring->next;
@@ -44,7 +44,7 @@ void a5xx_flush(struct msm_gpu *gpu, struct msm_ringbuffer
*ring,
/* Make sure to wrap wptr if we need to */
wptr = get_wptr(ring);
- spin_unlock_irqrestore(&ring->lock, flags);
+ spin_unlock_irqrestore(&ring->preempt_lock, flags);
/* Make sure everything is posted before making a decision */
mb();
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
index 7e04509c4e1f..183de1139eeb 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
@@ -45,9 +45,9 @@ static inline void update_wptr(struct msm_gpu *gpu, struct
msm_ringbuffer *ring)
if (!ring)
return;
- spin_lock_irqsave(&ring->lock, flags);
+ spin_lock_irqsave(&ring->preempt_lock, flags);
wptr = get_wptr(ring);
- spin_unlock_irqrestore(&ring->lock, flags);
+ spin_unlock_irqrestore(&ring->preempt_lock, flags);
gpu_write(gpu, REG_A5XX_CP_RB_WPTR, wptr);
}
@@ -62,9 +62,9 @@ static struct msm_ringbuffer *get_next_ring(struct msm_gpu
*gpu)
bool empty;
struct msm_ringbuffer *ring = gpu->rb[i];
- spin_lock_irqsave(&ring->lock, flags);
+ spin_lock_irqsave(&ring->preempt_lock, flags);
empty = (get_wptr(ring) == ring->memptrs->rptr);
- spin_unlock_irqrestore(&ring->lock, flags);
+ spin_unlock_irqrestore(&ring->preempt_lock, flags);
if (!empty)
return ring;
@@ -132,9 +132,9 @@ void a5xx_preempt_trigger(struct msm_gpu *gpu)
}
/* Make sure the wptr doesn't update while we're in motion */
- spin_lock_irqsave(&ring->lock, flags);
+ spin_lock_irqsave(&ring->preempt_lock, flags);
a5xx_gpu->preempt[ring->id]->wptr = get_wptr(ring);
- spin_unlock_irqrestore(&ring->lock, flags);
+ spin_unlock_irqrestore(&ring->preempt_lock, flags);
/* Set the address of the incoming preemption record */
gpu_write64(gpu, REG_A5XX_CP_CONTEXT_SWITCH_RESTORE_ADDR_LO,
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 8915882e..fc85f008d69d 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -65,7 +65,7 @@ static void a6xx_flush(struct msm_gpu *gpu, struct
msm_ringbuffer *ring)
OUT_RING(ring, upper_32_bits(shadowptr(a6xx_gpu, ring)));
}
- spin_lock_irqsave(&ring->lock, flags);
+ spin_lock_irqsave(&ring->preempt_lock, flags);
/* Copy the shadow to the actual register */
ring->cur = ring->next;
@@ -73,7 +73,7 @@ static void a6xx_flush(struct msm_gpu *gpu, struct
msm_ringbuffer *ring)
/* Make sure to wrap wptr if we need to */
wptr = get_wptr(ring);
- spin_unlock_irqrestore(&ring->lock, flags);
+ spin_unlock_irqrestore(&ring->preempt_lock, flags);
/* Make sure everything is posted before making a decision */
mb();
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 935bf9b1d941..1b6958e908dc 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -46,7 +46,7 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu
*gpu, int id,
ring->memptrs_iova = memptrs_iova;
INIT_LIST_HEAD(&ring->submits);
- spin_lock_init(&ring->lock);
+ spin_lock_init(&ring->preempt_lock);
snprintf(name, sizeof(name), "gpu-ring-%d", ring->id);
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.h
b/drivers/gpu/drm/msm/msm_ringbuffer.h
index 0987d6bf848c..4956d1bc5d0e 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.h
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.h
@@ -46,7 +46,12 @@ struct msm_ringbuffer {
struct msm_rbmemptrs *memptrs;
uint64_t m
[PATCH 14/14] drm/msm: Don't implicit-sync if only a single ring
From: Rob Clark
Any cross-device sync use-cases *must* use explicit sync. And if there
is only a single ring (no-preemption), everything is FIFO order and
there is no need to implicit-sync.
Mesa should probably just always use MSM_SUBMIT_NO_IMPLICIT, as behavior
is undefined when fences are not used to synchronize buffer usage across
contexts (which is the only case where multiple different priority rings
could come into play).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 7d653bdc92dc..b9b68153b7b2 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -219,7 +219,7 @@ static int submit_lock_objects(struct msm_gem_submit
*submit)
return ret;
}
-static int submit_fence_sync(struct msm_gem_submit *submit, bool no_implicit)
+static int submit_fence_sync(struct msm_gem_submit *submit, bool implicit_sync)
{
int i, ret = 0;
@@ -239,7 +239,7 @@ static int submit_fence_sync(struct msm_gem_submit *submit,
bool no_implicit)
return ret;
}
- if (no_implicit)
+ if (!implicit_sync)
continue;
ret = msm_gem_sync_object(&msm_obj->base, submit->ring->fctx,
@@ -704,7 +704,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
if (ret)
goto out;
- ret = submit_fence_sync(submit, !!(args->flags &
MSM_SUBMIT_NO_IMPLICIT));
+ ret = submit_fence_sync(submit, (gpu->nr_rings > 1) &&
+ !(args->flags & MSM_SUBMIT_NO_IMPLICIT));
if (ret)
goto out;
--
2.26.2
[PATCH 01/14] drm/msm: Use correct drm_gem_object_put() in fail case
From: Rob Clark
We only want to use the _unlocked() variant in the unlocked case.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 14e14caf90f9..a870b3ad129d 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -1115,7 +1115,11 @@ static struct drm_gem_object *_msm_gem_new(struct
drm_device *dev,
return obj;
fail:
- drm_gem_object_put(obj);
+ if (struct_mutex_locked) {
+ drm_gem_object_put_locked(obj);
+ } else {
+ drm_gem_object_put(obj);
+ }
return ERR_PTR(ret);
}
--
2.26.2
[PATCH 00/14] drm/msm: de-struct_mutex-ification
From: Rob Clark This doesn't remove *all* the struct_mutex, but it covers the worst of it, ie. shrinker/madvise/free/retire. The submit path still uses struct_mutex, but it still needs *something* serialize a portion of the submit path, and lock_stat mostly just shows the lock contention there being with other submits. And there are a few other bits of struct_mutex usage in less critical paths (debugfs, etc). But this seems like a reasonable step in the right direction. Rob Clark (14): drm/msm: Use correct drm_gem_object_put() in fail case drm/msm: Drop chatty trace drm/msm: Move update_fences() drm/msm: Add priv->mm_lock to protect active/inactive lists drm/msm: Document and rename preempt_lock drm/msm: Protect ring->submits with it's own lock drm/msm: Refcount submits drm/msm: Remove obj->gpu drm/msm: Drop struct_mutex from the retire path drm/msm: Drop struct_mutex in free_object() path drm/msm: remove msm_gem_free_work drm/msm: drop struct_mutex in madvise path drm/msm: Drop struct_mutex in shrinker path drm/msm: Don't implicit-sync if only a single ring drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 12 +-- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 +- drivers/gpu/drm/msm/msm_debugfs.c | 7 ++ drivers/gpu/drm/msm/msm_drv.c | 15 +--- drivers/gpu/drm/msm/msm_drv.h | 19 +++-- drivers/gpu/drm/msm/msm_gem.c | 76 ++ drivers/gpu/drm/msm/msm_gem.h | 53 + drivers/gpu/drm/msm/msm_gem_shrinker.c| 58 ++ drivers/gpu/drm/msm/msm_gem_submit.c | 17 ++-- drivers/gpu/drm/msm/msm_gpu.c | 96 ++- drivers/gpu/drm/msm/msm_gpu.h | 5 +- drivers/gpu/drm/msm/msm_ringbuffer.c | 3 +- drivers/gpu/drm/msm/msm_ringbuffer.h | 13 ++- 14 files changed, 188 insertions(+), 194 deletions(-) -- 2.26.2
[PATCH 03/14] drm/msm: Move update_fences()
From: Rob Clark
Small cleanup, update_fences() is used in the hangcheck path, but also
in the normal retire path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 31fce3ac0cdc..ca8c95b32c8b 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -265,6 +265,20 @@ int msm_gpu_hw_init(struct msm_gpu *gpu)
return ret;
}
+static void update_fences(struct msm_gpu *gpu, struct msm_ringbuffer *ring,
+ uint32_t fence)
+{
+ struct msm_gem_submit *submit;
+
+ list_for_each_entry(submit, &ring->submits, node) {
+ if (submit->seqno > fence)
+ break;
+
+ msm_update_fence(submit->ring->fctx,
+ submit->fence->seqno);
+ }
+}
+
#ifdef CONFIG_DEV_COREDUMP
static ssize_t msm_gpu_devcoredump_read(char *buffer, loff_t offset,
size_t count, void *data, size_t datalen)
@@ -411,20 +425,6 @@ static void msm_gpu_crashstate_capture(struct msm_gpu *gpu,
* Hangcheck detection for locked gpu:
*/
-static void update_fences(struct msm_gpu *gpu, struct msm_ringbuffer *ring,
- uint32_t fence)
-{
- struct msm_gem_submit *submit;
-
- list_for_each_entry(submit, &ring->submits, node) {
- if (submit->seqno > fence)
- break;
-
- msm_update_fence(submit->ring->fctx,
- submit->fence->seqno);
- }
-}
-
static struct msm_gem_submit *
find_submit(struct msm_ringbuffer *ring, uint32_t fence)
{
--
2.26.2
[PATCH 06/14] drm/msm: Protect ring->submits with it's own lock
From: Rob Clark
One less place to rely on dev->struct_mutex.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 2 ++
drivers/gpu/drm/msm/msm_gpu.c| 37 ++--
drivers/gpu/drm/msm/msm_ringbuffer.c | 1 +
drivers/gpu/drm/msm/msm_ringbuffer.h | 6 +
4 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index aa5c60a7132d..e1d1f005b3d4 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -63,7 +63,9 @@ static struct msm_gem_submit *submit_create(struct drm_device
*dev,
void msm_gem_submit_free(struct msm_gem_submit *submit)
{
dma_fence_put(submit->fence);
+ spin_lock(&submit->ring->submit_lock);
list_del(&submit->node);
+ spin_unlock(&submit->ring->submit_lock);
put_pid(submit->pid);
msm_submitqueue_put(submit->queue);
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index ca8c95b32c8b..8d1e254f964a 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -270,6 +270,7 @@ static void update_fences(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
{
struct msm_gem_submit *submit;
+ spin_lock(&ring->submit_lock);
list_for_each_entry(submit, &ring->submits, node) {
if (submit->seqno > fence)
break;
@@ -277,6 +278,7 @@ static void update_fences(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
msm_update_fence(submit->ring->fctx,
submit->fence->seqno);
}
+ spin_unlock(&ring->submit_lock);
}
#ifdef CONFIG_DEV_COREDUMP
@@ -430,11 +432,14 @@ find_submit(struct msm_ringbuffer *ring, uint32_t fence)
{
struct msm_gem_submit *submit;
- WARN_ON(!mutex_is_locked(&ring->gpu->dev->struct_mutex));
-
- list_for_each_entry(submit, &ring->submits, node)
- if (submit->seqno == fence)
+ spin_lock(&ring->submit_lock);
+ list_for_each_entry(submit, &ring->submits, node) {
+ if (submit->seqno == fence) {
+ spin_unlock(&ring->submit_lock);
return submit;
+ }
+ }
+ spin_unlock(&ring->submit_lock);
return NULL;
}
@@ -523,8 +528,10 @@ static void recover_worker(struct work_struct *work)
for (i = 0; i < gpu->nr_rings; i++) {
struct msm_ringbuffer *ring = gpu->rb[i];
+ spin_lock(&ring->submit_lock);
list_for_each_entry(submit, &ring->submits, node)
gpu->funcs->submit(gpu, submit);
+ spin_unlock(&ring->submit_lock);
}
}
@@ -711,7 +718,6 @@ static void retire_submit(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
static void retire_submits(struct msm_gpu *gpu)
{
struct drm_device *dev = gpu->dev;
- struct msm_gem_submit *submit, *tmp;
int i;
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
@@ -720,9 +726,24 @@ static void retire_submits(struct msm_gpu *gpu)
for (i = 0; i < gpu->nr_rings; i++) {
struct msm_ringbuffer *ring = gpu->rb[i];
- list_for_each_entry_safe(submit, tmp, &ring->submits, node) {
- if (dma_fence_is_signaled(submit->fence))
+ while (true) {
+ struct msm_gem_submit *submit = NULL;
+
+ spin_lock(&ring->submit_lock);
+ submit = list_first_entry_or_null(&ring->submits,
+ struct msm_gem_submit, node);
+ spin_unlock(&ring->submit_lock);
+
+ /*
+* If no submit, we are done. If submit->fence hasn't
+* been signalled, then later submits are not signalled
+* either, so we are also done.
+*/
+ if (submit && dma_fence_is_signaled(submit->fence)) {
retire_submit(gpu, ring, submit);
+ } else {
+ break;
+ }
}
}
}
@@ -765,7 +786,9 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit)
submit->seqno = ++ring->seqno;
+ spin_lock(&ring->submit_lock);
list_add_tail(&submit->node, &ring->submits);
+ spin_unlock(&ring->submit_lock);
msm_rd_dump_submit(priv->rd, submit, NULL);
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 1b6958e908dc..4d2a2a4abef8 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -46,6 +46,7 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu
*gpu,
[PATCH 07/14] drm/msm: Refcount submits
From: Rob Clark
Before we remove dev->struct_mutex from the retire path, we have to deal
with the situation of a submit retiring before the submit ioctl returns.
To deal with this, ring->submits will hold a reference to the submit,
which is dropped when the submit is retired. And the submit ioctl path
holds it's own ref, which it drops when it is done with the submit.
Also, add to submit list *after* getting/pinning bo's, to prevent badness
in case the completed fence is corrupted, and retire_worker mistakenly
believes the submit is done too early.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.h| 1 -
drivers/gpu/drm/msm/msm_gem.h| 13 +
drivers/gpu/drm/msm/msm_gem_submit.c | 12 ++--
drivers/gpu/drm/msm/msm_gpu.c| 21 -
4 files changed, 35 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 50978e5db376..535f9e718e2d 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -277,7 +277,6 @@ void msm_unregister_mmu(struct drm_device *dev, struct
msm_mmu *mmu);
bool msm_use_mmu(struct drm_device *dev);
-void msm_gem_submit_free(struct msm_gem_submit *submit);
int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
struct drm_file *file);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index a1bf741b9b89..e05b1530aca6 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -136,6 +136,7 @@ void msm_gem_free_work(struct work_struct *work);
* lasts for the duration of the submit-ioctl.
*/
struct msm_gem_submit {
+ struct kref ref;
struct drm_device *dev;
struct msm_gpu *gpu;
struct msm_gem_address_space *aspace;
@@ -169,6 +170,18 @@ struct msm_gem_submit {
} bos[];
};
+void __msm_gem_submit_destroy(struct kref *kref);
+
+static inline void msm_gem_submit_get(struct msm_gem_submit *submit)
+{
+ kref_get(&submit->ref);
+}
+
+static inline void msm_gem_submit_put(struct msm_gem_submit *submit)
+{
+ kref_put(&submit->ref, __msm_gem_submit_destroy);
+}
+
/* helper to determine of a buffer in submit should be dumped, used for both
* devcoredump and debugfs cmdstream dumping:
*/
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index e1d1f005b3d4..7d653bdc92dc 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -42,6 +42,7 @@ static struct msm_gem_submit *submit_create(struct drm_device
*dev,
if (!submit)
return NULL;
+ kref_init(&submit->ref);
submit->dev = dev;
submit->aspace = queue->ctx->aspace;
submit->gpu = gpu;
@@ -60,12 +61,12 @@ static struct msm_gem_submit *submit_create(struct
drm_device *dev,
return submit;
}
-void msm_gem_submit_free(struct msm_gem_submit *submit)
+void __msm_gem_submit_destroy(struct kref *kref)
{
+ struct msm_gem_submit *submit =
+ container_of(kref, struct msm_gem_submit, ref);
+
dma_fence_put(submit->fence);
- spin_lock(&submit->ring->submit_lock);
- list_del(&submit->node);
- spin_unlock(&submit->ring->submit_lock);
put_pid(submit->pid);
msm_submitqueue_put(submit->queue);
@@ -805,8 +806,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
submit_cleanup(submit);
if (has_ww_ticket)
ww_acquire_fini(&submit->ticket);
- if (ret)
- msm_gem_submit_free(submit);
+ msm_gem_submit_put(submit);
out_unlock:
if (ret && (out_fence_fd >= 0))
put_unused_fd(out_fence_fd);
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 8d1e254f964a..fd3fc6f36ab1 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -712,7 +712,12 @@ static void retire_submit(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
pm_runtime_mark_last_busy(&gpu->pdev->dev);
pm_runtime_put_autosuspend(&gpu->pdev->dev);
- msm_gem_submit_free(submit);
+
+ spin_lock(&ring->submit_lock);
+ list_del(&submit->node);
+ spin_unlock(&ring->submit_lock);
+
+ msm_gem_submit_put(submit);
}
static void retire_submits(struct msm_gpu *gpu)
@@ -786,10 +791,6 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit)
submit->seqno = ++ring->seqno;
- spin_lock(&ring->submit_lock);
- list_add_tail(&submit->node, &ring->submits);
- spin_unlock(&ring->submit_lock);
-
msm_rd_dump_submit(priv->rd, submit, NULL);
update_sw_cntrs(gpu);
@@ -816,6 +817,16 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit)
msm_gem_active_get(drm_obj, gpu);
}
+ /*
+* ring->submits holds a ref to the submit, to deal with
[PATCH 02/14] drm/msm: Drop chatty trace
From: Rob Clark
It is somewhat redundant with the gpu tracepoints, and anyways not too
useful to justify spamming the log when debug traces are enabled.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 55d16489d0f3..31fce3ac0cdc 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -535,7 +535,6 @@ static void recover_worker(struct work_struct *work)
static void hangcheck_timer_reset(struct msm_gpu *gpu)
{
- DBG("%s", gpu->name);
mod_timer(&gpu->hangcheck_timer,
round_jiffies_up(jiffies + DRM_MSM_HANGCHECK_JIFFIES));
}
--
2.26.2
[PATCH 10/14] drm/msm: Drop struct_mutex in free_object() path
From: Rob Clark
Now that active_list/inactive_list is protected by mm_lock, we no longer
need dev->struct_mutex in the free_object() path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index c52a3969e60b..126d92fd21cd 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -927,8 +927,6 @@ static void free_object(struct msm_gem_object *msm_obj)
struct drm_device *dev = obj->dev;
struct msm_drm_private *priv = dev->dev_private;
- WARN_ON(!mutex_is_locked(&dev->struct_mutex));
-
/* object should not be on active list: */
WARN_ON(is_active(msm_obj));
@@ -965,20 +963,14 @@ void msm_gem_free_work(struct work_struct *work)
{
struct msm_drm_private *priv =
container_of(work, struct msm_drm_private, free_work);
- struct drm_device *dev = priv->dev;
struct llist_node *freed;
struct msm_gem_object *msm_obj, *next;
while ((freed = llist_del_all(&priv->free_list))) {
-
- mutex_lock(&dev->struct_mutex);
-
llist_for_each_entry_safe(msm_obj, next,
freed, freed)
free_object(msm_obj);
- mutex_unlock(&dev->struct_mutex);
-
if (need_resched())
break;
}
--
2.26.2
[PATCH 04/14] drm/msm: Add priv->mm_lock to protect active/inactive lists
From: Rob Clark
Rather than relying on the big dev->struct_mutex hammer, introduce a
more specific lock for protecting the bo lists.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_debugfs.c | 7 +++
drivers/gpu/drm/msm/msm_drv.c | 1 +
drivers/gpu/drm/msm/msm_drv.h | 13 +++-
drivers/gpu/drm/msm/msm_gem.c | 28 +++---
drivers/gpu/drm/msm/msm_gem_shrinker.c | 12 +++
drivers/gpu/drm/msm/msm_gpu.h | 5 -
6 files changed, 52 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_debugfs.c
b/drivers/gpu/drm/msm/msm_debugfs.c
index ee2e270f464c..64afbed89821 100644
--- a/drivers/gpu/drm/msm/msm_debugfs.c
+++ b/drivers/gpu/drm/msm/msm_debugfs.c
@@ -112,6 +112,11 @@ static int msm_gem_show(struct drm_device *dev, struct
seq_file *m)
{
struct msm_drm_private *priv = dev->dev_private;
struct msm_gpu *gpu = priv->gpu;
+ int ret;
+
+ ret = mutex_lock_interruptible(&priv->mm_lock);
+ if (ret)
+ return ret;
if (gpu) {
seq_printf(m, "Active Objects (%s):\n", gpu->name);
@@ -121,6 +126,8 @@ static int msm_gem_show(struct drm_device *dev, struct
seq_file *m)
seq_printf(m, "Inactive Objects:\n");
msm_gem_describe_objects(&priv->inactive_list, m);
+ mutex_unlock(&priv->mm_lock);
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 49685571dc0e..dc6efc089285 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -441,6 +441,7 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
init_llist_head(&priv->free_list);
INIT_LIST_HEAD(&priv->inactive_list);
+ mutex_init(&priv->mm_lock);
drm_mode_config_init(ddev);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b9dd8f8f4887..50978e5db376 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -174,8 +174,19 @@ struct msm_drm_private {
struct msm_rd_state *hangrd; /* debugfs to dump hanging submits */
struct msm_perf_state *perf;
- /* list of GEM objects: */
+ /*
+* List of inactive GEM objects. Every bo is either in the
inactive_list
+* or gpu->active_list (for the gpu it is active on[1])
+*
+* These lists are protected by mm_lock. If struct_mutex is involved,
it
+* should be aquired prior to mm_lock. One should *not* hold mm_lock in
+* get_pages()/vmap()/etc paths, as they can trigger the shrinker.
+*
+* [1] if someone ever added support for the old 2d cores, there could
be
+* more than one gpu object
+*/
struct list_head inactive_list;
+ struct mutex mm_lock;
/* worker for delayed free of objects: */
struct work_struct free_work;
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index a870b3ad129d..b04ed8b52f9d 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -746,13 +746,17 @@ int msm_gem_sync_object(struct drm_gem_object *obj,
void msm_gem_active_get(struct drm_gem_object *obj, struct msm_gpu *gpu)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
- WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
+ struct msm_drm_private *priv = obj->dev->dev_private;
+
+ might_sleep();
WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED);
if (!atomic_fetch_inc(&msm_obj->active_count)) {
+ mutex_lock(&priv->mm_lock);
msm_obj->gpu = gpu;
list_del_init(&msm_obj->mm_list);
list_add_tail(&msm_obj->mm_list, &gpu->active_list);
+ mutex_unlock(&priv->mm_lock);
}
}
@@ -761,12 +765,14 @@ void msm_gem_active_put(struct drm_gem_object *obj)
struct msm_gem_object *msm_obj = to_msm_bo(obj);
struct msm_drm_private *priv = obj->dev->dev_private;
- WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
+ might_sleep();
if (!atomic_dec_return(&msm_obj->active_count)) {
+ mutex_lock(&priv->mm_lock);
msm_obj->gpu = NULL;
list_del_init(&msm_obj->mm_list);
list_add_tail(&msm_obj->mm_list, &priv->inactive_list);
+ mutex_unlock(&priv->mm_lock);
}
}
@@ -921,13 +927,16 @@ static void free_object(struct msm_gem_object *msm_obj)
{
struct drm_gem_object *obj = &msm_obj->base;
struct drm_device *dev = obj->dev;
+ struct msm_drm_private *priv = dev->dev_private;
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
/* object should not be on active list: */
WARN_ON(is_active(msm_obj));
+ mutex_lock(&priv->mm_lock);
list_del(&msm_obj->mm_list);
+ mutex_unlock(&priv->mm_lock);
mutex_lock(&msm_ob
[PATCH 08/14] drm/msm: Remove obj->gpu
From: Rob Clark
It cannot be atomically updated with obj->active_count, and the only
purpose is a useless WARN_ON() (which becomes a buggy WARN_ON() once
retire_submits() is not serialized with incoming submits via
struct_mutex)
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 2 --
drivers/gpu/drm/msm/msm_gem.h | 1 -
drivers/gpu/drm/msm/msm_gpu.c | 5 -
3 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index b04ed8b52f9d..c52a3969e60b 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -753,7 +753,6 @@ void msm_gem_active_get(struct drm_gem_object *obj, struct
msm_gpu *gpu)
if (!atomic_fetch_inc(&msm_obj->active_count)) {
mutex_lock(&priv->mm_lock);
- msm_obj->gpu = gpu;
list_del_init(&msm_obj->mm_list);
list_add_tail(&msm_obj->mm_list, &gpu->active_list);
mutex_unlock(&priv->mm_lock);
@@ -769,7 +768,6 @@ void msm_gem_active_put(struct drm_gem_object *obj)
if (!atomic_dec_return(&msm_obj->active_count)) {
mutex_lock(&priv->mm_lock);
- msm_obj->gpu = NULL;
list_del_init(&msm_obj->mm_list);
list_add_tail(&msm_obj->mm_list, &priv->inactive_list);
mutex_unlock(&priv->mm_lock);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index e05b1530aca6..61147bd96b06 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -64,7 +64,6 @@ struct msm_gem_object {
*
*/
struct list_head mm_list;
- struct msm_gpu *gpu; /* non-null if active */
/* Transiently in the process of submit ioctl, objects associated
* with the submit are on submit->bo_list.. this only lasts for
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index fd3fc6f36ab1..c9ff19a75169 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -800,11 +800,6 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit)
struct drm_gem_object *drm_obj = &msm_obj->base;
uint64_t iova;
- /* can't happen yet.. but when we add 2d support we'll have
-* to deal w/ cross-ring synchronization:
-*/
- WARN_ON(is_active(msm_obj) && (msm_obj->gpu != gpu));
-
/* submit takes a reference to the bo and iova until retired: */
drm_gem_object_get(&msm_obj->base);
msm_gem_get_and_pin_iova(&msm_obj->base, submit->aspace, &iova);
--
2.26.2
[PATCH 11/14] drm/msm: remove msm_gem_free_work
From: Rob Clark
Now that we don't need struct_mutex in the free path, we can get rid of
the asynchronous free altogether.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 3 ---
drivers/gpu/drm/msm/msm_drv.h | 5 -
drivers/gpu/drm/msm/msm_gem.c | 27 ---
drivers/gpu/drm/msm/msm_gem.h | 1 -
4 files changed, 36 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index dc6efc089285..e766c1f45045 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -437,9 +437,6 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
priv->wq = alloc_ordered_workqueue("msm", 0);
- INIT_WORK(&priv->free_work, msm_gem_free_work);
- init_llist_head(&priv->free_list);
-
INIT_LIST_HEAD(&priv->inactive_list);
mutex_init(&priv->mm_lock);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 535f9e718e2d..96f8009e247c 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -188,10 +188,6 @@ struct msm_drm_private {
struct list_head inactive_list;
struct mutex mm_lock;
- /* worker for delayed free of objects: */
- struct work_struct free_work;
- struct llist_head free_list;
-
struct workqueue_struct *wq;
unsigned int num_planes;
@@ -340,7 +336,6 @@ void msm_gem_kernel_put(struct drm_gem_object *bo,
struct msm_gem_address_space *aspace, bool locked);
struct drm_gem_object *msm_gem_import(struct drm_device *dev,
struct dma_buf *dmabuf, struct sg_table *sgt);
-void msm_gem_free_work(struct work_struct *work);
__printf(2, 3)
void msm_gem_object_set_name(struct drm_gem_object *bo, const char *fmt, ...);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 126d92fd21cd..5e75d644ce41 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -917,16 +917,6 @@ void msm_gem_free_object(struct drm_gem_object *obj)
struct drm_device *dev = obj->dev;
struct msm_drm_private *priv = dev->dev_private;
- if (llist_add(&msm_obj->freed, &priv->free_list))
- queue_work(priv->wq, &priv->free_work);
-}
-
-static void free_object(struct msm_gem_object *msm_obj)
-{
- struct drm_gem_object *obj = &msm_obj->base;
- struct drm_device *dev = obj->dev;
- struct msm_drm_private *priv = dev->dev_private;
-
/* object should not be on active list: */
WARN_ON(is_active(msm_obj));
@@ -959,23 +949,6 @@ static void free_object(struct msm_gem_object *msm_obj)
kfree(msm_obj);
}
-void msm_gem_free_work(struct work_struct *work)
-{
- struct msm_drm_private *priv =
- container_of(work, struct msm_drm_private, free_work);
- struct llist_node *freed;
- struct msm_gem_object *msm_obj, *next;
-
- while ((freed = llist_del_all(&priv->free_list))) {
- llist_for_each_entry_safe(msm_obj, next,
- freed, freed)
- free_object(msm_obj);
-
- if (need_resched())
- break;
- }
-}
-
/* convenience method to construct a GEM buffer object, and userspace handle */
int msm_gem_new_handle(struct drm_device *dev, struct drm_file *file,
uint32_t size, uint32_t flags, uint32_t *handle,
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 61147bd96b06..e98a8004813b 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -127,7 +127,6 @@ enum msm_gem_lock {
void msm_gem_purge(struct drm_gem_object *obj, enum msm_gem_lock subclass);
void msm_gem_vunmap(struct drm_gem_object *obj, enum msm_gem_lock subclass);
-void msm_gem_free_work(struct work_struct *work);
/* Created per submit-ioctl, to track bo's and cmdstream bufs, etc,
* associated with the cmdstream submission for synchronization (and
--
2.26.2
[PATCH 13/14] drm/msm: Drop struct_mutex in shrinker path
From: Rob Clark
Now that the inactive_list is protected by mm_lock, and everything
else on per-obj basis is protected by obj->lock, we no longer depend
on struct_mutex.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 1 -
drivers/gpu/drm/msm/msm_gem_shrinker.c | 54 --
2 files changed, 55 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 9cdac4f7228c..e749a1c6f4e0 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -654,7 +654,6 @@ void msm_gem_purge(struct drm_gem_object *obj, enum
msm_gem_lock subclass)
struct drm_device *dev = obj->dev;
struct msm_gem_object *msm_obj = to_msm_bo(obj);
- WARN_ON(!mutex_is_locked(&dev->struct_mutex));
WARN_ON(!is_purgeable(msm_obj, subclass));
WARN_ON(obj->import_attach);
diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c
b/drivers/gpu/drm/msm/msm_gem_shrinker.c
index 39a1b5327267..2c7bda1e2bf9 100644
--- a/drivers/gpu/drm/msm/msm_gem_shrinker.c
+++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c
@@ -8,48 +8,13 @@
#include "msm_gem.h"
#include "msm_gpu_trace.h"
-static bool msm_gem_shrinker_lock(struct drm_device *dev, bool *unlock)
-{
- /* NOTE: we are *closer* to being able to get rid of
-* mutex_trylock_recursive().. the msm_gem code itself does
-* not need struct_mutex, although codepaths that can trigger
-* shrinker are still called in code-paths that hold the
-* struct_mutex.
-*
-* Also, msm_obj->madv is protected by struct_mutex.
-*
-* The next step is probably split out a seperate lock for
-* protecting inactive_list, so that shrinker does not need
-* struct_mutex.
-*/
- switch (mutex_trylock_recursive(&dev->struct_mutex)) {
- case MUTEX_TRYLOCK_FAILED:
- return false;
-
- case MUTEX_TRYLOCK_SUCCESS:
- *unlock = true;
- return true;
-
- case MUTEX_TRYLOCK_RECURSIVE:
- *unlock = false;
- return true;
- }
-
- BUG();
-}
-
static unsigned long
msm_gem_shrinker_count(struct shrinker *shrinker, struct shrink_control *sc)
{
struct msm_drm_private *priv =
container_of(shrinker, struct msm_drm_private, shrinker);
- struct drm_device *dev = priv->dev;
struct msm_gem_object *msm_obj;
unsigned long count = 0;
- bool unlock;
-
- if (!msm_gem_shrinker_lock(dev, &unlock))
- return 0;
mutex_lock(&priv->mm_lock);
@@ -60,9 +25,6 @@ msm_gem_shrinker_count(struct shrinker *shrinker, struct
shrink_control *sc)
mutex_unlock(&priv->mm_lock);
- if (unlock)
- mutex_unlock(&dev->struct_mutex);
-
return count;
}
@@ -71,13 +33,8 @@ msm_gem_shrinker_scan(struct shrinker *shrinker, struct
shrink_control *sc)
{
struct msm_drm_private *priv =
container_of(shrinker, struct msm_drm_private, shrinker);
- struct drm_device *dev = priv->dev;
struct msm_gem_object *msm_obj;
unsigned long freed = 0;
- bool unlock;
-
- if (!msm_gem_shrinker_lock(dev, &unlock))
- return SHRINK_STOP;
mutex_lock(&priv->mm_lock);
@@ -92,9 +49,6 @@ msm_gem_shrinker_scan(struct shrinker *shrinker, struct
shrink_control *sc)
mutex_unlock(&priv->mm_lock);
- if (unlock)
- mutex_unlock(&dev->struct_mutex);
-
if (freed > 0)
trace_msm_gem_purge(freed << PAGE_SHIFT);
@@ -106,13 +60,8 @@ msm_gem_shrinker_vmap(struct notifier_block *nb, unsigned
long event, void *ptr)
{
struct msm_drm_private *priv =
container_of(nb, struct msm_drm_private, vmap_notifier);
- struct drm_device *dev = priv->dev;
struct msm_gem_object *msm_obj;
unsigned unmapped = 0;
- bool unlock;
-
- if (!msm_gem_shrinker_lock(dev, &unlock))
- return NOTIFY_DONE;
mutex_lock(&priv->mm_lock);
@@ -130,9 +79,6 @@ msm_gem_shrinker_vmap(struct notifier_block *nb, unsigned
long event, void *ptr)
mutex_unlock(&priv->mm_lock);
- if (unlock)
- mutex_unlock(&dev->struct_mutex);
-
*(unsigned long *)ptr += unmapped;
if (unmapped > 0)
--
2.26.2
[PATCH 09/14] drm/msm: Drop struct_mutex from the retire path
From: Rob Clark
Now that we are not relying on dev->struct_mutex to protect the
ring->submits lists, drop the struct_mutex lock.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index c9ff19a75169..5e351d1c00e9 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -707,7 +707,7 @@ static void retire_submit(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
msm_gem_active_put(&msm_obj->base);
msm_gem_unpin_iova(&msm_obj->base, submit->aspace);
- drm_gem_object_put_locked(&msm_obj->base);
+ drm_gem_object_put(&msm_obj->base);
}
pm_runtime_mark_last_busy(&gpu->pdev->dev);
@@ -722,11 +722,8 @@ static void retire_submit(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
static void retire_submits(struct msm_gpu *gpu)
{
- struct drm_device *dev = gpu->dev;
int i;
- WARN_ON(!mutex_is_locked(&dev->struct_mutex));
-
/* Retire the commits starting with highest priority */
for (i = 0; i < gpu->nr_rings; i++) {
struct msm_ringbuffer *ring = gpu->rb[i];
@@ -756,15 +753,12 @@ static void retire_submits(struct msm_gpu *gpu)
static void retire_worker(struct work_struct *work)
{
struct msm_gpu *gpu = container_of(work, struct msm_gpu, retire_work);
- struct drm_device *dev = gpu->dev;
int i;
for (i = 0; i < gpu->nr_rings; i++)
update_fences(gpu, gpu->rb[i], gpu->rb[i]->memptrs->fence);
- mutex_lock(&dev->struct_mutex);
retire_submits(gpu);
- mutex_unlock(&dev->struct_mutex);
}
/* call from irq handler to schedule work to retire bo's */
--
2.26.2
Re: [PATCH v7 3/5] PCI: pciehp: check and wait port status out of DPC before handling DLLSC and PDC
On Sat, Oct 03, 2020 at 03:55:12AM -0400, Ethan Zhao wrote: > When root port has DPC capability and it is enabled, then triggered by > errors, DPC DLLSC and PDC etc interrupts will be sent to DPC driver, pciehp > drivers almost at the same time. Do the DLLSC and PDC events occur as a result of handling the error or do they occur independently? If the latter, I don't see how we can tell whether the card in the slot is still the same. If the former, holding the hotplug slot's reset_lock and doing something along the lines of pciehp_reset_slot() (or calling it directly) might solve the race. Thanks, Lukas
[RFC PATCH 0/1] overlayfs: C/R enhancments (RFC)
Some time ago we discussed about the problem of Checkpoint-Restoring
overlayfs mounts [1]. Big thanks to Amir for review and suggestions.
Brief from previous discussion.
Problem statement: to checkpoint-restore overlayfs mounts we need
to save overlayfs mount state and save it into the image. Basically,
this state for us it's just mount options of overlayfs mount. But
here we have two problems:
I. during mounting overlayfs user may specify relative paths in upperdir,
workdir, lowerdir options
II. also user may unmount mount from which these paths was opened during
mounting
This is real problems for us. My first patch was attempt to address both
problems.
1. I've added refcnt get for mounts from which overlayfs was mounted.
2. I've changed overlayfs mountinfo show algorithm, so overlayfs started to
*always*
show full paths for upperdir,workdir,lowerdirs.
3. I've added mnt_id show-time only option which allows to determine from which
mnt_id
we opened options paths.
Pros:
- we can determine full information about overlayfs mount
- we hold refcnt to mount, so, user may unmount source mounts only
with lazy flag
Cons:
- by adding refcnt get for mount I've changed possible overlayfs usecases
- by showing *full* paths we can more easily reache PAGE_SIZE limit of
mounts options in procfs
- by adding mnt_id show-only option I've added inconsistency between
mount-time options and show-time mount options
After very productive discussion with Amir and Pavel I've decided to write new
implementation. In new approach we decided *not* to take extra refcnts to
mounts.
Also we decided to use exportfs fhandles instead of full paths. To determine
full path we plan to use the next algo:
1. Export {s_dev; fhandle} from overlayfs for *all* sources
2. User open_by_handle_at syscall to open all these fhandles (we need to
determine mount for each fhandle, looks like we can do this by s_dev by linear
search in /proc//mountinfo)
3. Then readlink /proc//fd/
4. Dump this full path+mnt_id
But there is question. How to export this {s_dev; fhandle} from kernel to
userspace?
- We decided not to use procfs.
- Amir proposed solution - use xattrs. But after diving into it I've meet
problem
where I can set this xattrs?
If I set this xattrs on overlayfs dentries then during rsync, or cp -p=xattr we
will copy
this temporary information.
- ioctls? (this patchset implements this approach)
- fsinfo subsystem (not merged yet) [2]
Problems with ioctls:
1. We limited in output data size (16 KB AFAIK)
but MAX_HANDLE_SZ=128(bytes), OVL_MAX_STACK=500(num lowerdirs)
So, MAX_HANDLE_SZ*OVL_MAX_STACK = 64KB which is bigger than limit.
So, I've decided to give user one fhandle by one call. This is also
bad from the performance point of view.
2. When using ioctls we need to have *fixed* size of input and output.
So, if MAX_HANDLE_SZ will change in the future our _IOR('o', 2, struct
ovl_mnt_opt_fh)
will also change with struct ovl_mnt_opt_fh.
So, I hope that we discuss about this patchset and try to make possible
solutions together.
Thanks.
Regards, Alex.
[1]
https://lore.kernel.org/linux-unionfs/20200604161133.20949-1-alexander.mikhalit...@virtuozzo.com/
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=fsinfo-core
Cc: Amir Goldstein
Cc: Andrei Vagin
Cc: Pavel Tikhomirov
Cc: Miklos Szeredi
Cc: David Howells
Cc: linux-unio...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Alexander Mikhalitsyn (1):
overlayfs: add ioctls that allows to get fhandle for layers dentries
fs/overlayfs/readdir.c | 160 +
1 file changed, 160 insertions(+)
--
2.25.1
Re: [PATCH] mm/vmscan: drop unneeded assignment in kswapd()
On Sun, Oct 04, 2020 at 02:58:27PM +0200, Lukas Bulwahn wrote:
> The refactoring to kswapd() in commit e716f2eb24de ("mm, vmscan: prevent
> kswapd sleeping prematurely due to mismatched classzone_idx") turned an
> assignment to reclaim_order into a dead store, as in all further paths,
> reclaim_order will be assigned again before it is used.
>
> make clang-analyzer on x86_64 tinyconfig caught my attention with:
>
> mm/vmscan.c: warning: Although the value stored to 'reclaim_order' is
> used in the enclosing expression, the value is never actually read from
> 'reclaim_order' [clang-analyzer-deadcode.DeadStores]
>
> Compilers will detect this unneeded assignment and optimize this anyway.
> So, the resulting binary is identical before and after this change.
>
> Simplify the code and remove unneeded assignment to make clang-analyzer
> happy.
>
> No functional change. No change in binary code.
>
> Signed-off-by: Lukas Bulwahn
I'm not really keen on this. With the patch, reclaim_order can be passed
uninitialised to kswapd_try_to_sleep. While a sufficiently smart
compiler might be able to optimise how reclaim_order is used, it's not
guaranteed either. Similarly, a change in kswapd_try_to_sleep and its
called functions could rely on reclaim_order being a valid value and
then introduce a subtle bug.
--
Mel Gorman
SUSE Labs
[RFC PATCH 1/1] overlayfs: add ioctls that allows to get fhandle for layers dentries
Add several ioctls to ovl_dir_operations that allows to get file handles
for upperdir, workdir, lowerdir dentries. Special {s_dev; fhandle}
format used. (Ideally should be {mnt_id; fhandle} but this impossible
because overlayfs not keeps mounts refcnt for layers.)
Added ioctls list:
OVL_IOC_GETLWRFHNDLSNUM - get lowerdirs count
OVL_IOC_GETLWRFHNDL - get i-th lowerdir fhandle
OVL_IOC_GETUPPRFHNDL - get upperdir fhandle
OVL_IOC_GETWRKFHNDL - get workdir fhandle
Cc: Amir Goldstein
Cc: Andrei Vagin
Cc: Pavel Tikhomirov
Cc: Miklos Szeredi
Cc: David Howells
Cc: linux-unio...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Alexander Mikhalitsyn
---
fs/overlayfs/readdir.c | 160 +
1 file changed, 160 insertions(+)
diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
index 596002054ac6..12ee043d2b3a 100644
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "overlayfs.h"
struct ovl_cache_entry {
@@ -58,6 +59,20 @@ struct ovl_dir_file {
struct file *upperfile;
};
+struct ovl_mnt_opt_fh {
+ __u32 s_dev;
+ struct file_handle fh;
+ /* use f_handle field from struct file_handle */
+ __u8 __fhdata[MAX_HANDLE_SZ];
+};
+
+struct ovl_mnt_opt_fh_req {
+ union {
+ unsigned int lowernum;
+ struct ovl_mnt_opt_fh result;
+ };
+} __packed;
+
static struct ovl_cache_entry *ovl_cache_entry_from_node(struct rb_node *n)
{
return rb_entry(n, struct ovl_cache_entry, node);
@@ -942,6 +957,150 @@ static int ovl_dir_open(struct inode *inode, struct file
*file)
return 0;
}
+static long ovl_ioctl_get_lowers_num(struct super_block *sb)
+{
+ struct ovl_entry *oe = sb->s_root->d_fsdata;
+ return oe->numlower;
+}
+
+static struct ovl_mnt_opt_fh *__ovl_encode_mnt_opt_fh(struct dentry *dentry)
+{
+ struct ovl_mnt_opt_fh *opt_fh;
+ int fh_type, dwords;
+ int buflen = MAX_HANDLE_SZ;
+ int err;
+
+ opt_fh = kzalloc(sizeof(struct ovl_mnt_opt_fh), GFP_KERNEL);
+ if (!opt_fh)
+ return ERR_PTR(-ENOMEM);
+
+ /* we ask for a non connected handle */
+ dwords = buflen >> 2;
+ fh_type = exportfs_encode_fh(dentry, (void *)opt_fh->fh.f_handle,
&dwords, 0);
+ buflen = (dwords << 2);
+
+ err = -EIO;
+ if (WARN_ON(fh_type < 0) ||
+ WARN_ON(buflen > MAX_HANDLE_SZ) ||
+ WARN_ON(fh_type == FILEID_INVALID))
+ goto out_err;
+
+ opt_fh->fh.handle_type = fh_type;
+ opt_fh->fh.handle_bytes = buflen;
+
+ /*
+* Ideally, we want to have mnt_id+fhandle, but overlayfs not
+* keep refcnts on layers mounts and we couldn't determine
+* mnt_ids for layers. So, let's give s_dev to CRIU.
+* It's better than nothing.
+*/
+ opt_fh->s_dev = dentry->d_sb->s_dev;
+
+ return opt_fh;
+
+out_err:
+ kfree(opt_fh);
+ return ERR_PTR(err);
+}
+
+static long __ovl_ioctl_get_fhandle(struct dentry *origin,
+ unsigned long arg)
+{
+ struct ovl_mnt_opt_fh *fh;
+ int ret = 0;
+
+ fh = __ovl_encode_mnt_opt_fh(origin);
+ if (IS_ERR(fh))
+ return PTR_ERR(fh);
+
+ if (copy_to_user((struct ovl_mnt_opt_fh __user *)arg,
+fh, sizeof(*fh)))
+ ret = -EFAULT;
+
+ kfree(fh);
+ return ret;
+}
+
+static long ovl_ioctl_get_lower_fhandle(struct super_block *sb,
+ unsigned long arg)
+{
+ struct ovl_entry *oe = sb->s_root->d_fsdata;
+ struct dentry *origin;
+ struct ovl_mnt_opt_fh_req input;
+
+ BUILD_BUG_ON(sizeof(struct ovl_mnt_opt_fh_req) != sizeof(struct
ovl_mnt_opt_fh));
+
+ if (copy_from_user(&input, (struct ovl_mnt_opt_fh_req __user *)arg,
+ sizeof(input)))
+ return -EFAULT;
+
+ if (input.lowernum >= oe->numlower)
+ return -EINVAL;
+
+ origin = oe->lowerstack[input.lowernum].dentry;
+
+ return __ovl_ioctl_get_fhandle(origin, arg);
+}
+
+static long ovl_ioctl_get_upper_fhandle(struct super_block *sb,
+ unsigned long arg)
+{
+ struct ovl_fs *ofs = sb->s_fs_info;
+ struct dentry *origin;
+
+ if (!ofs->config.upperdir)
+ return -EINVAL;
+
+ origin = OVL_I(d_inode(sb->s_root))->__upperdentry;
+
+ return __ovl_ioctl_get_fhandle(origin, arg);
+}
+
+static long ovl_ioctl_get_work_fhandle(struct super_block *sb,
+ unsigned long arg)
+{
+ struct ovl_fs *ofs = sb->s_fs_info;
+
+ if (!ofs->config.upperdir)
+ return -EINVAL;
+
+ return __ovl_ioctl_get_fhandle(ofs->workbasedir, arg);
+}
+
+#defineOVL_IOC_GETLWRFHN
[PATCH 0/3] w1: Constify w1_family_ops
None of the current instances of struct w1_family_ops in the kernel is modified. Constify these to let the compiler put them in read-only memory. The first patch changes the fops field in w1_family struct to a pointer to const and makes a local variable a pointer to const to avoid a compiler warning. This patch is a prerequisite for the second and third patches which constifies the static structs in drivers in w1 and power. These changes was done with coccinelle (details in the commit messages). With these changes applied, all instances of struct w1_family_ops in the kernel are const. Build-tested on x86 allmodconfig. Rikard Falkeborn (3): w1: Constify struct w1_family_ops w1: Constify static w1_family_ops structs power: supply: Constify static w1_family_ops structs drivers/power/supply/bq27xxx_battery_hdq.c | 2 +- drivers/power/supply/ds2760_battery.c | 2 +- drivers/power/supply/max1721x_battery.c| 2 +- drivers/w1/slaves/w1_ds2405.c | 2 +- drivers/w1/slaves/w1_ds2406.c | 2 +- drivers/w1/slaves/w1_ds2408.c | 2 +- drivers/w1/slaves/w1_ds2413.c | 2 +- drivers/w1/slaves/w1_ds2423.c | 2 +- drivers/w1/slaves/w1_ds2430.c | 2 +- drivers/w1/slaves/w1_ds2431.c | 2 +- drivers/w1/slaves/w1_ds2433.c | 2 +- drivers/w1/slaves/w1_ds2438.c | 2 +- drivers/w1/slaves/w1_ds250x.c | 2 +- drivers/w1/slaves/w1_ds2780.c | 2 +- drivers/w1/slaves/w1_ds2781.c | 2 +- drivers/w1/slaves/w1_ds2805.c | 2 +- drivers/w1/slaves/w1_ds28e04.c | 2 +- drivers/w1/slaves/w1_ds28e17.c | 2 +- drivers/w1/slaves/w1_therm.c | 6 +++--- drivers/w1/w1.c| 4 ++-- include/linux/w1.h | 2 +- 21 files changed, 24 insertions(+), 24 deletions(-) -- 2.28.0
[PATCH 2/3] w1: Constify static w1_family_ops structs
The only usage of these structs is to assign their address to the fops
field in the w1_family struct, which is a const pointer. Make them const
to allow the compiler to put them in read-only memory.
This was done with the following Coccinelle semantic patch
(http://coccinelle.lip6.fr/):
//
@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct w1_family_ops i@p = {...};
@ok1@
identifier r1.i;
position p;
identifier s;
@@
static struct w1_family s = {
.fops=&i@p,
};
@bad1@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p
@depends on !bad1 disable optional_qualifier@
identifier r1.i;
@@
static
+const
struct w1_family_ops i={};
//
Signed-off-by: Rikard Falkeborn
---
drivers/w1/slaves/w1_ds2405.c | 2 +-
drivers/w1/slaves/w1_ds2406.c | 2 +-
drivers/w1/slaves/w1_ds2408.c | 2 +-
drivers/w1/slaves/w1_ds2413.c | 2 +-
drivers/w1/slaves/w1_ds2423.c | 2 +-
drivers/w1/slaves/w1_ds2430.c | 2 +-
drivers/w1/slaves/w1_ds2431.c | 2 +-
drivers/w1/slaves/w1_ds2433.c | 2 +-
drivers/w1/slaves/w1_ds2438.c | 2 +-
drivers/w1/slaves/w1_ds250x.c | 2 +-
drivers/w1/slaves/w1_ds2780.c | 2 +-
drivers/w1/slaves/w1_ds2781.c | 2 +-
drivers/w1/slaves/w1_ds2805.c | 2 +-
drivers/w1/slaves/w1_ds28e04.c | 2 +-
drivers/w1/slaves/w1_ds28e17.c | 2 +-
drivers/w1/slaves/w1_therm.c | 6 +++---
drivers/w1/w1.c| 2 +-
17 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/w1/slaves/w1_ds2405.c b/drivers/w1/slaves/w1_ds2405.c
index 86cd97309d87..1d9a1183e83f 100644
--- a/drivers/w1/slaves/w1_ds2405.c
+++ b/drivers/w1/slaves/w1_ds2405.c
@@ -206,7 +206,7 @@ static struct attribute *w1_ds2405_attrs[] = {
ATTRIBUTE_GROUPS(w1_ds2405);
-static struct w1_family_ops w1_ds2405_fops = {
+static const struct w1_family_ops w1_ds2405_fops = {
.groups = w1_ds2405_groups
};
diff --git a/drivers/w1/slaves/w1_ds2406.c b/drivers/w1/slaves/w1_ds2406.c
index 762e5e4e2b48..6c269af73c80 100644
--- a/drivers/w1/slaves/w1_ds2406.c
+++ b/drivers/w1/slaves/w1_ds2406.c
@@ -138,7 +138,7 @@ static void w1_f12_remove_slave(struct w1_slave *sl)
&(w1_f12_sysfs_bin_files[i]));
}
-static struct w1_family_ops w1_f12_fops = {
+static const struct w1_family_ops w1_f12_fops = {
.add_slave = w1_f12_add_slave,
.remove_slave = w1_f12_remove_slave,
};
diff --git a/drivers/w1/slaves/w1_ds2408.c b/drivers/w1/slaves/w1_ds2408.c
index 83f8d94bb814..ad102c577122 100644
--- a/drivers/w1/slaves/w1_ds2408.c
+++ b/drivers/w1/slaves/w1_ds2408.c
@@ -336,7 +336,7 @@ static const struct attribute_group *w1_f29_groups[] = {
NULL,
};
-static struct w1_family_ops w1_f29_fops = {
+static const struct w1_family_ops w1_f29_fops = {
.add_slave = w1_f29_disable_test_mode,
.groups = w1_f29_groups,
};
diff --git a/drivers/w1/slaves/w1_ds2413.c b/drivers/w1/slaves/w1_ds2413.c
index f1fb18afbcea..c8cfac555b48 100644
--- a/drivers/w1/slaves/w1_ds2413.c
+++ b/drivers/w1/slaves/w1_ds2413.c
@@ -143,7 +143,7 @@ static const struct attribute_group *w1_f3a_groups[] = {
NULL,
};
-static struct w1_family_ops w1_f3a_fops = {
+static const struct w1_family_ops w1_f3a_fops = {
.groups = w1_f3a_groups,
};
diff --git a/drivers/w1/slaves/w1_ds2423.c b/drivers/w1/slaves/w1_ds2423.c
index f4367282dcc1..b6bd18d5b3f6 100644
--- a/drivers/w1/slaves/w1_ds2423.c
+++ b/drivers/w1/slaves/w1_ds2423.c
@@ -117,7 +117,7 @@ static struct attribute *w1_f1d_attrs[] = {
};
ATTRIBUTE_GROUPS(w1_f1d);
-static struct w1_family_ops w1_f1d_fops = {
+static const struct w1_family_ops w1_f1d_fops = {
.groups = w1_f1d_groups,
};
diff --git a/drivers/w1/slaves/w1_ds2430.c b/drivers/w1/slaves/w1_ds2430.c
index 75bb8a88620b..0ea7d779d17a 100644
--- a/drivers/w1/slaves/w1_ds2430.c
+++ b/drivers/w1/slaves/w1_ds2430.c
@@ -279,7 +279,7 @@ static const struct attribute_group *w1_f14_groups[] = {
NULL,
};
-static struct w1_family_ops w1_f14_fops = {
+static const struct w1_family_ops w1_f14_fops = {
.groups = w1_f14_groups,
};
diff --git a/drivers/w1/slaves/w1_ds2431.c b/drivers/w1/slaves/w1_ds2431.c
index e5bd7e2354d7..6856b1c29e17 100644
--- a/drivers/w1/slaves/w1_ds2431.c
+++ b/drivers/w1/slaves/w1_ds2431.c
@@ -278,7 +278,7 @@ static const struct attribute_group *w1_f2d_groups[] = {
NULL,
};
-static struct w1_family_ops w1_f2d_fops = {
+static const struct w1_family_ops w1_f2d_fops = {
.groups = w1_f2d_groups,
};
diff --git a/drivers/w1/slaves/w1_ds2433.c b/drivers/w1/slaves/w1_ds2433.c
index 1f805c86517a..0f72df15a024 100644
--- a/drivers/w1/slaves/w1_ds2433.c
+++ b/drivers/w1/slaves/w1_ds2433.c
@@ -288,7 +288,7 @@ static void w1_f23_remove_slave(struct w1_slave *sl)
#endif /* CONFIG_W1_SLAVE_DS2433_CRC */
}
-static struct w1_family_ops w1_f23_fops = {
+static const struct w1_family_ops w1_f23_fops = {
.add_slave = w1_f23_add_slave,
[PATCH 3/3] power: supply: Constify static w1_family_ops structs
The only usage of these structs is to assign their address to the fops
field in the w1_family struct, which is a const pointer. Make them const
to allow the compiler to put them in read-only memory.
This was done with the following Coccinelle semantic patch
(http://coccinelle.lip6.fr/):
//
@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct w1_family_ops i@p = {...};
@ok1@
identifier r1.i;
position p;
identifier s;
@@
static struct w1_family s = {
.fops=&i@p,
};
@bad1@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p
@depends on !bad1 disable optional_qualifier@
identifier r1.i;
@@
static
+const
struct w1_family_ops i={};
//
Signed-off-by: Rikard Falkeborn
---
drivers/power/supply/bq27xxx_battery_hdq.c | 2 +-
drivers/power/supply/ds2760_battery.c | 2 +-
drivers/power/supply/max1721x_battery.c| 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/power/supply/bq27xxx_battery_hdq.c
b/drivers/power/supply/bq27xxx_battery_hdq.c
index 12b10dad77d3..922759ab2e04 100644
--- a/drivers/power/supply/bq27xxx_battery_hdq.c
+++ b/drivers/power/supply/bq27xxx_battery_hdq.c
@@ -97,7 +97,7 @@ static void bq27xxx_battery_hdq_remove_slave(struct w1_slave
*sl)
bq27xxx_battery_teardown(di);
}
-static struct w1_family_ops bq27xxx_battery_hdq_fops = {
+static const struct w1_family_ops bq27xxx_battery_hdq_fops = {
.add_slave = bq27xxx_battery_hdq_add_slave,
.remove_slave = bq27xxx_battery_hdq_remove_slave,
};
diff --git a/drivers/power/supply/ds2760_battery.c
b/drivers/power/supply/ds2760_battery.c
index 11bed88a89fa..695bb6747400 100644
--- a/drivers/power/supply/ds2760_battery.c
+++ b/drivers/power/supply/ds2760_battery.c
@@ -795,7 +795,7 @@ static const struct of_device_id w1_ds2760_of_ids[] = {
};
#endif
-static struct w1_family_ops w1_ds2760_fops = {
+static const struct w1_family_ops w1_ds2760_fops = {
.add_slave = w1_ds2760_add_slave,
.remove_slave = w1_ds2760_remove_slave,
.groups = w1_ds2760_groups,
diff --git a/drivers/power/supply/max1721x_battery.c
b/drivers/power/supply/max1721x_battery.c
index 9ca895b0dabb..1b1a36f8e929 100644
--- a/drivers/power/supply/max1721x_battery.c
+++ b/drivers/power/supply/max1721x_battery.c
@@ -431,7 +431,7 @@ static int devm_w1_max1721x_add_device(struct w1_slave *sl)
return 0;
}
-static struct w1_family_ops w1_max1721x_fops = {
+static const struct w1_family_ops w1_max1721x_fops = {
.add_slave = devm_w1_max1721x_add_device,
};
--
2.28.0
[PATCH 1/3] w1: Constify struct w1_family_ops
The fops field in the w1_family struct is never modified. Make it const
to indicate that. Constifying the pointer makes it possible for drivers
to declare static w1_family_ops structs const, which in turn will allow
the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/w1/w1.c| 2 +-
include/linux/w1.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index e58c7592008d..6bd64bcb6316 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -613,7 +613,7 @@ static int w1_uevent(struct device *dev, struct
kobj_uevent_env *env)
static int w1_family_notify(unsigned long action, struct w1_slave *sl)
{
- struct w1_family_ops *fops;
+ const struct w1_family_ops *fops;
int err;
fops = sl->family->fops;
diff --git a/include/linux/w1.h b/include/linux/w1.h
index cebf3464bc03..949d3b10e531 100644
--- a/include/linux/w1.h
+++ b/include/linux/w1.h
@@ -269,7 +269,7 @@ struct w1_family {
struct list_headfamily_entry;
u8 fid;
- struct w1_family_ops*fops;
+ const struct w1_family_ops *fops;
const struct of_device_id *of_match_table;
--
2.28.0
Re: [PATCH] dt-bindings: vendor-prefixes: favor "gateworks" over "gw"
On Sat, Oct 3, 2020 at 12:33 PM Krzysztof Kozlowski wrote: > There are two vendor prefixes for Gateworks: "gw" and "gateworks". > Favor the longer one (more descriptive) and mark "gw" as deprecated so > it will not be used in new bindings. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [RFC PATCH 1/1] overlayfs: add ioctls that allows to get fhandle for layers dentries
On 10/4/20 12:24 PM, Alexander Mikhalitsyn wrote:
> +#define OVL_IOC_GETLWRFHNDLSNUM _IO('o', 1)
> +// DISCUSS: what if MAX_HANDLE_SZ will change?
> +#define OVL_IOC_GETLWRFHNDL _IOR('o', 2, struct
> ovl_mnt_opt_fh)
> +#define OVL_IOC_GETUPPRFHNDL_IOR('o', 3, struct
> ovl_mnt_opt_fh)
> +#define OVL_IOC_GETWRKFHNDL _IOR('o', 4, struct
> ovl_mnt_opt_fh)
Hi,
This needs to have Documentation/userspace-api/ioctl/ioctl-number.rst
updated also.
thanks.
--
~Randy
Re: [PATCH] perf inject: Flush ordered events on FINISHED_ROUND
On Fri, Oct 02, 2020 at 10:03:17PM +0900, Namhyung Kim wrote:
> Currently perf inject just repipes the event without any flush. It
> makes an issue that it changes the order of events processed.
>
> Normally we want to process events in time order, but events are
> recorded from several cpus and they weren't sorted with each other.
> So we put them into the ordered event queue, sorted by time, and flush
> them when we see a next FINISHED_ROUND event.
>
> But this is for events from kernel, user space events (like the
> FINISHED_ROUND) are processed without queueing. So during the perf
> inject, it writes all the FINISHED_ROUND events directly while
> SAMPLE (and other) events are kept in the queue. This makes the user
> space events are put before any kernel events.
>
> You can see that with the following command:
>
> $ perf record -a -o- sleep 1 | perf inject -b | perf script -i-
> --show-round-events
> PERF_RECORD_FINISHED_ROUND
> PERF_RECORD_FINISHED_ROUND
> PERF_RECORD_FINISHED_ROUND
> ...
>
> Omitting perf inject, you can see the events are placed in the middle
> of the data.
>
> You might argue that the whole point of the FINISHED_ROUND event is to
> sort (kernel) events. And after perf inject, all events are written
> in a proper time order so we don't care about the FINISHED_ROUND event
> anymore.
>
> But the problem is we don't know whether the input data is sorted or
> not (maybe we can add a feature bit for this?) so it should use an
> ordered event queue when processing the input like in perf report.
I like the idea of storing the information that the data is sorted,
and when it's there, let's not use ordered_oevets
>
> Remember all the FINISHED_ROUND events now come before other events so
> the tool cannot know when it can flush the data so everything will be
> queued until it meets the end of the input. Actually it's same for
> perf inject itself as it doesn't flush the queue.
>
> Below measures time and memory usage during the perf inject and
> report using ~190MB data file.
>
> Before:
> perf inject: 11.09 s, 382148 KB
> perf report: 8.05 s, 397440 KB
>
> After:
> perf inject: 16.24 s, 83376 KB
> perf report: 7.96 s, 216184 KB
>
> As you can see, it used 2x memory of the input size. I guess it's
> because it needs to keep the copy for the whole input. But I don't
> understand why processing time of perf inject increased..
would be good to find out first
thanks,
jirka
>
> I'm not sure how it affects the auxtrace, but it should be fine IMHO.
>
> Cc: Al Grant
> Cc: Adrian Hunter
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/builtin-inject.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
> index 6d2f410d773a..9fa78a9edfc5 100644
> --- a/tools/perf/builtin-inject.c
> +++ b/tools/perf/builtin-inject.c
> @@ -79,6 +79,7 @@ static int perf_event__repipe_oe_synth(struct perf_tool
> *tool,
> union perf_event *event,
> struct ordered_events *oe __maybe_unused)
> {
> + ordered_events__flush(oe, OE_FLUSH__ROUND);
> return perf_event__repipe_synth(tool, event);
> }
>
> --
> 2.28.0.806.g8561365e88-goog
>
Re: [PATCH] Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached"
Hi Paul.
On Sun, Oct 04, 2020 at 04:17:58PM +0200, Paul Cercueil wrote:
> This reverts commit 37054fc81443cc6a8c3a38395f384412b8373d82.
In the changelog please refer to commits like this:
37054fc81443 ("gpu/drm: ingenic: Add option to mmap GEM buffers cached")
Use "dim cite 37054fc81443cc6a8c3a38395f384412b8373d82" to get the right format.
>
> At the very moment this commit was created, the DMA API it relied on was
> modified in the DMA tree, which caused the driver to break in
> linux-next.
>
> Revert it for now, and it will be resubmitted later to work with the new
> DMA API.
>
> Signed-off-by: Paul Cercueil
With the changelog updated:
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 114 +-
> drivers/gpu/drm/ingenic/ingenic-drm.h | 4 -
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 12 +--
> 3 files changed, 4 insertions(+), 126 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index 0225dc1f5eb8..7d8b0ad52979 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -9,8 +9,6 @@
> #include
> #include
> #include
> -#include
> -#include
> #include
> #include
> #include
> @@ -24,7 +22,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -100,11 +97,6 @@ struct ingenic_drm {
> struct notifier_block clock_nb;
> };
>
> -static bool ingenic_drm_cached_gem_buf;
> -module_param_named(cached_gem_buffers, ingenic_drm_cached_gem_buf, bool,
> 0400);
> -MODULE_PARM_DESC(cached_gem_buffers,
> - "Enable fully cached GEM buffers [default=false]");
> -
> static bool ingenic_drm_writeable_reg(struct device *dev, unsigned int reg)
> {
> switch (reg) {
> @@ -402,8 +394,6 @@ static int ingenic_drm_plane_atomic_check(struct
> drm_plane *plane,
>plane->state->fb->format->format != state->fb->format->format))
> crtc_state->mode_changed = true;
>
> - drm_atomic_helper_check_plane_damage(state->state, state);
> -
> return 0;
> }
>
> @@ -521,38 +511,6 @@ void ingenic_drm_plane_config(struct device *dev,
> }
> }
>
> -void ingenic_drm_sync_data(struct device *dev,
> -struct drm_plane_state *old_state,
> -struct drm_plane_state *state)
> -{
> - const struct drm_format_info *finfo = state->fb->format;
> - struct ingenic_drm *priv = dev_get_drvdata(dev);
> - struct drm_atomic_helper_damage_iter iter;
> - unsigned int offset, i;
> - struct drm_rect clip;
> - dma_addr_t paddr;
> - void *addr;
> -
> - if (!ingenic_drm_cached_gem_buf)
> - return;
> -
> - drm_atomic_helper_damage_iter_init(&iter, old_state, state);
> -
> - drm_atomic_for_each_plane_damage(&iter, &clip) {
> - for (i = 0; i < finfo->num_planes; i++) {
> - paddr = drm_fb_cma_get_gem_addr(state->fb, state, i);
> - addr = phys_to_virt(paddr);
> -
> - /* Ignore x1/x2 values, invalidate complete lines */
> - offset = clip.y1 * state->fb->pitches[i];
> -
> - dma_cache_sync(priv->dev, addr + offset,
> -(clip.y2 - clip.y1) *
> state->fb->pitches[i],
> -DMA_TO_DEVICE);
> - }
> - }
> -}
> -
> static void ingenic_drm_update_palette(struct ingenic_drm *priv,
> const struct drm_color_lut *lut)
> {
> @@ -581,8 +539,6 @@ static void ingenic_drm_plane_atomic_update(struct
> drm_plane *plane,
> if (state && state->fb) {
> crtc_state = state->crtc->state;
>
> - ingenic_drm_sync_data(priv->dev, oldstate, state);
> -
> addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
> width = state->src_w >> 16;
> height = state->src_h >> 16;
> @@ -752,69 +708,7 @@ static void ingenic_drm_disable_vblank(struct drm_crtc
> *crtc)
> regmap_update_bits(priv->map, JZ_REG_LCD_CTRL, JZ_LCD_CTRL_EOF_IRQ, 0);
> }
>
> -static struct drm_framebuffer *
> -ingenic_drm_gem_fb_create(struct drm_device *dev, struct drm_file *file,
> - const struct drm_mode_fb_cmd2 *mode_cmd)
> -{
> - if (ingenic_drm_cached_gem_buf)
> - return drm_gem_fb_create_with_dirty(dev, file, mode_cmd);
> -
> - return drm_gem_fb_create(dev, file, mode_cmd);
> -}
> -
> -static int ingenic_drm_gem_mmap(struct drm_gem_object *obj,
> - struct vm_area_struct *vma)
> -{
> - struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
> - struct device *dev = cma_obj->base.dev->dev;
> - unsigned long attrs;
> - int ret;
> -
> - if (ingenic_drm_cached_gem_buf)
> - attrs = DMA_ATTR_NON_CONSISTENT;
> - else
Re: [RFC][PATCHSET] epoll cleanups
On Sun, Oct 04, 2020 at 11:08:11AM -0700, Linus Torvalds wrote: > On Sat, Oct 3, 2020 at 7:36 PM Al Viro wrote: > > > > Locking and especially control flow in fs/eventpoll.c is > > overcomplicated. As the result, the code has been hard to follow > > and easy to fuck up while modifying. > > Scanning through the patches they all look superficially ok to me, but > I'm wondering how much test coverage you have (because I'm wondering > how much test coverage we have in general for epoll). Besides the in-tree one (tools/testing/selftests/filesystems/epoll) and LTP stuff (testcases/kernel/syscalls/epoll) - only davidel's epoll_test.c. Plus slapped together "let's try to make it go through that codepath" stuff (combined with printks in fs/eventpoll.c)...
[PATCH] drm: bridge: dw-hdmi: Constify dw_hdmi_i2s_ops
The only usage of dw_hdmi_i2s_ops is to assign its address to the ops
field in the hdmi_codec_pdata struct, which is a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index 9fef6413741d..feb04f127b55 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -170,7 +170,7 @@ static int dw_hdmi_i2s_hook_plugged_cb(struct device *dev,
void *data,
return dw_hdmi_set_plugged_cb(hdmi, fn, codec_dev);
}
-static struct hdmi_codec_ops dw_hdmi_i2s_ops = {
+static const struct hdmi_codec_ops dw_hdmi_i2s_ops = {
.hw_params = dw_hdmi_i2s_hw_params,
.audio_startup = dw_hdmi_i2s_audio_startup,
.audio_shutdown = dw_hdmi_i2s_audio_shutdown,
--
2.28.0
