[PATCH v2 bpf-next 1/7] bpf: provide function to get vmlinux BTF information
It will be used later for BTF printk() support
Signed-off-by: Alan Maguire
---
include/linux/bpf.h | 2 ++
kernel/bpf/verifier.c | 18 --
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index cf4b6e4..de19a35 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -1203,6 +1203,8 @@ int bpf_check(struct bpf_prog **fp, union bpf_attr *attr,
union bpf_attr __user *uattr);
void bpf_patch_call_args(struct bpf_insn *insn, u32 stack_depth);
+struct btf *bpf_get_btf_vmlinux(void);
+
/* Map specifics */
struct xdp_buff;
struct sk_buff;
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 2a1826c..c6b1ba0 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -10728,6 +10728,17 @@ static int check_attach_btf_id(struct bpf_verifier_env
*env)
}
}
+struct btf *bpf_get_btf_vmlinux(void)
+{
+ if (!btf_vmlinux && IS_ENABLED(CONFIG_DEBUG_INFO_BTF)) {
+ mutex_lock(_verifier_lock);
+ if (!btf_vmlinux)
+ btf_vmlinux = btf_parse_vmlinux();
+ mutex_unlock(_verifier_lock);
+ }
+ return btf_vmlinux;
+}
+
int bpf_check(struct bpf_prog **prog, union bpf_attr *attr,
union bpf_attr __user *uattr)
{
@@ -10761,12 +10772,7 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr
*attr,
env->ops = bpf_verifier_ops[env->prog->type];
is_priv = capable(CAP_SYS_ADMIN);
- if (!btf_vmlinux && IS_ENABLED(CONFIG_DEBUG_INFO_BTF)) {
- mutex_lock(_verifier_lock);
- if (!btf_vmlinux)
- btf_vmlinux = btf_parse_vmlinux();
- mutex_unlock(_verifier_lock);
- }
+ bpf_get_btf_vmlinux();
/* grab the mutex to protect few globals used by verifier */
if (!is_priv)
--
1.8.3.1
[PATCH v2 bpf-next 7/7] bpf: add tests for %pT format specifier
tests verify we get > 0 return value from bpf_trace_print()
using %pT format specifier with various modifiers/pointer
values.
Signed-off-by: Alan Maguire
---
.../selftests/bpf/prog_tests/trace_printk_btf.c| 83 ++
.../selftests/bpf/progs/netif_receive_skb.c| 81 +
2 files changed, 164 insertions(+)
create mode 100644 tools/testing/selftests/bpf/prog_tests/trace_printk_btf.c
create mode 100644 tools/testing/selftests/bpf/progs/netif_receive_skb.c
diff --git a/tools/testing/selftests/bpf/prog_tests/trace_printk_btf.c
b/tools/testing/selftests/bpf/prog_tests/trace_printk_btf.c
new file mode 100644
index 000..d7ee158
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/trace_printk_btf.c
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+
+struct result {
+ int ret;
+ int subtest;
+ int num_subtest;
+};
+
+/* return value of bpf_trace_printk()s is stored; if nonzero we failed. */
+static void on_sample(void *ctx, int cpu, void *data, __u32 size)
+{
+ struct result *resp = (struct result *)data;
+
+ *(struct result *)ctx = *resp;
+}
+
+void test_trace_printk_btf(void)
+{
+ struct result res = { 0 };
+ struct bpf_prog_load_attr attr = {
+ .file = "./netif_receive_skb.o",
+ };
+ struct perf_buffer_opts pb_opts = {};
+ struct bpf_program *prog = NULL;
+ struct perf_buffer *pb = NULL;
+ struct bpf_object *obj = NULL;
+ struct bpf_link *link = NULL;
+ struct bpf_map *perf_buf_map;
+ __u32 duration = 0;
+ int err, prog_fd;
+
+ err = bpf_prog_load_xattr(, , _fd);
+ if (CHECK(err, "prog_load raw tp", "err %d errno %d\n", err, errno))
+ goto close_prog;
+
+ prog = bpf_object__find_program_by_title(obj,
+"tp_btf/netif_receive_skb");
+ if (CHECK(!prog, "find_prog", "prog netif_receive_skb not found\n"))
+ goto close_prog;
+
+ link = bpf_program__attach_raw_tracepoint(prog, NULL);
+ if (CHECK(IS_ERR(link), "attach_raw_tp", "err %ld\n", PTR_ERR(link)))
+ goto close_prog;
+
+ perf_buf_map = bpf_object__find_map_by_name(obj, "perf_buf_map");
+ if (CHECK(!perf_buf_map, "find_perf_buf_map", "not found\n"))
+ goto close_prog;
+
+ /* set up perf buffer */
+ pb_opts.sample_cb = on_sample;
+ pb_opts.ctx =
+ pb = perf_buffer__new(bpf_map__fd(perf_buf_map), 1, _opts);
+ if (CHECK(IS_ERR(pb), "perf_buf__new", "err %ld\n", PTR_ERR(pb)))
+ goto close_prog;
+
+ /* generate receive event */
+ system("ping -c 1 127.0.0.1 >/dev/null");
+
+ /* read perf buffer */
+ err = perf_buffer__poll(pb, 100);
+ if (CHECK(err < 0, "perf_buffer__poll", "err %d\n", err))
+ goto close_prog;
+
+ /*
+* Make sure netif_receive_skb program was triggered
+* and it sent expected return values from bpf_trace_printk()s
+* into ring buffer.
+*/
+ if (CHECK(res.ret <= 0,
+ "bpf_trace_printk: got return value",
+ "ret <= 0 %d test %d\n", res.ret, res.subtest))
+ goto close_prog;
+
+ CHECK(res.subtest != res.num_subtest, "check all subtests ran",
+ "only ran %d of %d tests\n", res.subtest, res.num_subtest);
+
+close_prog:
+ perf_buffer__free(pb);
+ if (!IS_ERR_OR_NULL(link))
+ bpf_link__destroy(link);
+ bpf_object__close(obj);
+}
diff --git a/tools/testing/selftests/bpf/progs/netif_receive_skb.c
b/tools/testing/selftests/bpf/progs/netif_receive_skb.c
new file mode 100644
index 000..b5148df
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/netif_receive_skb.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2020, Oracle and/or its affiliates. */
+#include
+#include
+#include
+#include
+#include
+
+char _license[] SEC("license") = "GPL";
+
+struct {
+ __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
+ __uint(key_size, sizeof(int));
+ __uint(value_size, sizeof(int));
+} perf_buf_map SEC(".maps");
+
+struct result {
+ int ret;
+ int subtest;
+ int num_subtest;
+};
+
+typedef struct {
+ int counter;
+} atomic_t;
+typedef struct refcount_struct {
+ atomic_t refs;
+} refcount_t;
+
+struct sk_buff {
+ /* field names and sizes should match to those in the kernel */
+ unsigned int len, data_len;
+ __u16 mac_len, hdr_len, queue_mapping;
+ struct net_device *dev;
+ /* order of the fields doesn't matter */
+ refcount_t users;
+ unsigned char *data;
+ char __pkt_type_offset[0];
+ char cb[48];
+};
+
+#define CHECK_PRINTK(_fmt, _p, res)\
+ do {\
+ char fmt[] = _fmt;
[PATCH v2 bpf-next 6/7] bpf: add support for %pT format specifier for bpf_trace_printk() helper
Allow %pT[cNx0] format specifier for BTF-based display of data associated
with pointer.
Signed-off-by: Alan Maguire
---
include/uapi/linux/bpf.h | 27 ++-
kernel/trace/bpf_trace.c | 21 ++---
tools/include/uapi/linux/bpf.h | 27 ++-
3 files changed, 62 insertions(+), 13 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 9d1932e..ab3c86c 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -695,7 +695,12 @@ struct bpf_stack_build_id {
* to file *\/sys/kernel/debug/tracing/trace* from DebugFS, if
* available. It can take up to three additional **u64**
* arguments (as an eBPF helpers, the total number of arguments is
- * limited to five).
+ * limited to five), and also supports %pT (BTF-based type
+ * printing), as long as BPF_READ lockdown is not active.
+ * "%pT" takes a "struct __btf_ptr *" as an argument; it
+ * consists of a pointer value and specified BTF type string or id
+ * used to select the type for display. For more details, see
+ * Documentation/core-api/printk-formats.rst.
*
* Each time the helper is called, it appends a line to the trace.
* Lines are discarded while *\/sys/kernel/debug/tracing/trace* is
@@ -731,10 +736,10 @@ struct bpf_stack_build_id {
* The conversion specifiers supported by *fmt* are similar, but
* more limited than for printk(). They are **%d**, **%i**,
* **%u**, **%x**, **%ld**, **%li**, **%lu**, **%lx**, **%lld**,
- * **%lli**, **%llu**, **%llx**, **%p**, **%s**. No modifier (size
- * of field, padding with zeroes, etc.) is available, and the
- * helper will return **-EINVAL** (but print nothing) if it
- * encounters an unknown specifier.
+ * **%lli**, **%llu**, **%llx**, **%p**, **%pT[cNx0], **%s**.
+ * Only %pT supports modifiers, and the helper will return
+ * **-EINVAL** (but print nothing) if it encouters an unknown
+ * specifier.
*
* Also, note that **bpf_trace_printk**\ () is slow, and should
* only be used for debugging purposes. For this reason, a notice
@@ -4058,4 +4063,16 @@ struct bpf_pidns_info {
__u32 pid;
__u32 tgid;
};
+
+/*
+ * struct __btf_ptr is used for %pT (typed pointer) display; the
+ * additional type string/BTF id are used to render the pointer
+ * data as the appropriate type.
+ */
+struct __btf_ptr {
+ void *ptr;
+ const char *type;
+ __u32 id;
+};
+
#endif /* _UAPI__LINUX_BPF_H__ */
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index d961428..c032c58 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -321,9 +321,12 @@ static const struct bpf_func_proto
*bpf_get_probe_write_proto(void)
return _probe_write_user_proto;
}
+#define isbtffmt(c)\
+ (c == 'T' || c == 'c' || c == 'N' || c == 'x' || c == '0')
+
/*
* Only limited trace_printk() conversion specifiers allowed:
- * %d %i %u %x %ld %li %lu %lx %lld %lli %llu %llx %p %s
+ * %d %i %u %x %ld %li %lu %lx %lld %lli %llu %llx %p %pT %s
*/
BPF_CALL_5(bpf_trace_printk, char *, fmt, u32, fmt_size, u64, arg1,
u64, arg2, u64, arg3)
@@ -361,8 +364,20 @@ static const struct bpf_func_proto
*bpf_get_probe_write_proto(void)
i++;
} else if (fmt[i] == 'p' || fmt[i] == 's') {
mod[fmt_cnt]++;
- /* disallow any further format extensions */
- if (fmt[i + 1] != 0 &&
+ /*
+* allow BTF type-based printing, and disallow any
+* further format extensions.
+*/
+ if (fmt[i] == 'p' && fmt[i + 1] == 'T') {
+ int ret;
+
+ ret = security_locked_down(LOCKDOWN_BPF_READ);
+ if (unlikely(ret < 0))
+ return ret;
+ i++;
+ while (isbtffmt(fmt[i]))
+ i++;
+ } else if (fmt[i + 1] != 0 &&
!isspace(fmt[i + 1]) &&
!ispunct(fmt[i + 1]))
return -EINVAL;
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 9d1932e..ab3c86c 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -695,7 +695,12 @@ struct bpf_stack_build_id {
* to file *\/sys/kernel/debug/tracing/trace* from DebugFS, if
* available. It can take up to three additional **u64**
*
[PATCH v2 bpf-next 4/7] printk: add type-printing %pT format specifier which uses BTF
printk supports multiple pointer object type specifiers (printing
netdev features etc). Extend this support using BTF to cover
arbitrary types. "%pT" specifies the typed format, and the pointer
argument is a "struct btf_ptr *" where struct btf_ptr is as follows:
struct btf_ptr {
void *ptr;
const char *type;
u32 id;
};
Either the "type" string ("struct sk_buff") or the BTF "id" can be
used to identify the type to use in displaying the associated "ptr"
value. A convenience function to create and point at the struct
is provided:
printk(KERN_INFO "%pT", BTF_PTR_TYPE(skb, struct sk_buff));
When invoked, BTF information is used to traverse the sk_buff *
and display it. Support is present for structs, unions, enums,
typedefs and core types (though in the latter case there's not
much value in using this feature of course).
Default output is indented, but compact output can be specified
via the 'c' option. Type names/member values can be suppressed
using the 'N' option. Zero values are not displayed by default
but can be using the '0' option. Pointer values are obfuscated
unless the 'x' option is specified. As an example:
struct sk_buff *skb = alloc_skb(64, GFP_KERNEL);
pr_info("%pT", BTF_PTR_TYPE(skb, struct sk_buff));
...gives us:
(struct sk_buff){
.transport_header = (__u16)65535,
.mac_header = (__u16)65535,
.end = (sk_buff_data_t)192,
.head = (unsigned char *)6b71155a,
.data = (unsigned char *)6b71155a,
.truesize = (unsigned int)768,
.users = (refcount_t){
.refs = (atomic_t){
.counter = (int)1,
},
},
.extensions = (struct skb_ext *)f486a130,
}
printk output is truncated at 1024 bytes. For cases where overflow
is likely, the compact/no type names display modes may be used.
Signed-off-by: Alan Maguire
---
Documentation/core-api/printk-formats.rst | 15
include/linux/btf.h | 3 +-
include/linux/printk.h| 16 +
lib/Kconfig | 16 +
lib/vsprintf.c| 113 ++
5 files changed, 162 insertions(+), 1 deletion(-)
diff --git a/Documentation/core-api/printk-formats.rst
b/Documentation/core-api/printk-formats.rst
index 8ebe46b1..5c66097 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -545,6 +545,21 @@ For printing netdev_features_t.
Passed by reference.
+BTF-based printing of pointer data
+--
+If '%pT' is specified, use the struct btf_ptr * along with kernel vmlinux
+BPF Type Format (BTF) to show the typed data. For example, specifying
+
+ printk(KERN_INFO "%pT", BTF_PTR_TYPE(skb, struct_sk_buff));
+
+will utilize BTF information to traverse the struct sk_buff * and display it.
+
+Supported modifers are
+ 'c' compact output (no indentation, newlines etc)
+ 'N' do not show type names
+ 'x' show raw pointers (no obfuscation)
+ '0' show zero-valued data (it is not shown by default)
+
Thanks
==
diff --git a/include/linux/btf.h b/include/linux/btf.h
index d571125..7b585ab 100644
--- a/include/linux/btf.h
+++ b/include/linux/btf.h
@@ -169,10 +169,11 @@ static inline const struct btf_member
*btf_type_member(const struct btf_type *t)
return (const struct btf_member *)(t + 1);
}
+struct btf *btf_parse_vmlinux(void);
+
#ifdef CONFIG_BPF_SYSCALL
const struct btf_type *btf_type_by_id(const struct btf *btf, u32 type_id);
const char *btf_name_by_offset(const struct btf *btf, u32 offset);
-struct btf *btf_parse_vmlinux(void);
struct btf *bpf_prog_get_target_btf(const struct bpf_prog *prog);
#else
static inline const struct btf_type *btf_type_by_id(const struct btf *btf,
diff --git a/include/linux/printk.h b/include/linux/printk.h
index fcde0772..3c3ea53 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -528,4 +528,20 @@ static inline void print_hex_dump_debug(const char
*prefix_str, int prefix_type,
#define print_hex_dump_bytes(prefix_str, prefix_type, buf, len)\
print_hex_dump_debug(prefix_str, prefix_type, 16, 1, buf, len, true)
+/**
+ * struct btf_ptr is used for %pT (typed pointer) display; the
+ * additional type string/BTF id are used to render the pointer
+ * data as the appropriate type.
+ */
+struct btf_ptr {
+ void *ptr;
+ const char *type;
+ u32 id;
+};
+
+#defineBTF_PTR_TYPE(ptrval, typeval) \
+ (&((struct btf_ptr){.ptr = ptrval, .type = #typeval}))
+
+#define BTF_PTR_ID(ptrval, idval) \
+ (&((struct btf_ptr){.ptr = ptrval, .id = idval}))
#endif
diff --git a/lib/Kconfig b/lib/Kconfig
index 5d53f96..ac3a513 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -6,6 +6,22 @@
config BINARY_PRINTF
def_bool n
+config BTF_PRINTF
+ bool "print type information using BPF type format"
+ depends on DEBUG_INFO_BTF
+ default n
+ help
+ Print structures, unions etc
Re: [PATCH v8 10/11] mtd: Support kmsg dumper based on pstore/blk
hi Kees Cook, On 2020/5/12 下午1:12, Kees Cook wrote: > [resend to proper CC list...] > > On Tue, May 12, 2020 at 11:12:42AM +0800, WeiXiong Liao wrote: >> hi Kees Cook, >> >> The off parameter on mtdpsore_block*() does not align to block size, >> which makes some bugs. For example, a block contains 4 dmesg zones >> and it's expected to erase this block when user remove all files on >> these zones. However it work failed since it get wrongly zonenum from >> misaligned off. > > Ah, okay. I haven't touched any of this logic. Did something change in > pstore/blk or /zone that I broke? Regardless, can you send a regular > patch for what you have below and I'll fold it into the mtdpstore > commit. > I will send a patch later. Maybe it needs to be reviewed again by MTD maintainers. And everything in pstore/blk and /zone are OK. > Thanks! > > -Kees > >> On 2020/5/12 AM 7:32, Kees Cook wrote: >>> From: WeiXiong Liao >>> >>> This introduces mtdpstore, which is similar to mtdoops but more >>> powerful. It uses pstore/blk, and aims to store panic and oops logs to >>> a flash partition, where pstore can later read back and present as files >>> in the mounted pstore filesystem. >>> >>> To make mtdpstore work, the "blkdev" of pstore/blk should be set >>> as MTD device name or MTD device number. For more details, see >>> Documentation/admin-guide/pstore-blk.rst >>> >>> This solves a number of issues: >>> - Work duplication: both of pstore and mtdoops do the same job storing >>> panic/oops log. They have very similar logic, registering to kmsg >>> dumper and storing logs to several chunks one by one. >>> - Layer violations: drivers should provides methods instead of polices. >>> MTD should provide read/write/erase operations, and allow a higher >>> level drivers to provide the chunk management, kmsg dump >>> configuration, etc. >>> - Missing features: pstore provides many additional features, including >>> presenting the logs as files, logging dump time and count, and >>> supporting other frontends like pmsg, console, etc. >>> >>> Signed-off-by: WeiXiong Liao >>> Link: >>> https://lore.kernel.org/r/1585126506-18635-12-git-send-email-liaoweixi...@allwinnertech.com >>> Signed-off-by: Kees Cook >>> --- >>> Documentation/admin-guide/pstore-blk.rst | 9 +- >>> drivers/mtd/Kconfig | 10 + >>> drivers/mtd/Makefile | 1 + >>> drivers/mtd/mtdpstore.c | 563 +++ >>> 4 files changed, 581 insertions(+), 2 deletions(-) >>> create mode 100644 drivers/mtd/mtdpstore.c >>> >>> diff --git a/Documentation/admin-guide/pstore-blk.rst >>> b/Documentation/admin-guide/pstore-blk.rst >>> index d45341e55e82..296d5027787a 100644 >>> --- a/Documentation/admin-guide/pstore-blk.rst >>> +++ b/Documentation/admin-guide/pstore-blk.rst >>> @@ -43,9 +43,9 @@ blkdev >>> ~~ >>> >>> The block device to use. Most of the time, it is a partition of block >>> device. >>> -It's required for pstore/blk. >>> +It's required for pstore/blk. It is also used for MTD device. >>> >>> -It accepts the following variants: >>> +It accepts the following variants for block device: >>> >>> 1. device number in hexadecimal represents itself; >>> no >>> leading 0x, for example b302. >>> @@ -64,6 +64,11 @@ It accepts the following variants: >>> partition with a known unique id. >>> #. : major and minor number of the device separated by a >>> colon. >>> >>> +It accepts the following variants for MTD device: >>> + >>> +1. MTD device name. "pstore" is recommended. >>> +#. MTD device number. >>> + >>> kmsg_size >>> ~ >>> >>> diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig >>> index 42d401ea60ee..6ddab796216d 100644 >>> --- a/drivers/mtd/Kconfig >>> +++ b/drivers/mtd/Kconfig >>> @@ -170,6 +170,16 @@ config MTD_OOPS >>> buffer in a flash partition where it can be read back at some >>> later point. >>> >>> +config MTD_PSTORE >>> + tristate "Log panic/oops to an MTD buffer based on pstore" >>> + depends on PSTORE_BLK >>> + help >>> + This enables panic and oops messages to be logged to a circular >>> + buffer in a flash partition where it can be read back as files after >>> + mounting pstore filesystem. >>> + >>> + If unsure, say N. >>> + >>> config MTD_SWAP >>> tristate "Swap on MTD device support" >>> depends on MTD && SWAP >>> diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile >>> index 56cc60ccc477..593d0593a038 100644 >>> --- a/drivers/mtd/Makefile >>> +++ b/drivers/mtd/Makefile >>> @@ -20,6 +20,7 @@ obj-$(CONFIG_RFD_FTL) += rfd_ftl.o >>> obj-$(CONFIG_SSFDC)+= ssfdc.o >>> obj-$(CONFIG_SM_FTL) += sm_ftl.o >>> obj-$(CONFIG_MTD_OOPS) += mtdoops.o >>> +obj-$(CONFIG_MTD_PSTORE) += mtdpstore.o >>> obj-$(CONFIG_MTD_SWAP) += mtdswap.o >>> >>> nftl-objs := nftlcore.o nftlmount.o >>> diff --git
Re: [PATCH] gcc-plugins: remove always false $(if ...) in Makefile
On Sun, May 10, 2020 at 11:14 AM Kees Cook wrote:
>
> On Sun, May 10, 2020 at 11:00:44AM +0900, Masahiro Yamada wrote:
> > This is the remnant of commit c17d6179ad5a ("gcc-plugins: remove unused
> > GCC_PLUGIN_SUBDIR").
> >
> > $(if $(findstring /,$(p)),...) is always false because none of plugins
> > contains '/' in the file name.
> >
> > Clean up the code.
> >
> > Signed-off-by: Masahiro Yamada
>
> Reviewed-by: Kees Cook
>
Applied to linux-kbuild.
--
Best Regards
Masahiro Yamada
Re: stable/linux-4.4.y bisection: baseline.login on at91-sama5d4_xplained
Please see the bisection report below about a boot failure.
Reports aren't automatically sent to the public while we're
trialing new bisection features on kernelci.org but this one
looks valid.
It appears to be due to the fact that the network interface is
failing to get brought up:
[ 114.385000] Waiting up to 10 more seconds for network.
[ 124.355000] Sending DHCP requests ...#
..#
.#
timed out!
[ 212.355000] IP-Config: Reopening network devices...
[ 212.365000] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
#
I guess the board would boot fine without network if it didn't
have ip=dhcp in the command line, so it's not strictly a kernel
boot failure but still an ethernet issue.
There wasn't any failure reported by kernelci on linux-4.9.y so
maybe this patch was applied by mistake on linux-4.4.y but I
haven't investigated enough to prove this.
Thanks,
Guillaume
On 10/05/2020 18:27, kernelci.org bot wrote:
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis *
> * that you may be involved with the breaking commit it has *
> * found. No manual investigation has been done to verify it, *
> * and the root cause of the problem may be somewhere else. *
> * *
> * If you do send a fix, please include this trailer:*
> * Reported-by: "kernelci.org bot" *
> * *
> * Hope this helps! *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
> stable/linux-4.4.y bisection: baseline.login on at91-sama5d4_xplained
>
> Summary:
> Start: e157447efd85b Linux 4.4.223
> Plain log:
> https://storage.kernelci.org/stable/linux-4.4.y/v4.4.223/arm/multi_v7_defconfig/gcc-8/lab-baylibre/baseline-at91-sama5d4_xplained.txt
> HTML log:
> https://storage.kernelci.org/stable/linux-4.4.y/v4.4.223/arm/multi_v7_defconfig/gcc-8/lab-baylibre/baseline-at91-sama5d4_xplained.html
> Result: 0d1951fa23ba0 net: phy: Avoid polling PHY with
> PHY_IGNORE_INTERRUPTS
>
> Checks:
> revert: PASS
> verify: PASS
>
> Parameters:
> Tree: stable
> URL:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> Branch: linux-4.4.y
> Target: at91-sama5d4_xplained
> CPU arch: arm
> Lab:lab-baylibre
> Compiler: gcc-8
> Config: multi_v7_defconfig
> Test case: baseline.login
>
> Breaking commit found:
>
> ---
> commit 0d1951fa23ba0d35a4c5498ff28d1c5206d6fcdd
> Author: Florian Fainelli
> Date: Mon Jan 18 19:33:06 2016 -0800
>
> net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS
>
> commit d5c3d84657db57bd23ecd58b97f1c99dd42a7b80 upstream.
>
> Commit 2c7b49212a86 ("phy: fix the use of PHY_IGNORE_INTERRUPT") changed
> a hunk in phy_state_machine() in the PHY_RUNNING case which was not
> needed. The change essentially makes the PHY library treat PHY devices
> with PHY_IGNORE_INTERRUPT to keep polling for the PHY device, even
> though the intent is not to do it.
>
> Fix this by reverting that specific hunk, which makes the PHY state
> machine wait for state changes, and stay in the PHY_RUNNING state for as
> long as needed.
>
> Fixes: 2c7b49212a86 ("phy: fix the use of PHY_IGNORE_INTERRUPT")
> Signed-off-by: Florian Fainelli
> Signed-off-by: David S. Miller
> Signed-off-by: Greg Kroah-Hartman
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 7d2cf015c5e76..b242bec834f4b 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -912,10 +912,10 @@ void phy_state_machine(struct work_struct *work)
> phydev->adjust_link(phydev->attached_dev);
> break;
> case PHY_RUNNING:
> - /* Only register a CHANGE if we are polling or ignoring
> - * interrupts and link changed since latest checking.
> + /* Only register a CHANGE if we are polling and link changed
> + * since latest checking.
>*/
> - if (!phy_interrupt_is_valid(phydev)) {
> + if (phydev->irq == PHY_POLL) {
> old_link = phydev->link;
> err = phy_read_status(phydev);
> if (err)
> @@ -1015,8 +1015,13 @@ void phy_state_machine(struct work_struct *work)
> dev_dbg(>dev, "PHY state change %s -> %s\n",
> phy_state_to_str(old_state), phy_state_to_str(phydev->state));
>
> - queue_delayed_work(system_power_efficient_wq, >state_queue,
> -PHY_STATE_TIME * HZ);
> + /* Only re-schedule a PHY state machine change if we are polling the
> + * PHY, if PHY_IGNORE_INTERRUPT is set,
Re: [PATCH] Makefile: support compressed debug info
On Tue, May 5, 2020 at 9:47 AM Fangrui Song wrote: > > > On 2020-05-04, Sedat Dilek wrote: > >On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers > > wrote: > >> > >> As debug information gets larger and larger, it helps significantly save > >> the size of vmlinux images to compress the information in the debug > >> information sections. Note: this debug info is typically split off from > >> the final compressed kernel image, which is why vmlinux is what's used > >> in conjunction with GDB. Minimizing the debug info size should have no > >> impact on boot times, or final compressed kernel image size. > >> > >> All of the debug sections will have a `C` flag set. > >> $ readelf -S > >> > >> $ bloaty vmlinux.gcc75.compressed.dwarf4 -- \ > >> vmlinux.gcc75.uncompressed.dwarf4 > >> > >> FILE SIZEVM SIZE > >> -- -- > >> +0.0% +18 [ = ] 0[Unmapped] > >> -73.3% -114Ki [ = ] 0.debug_aranges > >> -76.2% -2.01Mi [ = ] 0.debug_frame > >> -73.6% -2.89Mi [ = ] 0.debug_str > >> -80.7% -4.66Mi [ = ] 0.debug_abbrev > >> -82.9% -4.88Mi [ = ] 0.debug_ranges > >> -70.5% -9.04Mi [ = ] 0.debug_line > >> -79.3% -10.9Mi [ = ] 0.debug_loc > >> -39.5% -88.6Mi [ = ] 0.debug_info > >> -18.2% -123Mi [ = ] 0TOTAL > >> > >> $ bloaty vmlinux.clang11.compressed.dwarf4 -- \ > >> vmlinux.clang11.uncompressed.dwarf4 > >> > >> FILE SIZEVM SIZE > >> -- -- > >> +0.0% +23 [ = ] 0[Unmapped] > >> -65.6%-871 [ = ] 0.debug_aranges > >> -77.4% -1.84Mi [ = ] 0.debug_frame > >> -82.9% -2.33Mi [ = ] 0.debug_abbrev > >> -73.1% -2.43Mi [ = ] 0.debug_str > >> -84.8% -3.07Mi [ = ] 0.debug_ranges > >> -65.9% -8.62Mi [ = ] 0.debug_line > >> -86.2% -40.0Mi [ = ] 0.debug_loc > >> -42.0% -64.1Mi [ = ] 0.debug_info > >> -22.1% -122Mi [ = ] 0TOTAL > >> > > > >Hi Nick, > > > >thanks for the patch. > > > >I have slightly modified it to adapt to Linux v5.7-rc4 (what was your base?). > > > >Which linker did you use and has it an impact if you switch from > >ld.bfd to ld.lld? > > lld has supported the linker option --compress-debug-sections=zlib since > about 5.0.0 (https://reviews.llvm.org/D31941) > > >I tried a first normal run and in a 2nd one with > >CONFIG_DEBUG_INFO_COMPRESSED=y both with clang-10 and ld.lld-10. > > > >My numbers (sizes in MiB): > > > >[ diffconfig ] > > > >$ scripts/diffconfig /boot/config-5.7.0-rc4-1-amd64-clang > >/boot/config-5.7.0-rc4-2-amd64-clang > > BUILD_SALT "5.7.0-rc4-1-amd64-clang" -> "5.7.0-rc4-2-amd64-clang" > >+DEBUG_INFO_COMPRESSED y > > > >[ compiler and linker ] > > > >$ clang-10 -v > >ClangBuiltLinux clang version 10.0.1 > >(https://github.com/llvm/llvm-project > >92d5c1be9ee93850c0a8903f05f36a23ee835dc2) > >Target: x86_64-unknown-linux-gnu > >Thread model: posix > >InstalledDir: /home/dileks/src/llvm-toolchain/install/bin > >Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10 > >Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8 > >Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 > >Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10 > >Candidate multilib: .;@m64 > >Candidate multilib: 32;@m32 > >Candidate multilib: x32;@mx32 > >Selected multilib: .;@m64 > > > >$ ld.lld-10 -v > >LLD 10.0.1 (https://github.com/llvm/llvm-project > >92d5c1be9ee93850c0a8903f05f36a23ee835dc2) (compatible with GNU > >linkers) > > > >[ sizes vmlinux ] > > > >$ du -m 5.7.0-rc4-*/vmlinux* > >409 5.7.0-rc4-1-amd64-clang/vmlinux > >7 5.7.0-rc4-1-amd64-clang/vmlinux.compressed > >404 5.7.0-rc4-1-amd64-clang/vmlinux.o > >324 5.7.0-rc4-2-amd64-clang/vmlinux > >7 5.7.0-rc4-2-amd64-clang/vmlinux.compressed > >299 5.7.0-rc4-2-amd64-clang/vmlinux.o > > > >[ readelf (.debug_info as example) ] > > > >$ readelf -S vmlinux.o > > [33] .debug_info PROGBITS 01d6a5e8 > > 06be1ee6 0 0 1 > > > >$ readelf -S vmlinux.o > > [33] .debug_info PROGBITS 01749f18 > > 02ef04d2 C 0 0 1 <--- > >XXX: "C (compressed)" Flag > > > >Key to Flags: > > W (write), A (alloc), X (execute), M (merge), S (strings), I (info), > > L (link order), O (extra OS processing required), G (group), T (TLS), > > C (compressed), x (unknown), o (OS specific), E (exclude), > > l (large), p (processor specific) > > > >[ sizes linux-image debian packages ] > > > >$ du -m 5.7.0-rc4-*/linux-image*.deb > >47 > >5.7.0-rc4-1-amd64-clang/linux-image-5.7.0-rc4-1-amd64-clang_5.7.0~rc4-1~bullseye+dileks1_amd64.deb > >424 > >5.7.0-rc4-1-amd64-clang/linux-image-5.7.0-rc4-1-amd64-clang-dbg_5.7.0~rc4-1~bullseye+dileks1_amd64.deb >
Re: [PATCH] ifcvf: move IRQ request/free to status change handlers
On 2020/5/12 上午11:38, Jason Wang wrote:
static int ifcvf_start_datapath(void *private)
{
struct ifcvf_hw *vf = ifcvf_private_to_vf(private);
@@ -118,9 +172,12 @@ static void ifcvf_vdpa_set_status(struct
vdpa_device *vdpa_dev, u8 status)
{
struct ifcvf_adapter *adapter;
struct ifcvf_hw *vf;
+ u8 status_old;
+ int ret;
vf = vdpa_to_vf(vdpa_dev);
adapter = dev_get_drvdata(vdpa_dev->dev.parent);
+ status_old = ifcvf_get_status(vf);
if (status == 0) {
ifcvf_stop_datapath(adapter);
@@ -128,7 +185,22 @@ static void ifcvf_vdpa_set_status(struct
vdpa_device *vdpa_dev, u8 status)
return;
}
- if (status & VIRTIO_CONFIG_S_DRIVER_OK) {
+ if ((status_old & VIRTIO_CONFIG_S_DRIVER_OK) &&
+ !(status & VIRTIO_CONFIG_S_DRIVER_OK)) {
+ ifcvf_stop_datapath(adapter);
+ ifcvf_free_irq(adapter, IFCVF_MAX_QUEUE_PAIRS * 2);
+ }
+
+ if ((status & VIRTIO_CONFIG_S_DRIVER_OK) &&
+ !(status_old & VIRTIO_CONFIG_S_DRIVER_OK)) {
+ ret = ifcvf_request_irq(adapter);
+ if (ret) {
+ status = ifcvf_get_status(vf);
+ status |= VIRTIO_CONFIG_S_FAILED;
+ ifcvf_set_status(vf, status);
+ return;
+ }
+
Have a hard though on the logic here.
This depends on the status setting from guest or userspace. Which
means it can not deal with e.g when qemu or userspace is crashed? Do
we need to care this or it's a over engineering?
Thanks
If qemu crash, I guess users may re-run qmeu / re-initialize the
device, according to the spec, there should be a reset routine.
This code piece handles status change on DRIVER_OK flipping. I am not
sure I get your point, mind to give more hints?
The problem is if we don't launch new qemu instance, the interrupt
will be still there?
Ok, we reset on vhost_vdpa_release() so the following is suspicious:
With the patch, we do:
static void ifcvf_vdpa_set_status(struct vdpa_device *vdpa_dev, u8 status)
{
struct ifcvf_adapter *adapter;
struct ifcvf_hw *vf;
u8 status_old;
int ret;
vf = vdpa_to_vf(vdpa_dev);
adapter = dev_get_drvdata(vdpa_dev->dev.parent);
status_old = ifcvf_get_status(vf);
if (status == 0) {
ifcvf_stop_datapath(adapter);
ifcvf_reset_vring(adapter);
return;
}
if ((status_old & VIRTIO_CONFIG_S_DRIVER_OK) &&
!(status & VIRTIO_CONFIG_S_DRIVER_OK)) {
ifcvf_stop_datapath(adapter);
ifcvf_free_irq(adapter, IFCVF_MAX_QUEUE_PAIRS * 2);
}
...
So the handling of status == 0 looks wrong.
The OK -> !OK check should already cover the datapath stopping and irq
stuffs.
We only need to deal with vring reset and only need to do it after we
stop the datapath/irq stuffs.
Thanks
Thanks
Re: [PATCH v8 01/11] pstore/zone: Introduce common layer to manage storage zones
hi Kees Cook,
On 2020/5/12 PM 1:15, Kees Cook wrote:
> On Tue, May 12, 2020 at 11:55:20AM +0800, WeiXiong Liao wrote:
>> On 2020/5/12 AM 7:32, Kees Cook wrote:
>>> [...]
>>> +struct psz_context {
>>> + struct pstore_zone **kpszs;
>>> + unsigned int kmsg_max_cnt;
>>> + unsigned int kmsg_read_cnt;
>>> + unsigned int kmsg_write_cnt;
>>> + /*
>>> +* These counters should be calculated during recovery.
>>> +* It records the oops/panic times after crashes rather than boots.
>>> +*/
>>> + unsigned int oops_counter;
>>> + unsigned int panic_counter;
>>
>> oops/panic_counter is designed to count the crash times since the
>> linux kernel was installed. pstore/zone lookup the max counter from all
>> valid kmsg zones when recovery and saves them to oops/panic_counter.
>> However, they are unable to get real number if we remove files. It's
>> not serious, we can fix it after this series.
>
> Since the kernel was installed? I don't see a kernel version check in
> here? Or do you mean "since ever", in that it's a rolling count?
>
Yes, "since ever".
>> And since pstore supports "max_reason", should pstore/zone count for
>> other reason?
>
> For now, no. I opted to try to keep this as simple as possible a port
> from dump_oops to max_reason for now.
>
OK.
>>> +static inline int psz_kmsg_erase(struct psz_context *cxt,
>>> + struct pstore_zone *zone, struct pstore_record *record)
>>> +{
>>> + struct psz_buffer *buffer = zone->buffer;
>>> + struct psz_kmsg_header *hdr =
>>> + (struct psz_kmsg_header *)buffer->data;
>>> +
>>> + if (unlikely(!psz_ok(zone)))
>>> + return 0;
>>> + /* this zone is already updated, no need to erase */
>>> + if (record->count != hdr->counter)
>>> + return 0;
>>
>> These codes is to fix bug that user remove files on pstore filesystem
>> but kmsg zone is already updated and pstore/zone should not erase
>> zone. It work for oops and panic because the count number is increasing.
>> However, it's useless for other reason of kmsg. We can fix it after this
>> series.
>
> Okay, sounds good.
>
--
WeiXiong Liao
Re: [PATCH] Makefile: support compressed debug info
Hi Sedat, On Tue, May 5, 2020 at 1:25 AM Sedat Dilek wrote: > > On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers > wrote: > > > > As debug information gets larger and larger, it helps significantly save > > the size of vmlinux images to compress the information in the debug > > information sections. Note: this debug info is typically split off from > > the final compressed kernel image, which is why vmlinux is what's used > > in conjunction with GDB. Minimizing the debug info size should have no > > impact on boot times, or final compressed kernel image size. > > > > All of the debug sections will have a `C` flag set. > > $ readelf -S > > > > $ bloaty vmlinux.gcc75.compressed.dwarf4 -- \ > > vmlinux.gcc75.uncompressed.dwarf4 > > > > FILE SIZEVM SIZE > > -- -- > > +0.0% +18 [ = ] 0[Unmapped] > > -73.3% -114Ki [ = ] 0.debug_aranges > > -76.2% -2.01Mi [ = ] 0.debug_frame > > -73.6% -2.89Mi [ = ] 0.debug_str > > -80.7% -4.66Mi [ = ] 0.debug_abbrev > > -82.9% -4.88Mi [ = ] 0.debug_ranges > > -70.5% -9.04Mi [ = ] 0.debug_line > > -79.3% -10.9Mi [ = ] 0.debug_loc > > -39.5% -88.6Mi [ = ] 0.debug_info > > -18.2% -123Mi [ = ] 0TOTAL > > > > $ bloaty vmlinux.clang11.compressed.dwarf4 -- \ > > vmlinux.clang11.uncompressed.dwarf4 > > > > FILE SIZEVM SIZE > > -- -- > > +0.0% +23 [ = ] 0[Unmapped] > > -65.6%-871 [ = ] 0.debug_aranges > > -77.4% -1.84Mi [ = ] 0.debug_frame > > -82.9% -2.33Mi [ = ] 0.debug_abbrev > > -73.1% -2.43Mi [ = ] 0.debug_str > > -84.8% -3.07Mi [ = ] 0.debug_ranges > > -65.9% -8.62Mi [ = ] 0.debug_line > > -86.2% -40.0Mi [ = ] 0.debug_loc > > -42.0% -64.1Mi [ = ] 0.debug_info > > -22.1% -122Mi [ = ] 0TOTAL > > > > Hi Nick, > > thanks for the patch. > > I have slightly modified it to adapt to Linux v5.7-rc4 (what was your base?). > > Which linker did you use and has it an impact if you switch from > ld.bfd to ld.lld? > > I tried a first normal run and in a 2nd one with > CONFIG_DEBUG_INFO_COMPRESSED=y both with clang-10 and ld.lld-10. > > My numbers (sizes in MiB): > > [ diffconfig ] > > $ scripts/diffconfig /boot/config-5.7.0-rc4-1-amd64-clang > /boot/config-5.7.0-rc4-2-amd64-clang > BUILD_SALT "5.7.0-rc4-1-amd64-clang" -> "5.7.0-rc4-2-amd64-clang" > +DEBUG_INFO_COMPRESSED y > > [ compiler and linker ] > > $ clang-10 -v > ClangBuiltLinux clang version 10.0.1 > (https://github.com/llvm/llvm-project > 92d5c1be9ee93850c0a8903f05f36a23ee835dc2) > Target: x86_64-unknown-linux-gnu > Thread model: posix > InstalledDir: /home/dileks/src/llvm-toolchain/install/bin > Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10 > Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8 > Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 > Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10 > Candidate multilib: .;@m64 > Candidate multilib: 32;@m32 > Candidate multilib: x32;@mx32 > Selected multilib: .;@m64 > > $ ld.lld-10 -v > LLD 10.0.1 (https://github.com/llvm/llvm-project > 92d5c1be9ee93850c0a8903f05f36a23ee835dc2) (compatible with GNU > linkers) > > [ sizes vmlinux ] > > $ du -m 5.7.0-rc4-*/vmlinux* > 409 5.7.0-rc4-1-amd64-clang/vmlinux > 7 5.7.0-rc4-1-amd64-clang/vmlinux.compressed > 404 5.7.0-rc4-1-amd64-clang/vmlinux.o > 324 5.7.0-rc4-2-amd64-clang/vmlinux > 7 5.7.0-rc4-2-amd64-clang/vmlinux.compressed > 299 5.7.0-rc4-2-amd64-clang/vmlinux.o > > [ readelf (.debug_info as example) ] > > $ readelf -S vmlinux.o > [33] .debug_info PROGBITS 01d6a5e8 >06be1ee6 0 0 1 > > $ readelf -S vmlinux.o > [33] .debug_info PROGBITS 01749f18 >02ef04d2 C 0 0 1 <--- > XXX: "C (compressed)" Flag > > Key to Flags: > W (write), A (alloc), X (execute), M (merge), S (strings), I (info), > L (link order), O (extra OS processing required), G (group), T (TLS), > C (compressed), x (unknown), o (OS specific), E (exclude), > l (large), p (processor specific) > > [ sizes linux-image debian packages ] > > $ du -m 5.7.0-rc4-*/linux-image*.deb > 47 > 5.7.0-rc4-1-amd64-clang/linux-image-5.7.0-rc4-1-amd64-clang_5.7.0~rc4-1~bullseye+dileks1_amd64.deb > 424 > 5.7.0-rc4-1-amd64-clang/linux-image-5.7.0-rc4-1-amd64-clang-dbg_5.7.0~rc4-1~bullseye+dileks1_amd64.deb > 47 > 5.7.0-rc4-2-amd64-clang/linux-image-5.7.0-rc4-2-amd64-clang_5.7.0~rc4-2~bullseye+dileks1_amd64.deb > 771 > 5.7.0-rc4-2-amd64-clang/linux-image-5.7.0-rc4-2-amd64-clang-dbg_5.7.0~rc4-2~bullseye+dileks1_amd64.deb > > [ sizes linux-git dir (compilation finished ] > >
Re: linux-next: manual merge of the vfs tree with the parisc-hd tree
On Mon, May 11, 2020 at 10:22:04PM -0700, Kees Cook wrote:
> On Tue, May 12, 2020 at 12:33:05AM +, Luis Chamberlain wrote:
> > On Mon, May 11, 2020 at 09:55:16AM +0800, Xiaoming Ni wrote:
> > > On 2020/5/11 9:11, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > Today's linux-next merge of the vfs tree got a conflict in:
> > > >
> > > >kernel/sysctl.c
> > > >
> > > > between commit:
> > > >
> > > >b6522fa409cf ("parisc: add sysctl file interface
> > > > panic_on_stackoverflow")
> > > >
> > > > from the parisc-hd tree and commit:
> > > >
> > > >f461d2dcd511 ("sysctl: avoid forward declarations")
> > > >
> > > > from the vfs tree.
> > > >
> > > > I fixed it up (see below) and can carry the fix as necessary. This
> > > > is now fixed as far as linux-next is concerned, but any non trivial
> > > > conflicts should be mentioned to your upstream maintainer when your tree
> > > > is submitted for merging. You may also want to consider cooperating
> > > > with the maintainer of the conflicting tree to minimise any particularly
> > > > complex conflicts.
> > > >
> > >
> > >
> > > Kernel/sysctl.c contains more than 190 interface files, and there are a
> > > large number of config macro controls. When modifying the sysctl interface
> > > directly in kernel/sysctl.c , conflicts are very easy to occur.
> > >
> > > At the same time, the register_sysctl_table() provided by the system can
> > > easily add the sysctl interface, and there is no conflict of
> > > kernel/sysctl.c
> > > .
> > >
> > > Should we add instructions in the patch guide (coding-style.rst
> > > submitting-patches.rst):
> > > Preferentially use register_sysctl_table() to add a new sysctl interface,
> > > centralize feature codes, and avoid directly modifying kernel/sysctl.c ?
> >
> > Yes, however I don't think folks know how to do this well. So I think we
> > just have to do at least start ourselves, and then reflect some of this
> > in the docs. The reason that this can be not easy is that we need to
> > ensure that at an init level we haven't busted dependencies on setting
> > this. We also just don't have docs on how to do this well.
> >
> > > In addition, is it necessary to transfer the architecture-related sysctl
> > > interface to arch/xxx/kernel/sysctl.c ?
> >
> > Well here's an initial attempt to start with fs stuff in a very
> > conservative way. What do folks think?
> >
> > [...]
> > +static unsigned long zero_ul;
> > +static unsigned long long_max = LONG_MAX;
>
> I think it'd be nice to keep these in one place for others to reuse,
> though that means making them non-static. (And now that I look at them,
> I thought they were supposed to be const?)
So much spring cleaning to do. I can add the const and share it.
It seems odd to stuff this into a sysctl.h, types.h doesn't seem
right... I can't think of something proper, so I'll just move them
to sysctl.h for now.
Any thought on the approach though? I mean, I realize that this will
require more of the subsystem specific folks to look at the code and
review, but if this seems fair, I'll get the ball rolling.
Luis
Re: [PATCH -next] iommu/msm: Make msm_iommu_lock static
On Mon 11 May 19:17 PDT 2020, Samuel Zou wrote:
> Fix the following sparse warning:
>
> drivers/iommu/msm_iommu.c:37:1: warning: symbol 'msm_iommu_lock' was not
> declared.
>
> The msm_iommu_lock has only call site within msm_iommu.c
> It should be static
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Fixes: 0720d1f052dc ("msm: Add MSM IOMMU support")
> Reported-by: Hulk Robot
> Signed-off-by: Samuel Zou
> ---
> drivers/iommu/msm_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index 10cd4db..3d8a635 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -34,7 +34,7 @@ __asm__ __volatile__ (
> \
> /* bitmap of the page sizes currently supported */
> #define MSM_IOMMU_PGSIZES(SZ_4K | SZ_64K | SZ_1M | SZ_16M)
>
> -DEFINE_SPINLOCK(msm_iommu_lock);
> +static DEFINE_SPINLOCK(msm_iommu_lock);
> static LIST_HEAD(qcom_iommu_devices);
> static struct iommu_ops msm_iommu_ops;
>
> --
> 2.6.2
>
Re: [v2 4/4] regulator: qcom: labibb: Add SC interrupt handling
On Fri 08 May 13:42 PDT 2020, Sumit Semwal wrote:
> From: Nisha Kumari
>
> Add Short circuit interrupt handling and recovery for the lab and
> ibb regulators on qcom platforms.
>
> The client panel drivers need to register for REGULATOR_EVENT_OVER_CURRENT
> notification which will be triggered on short circuit. They should
> try to enable the regulator once, and if it doesn't get enabled,
> handle shutting down the panel accordingly.
>
> Signed-off-by: Nisha Kumari
> Signed-off-by: Sumit Semwal
>
> --
> v2: sumits: reworked handling to user regmap_read_poll_timeout, and handle it
> per-regulator instead of clearing both lab and ibb errors on either irq
> triggering. Also added REGULATOR_EVENT_OVER_CURRENT handling and
> notification to clients.
> ---
> drivers/regulator/qcom-labibb-regulator.c | 103 +-
> 1 file changed, 100 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/regulator/qcom-labibb-regulator.c
> b/drivers/regulator/qcom-labibb-regulator.c
> index a9dc7c060375..3539631c9f96 100644
> --- a/drivers/regulator/qcom-labibb-regulator.c
> +++ b/drivers/regulator/qcom-labibb-regulator.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0
> // Copyright (c) 2019, The Linux Foundation. All rights reserved.
>
> +#include
> #include
> #include
> #include
> @@ -18,11 +19,15 @@
> #define REG_LABIBB_ENABLE_CTL0x46
> #define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
> #define LABIBB_CONTROL_ENABLEBIT(7)
> +#define LABIBB_STATUS1_SC_DETECT_BIT BIT(6)
>
> #define LAB_ENABLE_CTL_MASK BIT(7)
> #define IBB_ENABLE_CTL_MASK (BIT(7) | BIT(6))
>
> #define POWER_DELAY 8000
> +#define POLLING_SCP_DONE_INTERVAL_US 5000
> +#define POLLING_SCP_TIMEOUT 16000
> +
>
> struct labibb_regulator {
> struct regulator_desc desc;
> @@ -30,6 +35,8 @@ struct labibb_regulator {
> struct regmap *regmap;
> struct regulator_dev*rdev;
> u16 base;
> + int sc_irq;
> + int vreg_enabled;
> u8 type;
> };
>
> @@ -112,9 +119,10 @@ static int qcom_labibb_regulator_enable(struct
> regulator_dev *rdev)
> return ret;
> }
>
> - if (ret)
> + if (ret) {
> + reg->vreg_enabled = 1;
> return 0;
> -
> + }
>
> dev_err(reg->dev, "Can't enable %s\n", reg->desc.name);
> return -EINVAL;
> @@ -140,8 +148,10 @@ static int qcom_labibb_regulator_disable(struct
> regulator_dev *rdev)
> return ret;
> }
>
> - if (!ret)
> + if (!ret) {
> + reg->vreg_enabled = 0;
> return 0;
> + }
>
> dev_err(reg->dev, "Can't disable %s\n", reg->desc.name);
> return -EINVAL;
> @@ -153,6 +163,70 @@ static struct regulator_ops qcom_labibb_ops = {
> .is_enabled = qcom_labibb_regulator_is_enabled,
> };
>
> +
> +static irqreturn_t labibb_sc_err_handler(int irq, void *_reg)
> +{
> + int ret, count;
> + u16 reg;
> + u8 sc_err_mask;
> + unsigned int val;
> + struct labibb_regulator *labibb_reg = (struct labibb_regulator *)_reg;
No need to explicitly typecast a void *.
> + bool in_sc_err, reg_en, scp_done = false;
reg_en is unused.
> +
> + if (irq == labibb_reg->sc_irq)
When is this false?
> + reg = labibb_reg->base + REG_LABIBB_STATUS1;
> + else
> + return IRQ_HANDLED;
> +
> + sc_err_mask = LABIBB_STATUS1_SC_DETECT_BIT;
> +
> + ret = regmap_bulk_read(labibb_reg->regmap, reg, , 1);
Just inline reg->base + REG_LABIBB_STATUS1 in this call.
> + if (ret < 0) {
> + dev_err(labibb_reg->dev, "Read failed, ret=%d\n", ret);
> + return IRQ_HANDLED;
> + }
> + dev_dbg(labibb_reg->dev, "%s SC error triggered! STATUS1 = %d\n",
> + labibb_reg->desc.name, val);
> +
> + in_sc_err = !!(val & sc_err_mask);
> +
> + /*
> + * The SC(short circuit) fault would trigger PBS(Portable Batch
> + * System) to disable regulators for protection. This would
> + * cause the SC_DETECT status being cleared so that it's not
> + * able to get the SC fault status.
> + * Check if the regulator is enabled in the driver but
> + * disabled in hardware, this means a SC fault had happened
> + * and SCP handling is completed by PBS.
> + */
> + if (!in_sc_err) {
if (!(val & LABIBB_STATUS1_SC_DETECT_BIT)) {
> +
> + reg = labibb_reg->base + REG_LABIBB_ENABLE_CTL;
> +
> + ret = regmap_read_poll_timeout(labibb_reg->regmap,
> + reg, val,
> + !(val & LABIBB_CONTROL_ENABLE),
> + POLLING_SCP_DONE_INTERVAL_US,
> +
Re: [PATCH v2] tpm: eventlog: Replace zero-length array with flexible-array member
On Fri, May 08, 2020 at 11:38:26AM -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on.
>
> Also, notice that, dynamic memory allocations won't be affected by
> this change:
>
> "Flexible array members have incomplete type, and so the sizeof operator
> may not be applied. As a quirk of the original implementation of
> zero-length arrays, sizeof evaluates to zero."[1]
>
> sizeof(flexible-array-member) triggers a warning because flexible array
> members have incomplete type[1]. There are some instances of code in
> which the sizeof operator is being incorrectly/erroneously applied to
> zero-length arrays and the result is zero. Such instances may be hiding
> some bugs. So, this work (flexible-array member conversions) will also
> help to get completely rid of those sorts of issues.
>
> Also, the following issue shows up due to the flexible-array member
> having incomplete type[4]:
>
> drivers/char/tpm/eventlog/tpm2.c: In function ‘tpm2_bios_measurements_start’:
> drivers/char/tpm/eventlog/tpm2.c:54:46: error: invalid application of
> ‘sizeof’ to incomplete type ‘u8[]’ {aka ‘unsigned char[]’}
>54 | size = sizeof(struct tcg_pcr_event) - sizeof(event_header->event)
> | ^
> drivers/char/tpm/eventlog/tpm2.c: In function ‘tpm2_bios_measurements_next’:
> drivers/char/tpm/eventlog/tpm2.c:102:10: error: invalid application of
> ‘sizeof’ to incomplete type ‘u8[]’ {aka ‘unsigned char[]’}
> 102 |sizeof(event_header->event) + event_header->event_size;
> | ^
> drivers/char/tpm/eventlog/tpm2.c: In function
> ‘tpm2_binary_bios_measurements_show’:
> drivers/char/tpm/eventlog/tpm2.c:140:10: error: invalid application of
> ‘sizeof’ to incomplete type ‘u8[]’ {aka ‘unsigned char[]’}
> 140 |sizeof(event_header->event) + event_header->event_size;
> | ^
> scripts/Makefile.build:266: recipe for target
> 'drivers/char/tpm/eventlog/tpm2.o' failed
> make[3]: *** [drivers/char/tpm/eventlog/tpm2.o] Error 1
>
> As mentioned above: "Flexible array members have incomplete type, and
> so the sizeof operator may not be applied. As a quirk of the original
> implementation of zero-length arrays, sizeof evaluates to zero."[1] As
> in "sizeof(event_header->event) always evaluated to 0, so removing it
> has no effect".
>
> Lastly, make use of the struct_size() helper to deal with the
> flexible array member and its host structure.
>
> This issue was found with the help of Coccinelle.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
> [4] https://github.com/KSPP/linux/issues/43
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Kees Cook
--
Kees Cook
[tip:core/rcu] BUILD SUCCESS 68f0f2690e183306b52671a9ad09fb31808b0500
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/rcu branch HEAD: 68f0f2690e183306b52671a9ad09fb31808b0500 Merge branch 'for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu elapsed time: 499m configs tested: 114 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig m68k allyesconfig sparcallyesconfig powerpc tqm8xx_defconfig riscv rv32_defconfig shedosk7705_defconfig sh lboxre2_defconfig sh se7722_defconfig xtensaxip_kc705_defconfig arm alldefconfig i386 allnoconfig i386defconfig i386 debian-10.3 i386 allyesconfig ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a006-20200511 i386 randconfig-a005-20200511 i386 randconfig-a003-20200511 i386 randconfig-a001-20200511 i386 randconfig-a004-20200511 i386 randconfig-a002-20200511 x86_64 randconfig-a006-20200512 x86_64 randconfig-a004-20200512 x86_64 randconfig-a002-20200512 i386 randconfig-a012-20200511 i386 randconfig-a016-20200511 i386 randconfig-a014-20200511 i386 randconfig-a011-20200511 i386 randconfig-a013-20200511 i386 randconfig-a015-20200511 i386 randconfig-a012-20200512 i386 randconfig-a016-20200512 i386 randconfig-a014-20200512 i386 randconfig-a011-20200512 i386 randconfig-a013-20200512 i386 randconfig-a015-20200512 x86_64 randconfig-a005-20200511 x86_64 randconfig-a003-20200511 x86_64 randconfig-a006-20200511 x86_64 randconfig-a004-20200511 x86_64 randconfig-a001-20200511 x86_64 randconfig-a002-20200511 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig x86_64 defconfig sparc defconfig sparc64
Re: linux-next: manual merge of the vfs tree with the parisc-hd tree
On Tue, May 12, 2020 at 12:33:05AM +, Luis Chamberlain wrote:
> On Mon, May 11, 2020 at 09:55:16AM +0800, Xiaoming Ni wrote:
> > On 2020/5/11 9:11, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the vfs tree got a conflict in:
> > >
> > >kernel/sysctl.c
> > >
> > > between commit:
> > >
> > >b6522fa409cf ("parisc: add sysctl file interface
> > > panic_on_stackoverflow")
> > >
> > > from the parisc-hd tree and commit:
> > >
> > >f461d2dcd511 ("sysctl: avoid forward declarations")
> > >
> > > from the vfs tree.
> > >
> > > I fixed it up (see below) and can carry the fix as necessary. This
> > > is now fixed as far as linux-next is concerned, but any non trivial
> > > conflicts should be mentioned to your upstream maintainer when your tree
> > > is submitted for merging. You may also want to consider cooperating
> > > with the maintainer of the conflicting tree to minimise any particularly
> > > complex conflicts.
> > >
> >
> >
> > Kernel/sysctl.c contains more than 190 interface files, and there are a
> > large number of config macro controls. When modifying the sysctl interface
> > directly in kernel/sysctl.c , conflicts are very easy to occur.
> >
> > At the same time, the register_sysctl_table() provided by the system can
> > easily add the sysctl interface, and there is no conflict of kernel/sysctl.c
> > .
> >
> > Should we add instructions in the patch guide (coding-style.rst
> > submitting-patches.rst):
> > Preferentially use register_sysctl_table() to add a new sysctl interface,
> > centralize feature codes, and avoid directly modifying kernel/sysctl.c ?
>
> Yes, however I don't think folks know how to do this well. So I think we
> just have to do at least start ourselves, and then reflect some of this
> in the docs. The reason that this can be not easy is that we need to
> ensure that at an init level we haven't busted dependencies on setting
> this. We also just don't have docs on how to do this well.
>
> > In addition, is it necessary to transfer the architecture-related sysctl
> > interface to arch/xxx/kernel/sysctl.c ?
>
> Well here's an initial attempt to start with fs stuff in a very
> conservative way. What do folks think?
>
> [...]
> +static unsigned long zero_ul;
> +static unsigned long long_max = LONG_MAX;
I think it'd be nice to keep these in one place for others to reuse,
though that means making them non-static. (And now that I look at them,
I thought they were supposed to be const?)
--
Kees Cook
MAINTAINERS: Wrong ordering in VIRTIO BALLOON
Hi David,
with your commit 6d6b93b9afd8 ("MAINTAINERS: Add myself as virtio-balloon
co-maintainer"), visible on next-20200508, ./scripts/checkpatch.pl -f
MAINTAINERS complains:
WARNING: Misordered MAINTAINERS entry - list file patterns in alphabetic order
#17982: FILE: MAINTAINERS:17982:
+F: include/uapi/linux/virtio_balloon.h
+F: include/linux/balloon_compaction.h
This is due to wrong ordering of the entries in your submission. If you
would like me to send you a patch fixing that, please just let me know.
It is a recent addition to checkpatch.pl to report ordering problems in
MAINTAINERS, so you might have not seen that at submission time.
Best regards,
Lukas
Re: [PATCH net 2/2 RESEND] ipmr: Add lockdep expression to ipmr_for_each_table macro
On Sat, May 09, 2020 at 02:19:38PM -0700, Jakub Kicinski wrote:
> On Sat, 9 May 2020 12:52:44 +0530 Amol Grover wrote:
> > ipmr_for_each_table() uses list_for_each_entry_rcu() for
> > traversing outside of an RCU read-side critical section but
> > under the protection of pernet_ops_rwsem. Hence add the
> > corresponding lockdep expression to silence the following
> > false-positive warning at boot:
>
> Thanks for the fix, the warning has been annoying me as well!
>
> > [0.645292] =
> > [0.645294] WARNING: suspicious RCU usage
> > [0.645296] 5.5.4-stable #17 Not tainted
> > [0.645297] -
> > [0.645299] net/ipv4/ipmr.c:136 RCU-list traversed in non-reader
> > section!!
>
> please provide a fuller stack trace, it would have helped the review
>
> > Signed-off-by: Amol Grover
> > ---
> > net/ipv4/ipmr.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> > index 99c864eb6e34..950ffe9943da 100644
> > --- a/net/ipv4/ipmr.c
> > +++ b/net/ipv4/ipmr.c
> > @@ -109,9 +109,10 @@ static void mroute_clean_tables(struct mr_table *mrt,
> > int flags);
> > static void ipmr_expire_process(struct timer_list *t);
> >
> > #ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES
> > -#define ipmr_for_each_table(mrt, net) \
> > - list_for_each_entry_rcu(mrt, >ipv4.mr_tables, list, \
> > - lockdep_rtnl_is_held())
> > +#define ipmr_for_each_table(mrt, net)
> > \
> > + list_for_each_entry_rcu(mrt, >ipv4.mr_tables, list,\
> > + lockdep_rtnl_is_held() || \
> > + lockdep_is_held(_ops_rwsem))
>
> This is a strange condition, IMHO. How can we be fine with either
> lock.. This is supposed to be the writer side lock, one can't have
> two writer side locks..
>
> I think what is happening is this:
>
> ipmr_net_init() -> ipmr_rules_init() -> ipmr_new_table()
>
> ipmr_new_table() returns an existing table if there is one, but
> obviously none can exist at init. So a better fix would be:
>
> #define ipmr_for_each_table(mrt, net) \
> list_for_each_entry_rcu(mrt, >ipv4.mr_tables, list,\
> lockdep_rtnl_is_held() || \
> list_empty(>ipv4.mr_tables))
>
(adding Stephen)
Hi Jakub,
Thank you for your suggestion about this patch.
Here is a stack trace for ipmr.c:
[1.515015] TCP: Hash tables configured (established 8192 bind 8192)
[1.516790] UDP hash table entries: 512 (order: 3, 49152 bytes, linear)
[1.518177] UDP-Lite hash table entries: 512 (order: 3, 49152 bytes, linear)
[1.519805]
[1.520178] =
[1.520982] WARNING: suspicious RCU usage
[1.521798] 5.7.0-rc2-6-gb35af6a26b7c6f #1 Not tainted
[1.522910] -
[1.523671] net/ipv4/ipmr.c:136 RCU-list traversed in non-reader section!!
[1.525218]
[1.525218] other info that might help us debug this:
[1.525218]
[1.526731]
[1.526731] rcu_scheduler_active = 2, debug_locks = 1
[1.528004] 1 lock held by swapper/1:
[1.528714] #0: c20be1d8 (pernet_ops_rwsem){+.+.}-{3:3}, at:
register_pernet_subsys+0xd/0x30
[1.530433]
[1.530433] stack backtrace:
[1.531262] CPU: 0 PID: 1 Comm: swapper Not tainted
5.7.0-rc2-6-gb35af6a26b7c6f #1
[1.532729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-1 04/01/2014
[1.534305] Call Trace:
[1.534758] ? ipmr_get_table+0x3c/0x70
[1.535430] ? ipmr_new_table+0x1c/0x60
[1.536173] ? ipmr_net_init+0x7b/0x170
[1.536923] ? register_pernet_subsys+0xd/0x30
[1.537810] ? ops_init+0x1a0/0x1e0
[1.538518] ? kmem_cache_create_usercopy+0x28a/0x350
[1.539752] ? register_pernet_operations+0xc9/0x1c0
[1.540630] ? ipv4_offload_init+0x65/0x65
[1.541451] ? register_pernet_subsys+0x19/0x30
[1.542357] ? ip_mr_init+0x28/0xff
[1.543079] ? inet_init+0x17b/0x249
[1.543773] ? do_one_initcall+0xc5/0x240
[1.544532] ? parse_args+0x192/0x350
[1.545266] ? rcu_read_lock_sched_held+0x2f/0x60
[1.546180] ? trace_initcall_level+0x61/0x93
[1.547061] ? kernel_init_freeable+0x112/0x18a
[1.547978] ? kernel_init_freeable+0x12b/0x18a
[1.548974] ? rest_init+0x220/0x220
[1.549792] ? kernel_init+0x8/0x100
[1.550548] ? rest_init+0x220/0x220
[1.551288] ? schedule_tail_wrapper+0x6/0x8
[1.552136] ? rest_init+0x220/0x220
[1.552873] ? ret_from_fork+0x2e/0x38
ALso, there is a similar warning for ip6mr.c :
=
WARNING: suspicious RCU usage
5.7.0-rc4-next-20200507-syzkaller #0 Not tainted
-
net/ipv6/ip6mr.c:124 RCU-list traversed in non-reader section!!
other info that might help us debug this:
Re: [PATCH 2/3] remoteproc: Add inline coredump functionality
On Mon 11 May 17:41 PDT 2020, risha...@codeaurora.org wrote:
> On 2020-05-11 17:30, Bjorn Andersson wrote:
> > On Mon 11 May 17:11 PDT 2020, risha...@codeaurora.org wrote:
> > > On 2020-05-07 13:21, Bjorn Andersson wrote:
> > > > On Thu 16 Apr 11:38 PDT 2020, Rishabh Bhatnagar wrote:
> > > > > diff --git a/drivers/remoteproc/remoteproc_coredump.c
> > > > > b/drivers/remoteproc/remoteproc_coredump.c
[..]
> > > > > +static ssize_t rproc_read_dump(char *buffer, loff_t offset, size_t
> > > > > count,
> > > > > + void *data, size_t header_size)
> > > > > +{
> > > > > + void *device_mem;
> > > > > + size_t data_left, copy_size, bytes_left = count;
> > > > > + unsigned long addr;
> > > > > + struct rproc_coredump_state *dump_state = data;
> > > > > + struct rproc *rproc = dump_state->rproc;
> > > > > + void *elfcore = dump_state->header;
> > > > > +
> > > > > + /* Copy the header first */
> > > > > + if (offset < header_size) {
> > > > > + copy_size = header_size - offset;
> > > > > + copy_size = min(copy_size, bytes_left);
> > > > > +
> > > > > + memcpy(buffer, elfcore + offset, copy_size);
> > > > > + offset += copy_size;
> > > > > + bytes_left -= copy_size;
> > > > > + buffer += copy_size;
> > > > > + }
> > > >
> > > > Perhaps you can take inspiration from devcd_readv() here?
> > > >
> > > > > +
> > > > > + while (bytes_left) {
> > > > > + addr = resolve_addr(offset - header_size,
> > > > > + >dump_segments, _left);
> > > > > + /* EOF check */
> > > > > + if (data_left == 0) {
> > > >
> > > > Afaict data_left denotes the amount of data left in this particular
> > > > segment, rather than in the entire core.
> > > >
> > > Yes, but it only returns 0 when the final segment has been copied
> > > completely. Otherwise it gives data left to copy for every segment
> > > and moves to next segment once the current one is copied.
> >
> > You're right.
> >
> > > > I think you should start by making bytes_left the minimum of the core
> > > > size and @count and then have this loop as long as bytes_left, copying
> > > > data to the buffer either from header or an appropriate segment based on
> > > > the current offset.
> > > >
> > > That would require an extra function that calculates entire core size,
> > > as its not available right now. Do you see any missed corner cases
> > > with this
> > > approach?
> >
> > You're looping over all the segments as you're building the header
> > anyways, so you could simply store this in the dump_state. I think this
> > depend more on the ability to reuse the read function between inline and
> > default coredump.
> >
> > Regards,
> > Bjorn
>
> Wouldn't the first if condition take care of "default" dump as it is?
> The header_size in that case would involve the 'header + all segments'.
Correct.
Regards,
Bjorn
Re: [PATCH v8 01/11] pstore/zone: Introduce common layer to manage storage zones
On Tue, May 12, 2020 at 11:55:20AM +0800, WeiXiong Liao wrote:
> On 2020/5/12 AM 7:32, Kees Cook wrote:
> > [...]
> > +struct psz_context {
> > + struct pstore_zone **kpszs;
> > + unsigned int kmsg_max_cnt;
> > + unsigned int kmsg_read_cnt;
> > + unsigned int kmsg_write_cnt;
> > + /*
> > +* These counters should be calculated during recovery.
> > +* It records the oops/panic times after crashes rather than boots.
> > +*/
> > + unsigned int oops_counter;
> > + unsigned int panic_counter;
>
> oops/panic_counter is designed to count the crash times since the
> linux kernel was installed. pstore/zone lookup the max counter from all
> valid kmsg zones when recovery and saves them to oops/panic_counter.
> However, they are unable to get real number if we remove files. It's
> not serious, we can fix it after this series.
Since the kernel was installed? I don't see a kernel version check in
here? Or do you mean "since ever", in that it's a rolling count?
> And since pstore supports "max_reason", should pstore/zone count for
> other reason?
For now, no. I opted to try to keep this as simple as possible a port
from dump_oops to max_reason for now.
> > +static inline int psz_kmsg_erase(struct psz_context *cxt,
> > + struct pstore_zone *zone, struct pstore_record *record)
> > +{
> > + struct psz_buffer *buffer = zone->buffer;
> > + struct psz_kmsg_header *hdr =
> > + (struct psz_kmsg_header *)buffer->data;
> > +
> > + if (unlikely(!psz_ok(zone)))
> > + return 0;
> > + /* this zone is already updated, no need to erase */
> > + if (record->count != hdr->counter)
> > + return 0;
>
> These codes is to fix bug that user remove files on pstore filesystem
> but kmsg zone is already updated and pstore/zone should not erase
> zone. It work for oops and panic because the count number is increasing.
> However, it's useless for other reason of kmsg. We can fix it after this
> series.
Okay, sounds good.
--
Kees Cook
Re: Re: signal quality and cable diagnostic
On Mon, May 11, 2020 at 09:54:35PM +0200, Andrew Lunn wrote: > On Mon, May 11, 2020 at 07:32:05PM +, Christian Herber wrote: > > On May 11, 2020 4:33:53 PM Andrew Lunn wrote: > > > > > > Are the classes part of the Open Alliance specification? Ideally we > > > want to report something standardized, not something proprietary to > > > NXP. > > > > > >Andrew > > > > Hi Andrew, > > > > > Such mechanisms are standardized and supported by pretty much all > > devices in the market. The Open Alliance specification is publicly > > available here: > > http://www.opensig.org/download/document/218/Advanced_PHY_features_for_automotive_Ethernet_V1.0.pdf > > > > As the specification is newer than the 100BASE-T1 spec, do not > > expect first generation devices to follow the register definitions > > as per Open Alliance. But for future devices, also registers should > > be same across different vendors. > > Hi Christian > > Since we are talking about a kernel/user API definition here, i don't > care about the exact registers. What is important is the > naming/representation of the information. It seems like NXP uses Class > A - Class H, where as the standard calls them SQI=0 - SQI=7. So we > should name the KAPI based on the standard, not what NXP calls them. OK, sounds good for me. Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH] dma-buf: fix use-after-free in dmabuffs_dname
Thank you Greg for the comments.
On 5/6/2020 2:30 PM, Greg KH wrote:
On Wed, May 06, 2020 at 02:00:10PM +0530, Charan Teja Kalla wrote:
Thank you Greg for the reply.
On 5/5/2020 3:38 PM, Greg KH wrote:
On Tue, Apr 28, 2020 at 01:24:02PM +0530, Charan Teja Reddy wrote:
The following race occurs while accessing the dmabuf object exported as
file:
P1 P2
dma_buf_release() dmabuffs_dname()
[say lsof reading /proc//fd/]
read dmabuf stored in dentry->fsdata
Free the dmabuf object
Start accessing the dmabuf structure
In the above description, the dmabuf object freed in P1 is being
accessed from P2 which is resulting into the use-after-free. Below is
the dump stack reported.
Call Trace:
kasan_report+0x12/0x20
__asan_report_load8_noabort+0x14/0x20
dmabuffs_dname+0x4f4/0x560
tomoyo_realpath_from_path+0x165/0x660
tomoyo_get_realpath
tomoyo_check_open_permission+0x2a3/0x3e0
tomoyo_file_open
tomoyo_file_open+0xa9/0xd0
security_file_open+0x71/0x300
do_dentry_open+0x37a/0x1380
vfs_open+0xa0/0xd0
path_openat+0x12ee/0x3490
do_filp_open+0x192/0x260
do_sys_openat2+0x5eb/0x7e0
do_sys_open+0xf2/0x180
Fixes: bb2bb90 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Nit, please read the documentation for how to do a Fixes: line properly,
you need more digits:
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Will update the patch
Reported-by:syzbot+3643a18836bce555b...@syzkaller.appspotmail.com
Signed-off-by: Charan Teja Reddy
Also, any reason you didn't include the other mailing lists that
get_maintainer.pl said to?
Really sorry for not sending to complete list. Added now.
And finally, no cc: stable in the s-o-b area for an issue that needs to
be backported to older kernels?
Will update the patch.
---
drivers/dma-buf/dma-buf.c | 25 +++--
include/linux/dma-buf.h | 1 +
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 570c923..069d8f78 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -38,18 +39,34 @@ struct dma_buf_list {
static struct dma_buf_list db_list;
+static void dmabuf_dent_put(struct dma_buf *dmabuf)
+{
+ if (atomic_dec_and_test(>dent_count)) {
+ kfree(dmabuf->name);
+ kfree(dmabuf);
+ }
Why not just use a kref instead of an open-coded atomic value?
Kref approach looks cleaner. will update the patch accordingly.
+}
+
static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen)
{
struct dma_buf *dmabuf;
char name[DMA_BUF_NAME_LEN];
size_t ret = 0;
+ spin_lock(>d_lock);
dmabuf = dentry->d_fsdata;
+ if (!dmabuf || !atomic_add_unless(>dent_count, 1, 0)) {
+ spin_unlock(>d_lock);
+ goto out;
How can dmabuf not be valid here?
And isn't there already a usecount for the buffer?
dmabuf exported as file simply relies on that file's refcount, thus fput()
releases the dmabuf.
We are storing the dmabuf in the dentry->d_fsdata but there is no binding
between the dentry and the dmabuf. So, flow will be like
1) P1 calls fput(dmabuf_fd)
2) P2 trying to access the file information of P1.
Eg: lsof command trying to list out the dmabuf_fd information using
/proc//fd/dmabuf_fd
3) P1 calls the file->f_op->release(dmabuf_fd_file)(ends up in calling
dma_buf_release()), thus frees up the dmabuf buffer.
4) P2 access the dmabuf stored in the dentry->d_fsdata which was freed in
step 3.
So we need to have some refcount mechanism to avoid the use-after-free in
step 4.
Ok, but watch out, now you have 2 different reference counts for the
same structure. Keeping them coordinated is almost always an impossible
task so you need to only rely on one. If you can't use the file api,
just drop all of the reference counting logic in there and only use the
kref one.
I feel that changing the refcount logic now to dma-buf objects involve
changes in
the core dma-buf framework. NO? Instead, how about passing the user
passed name directly
in the ->d_fsdata inplace of dmabuf object? Because we just need user
passed name in the
dmabuffs_dname(). With this we can avoid the need for extra refcount on
dmabuf.
Posted patch-V2: https://lkml.org/lkml/2020/5/8/158
good luck!
greg k-h
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
Re: [PATCH v8 10/11] mtd: Support kmsg dumper based on pstore/blk
[resend to proper CC list...] On Tue, May 12, 2020 at 11:12:42AM +0800, WeiXiong Liao wrote: > hi Kees Cook, > > The off parameter on mtdpsore_block*() does not align to block size, > which makes some bugs. For example, a block contains 4 dmesg zones > and it's expected to erase this block when user remove all files on > these zones. However it work failed since it get wrongly zonenum from > misaligned off. Ah, okay. I haven't touched any of this logic. Did something change in pstore/blk or /zone that I broke? Regardless, can you send a regular patch for what you have below and I'll fold it into the mtdpstore commit. Thanks! -Kees > On 2020/5/12 AM 7:32, Kees Cook wrote: > > From: WeiXiong Liao > > > > This introduces mtdpstore, which is similar to mtdoops but more > > powerful. It uses pstore/blk, and aims to store panic and oops logs to > > a flash partition, where pstore can later read back and present as files > > in the mounted pstore filesystem. > > > > To make mtdpstore work, the "blkdev" of pstore/blk should be set > > as MTD device name or MTD device number. For more details, see > > Documentation/admin-guide/pstore-blk.rst > > > > This solves a number of issues: > > - Work duplication: both of pstore and mtdoops do the same job storing > > panic/oops log. They have very similar logic, registering to kmsg > > dumper and storing logs to several chunks one by one. > > - Layer violations: drivers should provides methods instead of polices. > > MTD should provide read/write/erase operations, and allow a higher > > level drivers to provide the chunk management, kmsg dump > > configuration, etc. > > - Missing features: pstore provides many additional features, including > > presenting the logs as files, logging dump time and count, and > > supporting other frontends like pmsg, console, etc. > > > > Signed-off-by: WeiXiong Liao > > Link: > > https://lore.kernel.org/r/1585126506-18635-12-git-send-email-liaoweixi...@allwinnertech.com > > Signed-off-by: Kees Cook > > --- > > Documentation/admin-guide/pstore-blk.rst | 9 +- > > drivers/mtd/Kconfig | 10 + > > drivers/mtd/Makefile | 1 + > > drivers/mtd/mtdpstore.c | 563 +++ > > 4 files changed, 581 insertions(+), 2 deletions(-) > > create mode 100644 drivers/mtd/mtdpstore.c > > > > diff --git a/Documentation/admin-guide/pstore-blk.rst > > b/Documentation/admin-guide/pstore-blk.rst > > index d45341e55e82..296d5027787a 100644 > > --- a/Documentation/admin-guide/pstore-blk.rst > > +++ b/Documentation/admin-guide/pstore-blk.rst > > @@ -43,9 +43,9 @@ blkdev > > ~~ > > > > The block device to use. Most of the time, it is a partition of block > > device. > > -It's required for pstore/blk. > > +It's required for pstore/blk. It is also used for MTD device. > > > > -It accepts the following variants: > > +It accepts the following variants for block device: > > > > 1. device number in hexadecimal represents itself; > > no > > leading 0x, for example b302. > > @@ -64,6 +64,11 @@ It accepts the following variants: > > partition with a known unique id. > > #. : major and minor number of the device separated by a > > colon. > > > > +It accepts the following variants for MTD device: > > + > > +1. MTD device name. "pstore" is recommended. > > +#. MTD device number. > > + > > kmsg_size > > ~ > > > > diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig > > index 42d401ea60ee..6ddab796216d 100644 > > --- a/drivers/mtd/Kconfig > > +++ b/drivers/mtd/Kconfig > > @@ -170,6 +170,16 @@ config MTD_OOPS > > buffer in a flash partition where it can be read back at some > > later point. > > > > +config MTD_PSTORE > > + tristate "Log panic/oops to an MTD buffer based on pstore" > > + depends on PSTORE_BLK > > + help > > + This enables panic and oops messages to be logged to a circular > > + buffer in a flash partition where it can be read back as files after > > + mounting pstore filesystem. > > + > > + If unsure, say N. > > + > > config MTD_SWAP > > tristate "Swap on MTD device support" > > depends on MTD && SWAP > > diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile > > index 56cc60ccc477..593d0593a038 100644 > > --- a/drivers/mtd/Makefile > > +++ b/drivers/mtd/Makefile > > @@ -20,6 +20,7 @@ obj-$(CONFIG_RFD_FTL) += rfd_ftl.o > > obj-$(CONFIG_SSFDC)+= ssfdc.o > > obj-$(CONFIG_SM_FTL) += sm_ftl.o > > obj-$(CONFIG_MTD_OOPS) += mtdoops.o > > +obj-$(CONFIG_MTD_PSTORE) += mtdpstore.o > > obj-$(CONFIG_MTD_SWAP) += mtdswap.o > > > > nftl-objs := nftlcore.o nftlmount.o > > diff --git a/drivers/mtd/mtdpstore.c b/drivers/mtd/mtdpstore.c > > new file mode 100644 > > index ..06084eff1004 > > --- /dev/null > > +++ b/drivers/mtd/mtdpstore.c > > @@ -0,0 +1,563 @@ > > +// SPDX-License-Identifier:
RE: [PATCH v7 1/7] i3c: master: secondary master initialization document
>> Document describing secondary master initialization, >> mastership handover and DEFSLVS handling processes. > >Thanks for doing that, but you probably didn't try to compile the doc >(the formatting is all messed up). > ># make htmldocs Yes, it looks messed in email but I built html format of doc and formatting was ok. May be because some tab/space issue it is looking messed up in email. I will check that. Regards, Parshuram Thombare
Re: linux-next boot error: WARNING: suspicious RCU usage in ip6mr_get_table
On Tue, May 12, 2020 at 11:28:47AM +1000, Stephen Rothwell wrote: > Hi all, > > On Fri, 8 May 2020 04:54:02 +0530 Madhuparna Bhowmik > wrote: > > > > On Thu, May 07, 2020 at 08:50:55AM -0400, Qian Cai wrote: > > > > > > > > > > On May 7, 2020, at 5:32 AM, Dmitry Vyukov wrote: > > > > > > > > On Thu, May 7, 2020 at 11:26 AM syzbot > > > > wrote: > > > >> > > > >> Hello, > > > >> > > > >> syzbot found the following crash on: > > > >> > > > >> HEAD commit:6b43f715 Add linux-next specific files for 20200507 > > > >> git tree: linux-next > > > >> console output: > > > >> https://syzkaller.appspot.com/x/log.txt?x=16f6437010 > > > >> kernel config: > > > >> https://syzkaller.appspot.com/x/.config?x=ef9b7a80b923f328 > > > >> dashboard link: > > > >> https://syzkaller.appspot.com/bug?extid=761cff389b454aa387d2 > > > >> compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > >> > > > >> Unfortunately, I don't have any reproducer for this crash yet. > > > >> > > > >> IMPORTANT: if you fix the bug, please add the following tag to the > > > >> commit: > > > >> Reported-by: syzbot+761cff389b454aa38...@syzkaller.appspotmail.com > > > > > > > > > > > > +linux-next for linux-next boot breakage > > > > > > Amol, Madhuparna, Is either of you still working on this? > > > > > > >> = > > > >> WARNING: suspicious RCU usage > > > >> 5.7.0-rc4-next-20200507-syzkaller #0 Not tainted > > > >> - > > > >> net/ipv6/ip6mr.c:124 RCU-list traversed in non-reader section!! > > > >> > > I had some doubt in this one, I have already mailed the maintainers, > > waiting for their reply. > > This is blocking syzbot testing of linux-next ... are we getting > anywhere? Will a patch similar to the ipmr.c one help here? > Hi Stephen, There are some discussions going on about the ipmr.c patch, I guess even ip6mr can be fixed in a similar way. Let me still confirm once. Thank you, Mahuparna > -- > Cheers, > Stephen Rothwell
Re: [PATCH] kernel: sysctl: ignore invalid taint bits introduced via kernel.tainted and taint the kernel with TAINT_USER on writes
On Mon, May 11, 2020 at 09:03:13PM -0400, Rafael Aquini wrote:
> On Tue, May 12, 2020 at 12:17:03AM +, Luis Chamberlain wrote:
> > On Mon, May 11, 2020 at 07:59:14PM -0400, Rafael Aquini wrote:
> > > On Mon, May 11, 2020 at 11:10:45PM +, Luis Chamberlain wrote:
> > > > On Mon, May 11, 2020 at 05:59:04PM -0400, Rafael Aquini wrote:
> > > > > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > > > > index 8a176d8727a3..f0a4fb38ac62 100644
> > > > > --- a/kernel/sysctl.c
> > > > > +++ b/kernel/sysctl.c
> > > > > @@ -2623,17 +2623,32 @@ static int proc_taint(struct ctl_table
> > > > > *table, int write,
> > > > > return err;
> > > > >
> > > > > if (write) {
> > > > > + int i;
> > > > > +
> > > > > + /*
> > > > > + * Ignore user input that would make us committing
> > > > > + * arbitrary invalid TAINT flags in the loop below.
> > > > > + */
> > > > > + tmptaint &= (1UL << TAINT_FLAGS_COUNT) - 1;
> > > >
> > > > This looks good but we don't pr_warn() of information lost on intention.
> > > >
> > >
> > > Are you thinking in sth like:
> > >
> > > + if (tmptaint > TAINT_FLAGS_MAX) {
> > > + tmptaint &= TAINT_FLAGS_MAX;
> > > + pr_warn("proc_taint: out-of-range invalid input
> > > ignored"
> > > + " tainted_mask adjusted to 0x%x\n",
> > > tmptaint);
> > > + }
> > > ?
> >
> > Sure that would clarify this.
> >
> > > > > +
> > > > > /*
> > > > >* Poor man's atomic or. Not worth adding a primitive
> > > > >* to everyone's atomic.h for this
> > > > >*/
> > > > > - int i;
> > > > > for (i = 0; i < BITS_PER_LONG && tmptaint >> i; i++) {
> > > > > if ((tmptaint >> i) & 1)
> > > > > add_taint(i, LOCKDEP_STILL_OK);
> > > > > }
> > > > > +
> > > > > + /*
> > > > > + * Users with SYS_ADMIN capability can include any
> > > > > arbitrary
> > > > > + * taint flag by writing to this interface. If that's
> > > > > the case,
> > > > > + * we also need to mark the kernel "tainted by user".
> > > > > + */
> > > > > + add_taint(TAINT_USER, LOCKDEP_STILL_OK);
> > > >
> > > > I'm in favor of this however I'd like to hear from Ted on if it meets
> > > > the original intention. I would think he had a good reason not to add
> > > > it here.
> > > >
> > >
> > > Fair enough. The impression I got by reading Ted's original commit
> > > message is that the intent was to have TAINT_USER as the flag set
> > > via this interface, even though the code was allowing for any
> > > arbitrary value.
> >
> > That wasn't my reading, it was that the user did something very odd
> > with user input which we don't like as kernel developers, and it gives
> > us a way to prove: hey you did something stupid, sorry but I cannot
> > support your kernel panic.
> >
> > > I think it's OK to let the user fiddle with
> > > the flags, as it's been allowed since the introduction of
> > > this interface, but we need to reflect that fact in the
> > > tainting itself. Since TAINT_USER is not used anywhere,
> >
> > I see users of TAINT_USER sprinkled around
> >
>
> I meant in the original commit that introduced it
> (commit 34f5a39899f3f3e815da64f48ddb72942d86c366). Sorry I
> miscomunicated that.
>
> In its current usage, it seems that the other places adding TAINT_USER
> match with what is being proposed here: To signal when we have user
> fiddling with kernel / module parameters.
drivers/base/regmap/regmap-debugfs.c requires *manual* code changes
to compile / enable some knob. i915 complains about unsafe module
params such as module_param_cb_unsafe() core_param_unsafe(). Then
drivers/soundwire/cadence_master.c is for when a debugfs dangerous
param was used.
This still doesn't rule out the use of proc_taint() for testing taint,
and that adding it may break some tests. So even though this would
only affect some tests scripts, I can't say that adding this taint won't
cause some headaches to someone. I wouldn't encourage its use on
proc_taint() from what I can see so far.
Luis
[PATCH] perf record: Use an eventfd to wakeup when done
The setting and checking of 'done' contains a rare race where the signal
handler setting 'done' is run after checking to break the loop, but
before waiting in evlist__poll(). In this case, the main loop won't wake
up until either another signal is sent, or the perf data fd causes a
wake up.
The following simple script can trigger this condition (but you might
need to run it for several hours):
for ((i = 0; i >= 0; i++)) ; do
echo "Loop $i"
delay=$(echo "scale=4; 0.1 * $RANDOM/32768" | bc)
./perf record -- sleep 3000 >/dev/null&
pid=$!
sleep $delay
kill -TERM $pid
echo "PID $pid"
wait $pid
done
At some point, the loop will stall. Adding logging, even though perf has
received the SIGTERM and set 'done = 1', perf will remain sleeping until
a second signal is sent.
Signed-off-by: Anand K Mistry
---
tools/perf/builtin-record.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 1ab349abe90469..099ecaa66732a2 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -53,6 +53,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -518,15 +519,28 @@ static int record__pushfn(struct mmap *map, void *to,
void *bf, size_t size)
static volatile int signr = -1;
static volatile int child_finished;
+static int done_fd = -1;
static void sig_handler(int sig)
{
+ u64 tmp = 1;
if (sig == SIGCHLD)
child_finished = 1;
else
signr = sig;
done = 1;
+
+ /*
+* It is possible for this signal handler to run after done is checked
+* in the main loop, but before the perf counter fds are polled. If this
+* happens, the poll() will continue to wait even though done is set,
+* and will only break out if either another signal is received, or the
+* counters are ready for read. To ensure the poll() doesn't sleep when
+* done is set, use an eventfd (done_fd) to wake up the poll().
+*/
+ if (write(done_fd, , sizeof(tmp)) < 0)
+ pr_err("failed to signal wakeup fd\n");
}
static void sigsegv_handler(int sig)
@@ -1424,6 +1438,17 @@ static int __cmd_record(struct record *rec, int argc,
const char **argv)
int fd;
float ratio = 0;
+ done_fd = eventfd(0, EFD_NONBLOCK);
+ if (done_fd < 0) {
+ pr_err("Failed to create wakeup eventfd, error: %m\n");
+ return -1;
+ }
+ err = evlist__add_pollfd(rec->evlist, done_fd);
+ if (err < 0) {
+ pr_err("Failed to add wakeup eventfd to poll list\n");
+ return -1;
+ }
+
atexit(record__sig_exit);
signal(SIGCHLD, sig_handler);
signal(SIGINT, sig_handler);
--
2.26.2.645.ge9eca65c58-goog
RE: [PATCH v7 2/7] i3c: master: use i3c_master_register only for main master
>> +/** >> + * i3c_master_register() - register an I3C master > >The function should be renamed and the doc updated to reflect the fact >that it only works for primary masters: > >i3c_primary_master_register() - register a primary I3C master Sure, I will do that. >> + * @master: master used to send frames on the bus >> + * @parent: the parent device (the one that provides this I3C master >> + * controller) >> + * @ops: the master controller operations >> + * @secondary: true if you are registering a secondary master. Will return >> + * -ENOTSUPP if set to true since secondary masters are not yet >> + * supported > >This argument no longer exists. Thanks, I missed that comment. It should be removed. Regards, Parshuram Thombare
Re: [PATCH v10 08/11] KVM: x86/pmu: Add LBR feature emulation via guest LBR event
On 2020/5/8 21:09, Peter Zijlstra wrote:
On Mon, Apr 27, 2020 at 11:16:40AM +0800, Like Xu wrote:
On 2020/4/24 20:16, Peter Zijlstra wrote:
And I suppose that is why you need that horrible:
needs_guest_lbr_without_counter() thing to begin with.
Do you suggest to use event->attr.config check to replace
"needs_branch_stack(event) && is_kernel_event(event) &&
event->attr.exclude_host" check for guest LBR event ?
That's what the BTS thing does.
Thanks, I'll apply it.
Please allocate yourself an event from the pseudo event range:
event==0x00. Currently we only have umask==3 for Fixed2 and umask==4
for Fixed3, given you claim 58, which is effectively Fixed25,
umask==0x1a might be appropriate.
OK, I assume that adding one more field ".config = 0x1a00" is
efficient enough for perf_event_attr to allocate guest LBR events.
Uh what? The code is already setting .config. You just have to change it
do another value.
Thanks, I'll apply it.
Also, I suppose we need to claim 0x as an error, so that other
people won't try this again.
Does the following fix address your concern on this ?
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 2405926e2dba..32d2a3f8c51f 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -498,6 +498,9 @@ int x86_pmu_max_precise(void)
int x86_pmu_hw_config(struct perf_event *event)
{
+ if (!unlikely(event->attr.config & X86_ARCH_EVENT_MASK))
+ return -EINVAL;
+
if (event->attr.precise_ip) {
int precise = x86_pmu_max_precise();
That wouldn't work right for AMD. But yes, something like that.
Sure, I may figure it out and leave it in another thread.
Also, what happens if you fail programming due to a conflicting cpu
event? That pinned doesn't guarantee you'll get the event, it just means
you'll error instead of getting RR.
I didn't find any code checking the event state.
Error instead of RR is expected.
If the KVM fails programming due to a conflicting cpu event
the LBR registers will not be passthrough to the guest,
and KVM would return zero for any guest LBR records accesses
until the next attempt to program the guest LBR event.
Every time before cpu enters the non-root mode where irq is
disabled, the "event-> oncpu! =-1" check will be applied.
(more details in the comment around intel_pmu_availability_check())
The guests administer is supposed to know the result of guest
LBR records is inaccurate if someone is using LBR to record
guest or hypervisor on the host side.
Is this acceptable to you？
If there is anything needs to be improved, please let me know.
It might be nice to emit a pr_warn() or something on the host when this
happens. Then at least the host admin can know he wrecked things for
which guest.
Sure, I will use pr_warn () and indicate which guest it is.
If you have more comments on the patchset, please let me know.
If not, I'll spin the next version based on your current feedback.
Thanks,
Like Xu
[Patch v2] efi: cper: Add support for printing Firmware Error Record Reference
While debugging a boot failure, the following unknown error record was
seen in the boot logs.
<...>
BERT: Error records from previous boot:
[Hardware Error]: event severity: fatal
[Hardware Error]: Error 0, type: fatal
[Hardware Error]: section type: unknown,
81212a96-09ed-4996-9471-8d729c8e69ed
[Hardware Error]: section length: 0x290
[Hardware Error]: : 0001 00020002
[Hardware Error]: 0010: 00020002 001f 0320
...
[Hardware Error]: 0020:
[Hardware Error]: 0030:
<...>
On further investigation, it was found that the error record with
UUID (81212a96-09ed-4996-9471-8d729c8e69ed) has been defined in the
UEFI Specification at least since v2.4 and has recently had additional
fields defined in v2.7 Section N.2.10 Firmware Error Record Reference.
Add support for parsing and printing the defined fields to give users
a chance to figure out what went wrong.
Signed-off-by: Punit Agrawal
Cc: Ard Biesheuvel
Cc: "Rafael J. Wysocki"
Cc: Borislav Petkov
Cc: James Morse
Cc: linux-a...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
Hi Ard,
I've updated the patch based on your feedback.
As you noted, some aspects of the spec make it a bit tricky to support
all revisions in a nice way (e.g., size check) but this version should
fix existing issues.
Thanks,
Punit
v1[0] -> v2:
* Simplified error record structure definition
* Fixed size check
* Added comment to clarify offset calculation for dumped data
* Style fixes for multiline if blocks
[0]
https://lkml.kernel.org/lkml/20200427085242.2380614-1-punit1.agra...@toshiba.co.jp/
---
drivers/firmware/efi/cper.c | 62 +
include/linux/cper.h| 9 ++
2 files changed, 71 insertions(+)
diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index 9d2512913d25..f564e15fbc7e 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -407,6 +407,58 @@ static void cper_print_pcie(const char *pfx, const struct
cper_sec_pcie *pcie,
}
}
+static const char * const fw_err_rec_type_strs[] = {
+ "IPF SAL Error Record",
+ "SOC Firmware Error Record Type1 (Legacy CrashLog Support)",
+ "SOC Firmware Error Record Type2",
+};
+
+static void cper_print_fw_err(const char *pfx,
+ struct acpi_hest_generic_data *gdata,
+ const struct cper_sec_fw_err_rec_ref *fw_err)
+{
+ void *buf = acpi_hest_get_payload(gdata);
+ u32 offset, length = gdata->error_data_length;
+
+ printk("%s""Firmware Error Record Type: %s\n", pfx,
+ fw_err->record_type < ARRAY_SIZE(fw_err_rec_type_strs) ?
+ fw_err_rec_type_strs[fw_err->record_type] : "unknown");
+ printk("%s""Revision: %d\n", pfx, fw_err->revision);
+
+ /* Record Type based on UEFI 2.7 */
+ if (fw_err->revision == 0) {
+ printk("%s""Record Identifier: %08llx\n", pfx,
+ fw_err->record_identifier);
+ } else if (fw_err->revision == 2) {
+ printk("%s""Record Identifier: %pUl\n", pfx,
+ _err->record_identifier_guid);
+ }
+
+ /*
+* The FW error record may contain trailing data beyond the
+* structure defined by the specification. As the fields
+* defined (and hence the offset of any trailing data) vary
+* with the revision, set the offset to account for this
+* variation.
+*/
+ if (fw_err->revision == 0) {
+ /* record_identifier_guid not defined */
+ offset = offsetof(struct cper_sec_fw_err_rec_ref,
+ record_identifier_guid);
+ } else if (fw_err->revision == 1) {
+ /* record_identifier not defined */
+ offset = offsetof(struct cper_sec_fw_err_rec_ref,
+ record_identifier);
+ } else {
+ offset = sizeof(*fw_err);
+ }
+
+ buf += offset;
+ length -= offset;
+
+ print_hex_dump(pfx, "", DUMP_PREFIX_OFFSET, 16, 4, buf, length, true);
+}
+
static void cper_print_tstamp(const char *pfx,
struct acpi_hest_generic_data_v300 *gdata)
{
@@ -494,6 +546,16 @@ cper_estatus_print_section(const char *pfx, struct
acpi_hest_generic_data *gdata
else
goto err_section_too_small;
#endif
+ } else if (guid_equal(sec_type, _SEC_FW_ERR_REC_REF)) {
+ struct cper_sec_fw_err_rec_ref *fw_err =
acpi_hest_get_payload(gdata);
+
+ printk("%ssection_type: Firmware Error Record Reference\n",
+ newpfx);
+ /* The minimal FW Error Record contains 16 bytes */
+
linux-next: manual merge of the sound-asoc tree with the crypto tree
Hi all,
Today's linux-next merge of the sound-asoc tree got a conflict in:
sound/soc/codecs/cros_ec_codec.c
between commit:
85fc78b80f15 ("ASoC: cros_ec_codec: use crypto_shash_tfm_digest()")
from the crypto tree and commit:
a1304cba816e ("ASoC: cros_ec_codec: allocate shash_desc dynamically")
from the sound-asoc tree.
I fixed it up (I just used the former) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpNsvVFXELLN.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/2] kbuild: remove {CLEAN,MRPROPER,DISTCLEAN}_DIRS
On Mon, May 4, 2020 at 5:08 PM Masahiro Yamada wrote:
>
> Merge {CLEAN,MRPROPER,DISTCLEAN}_DIRS into {CLEAN,MRPROPER,DISTCLEAN}_FILES
> because the difference is just the -r option passed to the 'rm' command.
>
> Do likewise as commit 1634f2bfdb84 ("kbuild: remove clean-dirs syntax").
>
> Signed-off-by: Masahiro Yamada
Applied to linux-kbuild.
> ---
>
> Makefile | 22 ++
> arch/um/Makefile | 2 +-
> 2 files changed, 7 insertions(+), 17 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ffd80afcd0bb..8a7c931cc0d9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1389,14 +1389,14 @@ endif # CONFIG_MODULES
> # make distclean Remove editor backup files, patch leftover files and the
> like
>
> # Directories & files removed with 'make clean'
> -CLEAN_DIRS += include/ksym
> -CLEAN_FILES += modules.builtin modules.builtin.modinfo modules.nsdeps
> +CLEAN_FILES += include/ksym \
> + modules.builtin modules.builtin.modinfo modules.nsdeps
>
> # Directories & files removed with 'make mrproper'
> -MRPROPER_DIRS += include/config include/generated \
> +MRPROPER_FILES += include/config include/generated \
> arch/$(SRCARCH)/include/generated .tmp_objdiff \
> - debian/ snap/ tar-install/
> -MRPROPER_FILES += .config .config.old .version \
> + debian snap tar-install \
> + .config .config.old .version \
> Module.symvers \
> signing_key.pem signing_key.priv signing_key.x509 \
> x509.genkey extra_certificates signing_key.x509.keyid \
> @@ -1404,12 +1404,10 @@ MRPROPER_FILES += .config .config.old .version \
> *.spec
>
> # Directories & files removed with 'make distclean'
> -DISTCLEAN_DIRS +=
> DISTCLEAN_FILES += tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS
>
> # clean - Delete most, but leave enough to build external modules
> #
> -clean: rm-dirs := $(CLEAN_DIRS)
> clean: rm-files := $(CLEAN_FILES)
>
> PHONY += archclean vmlinuxclean
> @@ -1422,7 +1420,6 @@ clean: archclean vmlinuxclean
>
> # mrproper - Delete all generated files, including .config
> #
> -mrproper: rm-dirs := $(wildcard $(MRPROPER_DIRS))
> mrproper: rm-files := $(wildcard $(MRPROPER_FILES))
> mrproper-dirs := $(addprefix _mrproper_,scripts)
>
> @@ -1431,18 +1428,15 @@ $(mrproper-dirs):
> $(Q)$(MAKE) $(clean)=$(patsubst _mrproper_%,%,$@)
>
> mrproper: clean $(mrproper-dirs)
> - $(call cmd,rmdirs)
> $(call cmd,rmfiles)
>
> # distclean
> #
> -distclean: rm-dirs := $(wildcard $(DISTCLEAN_DIRS))
> distclean: rm-files := $(wildcard $(DISTCLEAN_FILES))
>
> PHONY += distclean
>
> distclean: mrproper
> - $(call cmd,rmdirs)
> $(call cmd,rmfiles)
> @find $(srctree) $(RCS_FIND_IGNORE) \
> \( -name '*.orig' -o -name '*.rej' -o -name '*~' \
> @@ -1732,7 +1726,6 @@ $(clean-dirs):
> $(Q)$(MAKE) $(clean)=$(patsubst _clean_%,%,$@)
>
> clean: $(clean-dirs)
> - $(call cmd,rmdirs)
> $(call cmd,rmfiles)
> @find $(if $(KBUILD_EXTMOD), $(KBUILD_EXTMOD), .) $(RCS_FIND_IGNORE) \
> \( -name '*.[aios]' -o -name '*.ko' -o -name '.*.cmd' \
> @@ -1827,11 +1820,8 @@ tools/%: FORCE
> $(Q)mkdir -p $(objtree)/tools
> $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j%
> -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(srctree)/tools/ $*
>
> -quiet_cmd_rmdirs = $(if $(wildcard $(rm-dirs)),CLEAN $(wildcard
> $(rm-dirs)))
> - cmd_rmdirs = rm -rf $(rm-dirs)
> -
> quiet_cmd_rmfiles = $(if $(wildcard $(rm-files)),CLEAN $(wildcard
> $(rm-files)))
> - cmd_rmfiles = rm -f $(rm-files)
> + cmd_rmfiles = rm -rf $(rm-files)
>
> # Run depmod only if we have System.map and depmod is executable
> quiet_cmd_depmod = DEPMOD $(KERNELRELEASE)
> diff --git a/arch/um/Makefile b/arch/um/Makefile
> index 275f5ffdf6f0..3f27aa3ec0a6 100644
> --- a/arch/um/Makefile
> +++ b/arch/um/Makefile
> @@ -140,7 +140,7 @@ export CFLAGS_vmlinux := $(LINK-y) $(LINK_WRAPS)
> $(LD_FLAGS_CMDLINE)
> # When cleaning we don't include .config, so we don't include
> # TT or skas makefiles and don't clean skas_ptregs.h.
> CLEAN_FILES += linux x.i gmon.out
> -MRPROPER_DIRS += arch/$(SUBARCH)/include/generated
> +MRPROPER_FILES += arch/$(SUBARCH)/include/generated
>
> archclean:
> @find . \( -name '*.bb' -o -name '*.bbg' -o -name '*.da' \
> --
> 2.25.1
>
--
Best Regards
Masahiro Yamada
[RFC] e1000e: Relax condition to trigger reset for ME workaround
It's an error if the value of the RX/TX tail descriptor does not match
what was written. The error condition is true regardless the duration
of the interference from ME. But the code only performs the reset if
E1000_ICH_FWSM_PCIM2PCI_COUNT (2000) iterations of 50us delay have
transpired. The extra condition can lead to inconsistency between the
state of hardware as expected by the driver.
Fix this by dropping the check for number of delay iterations.
Signed-off-by: Punit Agrawal
Cc: Jeff Kirsher
Cc: "David S. Miller"
Cc: intel-wired-...@lists.osuosl.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Hi,
The issue was noticed through code inspection while backporting the
workaround for TDT corruption. Sending it out as an RFC as I am not
familiar with the hardware internals of the e1000e.
Another unresolved question is the inherent racy nature of the
workaround - the ME could block access again after releasing the
device (i.e., BIT(E1000_ICH_FWSM_PCIM2PCI) clear) but before the
driver performs the write. Has this not been a problem?
Any feedback on the patch or the more information on the issues
appreciated.
Thanks,
Punit
drivers/net/ethernet/intel/e1000e/netdev.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 177c6da80c57..5ed4d7ed35b3 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -607,11 +607,11 @@ static void e1000e_update_rdt_wa(struct e1000_ring
*rx_ring, unsigned int i)
{
struct e1000_adapter *adapter = rx_ring->adapter;
struct e1000_hw *hw = >hw;
- s32 ret_val = __ew32_prepare(hw);
+ __ew32_prepare(hw);
writel(i, rx_ring->tail);
- if (unlikely(!ret_val && (i != readl(rx_ring->tail {
+ if (unlikely(i != readl(rx_ring->tail))) {
u32 rctl = er32(RCTL);
ew32(RCTL, rctl & ~E1000_RCTL_EN);
@@ -624,11 +624,11 @@ static void e1000e_update_tdt_wa(struct e1000_ring
*tx_ring, unsigned int i)
{
struct e1000_adapter *adapter = tx_ring->adapter;
struct e1000_hw *hw = >hw;
- s32 ret_val = __ew32_prepare(hw);
+ __ew32_prepare(hw);
writel(i, tx_ring->tail);
- if (unlikely(!ret_val && (i != readl(tx_ring->tail {
+ if (unlikely(i != readl(tx_ring->tail))) {
u32 tctl = er32(TCTL);
ew32(TCTL, tctl & ~E1000_TCTL_EN);
--
2.26.2
[PATCH v4 2/2] KVM: x86/pmu: Support full width counting
Intel CPUs have a new alternative MSR range (starting from MSR_IA32_PMC0)
for GP counters that allows writing the full counter width. Enable this
range from a new capability bit (IA32_PERF_CAPABILITIES.FW_WRITE[bit 13]).
The guest would query CPUID to get the counter width, and sign extends
the counter values as needed. The traditional MSRs always limit to 32bit,
even though the counter internally is larger (usually 48 bits).
When the new capability is set, use the alternative range which do not
have these restrictions. This lowers the overhead of perf stat slightly
because it has to do less interrupts to accumulate the counter value.
Signed-off-by: Like Xu
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/cpuid.c| 2 +-
arch/x86/kvm/vmx/capabilities.h | 11
arch/x86/kvm/vmx/pmu_intel.c| 46 ++---
arch/x86/kvm/vmx/vmx.c | 3 +++
arch/x86/kvm/x86.c | 1 +
6 files changed, 59 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 35a915787559..8c3ae83f63d9 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -599,6 +599,7 @@ struct kvm_vcpu_arch {
u64 ia32_xss;
u64 microcode_version;
u64 arch_capabilities;
+ u64 perf_capabilities;
/*
* Paging state of the vcpu
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 35845704cf57..411ce1b58341 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -294,7 +294,7 @@ void kvm_set_cpu_caps(void)
F(XMM3) | F(PCLMULQDQ) | 0 /* DTES64, MONITOR */ |
0 /* DS-CPL, VMX, SMX, EST */ |
0 /* TM2 */ | F(SSSE3) | 0 /* CNXT-ID */ | 0 /* Reserved */ |
- F(FMA) | F(CX16) | 0 /* xTPR Update, PDCM */ |
+ F(FMA) | F(CX16) | 0 /* xTPR Update */ | F(PDCM) |
F(PCID) | 0 /* Reserved, DCA */ | F(XMM4_1) |
F(XMM4_2) | F(X2APIC) | F(MOVBE) | F(POPCNT) |
0 /* Reserved*/ | F(AES) | F(XSAVE) | 0 /* OSXSAVE */ | F(AVX) |
diff --git a/arch/x86/kvm/vmx/capabilities.h b/arch/x86/kvm/vmx/capabilities.h
index 8903475f751e..4bbd8b448d22 100644
--- a/arch/x86/kvm/vmx/capabilities.h
+++ b/arch/x86/kvm/vmx/capabilities.h
@@ -18,6 +18,8 @@ extern int __read_mostly pt_mode;
#define PT_MODE_SYSTEM 0
#define PT_MODE_HOST_GUEST 1
+#define PMU_CAP_FW_WRITES (1ULL << 13)
+
struct nested_vmx_msrs {
/*
* We only store the "true" versions of the VMX capability MSRs. We
@@ -367,4 +369,13 @@ static inline bool vmx_pt_mode_is_host_guest(void)
return pt_mode == PT_MODE_HOST_GUEST;
}
+static inline u64 vmx_get_perf_capabilities(void)
+{
+ /*
+* Since counters are virtualized, KVM would support full
+* width counting unconditionally, even if the host lacks it.
+*/
+ return PMU_CAP_FW_WRITES;
+}
+
#endif /* __KVM_X86_VMX_CAPS_H */
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index e1a303fefc16..f66a3e2e42cd 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -18,6 +18,8 @@
#include "nested.h"
#include "pmu.h"
+#define MSR_PMC_FULL_WIDTH_BIT (MSR_IA32_PMC0 - MSR_IA32_PERFCTR0)
+
static struct kvm_event_hw_type_mapping intel_arch_events[] = {
/* Index must match CPUID 0x0A.EBX bit vector */
[0] = { 0x3c, 0x00, PERF_COUNT_HW_CPU_CYCLES },
@@ -150,6 +152,14 @@ static struct kvm_pmc *intel_rdpmc_ecx_to_pmc(struct
kvm_vcpu *vcpu,
return [array_index_nospec(idx, num_counters)];
}
+static inline bool fw_writes_is_enabled(struct kvm_vcpu *vcpu)
+{
+ if (!guest_cpuid_has(vcpu, X86_FEATURE_PDCM))
+ return false;
+
+ return vcpu->arch.perf_capabilities & PMU_CAP_FW_WRITES;
+}
+
static bool intel_is_valid_msr(struct kvm_vcpu *vcpu, u32 msr)
{
struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
@@ -162,10 +172,15 @@ static bool intel_is_valid_msr(struct kvm_vcpu *vcpu, u32
msr)
case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
ret = pmu->version > 1;
break;
+ case MSR_IA32_PERF_CAPABILITIES:
+ ret = guest_cpuid_has(vcpu, X86_FEATURE_PDCM);
+ break;
default:
ret = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0) ||
get_gp_pmc(pmu, msr, MSR_P6_EVNTSEL0) ||
- get_fixed_pmc(pmu, msr);
+ get_fixed_pmc(pmu, msr) ||
+ (fw_writes_is_enabled(vcpu) &&
+ get_gp_pmc(pmu, msr, MSR_IA32_PMC0));
break;
}
@@ -203,8 +218,15 @@ static int intel_pmu_get_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
msr_info->data = pmu->global_ovf_ctrl;
return 0;
+ case
[PATCH 1/2] KVM: x86/pmu: Tweak kvm_pmu_get_msr to pass 'struct msr_data' in
From: Wei Wang
Change kvm_pmu_get_msr() to get the msr_data struct, as the host_initiated
field from the struct could be used by get_msr. This also makes this API
consistent with kvm_pmu_set_msr. No functional changes.
Signed-off-by: Wei Wang
---
arch/x86/kvm/pmu.c | 4 ++--
arch/x86/kvm/pmu.h | 4 ++--
arch/x86/kvm/svm/pmu.c | 7 ---
arch/x86/kvm/vmx/pmu_intel.c | 19 +++
arch/x86/kvm/x86.c | 4 ++--
5 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index a5078841bdac..b86346903f2e 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -397,9 +397,9 @@ static void kvm_pmu_mark_pmc_in_use(struct kvm_vcpu *vcpu,
u32 msr)
__set_bit(pmc->idx, pmu->pmc_in_use);
}
-int kvm_pmu_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *data)
+int kvm_pmu_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
{
- return kvm_x86_ops.pmu_ops->get_msr(vcpu, msr, data);
+ return kvm_x86_ops.pmu_ops->get_msr(vcpu, msr_info);
}
int kvm_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
index a6c78a797cb1..ab85eed8a6cc 100644
--- a/arch/x86/kvm/pmu.h
+++ b/arch/x86/kvm/pmu.h
@@ -32,7 +32,7 @@ struct kvm_pmu_ops {
struct kvm_pmc *(*msr_idx_to_pmc)(struct kvm_vcpu *vcpu, u32 msr);
int (*is_valid_rdpmc_ecx)(struct kvm_vcpu *vcpu, unsigned int idx);
bool (*is_valid_msr)(struct kvm_vcpu *vcpu, u32 msr);
- int (*get_msr)(struct kvm_vcpu *vcpu, u32 msr, u64 *data);
+ int (*get_msr)(struct kvm_vcpu *vcpu, struct msr_data *msr_info);
int (*set_msr)(struct kvm_vcpu *vcpu, struct msr_data *msr_info);
void (*refresh)(struct kvm_vcpu *vcpu);
void (*init)(struct kvm_vcpu *vcpu);
@@ -147,7 +147,7 @@ void kvm_pmu_handle_event(struct kvm_vcpu *vcpu);
int kvm_pmu_rdpmc(struct kvm_vcpu *vcpu, unsigned pmc, u64 *data);
int kvm_pmu_is_valid_rdpmc_ecx(struct kvm_vcpu *vcpu, unsigned int idx);
bool kvm_pmu_is_valid_msr(struct kvm_vcpu *vcpu, u32 msr);
-int kvm_pmu_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *data);
+int kvm_pmu_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info);
int kvm_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info);
void kvm_pmu_refresh(struct kvm_vcpu *vcpu);
void kvm_pmu_reset(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/svm/pmu.c b/arch/x86/kvm/svm/pmu.c
index ce0b10fe5e2b..035da07500e8 100644
--- a/arch/x86/kvm/svm/pmu.c
+++ b/arch/x86/kvm/svm/pmu.c
@@ -215,21 +215,22 @@ static struct kvm_pmc *amd_msr_idx_to_pmc(struct kvm_vcpu
*vcpu, u32 msr)
return pmc;
}
-static int amd_pmu_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *data)
+static int amd_pmu_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
{
struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
struct kvm_pmc *pmc;
+ u32 msr = msr_info->index;
/* MSR_PERFCTRn */
pmc = get_gp_pmc_amd(pmu, msr, PMU_TYPE_COUNTER);
if (pmc) {
- *data = pmc_read_counter(pmc);
+ msr_info->data = pmc_read_counter(pmc);
return 0;
}
/* MSR_EVNTSELn */
pmc = get_gp_pmc_amd(pmu, msr, PMU_TYPE_EVNTSEL);
if (pmc) {
- *data = pmc->eventsel;
+ msr_info->data = pmc->eventsel;
return 0;
}
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index 7c857737b438..e1a303fefc16 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -184,35 +184,38 @@ static struct kvm_pmc *intel_msr_idx_to_pmc(struct
kvm_vcpu *vcpu, u32 msr)
return pmc;
}
-static int intel_pmu_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *data)
+static int intel_pmu_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
{
struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
struct kvm_pmc *pmc;
+ u32 msr = msr_info->index;
switch (msr) {
case MSR_CORE_PERF_FIXED_CTR_CTRL:
- *data = pmu->fixed_ctr_ctrl;
+ msr_info->data = pmu->fixed_ctr_ctrl;
return 0;
case MSR_CORE_PERF_GLOBAL_STATUS:
- *data = pmu->global_status;
+ msr_info->data = pmu->global_status;
return 0;
case MSR_CORE_PERF_GLOBAL_CTRL:
- *data = pmu->global_ctrl;
+ msr_info->data = pmu->global_ctrl;
return 0;
case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
- *data = pmu->global_ovf_ctrl;
+ msr_info->data = pmu->global_ovf_ctrl;
return 0;
default:
if ((pmc = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0))) {
u64 val = pmc_read_counter(pmc);
- *data = val & pmu->counter_bitmask[KVM_PMC_GP];
+ msr_info->data =
+
Re: mmotm 2020-05-11-15-43 uploaded (mm/memcontrol.c, huge pages)
On 5/11/20 3:44 PM, Andrew Morton wrote:
> The mm-of-the-moment snapshot 2020-05-11-15-43 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my -mm patch queue. Uploaded at random hopefully
> more than once a week.
>
> You will need quilt to apply these patches to the latest Linus release (5.x
> or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in
> http://ozlabs.org/~akpm/mmotm/series
>
> The file broken-out.tar.gz contains two datestamp files: .DATE and
> .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss,
> followed by the base kernel version against which this patch series is to
> be applied.
>
> This tree is partially included in linux-next. To see which patches are
> included in linux-next, consult the `series' file. Only the patches
> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> linux-next.
>
>
> A full copy of the full kernel tree with the linux-next and mmotm patches
> already applied is available through git within an hour of the mmotm
> release. Individual mmotm releases are tagged. The master branch always
> points to the latest release, so it's constantly rebasing.
>
> https://github.com/hnaz/linux-mm
>
> The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
> contains daily snapshots of the -mm tree. It is updated more frequently
> than mmotm, and is untested.
>
> A git copy of this tree is also available at
>
> https://github.com/hnaz/linux-mm
on x86_64:
In file included from ../arch/x86/include/asm/atomic.h:5:0,
from ../include/linux/atomic.h:7,
from ../include/linux/page_counter.h:5,
from ../mm/memcontrol.c:25:
../mm/memcontrol.c: In function ‘memcg_stat_show’:
../include/linux/compiler.h:394:38: error: call to ‘__compiletime_assert_383’
declared with attribute error: BUILD_BUG failed
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^
../include/linux/compiler.h:375:4: note: in definition of macro
‘__compiletime_assert’
prefix ## suffix();\
^~
../include/linux/compiler.h:394:2: note: in expansion of macro
‘_compiletime_assert’
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^~~
../include/linux/build_bug.h:39:37: note: in expansion of macro
‘compiletime_assert’
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
../include/linux/build_bug.h:59:21: note: in expansion of macro
‘BUILD_BUG_ON_MSG’
#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
^~~~
../include/linux/huge_mm.h:319:28: note: in expansion of macro ‘BUILD_BUG’
#define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
^
../include/linux/huge_mm.h:115:26: note: in expansion of macro ‘HPAGE_PMD_SHIFT’
#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
^~~
../include/linux/huge_mm.h:116:26: note: in expansion of macro ‘HPAGE_PMD_ORDER’
#define HPAGE_PMD_NR (1<
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 5.7.0-rc5-mm1 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="gcc (SUSE Linux) 7.5.0"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=70500
CONFIG_LD_VERSION=23200
CONFIG_CLANG_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_UAPI_HEADER_TEST=y
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_WATCH_QUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_USELIB is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_INJECTION=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_DEBUGFS=y
# end of IRQ subsystem
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
Re: [PATCH 1/2] kbuild: remove misleading stale FIXME comment
On Mon, May 4, 2020 at 5:08 PM Masahiro Yamada wrote:
>
> This comment was added by commit ("kbuild: Restore build nr, improve
> vmlinux link") [1].
>
> It was talking about if_changed_rule at that time. Now, it is unclear
> what to fix.
>
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=ea52ca1b3e3882b499cc6c043f384958b88b62ff
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild.
>
> Makefile | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 9ff00bfe0575..ffd80afcd0bb 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1827,9 +1827,6 @@ tools/%: FORCE
> $(Q)mkdir -p $(objtree)/tools
> $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j%
> -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(srctree)/tools/ $*
>
> -# FIXME Should go into a make.lib or something
> -# ===
> -
> quiet_cmd_rmdirs = $(if $(wildcard $(rm-dirs)),CLEAN $(wildcard
> $(rm-dirs)))
>cmd_rmdirs = rm -rf $(rm-dirs)
>
> --
> 2.25.1
>
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 00/15] kbuild: support 'userprogs' syntax
On Wed, Apr 29, 2020 at 12:45 PM Masahiro Yamada wrote: > > > Several Makefiles use 'hostprogs' to build programs for the host > architecture where it is not appropriate to do so. > This is just because Kbuild lacks the support for building programs > for the target architecture. > > This series introduce 'userprogs' syntax and use it from > sample and bpf Makefiles. > > Sam worked on this in 2014. > https://lkml.org/lkml/2014/7/13/154 > > He used 'uapiprogs-y' but I just thought the meaning of > "UAPI programs" is unclear. > > Naming the syntax is one of the most difficult parts. > > I chose 'userprogs'. Anothor choice I had in my mind was 'targetprogs'. > > You can test this series quickly by 'make allmodconfig samples/' > > When building objects for userspace, [U] is displayed. > > masahiro@oscar:~/workspace/linux$ make allmodconfig samples/ All applied to linux-kbuild. > [snip] > AR samples/vfio-mdev/built-in.a > CC [M] samples/vfio-mdev/mtty.o > CC [M] samples/vfio-mdev/mdpy.o > CC [M] samples/vfio-mdev/mdpy-fb.o > CC [M] samples/vfio-mdev/mbochs.o > AR samples/mei/built-in.a > CC [U] samples/mei/mei-amt-version > CC [U] samples/auxdisplay/cfag12864b-example > CC [M] samples/configfs/configfs_sample.o > CC [M] samples/connector/cn_test.o > CC [U] samples/connector/ucon > CC [M] samples/ftrace/ftrace-direct.o > CC [M] samples/ftrace/ftrace-direct-too.o > CC [M] samples/ftrace/ftrace-direct-modify.o > CC [M] samples/ftrace/sample-trace-array.o > CC [U] samples/hidraw/hid-example > CC [M] samples/hw_breakpoint/data_breakpoint.o > CC [M] samples/kdb/kdb_hello.o > CC [M] samples/kfifo/bytestream-example.o > CC [M] samples/kfifo/dma-example.o > CC [M] samples/kfifo/inttype-example.o > CC [M] samples/kfifo/record-example.o > CC [M] samples/kobject/kobject-example.o > CC [M] samples/kobject/kset-example.o > CC [M] samples/kprobes/kprobe_example.o > CC [M] samples/kprobes/kretprobe_example.o > CC [M] samples/livepatch/livepatch-sample.o > CC [M] samples/livepatch/livepatch-shadow-mod.o > CC [M] samples/livepatch/livepatch-shadow-fix1.o > CC [M] samples/livepatch/livepatch-shadow-fix2.o > CC [M] samples/livepatch/livepatch-callbacks-demo.o > CC [M] samples/livepatch/livepatch-callbacks-mod.o > CC [M] samples/livepatch/livepatch-callbacks-busymod.o > CC [M] samples/rpmsg/rpmsg_client_sample.o > CC [U] samples/seccomp/bpf-fancy.o > CC [U] samples/seccomp/bpf-helper.o > LD [U] samples/seccomp/bpf-fancy > CC [U] samples/seccomp/dropper > CC [U] samples/seccomp/bpf-direct > CC [U] samples/seccomp/user-trap > CC [U] samples/timers/hpet_example > CC [M] samples/trace_events/trace-events-sample.o > CC [M] samples/trace_printk/trace-printk.o > CC [U] samples/uhid/uhid-example > CC [M] samples/v4l/v4l2-pci-skeleton.o > CC [U] samples/vfs/test-fsmount > CC [U] samples/vfs/test-statx > samples/vfs/test-statx.c:24:15: warning: ‘struct foo’ declared inside > parameter list will not be visible outside of this definition or declaration >24 | #define statx foo > | ^~~ > CC [U] samples/watchdog/watchdog-simple > AR samples/built-in.a > > Changes for v2: > - Fix ARCH=i386 build error for bpfilter_umh > - Rename 'user-ccflags' to 'userccflags' > because 'user-ccflags' would conflict if an object > called 'user.o' exists in the directory. > - Support 'userldflags' > > Masahiro Yamada (14): > bpfilter: match bit size of bpfilter_umh to that of the kernel > kbuild: add infrastructure to build userspace programs > bpfilter: use 'userprogs' syntax to build bpfilter_umh > samples: seccomp: build sample programs for target architecture > kbuild: doc: document the new syntax 'userprogs' > samples: uhid: build sample program for target architecture > samples: hidraw: build sample program for target architecture > samples: connector: build sample program for target architecture > samples: vfs: build sample programs for target architecture > samples: pidfd: build sample program for target architecture > samples: mei: build sample program for target architecture > samples: auxdisplay: use 'userprogs' syntax > samples: timers: use 'userprogs' syntax > samples: watchdog: use 'userprogs' syntax > > Sam Ravnborg (1): > samples: uhid: fix warnings in uhid-example > > Documentation/kbuild/makefiles.rst | 183 + > Makefile | 13 +- > init/Kconfig | 4 +- > net/bpfilter/Makefile | 11 +- > samples/Kconfig| 26 +++- > samples/Makefile | 4 + > samples/auxdisplay/Makefile| 11 +- > samples/connector/Makefile | 12 +- > samples/hidraw/Makefile| 9 +- > samples/mei/Makefile | 9 +- > samples/pidfd/Makefile | 8 +- >
Re: [PATCH] bpfilter: check if $(CC) can static link in Kconfig
On Sun, May 10, 2020 at 10:04 AM Alexei Starovoitov wrote: > > On Sat, May 9, 2020 at 12:40 AM Masahiro Yamada wrote: > > > > On Fedora, linking static libraries requires the glibc-static RPM > > package, which is not part of the glibc-devel package. > > > > CONFIG_CC_CAN_LINK does not check the capability of static linking, > > so you can enable CONFIG_BPFILTER_UMH, then fail to build. > > > > HOSTLD net/bpfilter/bpfilter_umh > > /usr/bin/ld: cannot find -lc > > collect2: error: ld returned 1 exit status > > > > Add CONFIG_CC_CAN_LINK_STATIC, and make CONFIG_BPFILTER_UMH depend > > on it. > > > > Reported-by: Valdis Kletnieks > > Signed-off-by: Masahiro Yamada > > Thanks! > Acked-by: Alexei Starovoitov Applied to linux-kbuild with Alexei's Ack. -- Best Regards Masahiro Yamada
Re: [PATCH] xen/pvcalls-back: test for errors when calling backend_connect()
On 11.05.20 23:41, Stefano Stabellini wrote:
On Mon, 11 May 2020, Juergen Gross wrote:
backend_connect() can fail, so switch the device to connected only if
no error occurred.
Fixes: 0a9c75c2c7258f2 ("xen/pvcalls: xenbus state handling")
Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross
Reviewed-by: Stefano Stabellini
---
drivers/xen/pvcalls-back.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index cf4ce3e9358d..41a18ece029a 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -1088,7 +1088,8 @@ static void set_backend_state(struct xenbus_device *dev,
case XenbusStateInitialised:
switch (state) {
case XenbusStateConnected:
- backend_connect(dev);
+ if (backend_connect(dev))
+ return;
Do you think it would make sense to WARN?
There already should be an error message (either due to a failed
grant mapping or a failed memory allocation).
Juergen
[RFC] mm/vmstat: Add events for THP migration without split
Add the following new trace events which will help in validating migration
events involving PMD based THP pages.
1. THP_PMD_MIGRATION_ENTRY_SET
2. THP_PMD_MIGRATION_ENTRY_REMOVE
There are no clear method to confirm whether a THP migration happened with
out involving it's split. These trace events along with PGMIGRATE_SUCCESS
and PGMIGRATE_FAILURE will provide additional insights. After this change,
A single 2M THP (2K base page) when migrated
1. Without split
pgmigrate_success 1
pgmigrate_fail 0
thp_pmd_migration_entry_set 1
thp_pmd_migration_entry_remove 1
2. With split
pgmigrate_success 512
pgmigrate_fail 0
thp_pmd_migration_entry_set 0
thp_pmd_migration_entry_remove 0
pgmigrate_success as 1 instead of 512, provides a hint for possible THP
migration event. But then it gets mixed with normal page migrations over
time. These additional trace events provide required co-relation.
Cc: Andrew Morton
Cc: "Kirill A. Shutemov"
Cc: Zi Yan
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
This is an indirect way for counting PMD migrations without split. Is there
a better method possible ? Just request for comments at the moment.
include/linux/vm_event_item.h | 4
mm/migrate.c | 1 +
mm/rmap.c | 1 +
mm/vmstat.c | 4
4 files changed, 10 insertions(+)
diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index ffef0f279747..4b25102cf3ad 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -91,6 +91,10 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
THP_ZERO_PAGE_ALLOC_FAILED,
THP_SWPOUT,
THP_SWPOUT_FALLBACK,
+#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
+ THP_PMD_MIGRATION_ENTRY_SET,
+ THP_PMD_MIGRATION_ENTRY_REMOVE,
+#endif
#endif
#ifdef CONFIG_MEMORY_BALLOON
BALLOON_INFLATE,
diff --git a/mm/migrate.c b/mm/migrate.c
index 7160c1556f79..8d50d55cbe97 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -228,6 +228,7 @@ static bool remove_migration_pte(struct page *page, struct
vm_area_struct *vma,
if (!pvmw.pte) {
VM_BUG_ON_PAGE(PageHuge(page) ||
!PageTransCompound(page), page);
remove_migration_pmd(, new);
+ count_vm_event(THP_PMD_MIGRATION_ENTRY_REMOVE);
continue;
}
#endif
diff --git a/mm/rmap.c b/mm/rmap.c
index f79a206b271a..3c1fe3f45cb5 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1418,6 +1418,7 @@ static bool try_to_unmap_one(struct page *page, struct
vm_area_struct *vma,
VM_BUG_ON_PAGE(PageHuge(page) ||
!PageTransCompound(page), page);
set_pmd_migration_entry(, page);
+ count_vm_event(THP_PMD_MIGRATION_ENTRY_SET);
continue;
}
#endif
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 96d21a792b57..a5254b7ee531 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1274,6 +1274,10 @@ const char * const vmstat_text[] = {
"thp_zero_page_alloc_failed",
"thp_swpout",
"thp_swpout_fallback",
+#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
+ "thp_pmd_migration_entry_set",
+ "thp_pmd_migration_entry_remove",
+#endif
#endif
#ifdef CONFIG_MEMORY_BALLOON
"balloon_inflate",
--
2.20.1
Re: [PATCH] x86/platform/uv: HUB RTC cleanup
On Mon, May 11, 2020 at 05:35:35PM -0500, Dimitri Sivanich wrote: > Remove unused event code and other cleanup for HUB RTC. Can you explain how this is dead? That's not entirely obvious from the patch. Also you probably want to split it the cleans into one or several additional patches and aso document them in the commit log(s). > diff --git a/arch/x86/platform/uv/uv_time.c b/arch/x86/platform/uv/uv_time.c > index 7af31b245636..1777b7164ff8 100644 > --- a/arch/x86/platform/uv/uv_time.c > +++ b/arch/x86/platform/uv/uv_time.c > @@ -1,25 +1,18 @@ > // SPDX-License-Identifier: GPL-2.0-or-later > /* > - * SGI RTC clock/timer routines. > + * HPE RTC clock routine. Might be worth mentioning this is for the UV platform? Both the old SGI and thew new HPE are not very descriptive.
Re: [PATCH 00/14] thermal core include cleanups
On 11-05-20, 17:54, Amit Kucheria wrote: > I noticed some remnants from when thermal core could be modular. While > cleaning that up, I fixed up the includes to be sorted alphabetically and > included export.h in files that were using EXPORT_SYMBOL* or THIS_MODULE > while at the same time removing inclusion of module.h from core files. > > Finally, the names of the source files for the governors and core have some > inconsistencies and the last couple of patches rename them. > > Build and boot tested on some ARM boards. Acked-by: Viresh Kumar -- viresh
Re: [PATCH v5 3/7] fpga: dfl: introduce interrupt trigger setting API
On Mon, Apr 20, 2020 at 04:11:39PM +0800, Xu Yilun wrote:
> FPGA user applications may be interested in interrupts generated by
> DFL features. For example, users can implement their own FPGA
> logics with interrupts enabled in AFU (Accelerated Function Unit,
> dynamic region of DFL based FPGA). So user applications need to be
> notified to handle these interrupts.
>
> In order to allow userspace applications to monitor interrupts,
> driver requires userspace to provide eventfds as interrupt
> notification channels. Applications then poll/select on the eventfds
> to get notified.
>
> This patch introduces a generic helper functions to do eventfds binding
> with given interrupts.
>
> Sub feature drivers are expected to use XXX_GET_IRQ_NUM to query irq
> info, and XXX_SET_IRQ to set eventfds for interrupts. This patch also
> introduces helper functions for these 2 ioctls.
>
> Signed-off-by: Luwei Kang
> Signed-off-by: Wu Hao
> Signed-off-by: Xu Yilun
> Acked-by: Wu Hao
>
> v2: use unsigned int instead of int for irq array indexes in
> dfl_fpga_set_irq_triggers()
> Improves comments for NULL fds param in dfl_fpga_set_irq_triggers()
> v3: Improve comments of dfl_fpga_set_irq_triggers()
> refines code for dfl_fpga_set_irq_triggers, delete local variable j
> v4: Introduce 2 helper functions to help handle the XXX_GET_IRQ_NUM &
> XXX_SET_IRQ ioctls for sub feature drivers.
> v5: Some minor fix for Hao's comments
> ---
> drivers/fpga/dfl.c| 156
> ++
> drivers/fpga/dfl.h| 17 +
> include/uapi/linux/fpga-dfl.h | 13
> 3 files changed, 186 insertions(+)
>
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index b49fbed..208d8f0 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -10,7 +10,9 @@
> * Wu Hao
> * Xiao Guangrong
> */
> +#include
> #include
> +#include
>
> #include "dfl.h"
>
> @@ -534,6 +536,7 @@ static int build_info_commit_dev(struct
> build_feature_devs_info *binfo)
> unsigned int i;
>
> /* save resource information for each feature */
> + feature->dev = fdev;
> feature->id = finfo->fid;
> feature->resource_index = index;
> feature->ioaddr = finfo->ioaddr;
> @@ -1395,6 +1398,159 @@ int dfl_fpga_cdev_config_ports_vf(struct
> dfl_fpga_cdev *cdev, int num_vfs)
> }
> EXPORT_SYMBOL_GPL(dfl_fpga_cdev_config_ports_vf);
>
> +static irqreturn_t dfl_irq_handler(int irq, void *arg)
> +{
> + struct eventfd_ctx *trigger = arg;
> +
> + eventfd_signal(trigger, 1);
> + return IRQ_HANDLED;
> +}
> +
> +static int do_set_irq_trigger(struct dfl_feature *feature, unsigned int idx,
> + int fd)
> +{
> + struct platform_device *pdev = feature->dev;
> + struct eventfd_ctx *trigger;
> + int irq, ret;
> +
> + if (idx >= feature->nr_irqs)
> + return -EINVAL;
> +
> + irq = feature->irq_ctx[idx].irq;
> +
> + if (feature->irq_ctx[idx].trigger) {
> + free_irq(irq, feature->irq_ctx[idx].trigger);
> + kfree(feature->irq_ctx[idx].name);
> + eventfd_ctx_put(feature->irq_ctx[idx].trigger);
> + feature->irq_ctx[idx].trigger = NULL;
> + }
> +
> + if (fd < 0)
> + return 0;
> +
> + feature->irq_ctx[idx].name =
> + kasprintf(GFP_KERNEL, "fpga-irq[%u](%s-%llx)", idx,
> + dev_name(>dev),
> + (unsigned long long)feature->id);
> + if (!feature->irq_ctx[idx].name)
> + return -ENOMEM;
> +
> + trigger = eventfd_ctx_fdget(fd);
> + if (IS_ERR(trigger)) {
> + ret = PTR_ERR(trigger);
> + goto free_name;
> + }
> +
> + ret = request_irq(irq, dfl_irq_handler, 0,
> + feature->irq_ctx[idx].name, trigger);
> + if (!ret) {
> + feature->irq_ctx[idx].trigger = trigger;
> + return ret;
> + }
> +
> + eventfd_ctx_put(trigger);
> +free_name:
> + kfree(feature->irq_ctx[idx].name);
> +
> + return ret;
> +}
> +
> +/**
> + * dfl_fpga_set_irq_triggers - set eventfd triggers for dfl feature
> interrupts
> + *
> + * @feature: dfl sub feature.
> + * @start: start of irq index in this dfl sub feature.
> + * @count: number of irqs.
> + * @fds: eventfds to bind with irqs. unbind related irq if fds[n] is
> negative.
> + *unbind "count" specified number of irqs if fds ptr is NULL.
> + *
> + * Bind given eventfds with irqs in this dfl sub feature. Unbind related irq
> if
> + * fds[n] is negative. Unbind "count" specified number of irqs if fds ptr is
> + * NULL.
> + *
> + * Return: 0 on success, negative error code otherwise.
> + */
> +int dfl_fpga_set_irq_triggers(struct dfl_feature *feature, unsigned int
> start,
> + unsigned int count, int32_t *fds)
> +{
> + unsigned int i;
> + int ret
Re: [PATCH v5 2/7] fpga: dfl: pci: add irq info for feature devices enumeration
On Mon, Apr 20, 2020 at 04:11:38PM +0800, Xu Yilun wrote:
> Some DFL FPGA PCIe cards (e.g. Intel FPGA Programmable Acceleration
> Card) support MSI-X based interrupts. This patch allows PCIe driver
> to prepare and pass interrupt resources to DFL via enumeration API.
> These interrupt resources could then be assigned to actual features
> which use them.
>
> Signed-off-by: Luwei Kang
> Signed-off-by: Wu Hao
> Signed-off-by: Xu Yilun
> Acked-by: Wu Hao
>
> v2: put irq resources init code inside cce_enumerate_feature_dev()
> Some minor changes for Hao's comments.
> v3: Some minor fix for Hao's comments for v2.
> v4: Some minor fix for Hao's comments for v3.
> v5: No change.
> ---
> drivers/fpga/dfl-pci.c | 80
> --
> 1 file changed, 71 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c
> index a78c409..2ff1274 100644
> --- a/drivers/fpga/dfl-pci.c
> +++ b/drivers/fpga/dfl-pci.c
> @@ -39,6 +39,27 @@ static void __iomem *cci_pci_ioremap_bar(struct pci_dev
> *pcidev, int bar)
> return pcim_iomap_table(pcidev)[bar];
> }
>
> +static int cci_pci_alloc_irq(struct pci_dev *pcidev)
> +{
> + int ret, nvec = pci_msix_vec_count(pcidev);
> +
> + if (nvec <= 0) {
> + dev_dbg(>dev, "fpga interrupt not supported\n");
> + return 0;
> + }
> +
> + ret = pci_alloc_irq_vectors(pcidev, nvec, nvec, PCI_IRQ_MSIX);
> + if (ret < 0)
> + return ret;
> +
> + return nvec;
> +}
> +
> +static void cci_pci_free_irq(struct pci_dev *pcidev)
> +{
> + pci_free_irq_vectors(pcidev);
> +}
> +
> /* PCI Device ID */
> #define PCIE_DEVICE_ID_PF_INT_5_X0xBCBD
> #define PCIE_DEVICE_ID_PF_INT_6_X0xBCC0
> @@ -78,17 +99,38 @@ static void cci_remove_feature_devs(struct pci_dev
> *pcidev)
>
> /* remove all children feature devices */
> dfl_fpga_feature_devs_remove(drvdata->cdev);
> + cci_pci_free_irq(pcidev);
> +}
> +
> +static int *cci_pci_create_irq_table(struct pci_dev *pcidev, unsigned int
> nvec)
> +{
> + unsigned int i;
> + int *table;
> +
> + table = kcalloc(nvec, sizeof(int), GFP_KERNEL);
> + if (table) {
> + for (i = 0; i < nvec; i++)
> + table[i] = pci_irq_vector(pcidev, i);
> + }
Have you considered:
if (!table)
return table;
for (i = 0; i < nvec; i++)
table[i] = pci_irq_vector(pcidev, i);
return table;
> +
> + return table;
> +}
> +
> +static void cci_pci_free_irq_table(int *table)
> +{
> + kfree(table);
> }
Have you considered just using kfree()?
>
> /* enumerate feature devices under pci device */
> static int cci_enumerate_feature_devs(struct pci_dev *pcidev)
> {
> struct cci_drvdata *drvdata = pci_get_drvdata(pcidev);
> + int port_num, bar, i, nvec, ret = 0;
> struct dfl_fpga_enum_info *info;
> struct dfl_fpga_cdev *cdev;
> resource_size_t start, len;
> - int port_num, bar, i, ret = 0;
> void __iomem *base;
> + int *irq_table;
> u32 offset;
> u64 v;
>
> @@ -97,11 +139,30 @@ static int cci_enumerate_feature_devs(struct pci_dev
> *pcidev)
> if (!info)
> return -ENOMEM;
>
> + /* add irq info for enumeration if the device support irq */
> + nvec = cci_pci_alloc_irq(pcidev);
> + if (nvec < 0) {
> + dev_err(>dev, "Fail to alloc irq %d.\n", nvec);
> + ret = nvec;
> + goto enum_info_free_exit;
> + } else if (nvec) {
> + irq_table = cci_pci_create_irq_table(pcidev, nvec);
> + if (!irq_table) {
> + ret = -ENOMEM;
> + goto irq_free_exit;
> + }
> +
> + ret = dfl_fpga_enum_info_add_irq(info, nvec, irq_table);
> + cci_pci_free_irq_table(irq_table);
> + if (ret)
> + goto irq_free_exit;
> + }
> +
> /* start to find Device Feature List from Bar 0 */
> base = cci_pci_ioremap_bar(pcidev, 0);
> if (!base) {
> ret = -ENOMEM;
> - goto enum_info_free_exit;
> + goto irq_free_exit;
> }
>
> /*
> @@ -154,7 +215,7 @@ static int cci_enumerate_feature_devs(struct pci_dev
> *pcidev)
> dfl_fpga_enum_info_add_dfl(info, start, len, base);
> } else {
> ret = -ENODEV;
> - goto enum_info_free_exit;
> + goto irq_free_exit;
> }
>
> /* start enumeration with prepared enumeration information */
> @@ -162,11 +223,14 @@ static int cci_enumerate_feature_devs(struct pci_dev
> *pcidev)
> if (IS_ERR(cdev)) {
> dev_err(>dev, "Enumeration failure\n");
> ret = PTR_ERR(cdev);
> - goto enum_info_free_exit;
> + goto irq_free_exit;
> }
>
> drvdata->cdev = cdev;
>
> +irq_free_exit:
> +
Re: [PATCH v2 1/3] iio: Add in_illumincance vectors in different color spaces
On Fri, May 8, 2020 at 8:16 AM Jonathan Cameron wrote: > > On Wed, 6 May 2020 16:03:22 -0700 > Gwendal Grignou wrote: > > Illuminance in the title. Plus I'm still arguing these > aren't illuminance values. > > The Y value is illuminance but X and Z definitely aren't. > RGB needs to stick to intensity - like the other existing > RGB sensors. > > Gah. XYZ and IIO is a mess. > > I suppose we could introduce a new type and have > in_illumiance_raw > in_chromacity_x_raw > in_chromacity_z_raw but chances of anyone understanding what we > are on about without reading wikipedia is low... > > Sigh. Unless someone else chips in, I'm inclined to be lazy and rely > on documentation to let in_illuminance_x,y,z be defined as being > cie xyz color space measurements. > > It seems slighlty preferable to defining another type for these, > though I suspect I'll regret this comment when some adds > cie lab which was always my favourite colour space :) > > > > > Define 2 spaces for defining color coming from color sensors: > > RGB and XYZ: Both are in lux. > > RGB is the raw output from sensors (Red, Green and Blue channels), in > > addition to the existing clear channel (C). > > > The RGBC vector goes through a matrix transformation to produce the XYZ > > vector. Y is illumincance, and XY caries the chromaticity information. > > The matrix is model specific, as the color sensor can be behing a glass > > that can filter some wavelengths. > > > > Signed-off-by: Gwendal Grignou > > --- > > New in v2. > > > > Documentation/ABI/testing/sysfs-bus-iio | 27 + > > 1 file changed, 27 insertions(+) > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio > > b/Documentation/ABI/testing/sysfs-bus-iio > > index d3e53a6d8331b..256db6e63a25e 100644 > > --- a/Documentation/ABI/testing/sysfs-bus-iio > > +++ b/Documentation/ABI/testing/sysfs-bus-iio > > @@ -1309,6 +1309,33 @@ Description: > > Illuminance measurement, units after application of scale > > and offset are lux. > > > > +What:/sys/.../iio:deviceX/in_illuminance_red_raw > > +What:/sys/.../iio:deviceX/in_illuminance_green_raw > > +What:/sys/.../iio:deviceX/in_illuminance_blue_raw > > +KernelVersion: 5.7 > > +Contact: linux-...@vger.kernel.org > > +Description: > > + Illuminance measuremed in red, green or blue channels, units > > + after application of scale and offset are lux. > > No they aren't. Units are some magic intensity at some magic wavelength. > > > + > > +What:/sys/.../iio:deviceX/in_illuminance_x_raw > > +What:/sys/.../iio:deviceX/in_illuminance_y_raw > > +What:/sys/.../iio:deviceX/in_illuminance_z_raw > > +KernelVersion: 5.7 > > +Contact: linux-...@vger.kernel.org > > +Description: > > + lluminance measured in the CIE 1931 color space (XYZ). > > + in_illuminance_y_raw is a measure of the brightness, and is > > + identical in_illuminance_raw. > > That is fair enough. > > > + in_illuminance_x_raw and in_illuminance_z_raw carry chromacity > > + information. > > + in_illuminance_x,y,z_raw are be obtained from the sensor color > > + channels using color matching functions that may be device > > + specific. > > + Units after application of scale and offset are lux. > > True for Y, not for X and Z which don't have 'units' as such. Indeed,I have difficulty mapping what comes from the sensor after adapting to an acceptable universal entity. The goal of the sensor is to measure the ambient correlated color temperature (CCT), based on the x and y of the CIE xyY color space. Given x and y are defined as x = X / (X + Y +Z) and y = X / (X + Y + Z), X, Y and Z must have the same units. CCT(x,y) is computed in user space, for example using this approximation (https://en.wikipedia.org/wiki/Color_temperature#Approximation). Gwendal. > > > + The measurments can be used to represent colors in the CIE > > + xyY color space > > XYZ > > > + > > What:/sys/.../iio:deviceX/in_intensityY_raw > > What:/sys/.../iio:deviceX/in_intensityY_ir_raw > > What:/sys/.../iio:deviceX/in_intensityY_both_raw > >
[PATCH 0/2] Let pci_fixup_final access iommu_fwnode
Some platform devices appear as PCI but are
actually on the AMBA bus, and they need fixup in
drivers/pci/quirks.c handling iommu_fwnode.
So calling pci_fixup_final after iommu_fwnode is allocated.
For example:
Hisilicon platform device need fixup in
drivers/pci/quirks.c
+static void quirk_huawei_pcie_sva(struct pci_dev *pdev)
+{
+ struct iommu_fwspec *fwspec;
+
+ pdev->eetlp_prefix_path = 1;
+ fwspec = dev_iommu_fwspec_get(>dev);
+ if (fwspec)
+ fwspec->can_stall = 1;
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0xa250, quirk_huawei_pcie_sva);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0xa251, quirk_huawei_pcie_sva);
Zhangfei Gao (2):
iommu/of: Let pci_fixup_final access iommu_fwnode
ACPI/IORT: Let pci_fixup_final access iommu_fwnode
drivers/acpi/arm64/iort.c | 1 +
drivers/iommu/of_iommu.c | 1 +
2 files changed, 2 insertions(+)
--
2.7.4
Re: [PATCH v5 1/7] fpga: dfl: parse interrupt info for feature devices on enumeration
On Mon, Apr 20, 2020 at 04:11:37PM +0800, Xu Yilun wrote:
> DFL based FPGA devices could support interrupts for different purposes,
> but current DFL framework only supports feature device enumeration with
> given MMIO resources information via common DFL headers. This patch
> introduces one new API dfl_fpga_enum_info_add_irq for low level bus
> drivers (e.g. PCIe device driver) to pass its interrupt resources
> information to DFL framework for enumeration, and also adds interrupt
> enumeration code in framework to parse and assign interrupt resources
> for enumerated feature devices and their own sub features.
>
> With this patch, DFL framework enumerates interrupt resources for core
> features, including PORT Error Reporting, FME (FPGA Management Engine)
> Error Reporting and also AFU User Interrupts.
>
> Signed-off-by: Luwei Kang
> Signed-off-by: Wu Hao
> Signed-off-by: Xu Yilun
> Acked-by: Wu Hao
>
> v2: early validating irq table for each feature in parse_feature_irq().
> Some code improvement and minor fix for Hao's comments.
> v3: put parse_feature_irqs() inside create_feature_instance()
> some minor fixes and more comments
> v4: no need to include asm/irq.h.
> fail the dfl enumeration when irq parsing error happens.
> v5: Some minor fix for Hao's comments
> ---
> drivers/fpga/dfl.c | 154
> +
> drivers/fpga/dfl.h | 40 ++
> 2 files changed, 194 insertions(+)
>
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index 9909948..b49fbed 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -421,6 +421,9 @@ EXPORT_SYMBOL_GPL(dfl_fpga_dev_ops_unregister);
> *
> * @dev: device to enumerate.
> * @cdev: the container device for all feature devices.
> + * @nr_irqs: number of irqs for all feature devices.
> + * @irq_table: Linux IRQ numbers for all irqs, indexed by local irq index of
> + * this device.
> * @feature_dev: current feature device.
> * @ioaddr: header register region address of feature device in enumeration.
> * @sub_features: a sub features linked list for feature device in
> enumeration.
> @@ -429,6 +432,9 @@ EXPORT_SYMBOL_GPL(dfl_fpga_dev_ops_unregister);
> struct build_feature_devs_info {
> struct device *dev;
> struct dfl_fpga_cdev *cdev;
> + unsigned int nr_irqs;
> + int *irq_table;
> +
> struct platform_device *feature_dev;
> void __iomem *ioaddr;
> struct list_head sub_features;
> @@ -442,12 +448,16 @@ struct build_feature_devs_info {
> * @mmio_res: mmio resource of this sub feature.
> * @ioaddr: mapped base address of mmio resource.
> * @node: node in sub_features linked list.
> + * @irq_base: start of irq index in this sub feature.
> + * @nr_irqs: number of irqs of this sub feature.
> */
> struct dfl_feature_info {
> u64 fid;
> struct resource mmio_res;
> void __iomem *ioaddr;
> struct list_head node;
> + unsigned int irq_base;
> + unsigned int nr_irqs;
> };
>
> static void dfl_fpga_cdev_add_port_dev(struct dfl_fpga_cdev *cdev,
> @@ -520,6 +530,8 @@ static int build_info_commit_dev(struct
> build_feature_devs_info *binfo)
> /* fill features and resource information for feature dev */
> list_for_each_entry_safe(finfo, p, >sub_features, node) {
> struct dfl_feature *feature = >features[index];
> + struct dfl_feature_irq_ctx *ctx;
> + unsigned int i;
>
> /* save resource information for each feature */
> feature->id = finfo->fid;
> @@ -527,6 +539,20 @@ static int build_info_commit_dev(struct
> build_feature_devs_info *binfo)
> feature->ioaddr = finfo->ioaddr;
> fdev->resource[index++] = finfo->mmio_res;
>
> + if (finfo->nr_irqs) {
> + ctx = devm_kcalloc(binfo->dev, finfo->nr_irqs,
> +sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + for (i = 0; i < finfo->nr_irqs; i++)
> + ctx[i].irq =
> + binfo->irq_table[finfo->irq_base + i];
> +
> + feature->irq_ctx = ctx;
> + feature->nr_irqs = finfo->nr_irqs;
> + }
> +
> list_del(>node);
> kfree(finfo);
> }
> @@ -638,6 +664,79 @@ static u64 feature_id(void __iomem *start)
> return 0;
> }
>
> +static int parse_feature_irqs(struct build_feature_devs_info *binfo,
> + resource_size_t ofst, u64 fid,
> + unsigned int *irq_base, unsigned int *nr_irqs)
> +{
> + void __iomem *base = binfo->ioaddr + ofst;
> + unsigned int i, ibase, inr = 0;
> + int virq;
> + u64 v;
> +
> + /*
> + * Ideally DFL framework should only read info from DFL header, but
> +
[PATCH 1/2] iommu/of: Let pci_fixup_final access iommu_fwnode
Calling pci_fixup_final after of_pci_iommu_init, which alloc
iommu_fwnode. Some platform devices appear as PCI but are
actually on the AMBA bus, and they need fixup in
drivers/pci/quirks.c handling iommu_fwnode.
So calling pci_fixup_final after iommu_fwnode is allocated.
Signed-off-by: Zhangfei Gao
---
drivers/iommu/of_iommu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 20738aac..c1b58c4 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -188,6 +188,7 @@ const struct iommu_ops *of_iommu_configure(struct device
*dev,
pci_request_acs();
err = pci_for_each_dma_alias(to_pci_dev(dev),
of_pci_iommu_init, );
+ pci_fixup_device(pci_fixup_final, to_pci_dev(dev));
} else if (dev_is_fsl_mc(dev)) {
err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
--
2.7.4
[PATCH 2/2] ACPI/IORT: Let pci_fixup_final access iommu_fwnode
Calling pci_fixup_final after iommu_fwspec_init, which alloc iommu_fwnode. Some platform devices appear as PCI but are actually on the AMBA bus, and they need fixup in drivers/pci/quirks.c handling iommu_fwnode. So calling pci_fixup_final after iommu_fwnode is allocated. Signed-off-by: Zhangfei Gao --- drivers/acpi/arm64/iort.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c index 7d04424..02e361d 100644 --- a/drivers/acpi/arm64/iort.c +++ b/drivers/acpi/arm64/iort.c @@ -1027,6 +1027,7 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev) info.node = node; err = pci_for_each_dma_alias(to_pci_dev(dev), iort_pci_iommu_init, ); + pci_fixup_device(pci_fixup_final, to_pci_dev(dev)); fwspec = dev_iommu_fwspec_get(dev); if (fwspec && iort_pci_rc_supports_ats(node)) -- 2.7.4
linux-next: build failure after merge of the nand tree
Hi all,
After merging the nand tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/mtd/nand/raw/stm32_fmc2_nand.c: In function 'stm32_fmc2_nfc_write_data':
drivers/mtd/nand/raw/stm32_fmc2_nand.c:1294:34: error: 'fmc2' undeclared (first
use in this function)
1294 | stm32_fmc2_nfc_set_buswidth_16(fmc2, true);
| ^~~~
drivers/mtd/nand/raw/stm32_fmc2_nand.c:1294:34: note: each undeclared
identifier is reported only once for each function it appears in
Caused by commit
6c1c863ca431 ("mtd: rawnand: stm32_fmc2: cleanup")
I have used the nand tree from next-20200511 for today.
--
Cheers,
Stephen Rothwell
pgpwE61_QRSpf.pgp
Description: OpenPGP digital signature
Quotation request to linux-kernel@vger.kernel.org
Hello Sir/Madame Good day. I am Rob Turner, Head of Procurement. Our marketing unit requested your products Models after coming across your Trade fair catalog last year and Webpage on registered trade site, we are interested to Purchase your products and its accessories as requested by our customers here in UK Market and Europe, Please send us your Updated product catalog. Please if you know your company will be able to handle extra purchase this year as we have good business experience. Once we confirm your competitive Price List of your product and company Terms, we will place Market order immediately with our company certificate and experience in business. Send your reply to robturner-purch...@exporttogroup.co for us to be able to treat with care and urgent. Regards Rob Turner Head of Procurement Operations robturner-purch...@exporttogroup.co www.exporttogroup.co REGISTERED OFFICE 171 VICTORIA STREET, LONDON SW1E 5NN COMPANY REGISTRATION NUMBER 233462 VAT NO. GB232457280 This e-mail may contain confidential and/or privileged information.If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden Este e-mail pode conter informações confidenciais e / ou privilegiadas. Se você não for o destinatário pretendido (ou tiver recebido este e-mail por engano), notifique o remetente imediatamente e destrua este e-mail. Qualquer cópia, divulgação ou distribuição não autorizada do material neste e-mail é estritamente proibida. Before printing think about your responsibility for the ENVIRONMENT
Re: [PATCH v8 01/11] pstore/zone: Introduce common layer to manage storage zones
hi Kees Cook,
On 2020/5/12 AM 7:32, Kees Cook wrote:
> From: WeiXiong Liao
>
> Implement a common set of APIs needed to support pstore storage zones,
> based on how ramoops is designed. This will be used by pstore/blk with
> the intention of migrating pstore/ram in the future.
>
> Signed-off-by: WeiXiong Liao
> Link:
> https://lore.kernel.org/r/1585126506-18635-2-git-send-email-liaoweixi...@allwinnertech.com
> Co-developed-by: Kees Cook
> Signed-off-by: Kees Cook
> ---
> fs/pstore/Kconfig | 7 +
> fs/pstore/Makefile | 3 +
> fs/pstore/zone.c| 987
> include/linux/pstore_zone.h | 44 ++
> 4 files changed, 1041 insertions(+)
> create mode 100644 fs/pstore/zone.c
> create mode 100644 include/linux/pstore_zone.h
>
> diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
> index 8f0369aad22a..98d2457bdd9f 100644
> --- a/fs/pstore/Kconfig
> +++ b/fs/pstore/Kconfig
> @@ -153,3 +153,10 @@ config PSTORE_RAM
> "ramoops.ko".
>
> For more information, see Documentation/admin-guide/ramoops.rst.
> +
> +config PSTORE_ZONE
> + tristate
> + depends on PSTORE
> + help
> + The common layer for pstore/blk (and pstore/ram in the future)
> + to manage storage in zones.
> diff --git a/fs/pstore/Makefile b/fs/pstore/Makefile
> index 967b5891f325..58a967cbe4af 100644
> --- a/fs/pstore/Makefile
> +++ b/fs/pstore/Makefile
> @@ -12,3 +12,6 @@ pstore-$(CONFIG_PSTORE_PMSG)+= pmsg.o
>
> ramoops-objs += ram.o ram_core.o
> obj-$(CONFIG_PSTORE_RAM) += ramoops.o
> +
> +pstore_zone-objs += zone.o
> +obj-$(CONFIG_PSTORE_ZONE)+= pstore_zone.o
> diff --git a/fs/pstore/zone.c b/fs/pstore/zone.c
> new file mode 100644
> index ..20fa52385c78
> --- /dev/null
> +++ b/fs/pstore/zone.c
> @@ -0,0 +1,987 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Provide a pstore intermediate backend, organized into kernel memory
> + * allocated zones that are then mapped and flushed into a single
> + * contiguous region on a storage backend of some kind (block, mtd, etc).
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "internal.h"
> +
> +/**
> + * struct psz_head - header of zone to flush to storage
> + *
> + * @sig: signature to indicate header (PSZ_SIG xor PSZONE-type value)
> + * @datalen: length of data in @data
> + * @data: zone data.
> + */
> +struct psz_buffer {
> +#define PSZ_SIG (0x43474244) /* DBGC */
> + uint32_t sig;
> + atomic_t datalen;
> + uint8_t data[];
> +};
> +
> +/**
> + * struct psz_kmsg_header - kmsg dump-specific header to flush to storage
> + *
> + * @magic: magic num for kmsg dump header
> + * @time: kmsg dump trigger time
> + * @compressed: whether conpressed
> + * @counter: kmsg dump counter
> + * @reason: the kmsg dump reason (e.g. oops, panic, etc)
> + * @data: pointer to log data
> + *
> + * This is a sub-header for a kmsg dump, trailing after _buffer.
> + */
> +struct psz_kmsg_header {
> +#define PSTORE_KMSG_HEADER_MAGIC 0x4dfc3ae5 /* Just a random number */
> + uint32_t magic;
> + struct timespec64 time;
> + bool compressed;
> + uint32_t counter;
> + enum kmsg_dump_reason reason;
> + uint8_t data[];
> +};
> +
> +/**
> + * struct pstore_zone - single stored buffer
> + *
> + * @off: zone offset of storage
> + * @type: front-end type for this zone
> + * @name: front-end name for this zone
> + * @buffer: pointer to data buffer managed by this zone
> + * @oldbuf: pointer to old data buffer
> + * @buffer_size: bytes in @buffer->data
> + * @should_recover: whether this zone should recover from storage
> + * @dirty: whether the data in @buffer dirty
> + *
> + * zone structure in memory.
> + */
> +struct pstore_zone {
> + loff_t off;
> + const char *name;
> + enum pstore_type_id type;
> +
> + struct psz_buffer *buffer;
> + struct psz_buffer *oldbuf;
> + size_t buffer_size;
> + bool should_recover;
> + atomic_t dirty;
> +};
> +
> +/**
> + * struct psz_context - all about running state of pstore/zone
> + *
> + * @kpszs: kmsg dump storage zones
> + * @kmsg_max_cnt: max count of @kpszs
> + * @kmsg_read_cnt: counter of total read kmsg dumps
> + * @kmsg_write_cnt: counter of total kmsg dump writes
> + * @oops_counter: counter of oops dumps
> + * @panic_counter: counter of panic dumps
> + * @recovered: whether finished recovering data from storage
> + * @on_panic: whether panic is happening
> + * @pstore_zone_info_lock: lock to @pstore_zone_info
> + * @pstore_zone_info: information from backend
> + * @pstore: structure for pstore
> + */
> +struct psz_context {
> + struct pstore_zone **kpszs;
> + unsigned int kmsg_max_cnt;
> + unsigned int kmsg_read_cnt;
> + unsigned int kmsg_write_cnt;
> + /*
> + * These
[PATCH] btrfs: Remove duplicated include in block-group.c
disk-io.h is included more than once in block-group.c, remove it. Signed-off-by: Tiezhu Yang --- fs/btrfs/block-group.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index 696f471..d3d5cf4 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -7,7 +7,6 @@ #include "disk-io.h" #include "free-space-cache.h" #include "free-space-tree.h" -#include "disk-io.h" #include "volumes.h" #include "transaction.h" #include "ref-verify.h" -- 2.1.0
Re: [PATCH v3 1/1] ppc/crash: Reset spinlocks during crash
Hello Paul, thanks for the reply! On Thu, 2020-04-09 at 10:27 +1000, Paul Mackerras wrote: > On Wed, Apr 08, 2020 at 10:21:29PM +1000, Michael Ellerman wrote: > > We should be able to just allocate the rtas_args on the stack, it's only > > ~80 odd bytes. And then we can use rtas_call_unlocked() which doesn't > > take the global lock. > > Do we instantiate a 64-bit RTAS these days, or is it still 32-bit? According to LoPAR, we can use instantiate-rtas or instantiate-rtas-64. It looks like we do instantiate-rtas today (grep pointed only to prom_instantiate_rtas()). > In the old days we had to make sure the RTAS argument buffer was > below the 4GB point. If that's still necessary then perhaps putting > rtas_args inside the PACA would be the way to go. Yes, we still need to make sure of this. I will study more about PACA and try to implement that way. Best regards, Leonardo Bras signature.asc Description: This is a digitally signed message part
Re: [PATCH] fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info()
On Tue, May 12, 2020 at 02:09:01AM +0100, Al Viro wrote:
> On Tue, Apr 21, 2020 at 10:14:25AM +0200, Alexander Potapenko wrote:
> > > Not lately and I would also like to hear the details; which regset it is?
> > > Should be reasonably easy to find - just memset() the damn thing to
> > > something
> > > recognizable, do whatever triggers that KMSAN report and look at that
> > > resulting coredump.
> >
> > The bug is easily triggerable by the following program:
> >
> >
> > int main() {
> > volatile char *c = 0;
> > (void)*c;
> > return 0;
> > }
> >
> >
> > in my QEMU after I do `ulimit -c 1`.
>
> .config, please - I hadn't been able to reproduce that on mine.
> Coredump obviously does happen, but not a trace of the poison
> is there - with your memset(data, 0xae, size) added, that is.
Actually, more interesting question would be your /proc/cpuinfo...
Re: [PATCH v2 net-next 15/15] docs: net: dsa: sja1105: document the best_effort_vlan_filtering option
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Vladimir Oltean > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v2 net-next 14/15] net: dsa: sja1105: implement VLAN retagging for dsa_8021q sub-VLANs
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Vladimir Oltean > > Expand the delta commit procedure for VLANs with additional logic for > treating bridge_vlans in the newly introduced operating mode, > SJA1105_VLAN_BEST_EFFORT. > > For every bridge VLAN on every user port, a sub-VLAN index is calculated > and retagging rules are installed towards a dsa_8021q rx_vid that > encodes that sub-VLAN index. This way, the tagger can identify the > original VLANs. > > Extra care is taken for VLANs to still work as intended in cross-chip > scenarios. Retagging may have unintended consequences for these because > a sub-VLAN encoding that works for the CPU does not make any sense for a > front-panel port. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH] ifcvf: move IRQ request/free to status change handlers
On 2020/5/11 下午6:18, Francesco Lavra wrote:
On 5/11/20 11:26 AM, Jason Wang wrote:
On 2020/5/11 下午3:19, Zhu Lingshan wrote:
This commit move IRQ request and free operations from probe()
to VIRTIO status change handler to comply with VIRTIO spec.
VIRTIO spec 1.1, section 2.1.2 Device Requirements: Device Status Field
The device MUST NOT consume buffers or send any used buffer
notifications to the driver before DRIVER_OK.
My previous explanation might be wrong here. It depends on how you
implement your hardware, if you hardware guarantee that no interrupt
will be triggered before DRIVER_OK, then it's fine.
And the main goal for this patch is to allocate the interrupt on demand.
Signed-off-by: Zhu Lingshan
---
drivers/vdpa/ifcvf/ifcvf_main.c | 119
1 file changed, 73 insertions(+), 46 deletions(-)
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c
b/drivers/vdpa/ifcvf/ifcvf_main.c
index abf6a061..4d58bf2 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -28,6 +28,60 @@ static irqreturn_t ifcvf_intr_handler(int irq,
void *arg)
return IRQ_HANDLED;
}
+static void ifcvf_free_irq_vectors(void *data)
+{
+ pci_free_irq_vectors(data);
+}
+
+static void ifcvf_free_irq(struct ifcvf_adapter *adapter, int queues)
+{
+ struct pci_dev *pdev = adapter->pdev;
+ struct ifcvf_hw *vf = >vf;
+ int i;
+
+
+ for (i = 0; i < queues; i++)
+ devm_free_irq(>dev, vf->vring[i].irq, >vring[i]);
+
+ ifcvf_free_irq_vectors(pdev);
+}
+
+static int ifcvf_request_irq(struct ifcvf_adapter *adapter)
+{
+ struct pci_dev *pdev = adapter->pdev;
+ struct ifcvf_hw *vf = >vf;
+ int vector, i, ret, irq;
+
+ ret = pci_alloc_irq_vectors(pdev, IFCVF_MAX_INTR,
+ IFCVF_MAX_INTR, PCI_IRQ_MSIX);
+ if (ret < 0) {
+ IFCVF_ERR(pdev, "Failed to alloc IRQ vectors\n");
+ return ret;
+ }
+
+ for (i = 0; i < IFCVF_MAX_QUEUE_PAIRS * 2; i++) {
+ snprintf(vf->vring[i].msix_name, 256, "ifcvf[%s]-%d\n",
+ pci_name(pdev), i);
+ vector = i + IFCVF_MSI_QUEUE_OFF;
+ irq = pci_irq_vector(pdev, vector);
+ ret = devm_request_irq(>dev, irq,
+ ifcvf_intr_handler, 0,
+ vf->vring[i].msix_name,
+ >vring[i]);
+ if (ret) {
+ IFCVF_ERR(pdev,
+ "Failed to request irq for vq %d\n", i);
+ ifcvf_free_irq(adapter, i);
I'm not sure this unwind is correct. It looks like we should loop and
call devm_free_irq() for virtqueue [0, i);
That's exactly what the code does: ifcvf_free_irq() contains a (i = 0;
i < queues; i++) loop, and here the function is called with the
`queues` argument set to `i`.
Oh right.
Thanks
Re: [PATCH v2 net-next 13/15] net: dsa: sja1105: implement a common frame memory partitioning function
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Vladimir Oltean > > There are 2 different features that require some reserved frame memory > space: VLAN retagging and virtual links. Create a central function that > modifies the static config and ensures frame memory is never > overcommitted. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v2 net-next 12/15] net: dsa: sja1105: add packing ops for the Retagging Table
On 5/11/2020 6:53 AM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The Retagging Table is an optional feature that allows the switch to
> match frames against a {ingress port, egress port, vid} rule and change
> their VLAN ID. The retagged frames are by default clones of the original
> ones (since the hardware-foreseen use case was to mirror traffic for
> debugging purposes and to tag it with a special VLAN for this purpose),
> but we can force the original frames to be dropped by removing the
> pre-retagging VLAN from the port membership list of the egress port.
>
> Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
--
Florian
Re: [PATCH v2 1/3] rcu/kasan: record and print call_rcu() call stack
On Mon, 2020-05-11 at 16:19 +0200, Dmitry Vyukov wrote:
> On Mon, May 11, 2020 at 3:29 PM Walter Wu wrote:
> > > > This feature will record first and last call_rcu() call stack and
> > > > print two call_rcu() call stack in KASAN report.
> > > >
> > > > When call_rcu() is called, we store the call_rcu() call stack into
> > > > slub alloc meta-data, so that KASAN report can print rcu stack.
> > > >
> > > > It doesn't increase the cost of memory consumption. Because we don't
> > > > enlarge struct kasan_alloc_meta size.
> > > > - add two call_rcu() call stack into kasan_alloc_meta, size is 8 bytes.
> > > > - remove free track from kasan_alloc_meta, size is 8 bytes.
> > > >
> > > > [1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
> > > > [2]https://groups.google.com/forum/#!searchin/kasan-dev/better$20stack$20traces$20for$20rcu%7Csort:date/kasan-dev/KQsjT_88hDE/7rNUZprRBgAJ
> > > >
> > > > Signed-off-by: Walter Wu
> > > > Suggested-by: Dmitry Vyukov
> > > > Cc: Andrey Ryabinin
> > > > Cc: Dmitry Vyukov
> > > > Cc: Alexander Potapenko
> > > > Cc: Andrew Morton
> > > > Cc: Paul E. McKenney
> > > > Cc: Josh Triplett
> > > > Cc: Mathieu Desnoyers
> > > > Cc: Lai Jiangshan
> > > > Cc: Joel Fernandes
> > > > ---
> > > > include/linux/kasan.h | 2 ++
> > > > kernel/rcu/tree.c | 3 +++
> > > > lib/Kconfig.kasan | 2 ++
> > > > mm/kasan/common.c | 4 ++--
> > > > mm/kasan/generic.c| 29 +
> > > > mm/kasan/kasan.h | 19 +++
> > > > mm/kasan/report.c | 21 +
> > > > 7 files changed, 74 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> > > > index 31314ca7c635..23b7ee00572d 100644
> > > > --- a/include/linux/kasan.h
> > > > +++ b/include/linux/kasan.h
> > > > @@ -174,11 +174,13 @@ static inline size_t kasan_metadata_size(struct
> > > > kmem_cache *cache) { return 0; }
> > > >
> > > > void kasan_cache_shrink(struct kmem_cache *cache);
> > > > void kasan_cache_shutdown(struct kmem_cache *cache);
> > > > +void kasan_record_aux_stack(void *ptr);
> > > >
> > > > #else /* CONFIG_KASAN_GENERIC */
> > > >
> > > > static inline void kasan_cache_shrink(struct kmem_cache *cache) {}
> > > > static inline void kasan_cache_shutdown(struct kmem_cache *cache) {}
> > > > +static inline void kasan_record_aux_stack(void *ptr) {}
> > > >
> > > > #endif /* CONFIG_KASAN_GENERIC */
> > > >
> > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > > index 06548e2ebb72..de872b6cc261 100644
> > > > --- a/kernel/rcu/tree.c
> > > > +++ b/kernel/rcu/tree.c
> > > > @@ -57,6 +57,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include "../time/tick-internal.h"
> > > >
> > > > #include "tree.h"
> > > > @@ -2694,6 +2695,8 @@ __call_rcu(struct rcu_head *head, rcu_callback_t
> > > > func)
> > > > trace_rcu_callback(rcu_state.name, head,
> > > >rcu_segcblist_n_cbs(>cblist));
> > > >
> > > > + kasan_record_aux_stack(head);
> > > > +
> > > > /* Go handle any RCU core processing required. */
> > > > if (IS_ENABLED(CONFIG_RCU_NOCB_CPU) &&
> > > > unlikely(rcu_segcblist_is_offloaded(>cblist))) {
> > > > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> > > > index 81f5464ea9e1..56a89291f1cc 100644
> > > > --- a/lib/Kconfig.kasan
> > > > +++ b/lib/Kconfig.kasan
> > > > @@ -58,6 +58,8 @@ config KASAN_GENERIC
> > > > For better error detection enable CONFIG_STACKTRACE.
> > > > Currently CONFIG_KASAN_GENERIC doesn't work with
> > > > CONFIG_DEBUG_SLAB
> > > > (the resulting kernel does not boot).
> > > > + Currently CONFIG_KASAN_GENERIC will print first and last
> > > > call_rcu()
> > > > + call stack. It doesn't increase the cost of memory
> > > > consumption.
> > > >
> > > > config KASAN_SW_TAGS
> > > > bool "Software tag-based mode"
> > > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > > > index 2906358e42f0..8bc618289bb1 100644
> > > > --- a/mm/kasan/common.c
> > > > +++ b/mm/kasan/common.c
> > > > @@ -41,7 +41,7 @@
> > > > #include "kasan.h"
> > > > #include "../slab.h"
> > > >
> > > > -static inline depot_stack_handle_t save_stack(gfp_t flags)
> > > > +depot_stack_handle_t kasan_save_stack(gfp_t flags)
> > > > {
> > > > unsigned long entries[KASAN_STACK_DEPTH];
> > > > unsigned int nr_entries;
> > > > @@ -54,7 +54,7 @@ static inline depot_stack_handle_t save_stack(gfp_t
> > > > flags)
> > > > static inline void set_track(struct kasan_track *track, gfp_t flags)
> > > > {
> > > > track->pid = current->pid;
> > > > - track->stack = save_stack(flags);
> > > > + track->stack = kasan_save_stack(flags);
> > > > }
> > > >
> > > > void kasan_enable_current(void)
> > > > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > > > index
Re: [PATCH] ifcvf: move IRQ request/free to status change handlers
On 2020/5/11 下午6:11, Zhu, Lingshan wrote:
On 5/11/2020 5:26 PM, Jason Wang wrote:
On 2020/5/11 下午3:19, Zhu Lingshan wrote:
This commit move IRQ request and free operations from probe()
to VIRTIO status change handler to comply with VIRTIO spec.
VIRTIO spec 1.1, section 2.1.2 Device Requirements: Device Status Field
The device MUST NOT consume buffers or send any used buffer
notifications to the driver before DRIVER_OK.
My previous explanation might be wrong here. It depends on how you
implement your hardware, if you hardware guarantee that no interrupt
will be triggered before DRIVER_OK, then it's fine.
And the main goal for this patch is to allocate the interrupt on demand.
Hi Jason,
So these code can a double assurance.
Signed-off-by: Zhu Lingshan
---
drivers/vdpa/ifcvf/ifcvf_main.c | 119
1 file changed, 73 insertions(+), 46 deletions(-)
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c
b/drivers/vdpa/ifcvf/ifcvf_main.c
index abf6a061..4d58bf2 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -28,6 +28,60 @@ static irqreturn_t ifcvf_intr_handler(int irq,
void *arg)
return IRQ_HANDLED;
}
+static void ifcvf_free_irq_vectors(void *data)
+{
+ pci_free_irq_vectors(data);
+}
+
+static void ifcvf_free_irq(struct ifcvf_adapter *adapter, int queues)
+{
+ struct pci_dev *pdev = adapter->pdev;
+ struct ifcvf_hw *vf = >vf;
+ int i;
+
+
+ for (i = 0; i < queues; i++)
+ devm_free_irq(>dev, vf->vring[i].irq, >vring[i]);
+
+ ifcvf_free_irq_vectors(pdev);
+}
+
+static int ifcvf_request_irq(struct ifcvf_adapter *adapter)
+{
+ struct pci_dev *pdev = adapter->pdev;
+ struct ifcvf_hw *vf = >vf;
+ int vector, i, ret, irq;
+
+ ret = pci_alloc_irq_vectors(pdev, IFCVF_MAX_INTR,
+ IFCVF_MAX_INTR, PCI_IRQ_MSIX);
+ if (ret < 0) {
+ IFCVF_ERR(pdev, "Failed to alloc IRQ vectors\n");
+ return ret;
+ }
+
+ for (i = 0; i < IFCVF_MAX_QUEUE_PAIRS * 2; i++) {
+ snprintf(vf->vring[i].msix_name, 256, "ifcvf[%s]-%d\n",
+ pci_name(pdev), i);
+ vector = i + IFCVF_MSI_QUEUE_OFF;
+ irq = pci_irq_vector(pdev, vector);
+ ret = devm_request_irq(>dev, irq,
+ ifcvf_intr_handler, 0,
+ vf->vring[i].msix_name,
+ >vring[i]);
+ if (ret) {
+ IFCVF_ERR(pdev,
+ "Failed to request irq for vq %d\n", i);
+ ifcvf_free_irq(adapter, i);
I'm not sure this unwind is correct. It looks like we should loop and
call devm_free_irq() for virtqueue [0, i);
we have the loop in ifcvf_free_irq(struct ifcvf_adapter *adapter, int queues),
it takes a parameter queues, and a loop
+ for (i = 0; i < queues; i++)+ devm_free_irq(>dev,
vf->vring[i].irq, >vring[i]); will free irq for vq[0,queues)
Aha, I get this.
+
+ return ret;
+ }
+
+ vf->vring[i].irq = irq;
+ }
+
+ return 0;
+}
+
static int ifcvf_start_datapath(void *private)
{
struct ifcvf_hw *vf = ifcvf_private_to_vf(private);
@@ -118,9 +172,12 @@ static void ifcvf_vdpa_set_status(struct
vdpa_device *vdpa_dev, u8 status)
{
struct ifcvf_adapter *adapter;
struct ifcvf_hw *vf;
+ u8 status_old;
+ int ret;
vf = vdpa_to_vf(vdpa_dev);
adapter = dev_get_drvdata(vdpa_dev->dev.parent);
+ status_old = ifcvf_get_status(vf);
if (status == 0) {
ifcvf_stop_datapath(adapter);
@@ -128,7 +185,22 @@ static void ifcvf_vdpa_set_status(struct
vdpa_device *vdpa_dev, u8 status)
return;
}
- if (status & VIRTIO_CONFIG_S_DRIVER_OK) {
+ if ((status_old & VIRTIO_CONFIG_S_DRIVER_OK) &&
+ !(status & VIRTIO_CONFIG_S_DRIVER_OK)) {
+ ifcvf_stop_datapath(adapter);
+ ifcvf_free_irq(adapter, IFCVF_MAX_QUEUE_PAIRS * 2);
+ }
+
+ if ((status & VIRTIO_CONFIG_S_DRIVER_OK) &&
+ !(status_old & VIRTIO_CONFIG_S_DRIVER_OK)) {
+ ret = ifcvf_request_irq(adapter);
+ if (ret) {
+ status = ifcvf_get_status(vf);
+ status |= VIRTIO_CONFIG_S_FAILED;
+ ifcvf_set_status(vf, status);
+ return;
+ }
+
Have a hard though on the logic here.
This depends on the status setting from guest or userspace. Which
means it can not deal with e.g when qemu or userspace is crashed? Do
we need to care this or it's a over engineering?
Thanks
If qemu crash, I guess users may re-run qmeu / re-initialize the device,
according to the spec, there should be a reset routine.
This code piece handles status change on DRIVER_OK flipping. I am not sure I
get your point, mind to give more hints?
The problem is if we don't launch new qemu instance, the interrupt will
be still there?
Thanks
Thanks,
BR
Zhu Lingshan
if (ifcvf_start_datapath(adapter) < 0)
IFCVF_ERR(adapter->pdev,
Re: [PATCH v2 net-next 11/15] net: dsa: sja1105: add a new best_effort_vlan_filtering devlink parameter
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Vladimir Oltean > > This devlink parameter enables the handling of DSA tags when enslaved to > a bridge with vlan_filtering=1. There are very good reasons to want > this, but there are also very good reasons for not enabling it by > default. So a devlink param named best_effort_vlan_filtering, currently > driver-specific and exported only by sja1105, is used to configure this. > > In practice, this is perhaps the way that most users are going to use > the switch in. It assumes that no more than 7 VLANs are needed per port. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v2 net-next 10/15] net: dsa: tag_sja1105: implement sub-VLAN decoding
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Vladimir Oltean > > Create a subvlan_map as part of each port's tagger private structure. > This keeps reverse mappings of bridge-to-dsa_8021q VLAN retagging rules. > > Note that as of this patch, this piece of code is never engaged, due to > the fact that the driver hasn't installed any retagging rule, so we'll > always see packets with a subvlan code of 0 (untagged). > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v2 net-next 09/15] net: dsa: tag_8021q: support up to 8 VLANs per port using sub-VLANs
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Vladimir Oltean > > For switches that support VLAN retagging, such as sja1105, we extend > dsa_8021q by encoding a "sub-VLAN" into the remaining 3 free bits in the > dsa_8021q tag. > > A sub-VLAN is nothing more than a number in the range 0-7, which serves > as an index into a per-port driver lookup table. The sub-VLAN value of > zero means that traffic is untagged (this is also backwards-compatible > with dsa_8021q without retagging). > > The switch should be configured to retag VLAN-tagged traffic that gets > transmitted towards the CPU port (and towards the CPU only). Example: > > bridge vlan add dev sw1p0 vid 100 > > The switch retags frames received on port 0, going to the CPU, and > having VID 100, to the VID of 1104 (0x0450). In dsa_8021q language: > > | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | > +---+-+-+---+---+ > |DIR| SVL |SWITCH_ID| SUBVLAN | PORT | > +---+-+-+---+---+ > > 0x0450 means: > - DIR = 0b01: this is an RX VLAN > - SUBVLAN = 0b001: this is subvlan #1 > - SWITCH_ID = 0b001: this is switch 1 (see the name "sw1p0") > - PORT = 0b: this is port 0 (see the name "sw1p0") > > The driver also remembers the "1 -> 100" mapping. In the hotpath, if the > sub-VLAN from the tag encodes a non-untagged frame, this mapping is used > to create a VLAN hwaccel tag, with the value of 100. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v2 net-next 08/15] net: dsa: sja1105: prepare tagger for handling DSA tags and VLAN simultaneously
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Vladimir Oltean > > In VLAN-unaware mode, sja1105 uses VLAN tags with a custom TPID of > 0xdadb. While in the yet-to-be introduced best_effort_vlan_filtering > mode, it needs to work with normal VLAN TPID values. > > A complication arises when we must transmit a VLAN-tagged packet to the > switch when it's in VLAN-aware mode. We need to construct a packet with > 2 VLAN tags, and the switch will use the outer header for routing and > pop it on egress. But sadly, here the 2 hardware generations don't > behave the same: > > - E/T switches won't pop an ETH_P_8021AD tag on egress, it seems > (packets will remain double-tagged). > - P/Q/R/S switches will drop a packet with 2 ETH_P_8021Q tags (it looks > like it tries to prevent VLAN hopping). > > But looks like the reverse is also true: > > - E/T switches have no problem popping the outer tag from packets with > 2 ETH_P_8021Q tags. > - P/Q/R/S will have no problem popping a single tag even if that is > ETH_P_8021AD. > > So it is clear that if we want the hardware to work with dsa_8021q > tagging in VLAN-aware mode, we need to send different TPIDs depending on > revision. Keep that information in priv->info->qinq_tpid. > > The per-port tagger structure will hold an xmit_tpid value that depends > not only upon the qinq_tpid, but also upon the VLAN awareness state > itself (in case we must transmit using 0xdadb). > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v2 net-next 07/15] net: dsa: sja1105: exit sja1105_vlan_filtering when called multiple times
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Vladimir Oltean > > VLAN filtering is a global property for sja1105, and that means that we > rely on the DSA core to not call us more than once. > > But we need to introduce some per-port state for the tagger, namely the > xmit_tpid, and the best place to do that is where the xmit_tpid changes, > namely in sja1105_vlan_filtering. So at the moment, exit early from the > function to avoid unnecessarily resetting the switch for each port call. > Then we'll change the xmit_tpid prior to the early exit in the next > patch. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH] scsi: lpfc: remove redundant initialization to variable rc
On Thu, 7 May 2020 21:31:11 +0100, Colin King wrote: > The variable rc is being initialized with a value that is never read > and it is being updated later with a new value. The initialization is > redundant and can be removed. Applied to 5.8/scsi-queue, thanks! [1/1] scsi: lpfc: Remove redundant initialization to variable rc https://git.kernel.org/mkp/scsi/c/6e27a86aed97 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v2 net-next 05/15] net: dsa: sja1105: save/restore VLANs using a delta commit method
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Vladimir Oltean > > Managing the VLAN table that is present in hardware will become very > difficult once we add a third operating state > (best_effort_vlan_filtering). That is because correct cleanup (not too > little, not too much) becomes virtually impossible, when VLANs can be > added from the bridge layer, from dsa_8021q for basic tagging, for > cross-chip bridging, as well as retagging rules for sub-VLANs and > cross-chip sub-VLANs. So we need to rethink VLAN interaction with the > switch in a more scalable way. > > In preparation for that, use the priv->expect_dsa_8021q boolean to > classify any VLAN request received through .port_vlan_add or > .port_vlan_del towards either one of 2 internal lists: bridge VLANs and > dsa_8021q VLANs. > > Then, implement a central sja1105_build_vlan_table method that creates a > VLAN configuration from scratch based on the 2 lists of VLANs kept by > the driver, and based on the VLAN awareness state. Currently, if we are > VLAN-unaware, install the dsa_8021q VLANs, otherwise the bridge VLANs. > > Then, implement a delta commit procedure that identifies which VLANs > from this new configuration are actually different from the config > previously committed to hardware. We apply the delta through the dynamic > configuration interface (we don't reset the switch). The result is that > the hardware should see the exact sequence of operations as before this > patch. > > This also helps remove the "br" argument passed to > dsa_8021q_crosschip_bridge_join, which it was only using to figure out > whether it should commit the configuration back to us or not, based on > the VLAN awareness state of the bridge. We can simplify that, by always > allowing those VLANs inside of our dsa_8021q_vlans list, and committing > those to hardware when necessary. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v8 0/8] scsi: ufs: support LU Dedicated buffer mode for WriteBooster
On Fri, 8 May 2020 16:01:07 +0800, Stanley Chu wrote: > This patchset adds LU dedicated buffer mode support for WriteBooster. > In the meanwhile, enable WriteBooster capability on MediaTek UFS platforms. > > v7 -> v8: > - In exported funtion ufshcd_fixup_dev_quirks(), add null checking for > parameter "fixups" (Avri Altman) > > v6 -> v7: > - Add device descriptor length check in ufshcd_wb_probe() back to prevent > out-of-boundary access in ufshcd_wb_probe() > - Fix the check of device descriptor length (Avri Altman) > - Provide a new ufs_fixup_device_setup() function to pack both device fixup > methods by general quirk table and vendor-specific way (Avri Altman) > > [...] Applied to 5.8/scsi-queue, thanks! [1/8] scsi: ufs: Enable WriteBooster on some pre-3.1 UFS devices https://git.kernel.org/mkp/scsi/c/817d7e140283 [2/8] scsi: ufs: Introduce fixup_dev_quirks vops https://git.kernel.org/mkp/scsi/c/c28c00ba4f06 [3/8] scsi: ufs: Export ufs_fixup_device_setup() function https://git.kernel.org/mkp/scsi/c/8db269a5102e [4/8] scsi: ufs-mediatek: Add fixup_dev_quirks vops https://git.kernel.org/mkp/scsi/c/62c2f503b54c [5/8] scsi: ufs: Add "index" in parameter list of ufshcd_query_flag() https://git.kernel.org/mkp/scsi/c/1f34eedf9bc1 [6/8] scsi: ufs: Add LU Dedicated buffer mode support for WriteBooster https://git.kernel.org/mkp/scsi/c/6f8d5a6a78cf [7/8] scsi: ufs-mediatek: Enable WriteBooster capability https://git.kernel.org/mkp/scsi/c/29060a629135 [8/8] scsi: ufs: Cleanup WriteBooster feature https://git.kernel.org/mkp/scsi/c/79e3520f82cb -- Martin K. Petersen Oracle Linux Engineering
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got conflicts in:
drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
drivers/net/ethernet/huawei/hinic/hinic_main.c
between commit:
e8a1b0efd632 ("hinic: fix a bug of ndo_stop")
from the net tree and commit:
7dd29ee12865 ("hinic: add sriov feature support")
from the net-next tree.
I fixed it up (I think, see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
index 992908e6eebf,eef855f11a01..
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
@@@ -358,12 -353,13 +358,16 @@@ int hinic_msg_to_mgmt(struct hinic_pf_t
return -EINVAL;
}
+ if (cmd == HINIC_PORT_CMD_SET_FUNC_STATE)
+ timeout = SET_FUNC_PORT_MGMT_TIMEOUT;
+
- return msg_to_mgmt_sync(pf_to_mgmt, mod, cmd, buf_in, in_size,
+ if (HINIC_IS_VF(hwif))
+ return hinic_mbox_to_pf(pf_to_mgmt->hwdev, mod, cmd, buf_in,
+ in_size, buf_out, out_size, 0);
+ else
+ return msg_to_mgmt_sync(pf_to_mgmt, mod, cmd, buf_in, in_size,
buf_out, out_size, MGMT_DIRECT_SEND,
- MSG_NOT_RESP);
+ MSG_NOT_RESP, timeout);
}
/**
diff --cc drivers/net/ethernet/huawei/hinic/hinic_main.c
index 63b92f6cc856,3d6569d7bac8..
--- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
@@@ -496,9 -501,23 +500,12 @@@ static int hinic_close(struct net_devic
up(_dev->mgmt_lock);
+ if (!HINIC_IS_VF(nic_dev->hwdev->hwif))
+ hinic_notify_all_vfs_link_changed(nic_dev->hwdev, 0);
+
- err = hinic_port_set_func_state(nic_dev, HINIC_FUNC_PORT_DISABLE);
- if (err) {
- netif_err(nic_dev, drv, netdev,
-"Failed to set func port state\n");
- nic_dev->flags |= (flags & HINIC_INTF_UP);
- return err;
- }
+ hinic_port_set_state(nic_dev, HINIC_PORT_DISABLE);
- err = hinic_port_set_state(nic_dev, HINIC_PORT_DISABLE);
- if (err) {
- netif_err(nic_dev, drv, netdev, "Failed to set port state\n");
- nic_dev->flags |= (flags & HINIC_INTF_UP);
- return err;
- }
+ hinic_port_set_func_state(nic_dev, HINIC_FUNC_PORT_DISABLE);
if (nic_dev->flags & HINIC_RSS_ENABLE) {
hinic_rss_deinit(nic_dev);
pgpLA0jUHIjqH.pgp
Description: OpenPGP digital signature
Re: [PATCH] scsi: qedi: remove unused variable udev & uctrl
On Tue, 5 May 2020 20:19:04 +0800, Xie XiuQi wrote:
> uctrl and udev are unused after commit 9632a6b4b747
> ("scsi: qedi: Move LL2 producer index processing in BH.")
>
> Remove them.
Applied to 5.8/scsi-queue, thanks!
[1/1] scsi: qedi: Remove unused variable udev & uctrl
https://git.kernel.org/mkp/scsi/c/f9491ed56e3a
--
Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: ufs: Replace zero-length array with flexible-array
On Thu, 7 May 2020 14:25:50 -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> [...]
Applied to 5.8/scsi-queue, thanks!
[1/1] scsi: ufs: Replace zero-length array with flexible-array
https://git.kernel.org/mkp/scsi/c/ec38c0adc0a1
--
Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: bfa: make bfad_iocmd_ioc_get_stats() static
On Tue, 5 May 2020 15:38:07 +0800, Jason Yan wrote: > Fix the following sparse warning: > > drivers/scsi/bfa/bfad_bsg.c:140:1: warning: symbol > 'bfad_iocmd_ioc_get_stats' was not declared. Should it be static? Applied to 5.8/scsi-queue, thanks! [1/1] scsi: bfa: Make bfad_iocmd_ioc_get_stats() static https://git.kernel.org/mkp/scsi/c/102026483d2b -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 3/3] soundwire: bus_type: add sdw_master_device support
On 11-05-20, 14:00, Pierre-Louis Bossart wrote: > > > + md = >md; > > > + md->dev.bus = _bus_type; > > > + md->dev.type = _master_type; > > > + md->dev.parent = parent; > > > + md->dev.of_node = parent->of_node; > > > + md->dev.fwnode = fwnode; > > > + md->dev.dma_mask = parent->dma_mask; > > > + > > > + dev_set_name(>dev, "sdw-master-%d", bus->link_id); > > > > This give nice sdw-master-0. In DT this comes from reg property. I dont > > seem to recall if the ACPI/Disco spec treats link_id as unique across > > the system, can you check that please, if not we would need to update > > this. > Table 3 in the Disco for Soundwire 1.0 spec: "all LinkID values are relative > to the immediate parent Device." > > There isn't any known implementation with more than one controller. But then it can come in "future" right. So lets try to make it future proof by not using the link_id (we can expose that as a sysfs if people want to know). So a global unique id needs to allocated (hint: idr or equivalent) and used as master_id Thanks -- ~Vinod
[PATCH v3] lib/flex_proportions.c: cleanup __fprop_inc_percpu_max
If the given type has fraction smaller than max_frac/FPROP_FRAC_BASE, the code could be modified to call __fprop_inc_percpu() directly and easier to understand. After this patch, fprop_reflect_period_percpu() will be called twice, and quicky return on pl->period == p->period test, so it would not result to significant downside of performance. Thanks for Jan's guidance. Signed-off-by: Tan Hu Reviewed-by: Jan Kara --- lib/flex_proportions.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/lib/flex_proportions.c b/lib/flex_proportions.c index 7852bfff5..451543937 100644 --- a/lib/flex_proportions.c +++ b/lib/flex_proportions.c @@ -266,8 +266,7 @@ void __fprop_inc_percpu_max(struct fprop_global *p, if (numerator > (((u64)denominator) * max_frac) >> FPROP_FRAC_SHIFT) return; - } else - fprop_reflect_period_percpu(p, pl); - percpu_counter_add_batch(>events, 1, PROP_BATCH); - percpu_counter_add(>events, 1); + } + + __fprop_inc_percpu(p, pl); } -- 2.19.1
Re: [PATCH] scsi: libsas: Replace zero-length array with flexible-array
On Thu, 7 May 2020 14:21:47 -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> [...]
Applied to 5.8/scsi-queue, thanks!
[1/1] scsi: libsas: Replace zero-length array with flexible-array
https://git.kernel.org/mkp/scsi/c/00b42b70ae52
--
Martin K. Petersen Oracle Linux Engineering
Re: [PATCH -next v2] scsi: aacraid: Use memdup_user() as a cleanup
On Sun, 26 Apr 2020 10:42:44 +0800, Zou Wei wrote: > Fix coccicheck warning which recommends to use memdup_user(). > > This patch fixes the following coccicheck warning: > > drivers/scsi/aacraid/commctrl.c:516:15-22: WARNING opportunity for memdup_user Applied to 5.8/scsi-queue, thanks! [1/1] scsi: aacraid: Use memdup_user() as a cleanup https://git.kernel.org/mkp/scsi/c/8d925b1f00e6 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH -next] scsi: mpt3sas: Remove unused including
On Fri, 8 May 2020 19:49:33 +0800, Samuel Zou wrote: > Fix the following versioncheck warning: > > drivers/scsi/mpt3sas/mpt3sas_debugfs.c:16:1: unused including > Applied to 5.8/scsi-queue, thanks! [1/1] scsi: mpt3sas: Remove unused including https://git.kernel.org/mkp/scsi/c/b59293b469b9 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v2 net-next 04/15] net: dsa: sja1105: deny alterations of dsa_8021q VLANs from the bridge
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Vladimir Oltean > > At the moment, this can never happen. The 2 modes that we operate in do > not permit that: > > - SJA1105_VLAN_UNAWARE: we are guarded from bridge VLANs added by the >user by the DSA core. We will later lift this restriction by setting >ds->vlan_bridge_vtu = true, and that is where we'll need it. > > - SJA1105_VLAN_FILTERING_FULL: in this mode, dsa_8021q configuration is >disabled. So the user is free to add these VLANs in the 1024-3071 >range. > > The reason for the patch is that we'll introduce a third VLAN awareness > state, where both dsa_8021q as well as the bridge are going to call our > .port_vlan_add and .port_vlan_del methods. > > For that, we need a good way to discriminate between the 2. The easiest > (and less intrusive way for upper layers) is to recognize the fact that > dsa_8021q configurations are always driven by our driver - we _know_ > when a .port_vlan_add method will be called from dsa_8021q because _we_ > initiated it. > > So introduce an expect_dsa_8021q boolean which is only used, at the > moment, for blacklisting VLANs in range 1024-3071 in the modes when > dsa_8021q is active.> > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v2 net-next 03/15] net: dsa: sja1105: keep the VLAN awareness state in a driver variable
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Vladimir Oltean > > Soon we'll add a third operating mode to the driver. Introduce a > vlan_state to make things more easy to manage, and use it where > applicable. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v2 net-next 06/15] net: dsa: sja1105: allow VLAN configuration from the bridge in all states
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Vladimir Oltean > > Let the DSA core call our .port_vlan_add methods every time the bridge > layer requests so. We will deal internally with saving/restoring VLANs > depending on our VLAN awareness state. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH V4] f2fs: Avoid double lock for cp_rwsem during checkpoint
On 05/12, Chao Yu wrote:
> On 2020/5/12 6:11, Jaegeuk Kim wrote:
> > On 05/11, Chao Yu wrote:
> >> On 2020/5/10 3:03, Jaegeuk Kim wrote:
> >>> On 05/09, Chao Yu wrote:
> On 2020/5/9 0:10, Jaegeuk Kim wrote:
> > Hi Sayali,
> >
> > In order to address the perf regression, how about this?
> >
> > >From 48418af635884803ffb35972df7958a2e6649322 Mon Sep 17 00:00:00 2001
> > From: Jaegeuk Kim
> > Date: Fri, 8 May 2020 09:08:37 -0700
> > Subject: [PATCH] f2fs: avoid double lock for cp_rwsem during checkpoint
> >
> > There could be a scenario where f2fs_sync_node_pages gets
> > called during checkpoint, which in turn tries to flush
> > inline data and calls iput(). This results in deadlock as
> > iput() tries to hold cp_rwsem, which is already held at the
> > beginning by checkpoint->block_operations().
> >
> > Call stack :
> >
> > Thread AThread B
> > f2fs_write_checkpoint()
> > - block_operations(sbi)
> > - f2fs_lock_all(sbi);
> > - down_write(>cp_rwsem);
> >
> > - open()
> > - igrab()
> > - write() write inline data
> > - unlink()
> > - f2fs_sync_node_pages()
> > - if (is_inline_node(page))
> > - flush_inline_data()
> >- ilookup()
> > page = f2fs_pagecache_get_page()
> > if (!page)
> > goto iput_out;
> > iput_out:
> > -close()
> > -iput()
> >iput(inode);
> >- f2fs_evict_inode()
> > - f2fs_truncate_blocks()
> > - f2fs_lock_op()
> >- down_read(>cp_rwsem);
> >
> > Fixes: 2049d4fcb057 ("f2fs: avoid multiple node page writes due to
> > inline_data")
> > Signed-off-by: Sayali Lokhande
> > Signed-off-by: Jaegeuk Kim
> > ---
> > fs/f2fs/node.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > index 1db8cabf727ef..626d7daca09de 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -1870,8 +1870,8 @@ int f2fs_sync_node_pages(struct f2fs_sb_info *sbi,
> > goto continue_unlock;
> > }
> >
> > - /* flush inline_data */
> > - if (is_inline_node(page)) {
> > + /* flush inline_data, if it's not sync path. */
> > + if (do_balance && is_inline_node(page)) {
>
> IIRC, this flow was designed to avoid running out of free space issue
> during checkpoint:
>
> 2049d4fcb057 ("f2fs: avoid multiple node page writes due to inline_data")
>
> The sceanrio is:
> 1. create fully node blocks
> 2. flush node blocks
> 3. write inline_data for all the node blocks again
> 4. flush node blocks redundantly
>
> I guess this may cause failing one case of fstest.
> >>>
> >>> Yeah, actually I was hitting 204 failure, and thus, revised like this.
> >>> Now, I don't see any regression in fstest.
> >>>
> >>> >From 8f1882acfb0a5fc43e5a2bbd576a8f3c681a7d2c Mon Sep 17 00:00:00 2001
> >>> From: Sayali Lokhande
> >>> Date: Thu, 30 Apr 2020 16:28:29 +0530
> >>> Subject: [PATCH] f2fs: Avoid double lock for cp_rwsem during checkpoint
> >>>
> >>> There could be a scenario where f2fs_sync_node_pages gets
> >>> called during checkpoint, which in turn tries to flush
> >>> inline data and calls iput(). This results in deadlock as
> >>> iput() tries to hold cp_rwsem, which is already held at the
> >>> beginning by checkpoint->block_operations().
> >>>
> >>> Call stack :
> >>>
> >>> Thread A Thread B
> >>> f2fs_write_checkpoint()
> >>> - block_operations(sbi)
> >>> - f2fs_lock_all(sbi);
> >>> - down_write(>cp_rwsem);
> >>>
> >>> - open()
> >>> - igrab()
> >>> - write() write inline data
> >>> - unlink()
> >>> - f2fs_sync_node_pages()
> >>> - if (is_inline_node(page))
> >>> - flush_inline_data()
> >>>- ilookup()
> >>> page = f2fs_pagecache_get_page()
> >>> if (!page)
> >>> goto iput_out;
> >>> iput_out:
> >>> -close()
> >>> -iput()
> >>>iput(inode);
> >>>- f2fs_evict_inode()
> >>> - f2fs_truncate_blocks()
> >>> - f2fs_lock_op()
> >>>- down_read(>cp_rwsem);
> >>>
> >>> Fixes: 2049d4fcb057 ("f2fs: avoid multiple node page writes due to
> >>> inline_data")
> >>> Signed-off-by: Sayali Lokhande
> >>> Signed-off-by: Jaegeuk Kim
> >>> ---
> >>> fs/f2fs/checkpoint.c | 9 -
> >>> fs/f2fs/f2fs.h | 4 ++--
> >>> fs/f2fs/node.c | 10 +-
> >>> 3 files changed, 15
Re: [PATCH net-next 4/4] net: bcmgenet: add support for ethtool flow control
On 5/11/2020 5:24 PM, Doug Berger wrote: > This commit extends the supported ethtool operations to allow MAC > level flow control to be configured for the bcmgenet driver. It > provides an example of how the new phy_set_pause function and the > phy_validate_pause function can be used to configure the desired > PHY advertising as well as how the phy_get_pause function can be > used for resolving negotiated pause modes which may be overridden > by the MAC. > > The ethtool utility can be used to change the configuration to enable > auto-negotiated symmetric and asymmetric modes as well as manually > enabling support for RX and TX Pause frames individually. > > Signed-off-by: Doug Berger [snip] Only if you need to respin this patch series, I would rename _flow_control_autoneg() to bcmgenet_flow_control_autoneg() or something shorter that still contains bcmgenet_ as a prefix for consistency. Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH net-next 3/4] net: ethernet: introduce phy_set_pause
On 5/11/2020 5:24 PM, Doug Berger wrote: > This commit introduces the phy_set_pause function to the phylib as > a helper to support the set_pauseparam ethtool method. > > It is hoped that the new behavior introduced by this function will > be widely embraced and the phy_set_sym_pause and phy_set_asym_pause > functions can be deprecated. Those functions are retained for all > existing users and for any desenting opinions on my interpretation > of the functionality. > > Signed-off-by: Doug Berger Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH net-next 1/4] net: ethernet: validate pause autoneg setting
On 5/11/2020 5:24 PM, Doug Berger wrote:
> A comment in uapi/linux/ethtool.h states "Drivers should reject a
> non-zero setting of @autoneg when autoneogotiation is disabled (or
> not supported) for the link".
>
> That check should be added to phy_validate_pause() to consolidate
> the code where possible.
>
> Fixes: 22b7d29926b5 ("net: ethernet: Add helper to determine if pause
> configuration is supported")
> Signed-off-by: Doug Berger
Reviewed-by: Florian Fainelli
--
Florian
Re: [PATCH v8 10/11] mtd: Support kmsg dumper based on pstore/blk
hi Kees Cook,
The off parameter on mtdpsore_block*() does not align to block size,
which makes some bugs. For example, a block contains 4 dmesg zones
and it's expected to erase this block when user remove all files on
these zones. However it work failed since it get wrongly zonenum from
misaligned off.
On 2020/5/12 AM 7:32, Kees Cook wrote:
> From: WeiXiong Liao
>
> This introduces mtdpstore, which is similar to mtdoops but more
> powerful. It uses pstore/blk, and aims to store panic and oops logs to
> a flash partition, where pstore can later read back and present as files
> in the mounted pstore filesystem.
>
> To make mtdpstore work, the "blkdev" of pstore/blk should be set
> as MTD device name or MTD device number. For more details, see
> Documentation/admin-guide/pstore-blk.rst
>
> This solves a number of issues:
> - Work duplication: both of pstore and mtdoops do the same job storing
> panic/oops log. They have very similar logic, registering to kmsg
> dumper and storing logs to several chunks one by one.
> - Layer violations: drivers should provides methods instead of polices.
> MTD should provide read/write/erase operations, and allow a higher
> level drivers to provide the chunk management, kmsg dump
> configuration, etc.
> - Missing features: pstore provides many additional features, including
> presenting the logs as files, logging dump time and count, and
> supporting other frontends like pmsg, console, etc.
>
> Signed-off-by: WeiXiong Liao
> Link:
> https://lore.kernel.org/r/1585126506-18635-12-git-send-email-liaoweixi...@allwinnertech.com
> Signed-off-by: Kees Cook
> ---
> Documentation/admin-guide/pstore-blk.rst | 9 +-
> drivers/mtd/Kconfig | 10 +
> drivers/mtd/Makefile | 1 +
> drivers/mtd/mtdpstore.c | 563 +++
> 4 files changed, 581 insertions(+), 2 deletions(-)
> create mode 100644 drivers/mtd/mtdpstore.c
>
> diff --git a/Documentation/admin-guide/pstore-blk.rst
> b/Documentation/admin-guide/pstore-blk.rst
> index d45341e55e82..296d5027787a 100644
> --- a/Documentation/admin-guide/pstore-blk.rst
> +++ b/Documentation/admin-guide/pstore-blk.rst
> @@ -43,9 +43,9 @@ blkdev
> ~~
>
> The block device to use. Most of the time, it is a partition of block device.
> -It's required for pstore/blk.
> +It's required for pstore/blk. It is also used for MTD device.
>
> -It accepts the following variants:
> +It accepts the following variants for block device:
>
> 1. device number in hexadecimal represents itself; no
> leading 0x, for example b302.
> @@ -64,6 +64,11 @@ It accepts the following variants:
> partition with a known unique id.
> #. : major and minor number of the device separated by a colon.
>
> +It accepts the following variants for MTD device:
> +
> +1. MTD device name. "pstore" is recommended.
> +#. MTD device number.
> +
> kmsg_size
> ~
>
> diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
> index 42d401ea60ee..6ddab796216d 100644
> --- a/drivers/mtd/Kconfig
> +++ b/drivers/mtd/Kconfig
> @@ -170,6 +170,16 @@ config MTD_OOPS
> buffer in a flash partition where it can be read back at some
> later point.
>
> +config MTD_PSTORE
> + tristate "Log panic/oops to an MTD buffer based on pstore"
> + depends on PSTORE_BLK
> + help
> + This enables panic and oops messages to be logged to a circular
> + buffer in a flash partition where it can be read back as files after
> + mounting pstore filesystem.
> +
> + If unsure, say N.
> +
> config MTD_SWAP
> tristate "Swap on MTD device support"
> depends on MTD && SWAP
> diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
> index 56cc60ccc477..593d0593a038 100644
> --- a/drivers/mtd/Makefile
> +++ b/drivers/mtd/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_RFD_FTL) += rfd_ftl.o
> obj-$(CONFIG_SSFDC) += ssfdc.o
> obj-$(CONFIG_SM_FTL) += sm_ftl.o
> obj-$(CONFIG_MTD_OOPS) += mtdoops.o
> +obj-$(CONFIG_MTD_PSTORE) += mtdpstore.o
> obj-$(CONFIG_MTD_SWAP) += mtdswap.o
>
> nftl-objs:= nftlcore.o nftlmount.o
> diff --git a/drivers/mtd/mtdpstore.c b/drivers/mtd/mtdpstore.c
> new file mode 100644
> index ..06084eff1004
> --- /dev/null
> +++ b/drivers/mtd/mtdpstore.c
> @@ -0,0 +1,563 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#define dev_fmt(fmt) "mtdoops-pstore: " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static struct mtdpstore_context {
> + int index;
> + struct pstore_blk_config info;
> + struct pstore_device_info dev;
> + struct mtd_info *mtd;
> + unsigned long *rmmap; /* removed bit map */
> + unsigned long *usedmap; /* used bit map */
> + /*
> + * used for panic write
> + * As there are no block_isbad for panic case, we should keep this
> + *
RE: [PATCH V2 2/2] dt-bindings: watchdog: Convert i.MX7ULP to json-schema
Hi Rob,
> From: Rob Herring
> Sent: Tuesday, April 21, 2020 5:28 AM
[...]
> > + timeout-sec:
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +description: |
> > + Contains the watchdog timeout in seconds.
>
> This already has a definition in watchdog.yaml, just need:
>
> timeout-sec: true
>
A bit interested what's the difference if not specifying it as we already have
a reference
to "watchdog.yaml#".
+allOf:
+ - $ref: "watchdog.yaml#"
I saw some mmc vendor yaml bindings seemed did not specifying the 'true' for
the properties
referenced from the parent "mmc-controller.yaml".
Would you help clarify a bit?
Regards
Aisheng
> > +
> > +required:
> > + - compatible
> > + - interrupts
> > + - reg
> > + - clocks
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +
> > +wdog1: watchdog@403d {
> > +compatible = "fsl,imx7ulp-wdt";
> > +reg = <0x403d 0x1>;
> > +interrupts = ;
> > +clocks = < IMX7ULP_CLK_WDG1>;
> > +assigned-clocks = < IMX7ULP_CLK_WDG1>;
> > +assigned-clocks-parents = < IMX7ULP_CLK_FIRC_BUS_CLK>;
> > +timeout-sec = <40>;
> > +};
> > +
> > +...
> > --
> > 2.7.4
> >
Good Morning!
Dear Sir/Madam. I am, MR.Abd Manaf,I have (15.5 M Dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Yours Sincerely,
Re: [PATCH v4 2/2] scripts: Add a intermediate file for 'make gtags'
On Sat, May 2, 2020 at 2:34 PM xujialu wrote:
>
> As 'GTAGS Manual' said: If ´gtags.files´ exists in the current directory
> directory or a file is specified by the -f option, target files are
> limited by it.
>
> So add gtags.files just like cscope.files.
>
> Signed-off-by: xujialu
> ---
> Makefile| 2 +-
> scripts/tags.sh | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 679f302a8b8b..2c8304ae103f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1398,7 +1398,7 @@ MRPROPER_FILES += .config .config.old .version \
>
> # Directories & files removed with 'make distclean'
> DISTCLEAN_DIRS +=
> -DISTCLEAN_FILES += tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS
> +DISTCLEAN_FILES += tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS gtags.files
>
> # clean - Delete most, but leave enough to build external modules
> #
> diff --git a/scripts/tags.sh b/scripts/tags.sh
> index 941a5c61d343..e2edd0cf67ec 100755
> --- a/scripts/tags.sh
> +++ b/scripts/tags.sh
> @@ -142,7 +142,8 @@ docscope()
>
> dogtags()
> {
> - all_target_sources | gtags -i -f -
> + all_target_sources > gtags.files
> + gtags -i -f gtags.files
> }
My previous reply was not sent to the list.
Here is the summary of my view.
With my basic knowledge of UNIX
such as the concept of pipe, redirect, etc.,
the following two commands should do the same work.
[1] { echo file lists; } | gtags -f -
[2] { echo file lists; } > tmpfile
gtags -f tmpfile
The gtags manual also says:
-f, --file file
Give a list of candidates of target files.
Files which are not on the list are ignored.
The argument file can be set to ´-´ to accept
a list of files from the standard input.
This patch looks no point to me.
As for the cscope.files, we had a reason to have it separately.
This commit:
https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=3cd681bae4360e2f67ef9b232db28e13319f1c17
And, the bug was elaborated here:
https://bugzilla.kernel.org/show_bug.cgi?id=1948
--
Best Regards
Masahiro Yamada
Re: [PATCH v5 1/2] dt-bindings: mtd: Add YAML for Nand Flash Controller support
Hi Rob,
Thank you for the review comments and your time...
On 11/5/2020 11:37 pm, Rob Herring wrote:
On Thu, May 07, 2020 at 08:15:36AM +0800, Ramuthevar,Vadivel MuruganX wrote:
From: Ramuthevar Vadivel Murugan
Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.
The $subject should some how reflect this is for this SoC.
Noted, will update.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/intel,lgm-nand.yaml| 85 ++
1 file changed, 85 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index ..69b592ae62f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+ - $ref: "nand-controller.yaml"
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+properties:
+ compatible:
+const: intel,lgm-nand-controller
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ dmas:
+maxItems: 2
+
+ dma-names:
+enum:
+ - rx
+ - tx
+
+ pinctrl-names: true
+
+patternProperties:
+ "^pinctrl-[0-9]+$": true
Don't need the pinctrl properties. The tooling adds them.
ok, will drop.
+
+ "^nand@[a-f0-9]+$":
+type: object
+properties:
+ reg:
+minimum: 0
+maximum: 7
+
+ nand-ecc-mode: true
+
+ nand-ecc-algo:
+const: hw
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - dmas
+
+additionalProperties: false
+
+examples:
+ - |
+#include
Is this applied somewhere? It's missing in my check and will break the
build.
You have already reviewed the below patch which has the file
https://lkml.org/lkml/2020/4/17/31
Regards
Vadivel
+nand-controller@e0f0 {
+ compatible = "intel,nand-controller";
+ reg = <0xe0f0 0x100>,
+<0xe100 0x300>,
+<0xe140 0x8000>,
+<0xe1c0 0x1000>;
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1";
+ clocks = < LGM_GCLK_EBU>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+
+ nand@0 {
+reg = <0>;
+nand-on-flash-bbt;
+#address-cells = <1>;
+#size-cells = <1>;
+ };
+};
+
+...
--
2.11.0
Re: [PATCH v4 1/2] scripts: Support compiled source, improved precise
On Sat, May 2, 2020 at 2:27 PM xujialu wrote:
>
> Original 'COMPILED_SOURCE=1 make cscope' collects nearly 3 files
> include too many unused files, this patch precisely collects source
> files from *.cmd, in this case just 3000 files include dts and dtsi.
>
> Usage:
> 1) COMPILED_SOURCE=1 make {cscope,gtags}
> 2) COMPILED_SOURCE=1 KBUILD_ABS_SRCTREE=1 make {cscope,gtags}
> 3) COMPILED_SOURCE=1 ./scripts/tags.sh {cscope,gtags}
> 4) COMPILED_SOURCE=1 ABSPWD=$PWD/ ./scripts/tags.sh {cscope,gtags}
>
> Signed-off-by: xujialu
> ---
> scripts/tags.sh | 36 ++--
> 1 file changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/scripts/tags.sh b/scripts/tags.sh
> index 4e18ae5282a6..941a5c61d343 100755
> --- a/scripts/tags.sh
> +++ b/scripts/tags.sh
> @@ -89,22 +89,30 @@ all_sources()
> find_other_sources '*.[chS]'
> }
>
> +# COMPILED_SOURCE=1 make {cscope,gtags}
> +# COMPILED_SOURCE=1 KBUILD_ABS_SRCTREE=1 make {cscope,gtags}
> +# COMPILED_SOURCE=1 ./scripts/tags.sh {cscope,gtags}
> +# COMPILED_SOURCE=1 ABSPWD=$PWD/ ./scripts/tags.sh {cscope,gtags}
These comment are misleading since this sounds like
is is only usef for cscope, gtags.
Please do not introduce a new variable ABSPWD, which is unneeded.
This is a rare use-case, but if you want to run this script directly,
you must set the variables described at line 9 properly.
> +xtags_juggle_list()
> +{
> + SRCTREE=$(realpath ${tree}.)
> +
> + cd $(dirname $(find -name .config -print -quit).)
Why is this needed?
You are already in objtree
when this script is being run.
If you handle the objects built with O= option,
you need to do 'make O=... gtags'.
> +
> + realpath -e --relative-to=${SRCTREE} $(find -name "*.cmd" -exec \
> + grep -Poh '(?(?=^source_.* \K).*|(?=^ \K\S).*(?= \\))' {} \+
> |
> + awk '!a[$0]++') include/generated/autoconf.h |
> + sed -e "/\.\./d" -e "s,^,${ABSPWD}${tree},"
> +}
Why is --relative-to=${SRCTREE} needed?
You are dropping ${SRCTREE} and adding ${ABSPWD}${tree}.
I do not understand what this is doing back-and-forth.
Lastly, the file order is currently carefully crafted
but this patch would make it random-ordered.
I am afraid the following commit would be broken.
commit f81b1be40c44b33b9706d64c117edd29e627ad12 (HEAD)
Author: Guennadi Liakhovetski
Date: Mon Feb 8 00:25:59 2010 +0100
tags: include headers before source files
Currently looking up a structure definition in TAGS / tags takes one to
one of multiple "static struct X" definitions in arch sources, which makes
it for many structs practically impossible to get to the required header.
This patch changes the order of sources being tagged to first scan
architecture includes, then the top-level include/ directory, and only
then the rest. It also takes into account, that many architectures have
more than one include directory, i.e., not only arch/$ARCH/include, but
also arch/$ARCH/mach-X/include etc.
Signed-off-by: Guennadi Liakhovetski
Reviewed-by: WANG Cong
[mma...@suse.cz: fix 'var+=text' bashism]
Signed-off-by: Michal Marek
> +
> all_compiled_sources()
> {
> - for i in $(all_sources); do
> - case "$i" in
> - *.[cS])
> - j=${i/\.[cS]/\.o}
> - j="${j#$tree}"
> - if [ -e $j ]; then
> - echo $i
> - fi
> - ;;
> - *)
> - echo $i
> - ;;
> - esac
> - done
> + # Consider 'git ls-files' features:
> + # 1) sort and uniq target files
> + # 2) limit target files by index
> + # git ls-files $(xtags_juggle_list)
How is this related to this ?
> +
> + xtags_juggle_list | sort -u
> }
>
> all_target_sources()
> --
> 2.20.1
>
--
Best Regards
Masahiro Yamada
Re: [PATCH 2/3] ASoC: fsl_esai: Add support for imx8qm
Hi Mark, Nicolin On Wed, May 6, 2020 at 10:33 AM Shengjiu Wang wrote: > > Hi > > On Fri, May 1, 2020 at 6:23 PM Mark Brown wrote: > > > > On Fri, May 01, 2020 at 04:12:05PM +0800, Shengjiu Wang wrote: > > > The difference for esai on imx8qm is that DMA device is EDMA. > > > > > > EDMA requires the period size to be multiple of maxburst. Otherwise > > > the remaining bytes are not transferred and thus noise is produced. > > > > If this constraint comes from the DMA controller then normally you'd > > expect the DMA controller integration to be enforcing this - is there no > > information in the DMA API that lets us know that this constraint is > > there? > > No, I can't find one API for this. > Do you have a recommendation? > could you please recommend which DMA API can I use? best regards wang shengjiu
Re: [PATCH v2 1/3] rcu/kasan: record and print call_rcu() call stack
On Mon, 2020-05-11 at 11:05 -0700, Paul E. McKenney wrote:
> On Mon, May 11, 2020 at 10:31:11AM +0800, Walter Wu wrote:
> > This feature will record first and last call_rcu() call stack and
> > print two call_rcu() call stack in KASAN report.
>
> Suppose that a given rcu_head structure is passed to call_rcu(), then
> the grace period elapses, the callback is invoked, and the enclosing
> data structure is freed. But then that same region of memory is
> immediately reallocated as the same type of structure and again
> passed to call_rcu(), and that this cycle repeats several times.
>
> Would the first call stack forever be associated with the first
> call_rcu() in this series? If so, wouldn't the last two usually
> be the most useful? Or am I unclear on the use case?
>
The first call stack doesn't forever associate with first call_rcu(),
if someone object freed and reallocated, then the first call stack will
replace with new object.
> > When call_rcu() is called, we store the call_rcu() call stack into
> > slub alloc meta-data, so that KASAN report can print rcu stack.
> >
> > It doesn't increase the cost of memory consumption. Because we don't
> > enlarge struct kasan_alloc_meta size.
> > - add two call_rcu() call stack into kasan_alloc_meta, size is 8 bytes.
> > - remove free track from kasan_alloc_meta, size is 8 bytes.
> >
> > [1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
> > [2]https://groups.google.com/forum/#!searchin/kasan-dev/better$20stack$20traces$20for$20rcu%7Csort:date/kasan-dev/KQsjT_88hDE/7rNUZprRBgAJ
> >
> > Signed-off-by: Walter Wu
> > Suggested-by: Dmitry Vyukov
> > Cc: Andrey Ryabinin
> > Cc: Dmitry Vyukov
> > Cc: Alexander Potapenko
> > Cc: Andrew Morton
> > Cc: Paul E. McKenney
> > Cc: Josh Triplett
> > Cc: Mathieu Desnoyers
> > Cc: Lai Jiangshan
> > Cc: Joel Fernandes
> > ---
> > include/linux/kasan.h | 2 ++
> > kernel/rcu/tree.c | 3 +++
> > lib/Kconfig.kasan | 2 ++
> > mm/kasan/common.c | 4 ++--
> > mm/kasan/generic.c| 29 +
> > mm/kasan/kasan.h | 19 +++
> > mm/kasan/report.c | 21 +
> > 7 files changed, 74 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> > index 31314ca7c635..23b7ee00572d 100644
> > --- a/include/linux/kasan.h
> > +++ b/include/linux/kasan.h
> > @@ -174,11 +174,13 @@ static inline size_t kasan_metadata_size(struct
> > kmem_cache *cache) { return 0; }
> >
> > void kasan_cache_shrink(struct kmem_cache *cache);
> > void kasan_cache_shutdown(struct kmem_cache *cache);
> > +void kasan_record_aux_stack(void *ptr);
> >
> > #else /* CONFIG_KASAN_GENERIC */
> >
> > static inline void kasan_cache_shrink(struct kmem_cache *cache) {}
> > static inline void kasan_cache_shutdown(struct kmem_cache *cache) {}
> > +static inline void kasan_record_aux_stack(void *ptr) {}
> >
> > #endif /* CONFIG_KASAN_GENERIC */
> >
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 06548e2ebb72..de872b6cc261 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -57,6 +57,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include "../time/tick-internal.h"
> >
> > #include "tree.h"
> > @@ -2694,6 +2695,8 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func)
> > trace_rcu_callback(rcu_state.name, head,
> >rcu_segcblist_n_cbs(>cblist));
> >
> > + kasan_record_aux_stack(head);
>
> Just for the record, at this point we have not yet queued the callback.
> We have also not yet disabled interrupts. Which might be OK, but I
> figured I should call out the possibility of moving this down a few
> lines to follow the local_irq_save().
>
We will intend to do it.
> If someone incorrectly invokes concurrently invokes call_rcu() on this
> same region of memory, possibly from an interrupt handler, we are OK
> corrupting the stack traces, right?
>
Yes, and the wrong invoking call_rcu should be recorded.
> But what happens if a given structure has more than one rcu_head
> structure? In that case, RCU would be just fine with it being
> concurrently passed to different call_rcu() invocations as long as the
> two invocations didn't both use the same rcu_head structure. (In that
> case, they had best not be both freeing the object, and if even one of
> them is freeing the object, coordination is necessary.)
>
> If this is a problem, one approach would be to move the
> kasan_record_aux_stack(head) call to kfree_rcu(). After all, it is
> definitely illegal to pass the same memory to a pair of kfree_rcu()
> invocations! ;-)
>
The function of kasan_record_aux_stack(head) is simple, it is only to
record call stack by the 'head' object.
Thanks.
> Thanx, Paul
>
> > +
> > /* Go handle any RCU core processing required. */
> > if
Re: [PATCH v11 08/56] Input: atmel_mxt_ts - implement T15 Key Array support
On Thu, May 07, 2020 at 10:56:08PM -0700, Jiada Wang wrote:
> From: Nick Dyer
>
> There is a key array object in many maXTouch chips which allows some X/Y
> lines to be used as a key array. This patch maps them to a series of keys
> which may be configured in a platform data array.
>
> Signed-off-by: Nick Dyer
> Acked-by: Benson Leung
> Acked-by: Yufeng Shen
> (cherry picked from ndyer/linux/for-upstream commit
> 15bb074b5abf3a101f7b79544213f1c110ea4cab)
> [gdavis: Resolve forward port conflicts due to applying upstream
>commit 96a938aa214e ("Input: atmel_mxt_ts - remove platform
>data support").]
> Signed-off-by: George G. Davis
> [jiada: Fix compilation warning]
> Signed-off-by: Jiada Wang
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 85
> 1 file changed, 85 insertions(+)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
> b/drivers/input/touchscreen/atmel_mxt_ts.c
> index df2e0ba76e63..d05249b02781 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -314,6 +314,9 @@ struct mxt_data {
> struct mxt_dbg dbg;
> struct gpio_desc *reset_gpio;
> bool use_retrigen_workaround;
> + unsigned long t15_keystatus;
> + int t15_num_keys;
> + const unsigned int *t15_keymap;
>
> /* Cached parameters from object table */
> u16 T5_address;
> @@ -324,6 +327,8 @@ struct mxt_data {
> u16 T71_address;
> u8 T9_reportid_min;
> u8 T9_reportid_max;
> + u8 T15_reportid_min;
> + u8 T15_reportid_max;
> u16 T18_address;
> u8 T19_reportid;
> u8 T42_reportid_min;
> @@ -987,6 +992,38 @@ static void mxt_proc_t100_message(struct mxt_data *data,
> u8 *message)
> data->update_input = true;
> }
>
> +static void mxt_proc_t15_messages(struct mxt_data *data, u8 *msg)
> +{
> + struct input_dev *input_dev = data->input_dev;
> + struct device *dev = >client->dev;
> + int key;
> + bool curr_state, new_state;
> + bool sync = false;
> + unsigned long keystates = le32_to_cpu((__force __le32)msg[2]);
?
It is a byte. Just say
unsigned long keystates = msg[2];
> +
> + for (key = 0; key < data->t15_num_keys; key++) {
> + curr_state = test_bit(key, >t15_keystatus);
> + new_state = test_bit(key, );
> +
> + if (!curr_state && new_state) {
> + dev_dbg(dev, "T15 key press: %u\n", key);
> + __set_bit(key, >t15_keystatus);
> + input_event(input_dev, EV_KEY,
> + data->t15_keymap[key], 1);
> + sync = true;
> + } else if (curr_state && !new_state) {
> + dev_dbg(dev, "T15 key release: %u\n", key);
> + __clear_bit(key, >t15_keystatus);
> + input_event(input_dev, EV_KEY,
> + data->t15_keymap[key], 0);
> + sync = true;
> + }
> + }
> +
> + if (sync)
> + input_sync(input_dev);
I wonder if the following is not simpler:
unsigned long changed_keys;
...
changed_keys = keystates ^ data->t15_keystatus;
for_each_set_bit(key, _keys, data->t15_num_keys) {
pressed = test_bit(key, );
input_event(input_dev, EV_KEY,
data->t15_keymap[key], pressed);
dev_dbg(dev, "T15 key %s: %u\n",
pressed ? "press" : "release", key);
}
if (changed_keys)
input_sync(input_dev);
data->t15_keystatus = keystates;
...
> + if (device_property_present(dev, buttons_property)) {
> + n_keys = device_property_read_u32_array(dev, buttons_property,
> + NULL, 0);
> + if (n_keys <= 0) {
> + error = n_keys < 0 ? n_keys : -EINVAL;
> + dev_err(dev, "invalid/malformed '%s' property: %d\n",
> + buttons_property, error);
> + return error;
> + }
> +
> + buttonmap = devm_kmalloc_array(dev, n_keys, sizeof(*buttonmap),
> +GFP_KERNEL);
> + if (!buttonmap)
> + return -ENOMEM;
So it is 8 keys max, I'd simply embed this into data. On 64 bit arch it
will occupy the same space as the pointer you use to reference it.
Can you also validate that we do not get too many keys in DT?
Also, set keycode/keycodemax/keycodesize in input device so userspace
can adjust keymap if needed?
Thanks.
--
Dmitry
RE: [PATCH V4 1/4] dt-bindings: fsl: add i.MX7ULP PMC binding doc
Hi Rob,
> Subject: [PATCH V4 1/4] dt-bindings: fsl: add i.MX7ULP PMC binding doc
Could I have your A-b for this patch?
Thanks,
Peng.
>
> From: Peng Fan
>
> Add i.MX7ULP Power Management Controller binding doc
> pmc0 is used by M4, pmc1 is used by A7, they have different register name
> and usage.
>
> Signed-off-by: Peng Fan
> ---
> .../bindings/arm/freescale/imx7ulp_pmc.yaml| 32
> ++
> 1 file changed, 32 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/arm/freescale/imx7ulp_pmc.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/arm/freescale/imx7ulp_pmc.yaml
> b/Documentation/devicetree/bindings/arm/freescale/imx7ulp_pmc.yaml
> new file mode 100644
> index ..c60903039718
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/freescale/imx7ulp_pmc.yaml
> @@ -0,0 +1,32 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/freescale/imx7ulp_pmc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: i.MX7ULP Power Management Controller(PMC) Device Tree Bindings
> +
> +maintainers:
> + - Peng Fan
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - fsl,imx7ulp-pmc0
> + - fsl,imx7ulp-pmc1
> +
> + reg:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> +pmc0: pmc0@410a1000 {
> +compatible = "fsl,imx7ulp-pmc0";
> +reg = <0x410a1000 0x1000>;
> +};
> +...
> --
> 2.16.4
[v1,1/1] hwmon: (nct7904) Add to read all of the SMI status registers in probe function.
From: Amy Shih
When nct7904 power up, it compares current sensor readings within the
default threshold immediately, thus some of SMI status registers would
get non zero values cause the false alarms on first reading. Add to
read all of the SMI status registers in probe function to clear the
alarms.
Signed-off-by: Amy Shih
---
drivers/hwmon/nct7904.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/hwmon/nct7904.c b/drivers/hwmon/nct7904.c
index 571a649..6fb06f7 100644
--- a/drivers/hwmon/nct7904.c
+++ b/drivers/hwmon/nct7904.c
@@ -45,6 +45,7 @@
#define FANCTL_MAX 4 /* Counted from 1 */
#define TCPU_MAX 8 /* Counted from 1 */
#define TEMP_MAX 4 /* Counted from 1 */
+#define SMI_STS_MAX10 /* Counted from 1 */
#define VT_ADC_CTRL0_REG 0x20/* Bank 0 */
#define VT_ADC_CTRL1_REG 0x21/* Bank 0 */
@@ -1126,6 +1127,13 @@ static int nct7904_probe(struct i2c_client *client,
data->fan_mode[i] = ret;
}
+ /* Read all of SMI status register to clear alarms */
+ for (i = 0; i < SMI_STS_MAX; i++) {
+ ret = nct7904_read_reg(data, BANK_0, SMI_STS1_REG + i);
+ if (ret < 0)
+ return ret;
+ }
+
hwmon_dev =
devm_hwmon_device_register_with_info(dev, client->name, data,
_chip_info, NULL);
--
1.8.3.1
[PATCH -next] ARM: OMAP2+: pm33xx-core: Make am43xx_get_rtc_base_addr static
Fix the following sparse warning:
arch/arm/mach-omap2/pm33xx-core.c:270:14: warning: symbol
'am43xx_get_rtc_base_addr' was not declared.
The am43xx_get_rtc_base_addr has only call site within pm33xx-core.c
It should be static
Fixes: 8c5a916f4c88 ("ARM: OMAP2+: sleep33/43xx: Add RTC-Mode support")
Reported-by: Hulk Robot
Signed-off-by: Samuel Zou
---
arch/arm/mach-omap2/pm33xx-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm33xx-core.c
b/arch/arm/mach-omap2/pm33xx-core.c
index 5455fc9..58236c7 100644
--- a/arch/arm/mach-omap2/pm33xx-core.c
+++ b/arch/arm/mach-omap2/pm33xx-core.c
@@ -267,7 +267,7 @@ static struct am33xx_pm_sram_addr *amx3_get_sram_addrs(void)
return NULL;
}
-void __iomem *am43xx_get_rtc_base_addr(void)
+static void __iomem *am43xx_get_rtc_base_addr(void)
{
rtc_oh = omap_hwmod_lookup("rtc");
--
2.6.2
