Re: [PATCH 2/2] lib/genalloc.c: export symbol addr_in_gen_pool
On Mon, Dec 24, 2018 at 03:06:22PM +0800, Huang Shijie wrote: > We may use the addr_in_gen_pool() in the driver module. > So export the addr_in_gen_pool for the compiling. Please send this along with the driver that plans to use it.
Re: [PATCH v4 05/10] KVM/x86: expose MSR_IA32_PERF_CAPABILITIES to the guest
On 01/03/2019 07:40 AM, Jim Mattson wrote: On Wed, Dec 26, 2018 at 2:01 AM Wei Wang wrote: Bits [0, 5] of MSR_IA32_PERF_CAPABILITIES tell about the format of the addresses stored in the LBR stack. Expose those bits to the guest when the guest lbr feature is enabled. Signed-off-by: Wei Wang Cc: Paolo Bonzini Cc: Andi Kleen --- arch/x86/include/asm/perf_event.h | 2 ++ arch/x86/kvm/cpuid.c | 2 +- arch/x86/kvm/vmx.c| 9 + 3 files changed, 12 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/perf_event.h b/arch/x86/include/asm/perf_event.h index 2f82795..eee09b7 100644 --- a/arch/x86/include/asm/perf_event.h +++ b/arch/x86/include/asm/perf_event.h @@ -87,6 +87,8 @@ #define ARCH_PERFMON_BRANCH_MISSES_RETIRED 6 #define ARCH_PERFMON_EVENTS_COUNT 7 +#define X86_PERF_CAP_MASK_LBR_FMT 0x3f + /* * Intel "Architectural Performance Monitoring" CPUID * detection/enumeration details: diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 7bcfa61..3b8a57b 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -365,7 +365,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, 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.c b/arch/x86/kvm/vmx.c index 8d5d984..ee02967 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -4161,6 +4161,13 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) return 1; msr_info->data = vcpu->arch.ia32_xss; break; + case MSR_IA32_PERF_CAPABILITIES: + if (!boot_cpu_has(X86_FEATURE_PDCM)) + return 1; + msr_info->data = native_read_msr(MSR_IA32_PERF_CAPABILITIES); Since this isn't guarded by vcpu->kvm->arch.lbr_in_guest, it breaks backwards compatibility, doesn't it? Right, thanks. Probably better to change it to below: msr_info->data = 0; data = native_read_msr(MSR_IA32_PERF_CAPABILITIES); if (vcpu->kvm->arch.lbr_in_guest) msr_info->data |= (data & X86_PERF_CAP_MASK_LBR_FMT); Best, Wei
Re: [PATCH] kfifo: add memory barrier in kfifo to prevent data loss
On 12/12/18 8:50 AM, Kees Cook wrote: > On Mon, Dec 10, 2018 at 7:41 PM wrote: >> >> From: Yulei Zhang >> >> Early this year we spot there may be two issues in kernel >> kfifo. >> >> One is reported by Xiao Guangrong to linux kernel. >> https://lkml.org/lkml/2018/5/11/58 >> In current kfifo implementation there are missing memory >> barrier in the read side, so that without proper barrier >> between reading the kfifo->in and fetching the data there >> is potential ordering issue. >> >> Beside that, there is another potential issue in kfifo, >> please consider the following case: >> at the beginning >> ring->size = 4 >> ring->out = 0 >> ring->in = 4 >> >> ConsumerProducer >> --- -- >> index = ring->out; /* index == 0 */ >> ring->out++; /* ring->out == 1 */ >> < Re-Order > >> out = ring->out; >> if (ring->in - out >= ring->mask) >> return -EFULL; >> /* see the ring is not full */ >> index = ring->in & ring->mask; >> /* index == 0 */ >> ring->data[index] = new_data; >> ring->in++; >> >> data = ring->data[index]; >> /* you will find the old data is overwritten by the new_data */ >> >> In order to avoid the issue: >> 1) for the consumer, we should read the ring->data[] out before >> updating ring->out >> 2) for the producer, we should read ring->out before updating >> ring->data[] >> >> So in this patch we introduce the following four functions which >> are wrapped with proper memory barrier and keep in pairs to make >> sure the in and out index are fetched and updated in order to avoid >> data loss. >> >> kfifo_read_index_in() >> kfifo_write_index_in() >> kfifo_read_index_out() >> kfifo_write_index_out() >> >> Signed-off-by: Yulei Zhang >> Signed-off-by: Guangrong Xiao > > I've added some more people to CC that might want to see this. Thanks > for sending this! Hi, Ping... could anyone have a look? ;) Thanks!
[RFC v4 0/3] pstore/rom: new support logger for block devices
Why should we need pstore_rom? 1. Most embedded intelligent equipment have no persistent ram, which increases costs. We perfer to cheaper solutions, like block devices. In fast, there is already a sample for block device logger in driver MTD (drivers/mtd/mtdoops.c). 2. Do not any equipment have battery, which means that it lost all data on general ram if power failure. Pstore has little to do for these equipments. [PATCH v4] On patch 1: 1. Fix always true condition '(--i >= 0) => (0-u32max >= 0)' in function romz_init_zones by defining variable i to 'int' rahter than 'unsigned int'. 2. To make codes more easily to read, we use macro READ_NEXT_ZONE for return value of romz_dmesg_read if it need to read next zone. Moveover, we assign READ_NEXT_ZONE -1024 rather than 0. 3. Add 'FLUSH_META' to 'enum romz_flush_mode' and rename 'NOT_FLUSH' to 'FLUSH_NONE' 4. Function romz_zone_write work badly with FLUSH_PART mode as badly address and offset to write. On patch 3: NEW SUPPORT psmg for pstore_rom. [PATCH v3] On patch 1: Fix build as module error for undefined 'vfs_read' and 'vfs_write' Both of 'vfs_read' and 'vfs_write' haven't be exproted yet, so we use 'kernel_read' and 'kernel_write' instead. [PATCH v2] On patch 1: Fix build as module error for redefinition of 'romz_unregister' and 'romz_register' [PATCH v1] On patch 1: Core codes of pstore_rom, which works well on allwinner(sunxi) platform. On patch 2: A sample for pstore_rom, using general ram rather than block device. liaoweixiong (3): pstore/rom: new support logger for block devices pstore/rom: add sample for pstore_rom pstore/rom: support pmsg for pstore_rom fs/pstore/Kconfig | 16 + fs/pstore/Makefile |5 + fs/pstore/rombuf.c | 46 ++ fs/pstore/romzone.c| 1138 include/linux/pstore_rom.h | 62 +++ 5 files changed, 1267 insertions(+) create mode 100644 fs/pstore/rombuf.c create mode 100644 fs/pstore/romzone.c create mode 100644 include/linux/pstore_rom.h -- 1.9.1
[RFC v4 3/3] pstore/rom: support pmsg for pstore_rom
To enable pmsg, just set pmsg_size when block device register romzone.
The pmsg have a single-boot lifetime, which means that zone of pmsg gets
wiped after its contents get copied out after boot.
Signed-off-by: liaoweixiong
---
fs/pstore/romzone.c| 194 +++--
include/linux/pstore_rom.h | 1 +
2 files changed, 187 insertions(+), 8 deletions(-)
diff --git a/fs/pstore/romzone.c b/fs/pstore/romzone.c
index 76a2648..d035694 100644
--- a/fs/pstore/romzone.c
+++ b/fs/pstore/romzone.c
@@ -31,12 +31,14 @@
*
* @sig: signature to indicate header (ROM_SIG xor ROMZONE-type value)
* @datalen: length of data in @data
+ * @start: offset into @data where the beginning of the stored bytes begin
* @data: zone data.
*/
struct romz_buffer {
#define ROM_SIG (0x43474244) /* DBGC */
uint32_t sig;
atomic_t datalen;
+ atomic_t start;
uint8_t data[0];
};
@@ -69,6 +71,10 @@ struct romz_dmesg_header {
* frontent name for this zone
* @buffer:
* pointer to data buffer managed by this zone
+ * @oldbuf:
+ * pointer to old data buffer. It is used for zone who have a single-boot
+ * lifetime, which means that this zone gets wiped after its contents get
+ * copied out after boot.
* @buffer_size:
* bytes in @buffer->data
* @should_recover:
@@ -82,6 +88,7 @@ struct romz_zone {
enum pstore_type_id type;
struct romz_buffer *buffer;
+ struct romz_buffer *oldbuf;
size_t buffer_size;
bool should_recover;
atomic_t dirty;
@@ -89,8 +96,10 @@ struct romz_zone {
struct romoops_context {
struct romz_zone **drzs;/* Oops dump zones */
+ struct romz_zone *prz; /* Pmsg dump zones */
unsigned int dmesg_max_cnt;
unsigned int dmesg_read_cnt;
+ unsigned int pmsg_read_cnt;
unsigned int dmesg_write_cnt;
/**
* the counter should be recovered when do recovery
@@ -124,6 +133,11 @@ static inline int buffer_datalen(struct romz_zone *zone)
return atomic_read(>buffer->datalen);
}
+static inline int buffer_start(struct romz_zone *zone)
+{
+ return atomic_read(>buffer->start);
+}
+
static inline bool is_on_panic(void)
{
struct romoops_context *cxt = _cxt;
@@ -398,6 +412,65 @@ static int romz_recover_dmesg(struct romoops_context *cxt)
return ret;
}
+static int romz_recover_pmsg(struct romoops_context *cxt)
+{
+ struct romz_info *info = cxt->rzinfo;
+ struct romz_buffer *oldbuf;
+ struct romz_zone *zone = NULL;
+ ssize_t (*readop)(char *buf, size_t bytes, loff_t pos);
+ int ret = 0;
+ ssize_t rcnt, len;
+
+ zone = cxt->prz;
+ if (!zone)
+ return -EINVAL;
+
+ if (zone->oldbuf)
+ return 0;
+
+ readop = info->read;
+ if (is_on_panic())
+ readop = info->panic_read;
+ if (!readop)
+ return -EINVAL;
+
+ len = zone->buffer_size + sizeof(*oldbuf);
+ oldbuf = kzalloc(len, GFP_KERNEL);
+ if (!oldbuf)
+ return -ENOMEM;
+
+ rcnt = readop((char *)oldbuf, len, zone->off);
+ if (rcnt != len) {
+ pr_debug("recovery pmsg failed\n");
+ ret = -EIO;
+ goto free_oldbuf;
+ }
+
+ if (oldbuf->sig != zone->buffer->sig) {
+ pr_debug("no valid data in zone %s\n", zone->name);
+ goto free_oldbuf;
+ }
+
+ if (zone->buffer_size < atomic_read(>datalen) ||
+ zone->buffer_size < atomic_read(>start)) {
+ pr_info("found overtop zone: %s: off %lu, size %zu\n",
+ zone->name, zone->off, zone->buffer_size);
+ goto free_oldbuf;
+ }
+
+ if (atomic_read(>dirty))
+ romz_zone_write(zone, FLUSH_ALL, NULL, buffer_datalen(zone), 0);
+ else
+ romz_zone_write(zone, FLUSH_META, NULL, 0, 0);
+
+ zone->oldbuf = oldbuf;
+ return 0;
+
+free_oldbuf:
+ kfree(oldbuf);
+ return ret;
+}
+
static inline int romz_recovery(struct romoops_context *cxt)
{
int ret = -EBUSY;
@@ -412,6 +485,10 @@ static inline int romz_recovery(struct romoops_context
*cxt)
if (ret)
goto recover_fail;
+ ret = romz_recover_pmsg(cxt);
+ if (ret)
+ goto recover_fail;
+
atomic_set(>recovery, 1);
pr_debug("recover end!\n");
return 0;
@@ -520,6 +597,55 @@ static int notrace romz_dmesg_write(struct romoops_context
*cxt,
return 0;
}
+static int notrace romz_pmsg_write(struct romoops_context *cxt,
+ struct pstore_record *record)
+{
+ struct romz_zone *zone;
+ size_t start, rem;
+ int cnt = record->size;
+ bool is_full_data = false;
+ char *buf = record->buf;
+
+ zone = cxt->prz;
+ if (!zone)
+ return
[RFC v4 2/3] pstore/rom: add sample for pstore_rom
It is a sample for pstore_rom, using general ram rather than block device.
According to pstore_rom, the data will be saved to ram buffer if not
register device path and apis for panic. So, it can only used to dump
Oops and some things will not reboot.
Signed-off-by: liaoweixiong
---
fs/pstore/Kconfig | 9 +
fs/pstore/Makefile | 2 ++
fs/pstore/rombuf.c | 46 ++
3 files changed, 57 insertions(+)
create mode 100644 fs/pstore/rombuf.c
diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index abf0453..426b5ea 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -159,3 +159,12 @@ config PSTORE_ROM
help
This enables panic and oops message to be logged to a block dev
where it can be read back at some later point.
+
+config PSTORE_ROMBUF
+ tristate "romoop buffer sample"
+ depends on PSTORE_ROM
+ help
+ This is a sample for pstore rom, but do NOT have a block dev.
+ According to pstore_rom, the data will be saved to ram buffer and
+ dropped when reboot. So, it can only used to dump Oops and some
+ things will not reboot.
diff --git a/fs/pstore/Makefile b/fs/pstore/Makefile
index ea38d6e..21c1226 100644
--- a/fs/pstore/Makefile
+++ b/fs/pstore/Makefile
@@ -15,3 +15,5 @@ obj-$(CONFIG_PSTORE_RAM) += ramoops.o
obj-$(CONFIG_PSTORE_ROM) += romoops.o
romoops-y += romzone.o
+
+obj-$(CONFIG_PSTORE_ROMBUF)+= rombuf.o
diff --git a/fs/pstore/rombuf.c b/fs/pstore/rombuf.c
new file mode 100644
index 000..bb21a85
--- /dev/null
+++ b/fs/pstore/rombuf.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
+ * rombuf.c: ROM Oops/Panic logger
+ *
+ * Copyright (C) 2019 liaoweixiong
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#define pr_fmt(fmt) "rombuf: " fmt
+
+#include
+#include
+#include
+
+struct romz_info rombuf_info = {
+ .owner = THIS_MODULE,
+ .name = "rombuf",
+ .part_size = 512 * 1024,
+ .dmesg_size = 64 * 1024,
+ .dump_oops = true,
+};
+
+static int __init rombuf_init(void)
+{
+ return romz_register(_info);
+}
+module_init(rombuf_init);
+
+static void __exit rombuf_exit(void)
+{
+ romz_unregister(_info);
+}
+module_exit(rombuf_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("liaoweixiong ");
+MODULE_DESCRIPTION("Sample for Pstore ROM with Oops logger");
--
1.9.1
[RFC v4 1/3] pstore/rom: new support logger for block devices
pstore_rom is similar to pstore_ram, but dump log to block devices
rather than persistent ram.
Why should we need pstore_rom?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fast, there is already a sample for block device logger in driver
MTD (drivers/mtd/mtdoops.c).
2. Do not any equipment have battery, which means that it lost all data
on general ram if power failure. Pstore has little to do for these
equipments.
pstore_rom can only dump Oops/Panic log to block devices. It only
supports dmesg now. To make pstore_rom work, the block driver should
provide the path of a block partition device (/dev/) and the
read/write apis when on panic.
pstore_rom begins at 'romz_register', by witch block device can register
a block partition to pstore_rom. Then pstore_rom divide and manage the
partition as zones, which is similar to pstore_ram.
Recommend that, block driver register pstore_rom after block device is
ready.
pstore_rom works well on allwinner(sunxi) platform.
Signed-off-by: liaoweixiong
---
fs/pstore/Kconfig | 7 +
fs/pstore/Makefile | 3 +
fs/pstore/romzone.c| 961 +
include/linux/pstore_rom.h | 61 +++
4 files changed, 1032 insertions(+)
create mode 100644 fs/pstore/romzone.c
create mode 100644 include/linux/pstore_rom.h
diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index 8b3ba27..abf0453 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -152,3 +152,10 @@ config PSTORE_RAM
"ramoops.ko".
For more information, see Documentation/admin-guide/ramoops.rst.
+
+config PSTORE_ROM
+ tristate "Log panic/oops to a block device"
+ depends on PSTORE
+ help
+ This enables panic and oops message to be logged to a block dev
+ where it can be read back at some later point.
diff --git a/fs/pstore/Makefile b/fs/pstore/Makefile
index 967b589..ea38d6e 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
+
+obj-$(CONFIG_PSTORE_ROM) += romoops.o
+romoops-y += romzone.o
diff --git a/fs/pstore/romzone.c b/fs/pstore/romzone.c
new file mode 100644
index 000..76a2648
--- /dev/null
+++ b/fs/pstore/romzone.c
@@ -0,0 +1,961 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
+ * romzone.c: ROM Oops/Panic logger
+ *
+ * Copyright (C) 2019 liaoweixiong
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#define pr_fmt(fmt) "romzone: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct romz_head - head of zone to flush to storage
+ *
+ * @sig: signature to indicate header (ROM_SIG xor ROMZONE-type value)
+ * @datalen: length of data in @data
+ * @data: zone data.
+ */
+struct romz_buffer {
+#define ROM_SIG (0x43474244) /* DBGC */
+ uint32_t sig;
+ atomic_t datalen;
+ uint8_t data[0];
+};
+
+/**
+ * sruct romz_dmesg_header: dmesg information
+ *
+ * @magic: magic num for dmesg header
+ * @time: trigger time
+ * @compressed: whether conpressed
+ * @count: oops/panic counter
+ * @reason: identify oops or panic
+ */
+struct romz_dmesg_header {
+#define DMESG_HEADER_MAGIC 0x4dfc3ae5
+ uint32_t magic;
+ struct timespec64 time;
+ bool compressed;
+ uint32_t counter;
+ enum kmsg_dump_reason reason;
+ uint8_t data[0];
+};
+
+/**
+ * struct romz_zone - zone information
+ * @off:
+ * zone offset of partition
+ * @type:
+ * frontent type for this zone
+ * @name:
+ * frontent name for this zone
+ * @buffer:
+ * pointer to data buffer managed by this zone
+ * @buffer_size:
+ * bytes in @buffer->data
+ * @should_recover:
+ * should recover from storage
+ * @dirty:
+ * mark whether the data in @buffer are dirty (not flush to storage yet)
+ */
+struct romz_zone {
+ unsigned long off;
+ const char *name;
+ enum pstore_type_id type;
+
+ struct romz_buffer *buffer;
+ size_t buffer_size;
+ bool should_recover;
+ atomic_t dirty;
+};
+
+struct romoops_context {
+ struct romz_zone **drzs;/* Oops dump zones */
+ unsigned int dmesg_max_cnt;
+ unsigned int dmesg_read_cnt;
+ unsigned int dmesg_write_cnt;
+ /**
+* the counter should be recovered when do recovery
+* It records the oops/panic times after burning rather than booting.
+*/
+
[PATCH] arm64: Mirror arm for small unimplemented compat syscalls
For syscall number smaller than 0xf, arm calls sys_ni_syscall
instead of arm_syscall in arch/arm/kernel/entry-common.S, which returns
-ENOSYS instead of raising SIGILL. Mirror this behavior for compat
syscalls in arm64.
Fixes: 532826f3712b607 ("arm64: Mirror arm for unimplemented compat
syscalls")
Signed-off-by: Pi-Hsun Shih
---
arch/arm64/kernel/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
index 8f3371415642ad..95fd8c7ec8a171 100644
--- a/arch/arm64/kernel/syscall.c
+++ b/arch/arm64/kernel/syscall.c
@@ -21,7 +21,7 @@ asmlinkage long do_ni_syscall(struct pt_regs *regs)
{
#ifdef CONFIG_COMPAT
long ret;
- if (is_compat_task()) {
+ if (is_compat_task() && regs->regs[7] >= __ARM_NR_COMPAT_BASE) {
ret = compat_arm_syscall(regs);
if (ret != -ENOSYS)
return ret;
--
2.20.1.415.g653613c723-goog
[PATCH] perf stat: Fix endless wait for child process
We hit a perf stat issue by using following script.
#!/bin/bash
sleep 1000 &
exec perf stat -a -e cycles -I1000 -- sleep 5
Since "perf stat" is launched by exec, so the "sleep 1000" would be
the child process of "perf stat". The wait4() will not return because
it's waiting for the child process "sleep 1000" to be end. So perf
stat doesn't return even 5s passed.
This patch lets the perf stat return when the specified child process
is end (in this case, specified child process is "sleep 5").
Signed-off-by: Jin Yao
---
tools/perf/builtin-stat.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 1410d66..63a3afc 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -561,7 +561,8 @@ static int __run_perf_stat(int argc, const char **argv, int
run_idx)
break;
}
}
- wait4(child_pid, , 0, _config.ru_data);
+ if (child_pid != -1)
+ wait4(child_pid, , 0, _config.ru_data);
if (workload_exec_errno) {
const char *emsg = str_error_r(workload_exec_errno,
msg, sizeof(msg));
--
2.7.4
Re: [v4 PATCH 2/2] mm: swap: add comment for swap_vma_readahead
Yang Shi writes:
> swap_vma_readahead()'s comment is missed, just add it.
>
> Cc: Huang Ying
> Cc: Tim Chen
> Cc: Minchan Kim
> Signed-off-by: Yang Shi
> ---
> mm/swap_state.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/mm/swap_state.c b/mm/swap_state.c
> index 78d500e..dd8f698 100644
> --- a/mm/swap_state.c
> +++ b/mm/swap_state.c
> @@ -698,6 +698,23 @@ static void swap_ra_info(struct vm_fault *vmf,
> pte_unmap(orig_pte);
> }
>
> +/**
> + * swap_vm_readahead - swap in pages in hope we need them soon
s/swap_vm_readahead/swap_vma_readahead/
> + * @entry: swap entry of this memory
> + * @gfp_mask: memory allocation flags
> + * @vmf: fault information
> + *
> + * Returns the struct page for entry and addr, after queueing swapin.
> + *
> + * Primitive swap readahead code. We simply read in a few pages whoes
> + * virtual addresses are around the fault address in the same vma.
> + *
> + * This has been extended to use the NUMA policies from the mm triggering
> + * the readahead.
What is this? I know you copy it from swap_cluster_readahead(), but we
have only one mm for vma readahead.
> + * Caller must hold down_read on the vma->vm_mm if vmf->vma is not NULL.
Better to make it explicit that your are talking about mmap_sem?
Best Regards,
Huang, Ying
> + *
> + */
> static struct page *swap_vma_readahead(swp_entry_t fentry, gfp_t gfp_mask,
> struct vm_fault *vmf)
> {
Re: Shaohua Li
Guoqing Jiang 于2019年1月3日周四 上午4:16写道： > > > > On 1/3/19 1:13 AM, Jens Axboe wrote: > > Hi, > > > > I've got some very sad news to share with you - over Christmas, Shaohua > > Li passed away after battling cancer for most of last year. > > It is really a sad news and a big lost for the community consider Shaohua's > great contribution! It's really a sad news, Shaohua is one of the best Chinese Linux Hackers. > > > As you know, Shaohua acted as the maintainer for md. He remained > > dedicated to that through the difficult times. With his passing, we > > obviously have a void that needs to be filled. > > It is better if there is a small team to maintain md in future since nobody > have broad/deep knowledge as Neil or Shaohua, also people in the team > can cover/backup each other, see [1]. Agree! > > > For now, I'll act as interim maintainer for md until we can find a good > > permanent solution. I'll queue up reviewed patches in a separate branch, > > in the block tree, and help review fixes. I'm subscribed to linux-raid, > > but please do CC me as well. > > Thanks, I think there are some patches in shli/md/for-next which supposed > to be merge to 4.21, could you please help to merge them to your branch? > And I suppose you will send a patch to CREDITS for Shaohua. +1 > > [1]. https://lkml.org/lkml/2015/12/21/9 > > Regards, > Guoqing Regards, Jack Wang
Re: [PATCH] kbuild: use assignment instead of define ... endef for filechk_* rules
On Thu, Jan 03, 2019 at 10:16:54AM +0900, Masahiro Yamada wrote: > You do not have to use define ... endef for filechk_* rules. > > For simple cases, the use of assignment looks cleaner, IMHO. > > I updated the usage for scripts/Kbuild.include in case somebody > misunderstands the 'define ... endif' is the requirement. > > Signed-off-by: Masahiro Yamada > --- > > Kbuild | 4 +--- > Makefile | 3 +-- > arch/s390/kernel/syscalls/Makefile | 12 +++- > arch/s390/tools/Makefile | 7 ++- > scripts/Kbuild.include | 8 > scripts/kconfig/Makefile | 4 +--- > 6 files changed, 12 insertions(+), 26 deletions(-) For the s390 bits: Acked-by: Heiko Carstens
Re: use generic DMA mapping code in powerpc V4
Hi Christian, happy new year and I hope you had a few restful deays off. I've pushed a new tree to: git://git.infradead.org/users/hch/misc.git powerpc-dma.6 Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Which has been rebased to the latests Linus tree, which has a lot of changes, and has also changed the patch split a bit to aid bisection. I think http://git.infradead.org/users/hch/misc.git/commitdiff/c446404b041130fbd9d1772d184f24715cf2362f might be a good commit to re-start testing, then bisecting up to the last commit using git bisect.
RFC: gpio: mmio: add support for 3 direction regs
Hi.
I'm working on a driver for STA2X11 GPIO controller who seems to fit best to
the generic mmio driver,
the only problem I have is with the dir register case.
The STA2X11 has 3 registers for dir, one for data, one for set and one for
clear.
The generic-mmio driver has support for this fashion for the dat & set & clear
registers but not for dirout/dirin registers.
I wonder if support for this is generic enough to deserve a patch, if so I'm
willing to quickly add this support, if not, adding a flag such as below, will
allow partly using the generic mmio driver only for set/get and the direction
can be handled outside the driver.
Thanks,
Ramon
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index a4d5eb3..4f91526 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -435,6 +435,7 @@ int bgpio_init(struct gpio_chip *gc, struct device *dev,
#define BGPIOF_BIG_ENDIAN_BYTE_ORDER BIT(3)
#define BGPIOF_READ_OUTPUT_REG_SET BIT(4) /* reg_set stores output value */
#define BGPIOF_NO_OUTPUT BIT(5) /* only input */
+#define BGPIOF_NO_DIRECTION BIT(6)
#endif
diff --git a/drivers/gpio/gpio-mmio.c b/drivers/gpio/gpio-mmio.c
index 935292a..66f6448 100644
--- a/drivers/gpio/gpio-mmio.c
+++ b/drivers/gpio/gpio-mmio.c
@@ -554,6 +554,8 @@ static int bgpio_setup_direction(struct gpio_chip *gc,
gc->direction_input = bgpio_dir_in;
gc->get_direction = bgpio_get_dir;
gc->bgpio_dir_inverted = true;
+ } else if (flags & BGPIOF_NO_DIRECTION) {
+ return 0;
} else {
if (flags & BGPIOF_NO_OUTPUT)
gc->direction_output = bgpio_dir_out_err;
@@ -638,7 +640,7 @@ int bgpio_init(struct gpio_chip *gc, struct device *dev,
if (gc->set == bgpio_set_set &&
!(flags & BGPIOF_UNREADABLE_REG_SET))
gc->bgpio_data = gc->read_reg(gc->reg_set);
- if (gc->reg_dir && !(flags & BGPIOF_UNREADABLE_REG_DIR))
+ if (gc->reg_dir && !(flags & (BGPIOF_UNREADABLE_REG_DIR |
BGPIOF_NO_DIRECTION)))
gc->bgpio_dir = gc->read_reg(gc->reg_dir);
return ret;
[PATCH V2 mips-fixes] MIPS: BCM47XX: Setup struct device for the SoC
From: Rafał Miłecki
So far we never had any device registered for the SoC. This resulted in
some small issues that we kept ignoring like:
1) Not working GPIOLIB_IRQCHIP (gpiochip_irqchip_add_key() failing)
2) Lack of proper tree in the /sys/devices/
3) mips_dma_alloc_coherent() silently handling empty coherent_dma_mask
Kernel 4.19 came with a lot of DMA changes and caused a regression on
bcm47xx. Starting with the commit f8c55dc6e828 ("MIPS: use generic dma
noncoherent ops for simple noncoherent platforms") DMA coherent
allocations just fail. Example:
[1.114914] bgmac_bcma bcma0:2: Allocation of TX ring 0x200 failed
[1.121215] bgmac_bcma bcma0:2: Unable to alloc memory for DMA
[1.127626] bgmac_bcma: probe of bcma0:2 failed with error -12
[1.133838] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded
The bgmac driver also triggers a WARNING:
[0.959486] [ cut here ]
[0.964387] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516
bgmac_enet_probe+0x1b4/0x5c4
[0.973751] Modules linked in:
[0.976913] CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.9 #0
[0.982750] Stack : 804a 804597c4 80458fd8 8381bc2c
838282d4 80481a47
[0.991367] 8042e3ec 0001 804d38f0 0204 8398 0065
8381bbe0 6f55b24f
[0.75] 8052 2018 0075
0007
[1.008583] 8048 000ee811
80432c00 80248db8
[1.017196] 0009 0204 8398 803ad7b0 801feeec
804d
[1.025804] ...
[1.028325] Call Trace:
[1.030875] [<8000aef8>] show_stack+0x58/0x100
[1.035513] [<8001f8b4>] __warn+0xe4/0x118
[1.039708] [<8001f9a4>] warn_slowpath_null+0x48/0x64
[1.044935] [<80248db8>] bgmac_enet_probe+0x1b4/0x5c4
[1.050101] [<802498e0>] bgmac_probe+0x558/0x590
[1.054906] [<80252fd0>] bcma_device_probe+0x38/0x70
[1.060017] [<8020e1e8>] really_probe+0x170/0x2e8
[1.064891] [<8020e714>] __driver_attach+0xa4/0xec
[1.069784] [<8020c1e0>] bus_for_each_dev+0x58/0xb0
[1.074833] [<8020d590>] bus_add_driver+0xf8/0x218
[1.079731] [<8020ef24>] driver_register+0xcc/0x11c
[1.084804] [<804b54cc>] bgmac_init+0x1c/0x44
[1.089258] [<8000121c>] do_one_initcall+0x7c/0x1a0
[1.094343] [<804a1d34>] kernel_init_freeable+0x150/0x218
[1.099886] [<803a082c>] kernel_init+0x10/0x104
[1.104583] [<80005878>] ret_from_kernel_thread+0x14/0x1c
[1.110107] ---[ end trace f441c0d873d1fb5b ]---
This patch setups a "struct device" (and passes it to the bcma) which
allows fixing all the mentioned problems. It'll also require a tiny bcma
patch which will follow through the wireless tree & its maintainer.
Fixes: f8c55dc6e828 ("MIPS: use generic dma noncoherent ops for simple
noncoherent platforms")
Cc: Christoph Hellwig
Cc: Linus Walleij
Cc: linux-wirel...@vger.kernel.org
Cc: sta...@vger.kernel.org # v4.19+
Signed-off-by: Rafał Miłecki
Acked-by: Hauke Mehrtens
---
V2: Reorder struct bcma_soc fields (trivial optimization - thanks Hauke)
Add pr_err on error
---
arch/mips/bcm47xx/setup.c | 31 +++
include/linux/bcma/bcma_soc.h | 1 +
2 files changed, 32 insertions(+)
diff --git a/arch/mips/bcm47xx/setup.c b/arch/mips/bcm47xx/setup.c
index 6054d49e608e..fe3773539eff 100644
--- a/arch/mips/bcm47xx/setup.c
+++ b/arch/mips/bcm47xx/setup.c
@@ -173,6 +173,31 @@ void __init plat_mem_setup(void)
pm_power_off = bcm47xx_machine_halt;
}
+#ifdef CONFIG_BCM47XX_BCMA
+static struct device * __init bcm47xx_setup_device(void)
+{
+ struct device *dev;
+ int err;
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return NULL;
+
+ err = dev_set_name(dev, "bcm47xx_soc");
+ if (err) {
+ pr_err("Failed to set SoC device name: %d\n", err);
+ kfree(dev);
+ return NULL;
+ }
+
+ err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
+ if (err)
+ pr_err("Failed to set SoC DMA mask: %d\n", err);
+
+ return dev;
+}
+#endif
+
/*
* This finishes bus initialization doing things that were not possible without
* kmalloc. Make sure to call it late enough (after mm_init).
@@ -183,6 +208,10 @@ void __init bcm47xx_bus_setup(void)
if (bcm47xx_bus_type == BCM47XX_BUS_TYPE_BCMA) {
int err;
+ bcm47xx_bus.bcma.dev = bcm47xx_setup_device();
+ if (!bcm47xx_bus.bcma.dev)
+ panic("Failed to setup SoC device\n");
+
err = bcma_host_soc_init(_bus.bcma);
if (err)
panic("Failed to initialize BCMA bus (err %d)", err);
@@ -235,6 +264,8 @@ static int __init bcm47xx_register_bus_complete(void)
#endif
#ifdef CONFIG_BCM47XX_BCMA
case BCM47XX_BUS_TYPE_BCMA:
+ if
Re: [PATCH 02/15] swiotlb: remove dma_mark_clean
On Wed, Jan 02, 2019 at 01:53:33PM -0800, Tony Luck wrote: > On Fri, Dec 7, 2018 at 11:08 AM Christoph Hellwig wrote: > > > > Instead of providing a special dma_mark_clean hook just for ia64, switch > > ia64 to use the normal arch_sync_dma_for_cpu hooks instead. > > > > This means that we now also set the PG_arch_1 bit for pages in the > > swiotlb buffer, which isn't stricly needed as we will never execute code > > out of the swiotlb buffer, but otherwise harmless. > > ia64 build based on arch/ia64/configs/zx1_defconfig now fails with undefined > symbols arch_dma_alloc and arch_dma_free (used by kernel/dma/direct.c). > > This config doesn't define CONFIG_SWIOTLB, so we don't get the > benefit of the routines in arch/ia64/kernel/dma-mapping.c I think something like the patch below should fix it: diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index ccd56f5df8cd..8d7396bd1790 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -31,7 +31,7 @@ config IA64 select HAVE_MEMBLOCK_NODE_MAP select HAVE_VIRT_CPU_ACCOUNTING select ARCH_HAS_DMA_COHERENT_TO_PFN if SWIOTLB - select ARCH_HAS_SYNC_DMA_FOR_CPU + select ARCH_HAS_SYNC_DMA_FOR_CPU if SWIOTLB select VIRT_TO_BUS select ARCH_DISCARD_MEMBLOCK select GENERIC_IRQ_PROBE
Re: [PATCH v4 04/10] KVM/x86: intel_pmu_lbr_enable
On 01/03/2019 07:26 AM, Jim Mattson wrote: On Wed, Dec 26, 2018 at 2:01 AM Wei Wang wrote: The lbr stack is architecturally specific, for example, SKX has 32 lbr stack entries while HSW has 16 entries, so a HSW guest running on a SKX machine may not get accurate perf results. Currently, we forbid the guest lbr enabling when the guest and host see different lbr stack entries. How do you handle live migration? This feature is gated by the QEMU "lbr=true" option. So if the lbr fails to work on the destination machine, the destination side QEMU wouldn't be able to boot, and migration will not happen. Best, Wei
Re: [BUG] dev_pm_opp refcount issue on Arm Juno r0
On 20-12-18, 15:27, Valentin Schneider wrote:
> Hi,
>
> While running some hotplug torture test [1] on my Juno r0 I came across
> the follow splat:
>
> [ 716.561862] [ cut here ]
> [ 716.566451] refcount_t: underflow; use-after-free.
> [ 716.571240] WARNING: CPU: 2 PID: 18 at lib/refcount.c:280
> refcount_dec_not_one+0x9c/0xc0
> [ 716.579246] Modules linked in:
> [ 716.582269] CPU: 2 PID: 18 Comm: cpuhp/2 Not tainted 4.20.0-rc7 #39
> [ 716.588469] Hardware name: ARM Juno development board (r0) (DT)
> [ 716.594326] pstate: 4005 (nZcv daif -PAN -UAO)
> [ 716.599065] pc : refcount_dec_not_one+0x9c/0xc0
> [ 716.603546] lr : refcount_dec_not_one+0x9c/0xc0
> [ 716.608024] sp : 0a063c70
> [ 716.611299] x29: 0a063c70 x28:
> [ 716.616555] x27: x26: 0002
> [ 716.621810] x25: 09169000 x24: 08f8e1b0
> [ 716.627065] x23: 08ce0920 x22:
> [ 716.632319] x21: 09169000 x20: 8009762a2664
> [ 716.637574] x19: 09294a90 x18: 0400
> [ 716.642828] x17: x16:
> [ 716.648082] x15: x14: 0400
> [ 716.653336] x13: 023f x12: 00043705
> [ 716.658590] x11: 0108 x10: 0960
> [ 716.663844] x9 : 0a063970 x8 : 800976943ec0
> [ 716.669098] x7 : x6 : 80097ff720b8
> [ 716.674353] x5 : 80097ff720b8 x4 :
> [ 716.679607] x3 : 80097ff78e68 x2 : 80097ff720b8
> [ 716.684861] x1 : 6374e2a7925c1100 x0 :
> [ 716.690115] Call trace:
> [ 716.692532] refcount_dec_not_one+0x9c/0xc0
> [ 716.696669] refcount_dec_and_mutex_lock+0x18/0x70
> [ 716.701409] _put_opp_list_kref+0x28/0x50
> [ 716.705373] _dev_pm_opp_find_and_remove_table+0x24/0x88
> [ 716.710628] _dev_pm_opp_cpumask_remove_table+0x50/0xa0
> [ 716.715796] dev_pm_opp_cpumask_remove_table+0x10/0x18
> [ 716.720879] scpi_cpufreq_exit+0x40/0x50
> [ 716.724758] cpufreq_offline+0x108/0x1e0
> [ 716.728637] cpuhp_cpufreq_offline+0xc/0x18
This probably happened due to some of recent OPP core changes and I missed
updating this platform (I updated mvebu though). The problem is completely
different from what you logs show :)
Please try the below patch.
@Sudeep: Please help review it as well.
--
viresh
-8<-
>From f3913738618031e9d71ebf64461cee22909e6e20 Mon Sep 17 00:00:00 2001
Message-Id:
From: Viresh Kumar
Date: Thu, 3 Jan 2019 12:28:26 +0530
Subject: [PATCH] cpufreq: scpi: Fix freeing of OPPs
Since the commit 2a4eb7358aba ("OPP: Don't remove dynamic OPPs from
_dev_pm_opp_remove_table()"), dynamically created OPP aren't
automatically removed anymore by dev_pm_opp_cpumask_remove_table().
The OPPs for scpi cpufreq driver aren't getting freed currently, fix
that by adding a new callback scpi_ops->remove_device_opps() which will
remove those OPPs.
Cc: 4.20 # v4.20
Reported-by: Valentin Schneider
Fixes: 2a4eb7358aba ("OPP: Don't remove dynamic OPPs from
_dev_pm_opp_remove_table()")
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/scpi-cpufreq.c | 4 ++--
drivers/firmware/arm_scpi.c| 15 +++
include/linux/scpi_protocol.h | 1 +
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/scpi-cpufreq.c b/drivers/cpufreq/scpi-cpufreq.c
index 87a98ec3..1bfd168de0b2 100644
--- a/drivers/cpufreq/scpi-cpufreq.c
+++ b/drivers/cpufreq/scpi-cpufreq.c
@@ -177,7 +177,7 @@ static int scpi_cpufreq_init(struct cpufreq_policy *policy)
out_free_priv:
kfree(priv);
out_free_opp:
- dev_pm_opp_cpumask_remove_table(policy->cpus);
+ scpi_ops->remove_device_opps(cpu_dev);
return ret;
}
@@ -190,7 +190,7 @@ static int scpi_cpufreq_exit(struct cpufreq_policy *policy)
clk_put(priv->clk);
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, >freq_table);
kfree(priv);
- dev_pm_opp_cpumask_remove_table(policy->related_cpus);
+ scpi_ops->remove_device_opps(priv->cpu_dev);
return 0;
}
diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index c7d06a36b23a..963f2ffbd820 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -716,6 +716,20 @@ static int scpi_dvfs_add_opps_to_device(struct device *dev)
return 0;
}
+static void scpi_dvfs_remove_device_opps(struct device *dev)
+{
+ int idx;
+ struct scpi_opp *opp;
+ struct scpi_dvfs_info *info = scpi_dvfs_info(dev);
+
+ /* We already added OPPs successfully, this data can't be invalid */
+ if (WARN_ON(IS_ERR(info) || !info->opps))
+ return;
+
+ for (opp = info->opps, idx = 0; idx < info->count; idx++, opp++)
+ dev_pm_opp_remove(dev, opp->freq);
+}
+
static int scpi_sensor_get_capability(u16 *sensors)
{
Re: [PATCH v5 2/3] thermal: broadcom: Add Stingray thermal driver
Hi Eduardo Valentin,
Thank you for the review. I will address your comments in next patchset.
Please find my comments in lined.
On Thu, Jan 3, 2019 at 1:33 AM Eduardo Valentin wrote:
>
> On Tue, Oct 16, 2018 at 08:41:19PM +0530, Srinath Mannam wrote:
> > From: Pramod Kumar
> >
> > Stingray SoC has six temperature sensor and those are
> > configured, controlled and accessed to read temperature
> > and update in DDR memory using m0 firmware.
> > All six sensors has been given 4 bytes of memory in DDR
> > to write temperature in millivolts.
> >
> > This thermal driver read temperature values from DDR
> > because no direct access to sensors.
> > Like this all temparature sensors are monitored and
> > trips at critical temperature.
> >
> > If driver can't handle thermal runaways because of
> > any unknown reason, then firmware in m0 Processor
> > will handle.
> >
> > Signed-off-by: Pramod Kumar
> > Signed-off-by: Srinath Mannam
> > Reviewed-by: Ray Jui
> > Reviewed-by: Scott Branden
> > Reviewed-by: Vikram Prakash
> > ---
> > drivers/thermal/Kconfig | 3 +-
> > drivers/thermal/broadcom/Kconfig | 9 +++
> > drivers/thermal/broadcom/Makefile | 1 +
> > drivers/thermal/broadcom/sr-thermal.c | 138
> > ++
> > 4 files changed, 150 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/thermal/broadcom/sr-thermal.c
> >
> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > index 0e69edc..5f9f070 100644
> > --- a/drivers/thermal/Kconfig
> > +++ b/drivers/thermal/Kconfig
> > @@ -416,7 +416,8 @@ config MTK_THERMAL
> > controller present in Mediatek SoCs
> >
> > menu "Broadcom thermal drivers"
> > -depends on ARCH_BCM || ARCH_BRCMSTB || ARCH_BCM2835 || COMPILE_TEST
> > +depends on ARCH_BCM || ARCH_BRCMSTB || ARCH_BCM2835 || ARCH_BCM_IPROC || \
> > + COMPILE_TEST
> > source "drivers/thermal/broadcom/Kconfig"
> > endmenu
> >
> > diff --git a/drivers/thermal/broadcom/Kconfig
> > b/drivers/thermal/broadcom/Kconfig
> > index c106a15..dc9a9bd 100644
> > --- a/drivers/thermal/broadcom/Kconfig
> > +++ b/drivers/thermal/broadcom/Kconfig
> > @@ -22,3 +22,12 @@ config BCM_NS_THERMAL
> > BCM4708, BCM4709, BCM5301x, BCM95852X, etc). It contains DMU (Device
> > Management Unit) block with a thermal sensor that allows checking
> > CPU
> > temperature.
> > +
> > +config BCM_SR_THERMAL
> > + tristate "Stingray thermal driver"
> > + depends on ARCH_BCM_IPROC || COMPILE_TEST
> > + default ARCH_BCM_IPROC
> > + help
> > + Support for the Stingray family of SoCs. Its different blocks like
> > + iHost, CRMU and NITRO has thermal sensor that allows checking its
> > + temperature.
> > diff --git a/drivers/thermal/broadcom/Makefile
> > b/drivers/thermal/broadcom/Makefile
> > index fae10ec..79df69e 100644
> > --- a/drivers/thermal/broadcom/Makefile
> > +++ b/drivers/thermal/broadcom/Makefile
> > @@ -1,3 +1,4 @@
> > obj-$(CONFIG_BCM2835_THERMAL)+= bcm2835_thermal.o
> > obj-$(CONFIG_BRCMSTB_THERMAL)+= brcmstb_thermal.o
> > obj-$(CONFIG_BCM_NS_THERMAL) += ns-thermal.o
> > +obj-$(CONFIG_BCM_SR_THERMAL) += sr-thermal.o
> > diff --git a/drivers/thermal/broadcom/sr-thermal.c
> > b/drivers/thermal/broadcom/sr-thermal.c
> > new file mode 100644
> > index 000..f45e12e
> > --- /dev/null
> > +++ b/drivers/thermal/broadcom/sr-thermal.c
> > @@ -0,0 +1,138 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018 Broadcom
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/*
> > + * In stingray thermal IO memory,
> > + * Total Number of available TMONs MASK is at offset 0
> > + * temperature registers BASE is at 4 byte offset.
> > + * Each TMON temperature register size is 4.
> > + */
> > +#define SR_TMON_TEMP_BASE(id) ((id) * 0x4)
> > +
> > +#define SR_TMON_MAX_LIST6
> > +
> > +struct sr_tmon {
> > + struct thermal_zone_device *tz;
> > + unsigned int crit_temp;
> > + unsigned int tmon_id;
> > + struct sr_thermal *priv;
> > +};
> > +
> > +struct sr_thermal {
> > + void __iomem *regs;
> > + unsigned int max_crit_temp;
> > + struct sr_tmon tmon[SR_TMON_MAX_LIST];
> > +};
> > +
> > +static int sr_get_temp(void *data, int *temp)
> > +{
> > + struct sr_tmon *tmon = data;
> > + struct sr_thermal *sr_thermal = tmon->priv;
> > +
> > + *temp = readl(sr_thermal->regs + SR_TMON_TEMP_BASE(tmon->tmon_id));
> > +
> > + return 0;
> > +}
> > +
> > +static const struct thermal_zone_of_device_ops sr_tz_ops = {
> > + .get_temp = sr_get_temp,
> > +};
> > +
> > +static int sr_thermal_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = >dev;
> > + struct sr_thermal *sr_thermal;
> > + struct sr_tmon *tmon;
> > + struct resource *res;
> > + uint32_t sr_tmon_list = 0;
> > + unsigned int
Re: [PATCH v1 0/2] Virtio: fix some vq allocation issues
On 12/28/2018 03:57 PM, Christian Borntraeger wrote: On 28.12.2018 03:26, Wei Wang wrote: Some vqs don't need to be allocated when the related feature bits are disabled. Callers notice the vq allocation layer by setting the related names[i] to be NULL. This patch series fixes the find_vqs implementations to handle this case. So the random crashes during boot are gone. What still does not work is actually using the balloon. So in the qemu monitor using lets say "balloon 1000" will hang the guest. Seems to be a deadlock in the virtio-ccw code. We seem to call the config code in the interrupt handler. Please try with applying both this series and the "virtio-balloon: tweak config_changed" series that I just sent. This series fixes the ccw booting issue and that series tries to fix the ccw deadlock issue. Best, Wei
[GIT] Networking
Several fixes here. Basically split down the line between newly
introduced regressions and long existing problems:
1) Double free in tipc_enable_bearer(), from Cong Wang.
2) Many fixes to nf_conncount, from Florian Westphal.
3) op->get_regs_len() can throw an error, check it, from Yunsheng Lin.
4) Need to use GFP_ATOMIC in *_add_hash_mac_address() of fsl/fman
driver, from Scott Wood.
5) Inifnite loop in fib_empty_table(), from Yue Haibing.
6) Use after free in ax25_fillin_cb(), from Cong Wang.
7) Fix socket locking in nr_find_socket(), also from Cong Wang.
8) Fix WoL wakeup enable in r8169, from Heiner Kallweit.
9) On 32-bit sock->sk_stamp is not thread-safe, from Deepa Dinamani.
10) Fix ptr_ring wrap during queue swap, from Cong Wang.
11) Missing shutdown callback in hinic driver, from Xue Chaojing.
12) Need to return NULL on error from ip6_neigh_lookup(), from Stefano
Brivio.
13) BPF out of bounds speculation fixes from Daniel Borkmann.
Please pull, thanks a lot!
The following changes since commit b71acb0e372160167bf6d5500b88b30b52ccef6e:
Merge branch 'linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 (2018-12-27
13:53:32 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
for you to fetch changes up to c5ee066333ebc322a24a00a743ed941a0c68617e:
ipv6: Consider sk_bound_dev_if when binding a socket to an address
(2019-01-02 20:16:37 -0800)
Aditya Pakki (2):
ipv6/route: Add a missing check on proc_dointvec
net: chelsio: Add a missing check on cudg_get_buffer
Alexei Starovoitov (1):
Merge branch 'prevent-oob-under-speculation'
Christophe JAILLET (1):
net/ipv6: Fix a test against 'ipv6_find_idev()' return value
Cong Wang (5):
tipc: fix a double free in tipc_enable_bearer()
ax25: fix a use-after-free in ax25_fillin_cb()
net/wan: fix a double free in x25_asy_open_tty()
netrom: fix locking in nr_find_socket()
ptr_ring: wrap back ->producer in __ptr_ring_swap_queue()
Daniel Borkmann (9):
bpf: move {prev_,}insn_idx into verifier env
bpf: move tmp variable into ax register in interpreter
bpf: enable access to ax register also from verifier rewrite
bpf: restrict map value pointer arithmetic for unprivileged
bpf: restrict stack pointer arithmetic for unprivileged
bpf: restrict unknown scalars of mixed signed bounds for unprivileged
bpf: fix check_map_access smin_value test when pointer contains offset
bpf: prevent out of bounds speculation on pointer arithmetic
bpf: add various test cases to selftests
David Ahern (2):
ipv6: Fix dump of specific table with strict checking
ipv6: Consider sk_bound_dev_if when binding a socket to an address
David S. Miller (2):
Merge git://git.kernel.org/.../pablo/nf
Merge git://git.kernel.org/.../bpf/bpf
Deepa Dinamani (1):
sock: Make sock->sk_stamp thread-safe
Eric Dumazet (2):
net/hamradio/6pack: use mod_timer() to rearm timers
isdn: fix kernel-infoleak in capi_unlocked_ioctl
Florian Westphal (5):
netfilter: nf_conncount: don't skip eviction when age is negative
netfilter: nf_conncount: split gc in two phases
netfilter: nf_conncount: restart search when nodes have been erased
netfilter: nf_conncount: merge lookup and add functions
netfilter: nf_conncount: fix argument order to find_next_bit
Heiner Kallweit (1):
r8169: fix WoL device wakeup enable
Huazhong Tan (1):
net: hns3: call hns3_nic_net_open() while doing HNAE3_UP_CLIENT
Jia-Ju Bai (1):
isdn: hisax: hfc_pci: Fix a possible concurrency use-after-free bug in
HFCPCI_l1hw()
Kangjie Lu (8):
niu: fix missing checks of niu_pci_eeprom_read
net: (cpts) fix a missing check of clk_prepare
net: stmicro: fix a missing check of clk_prepare
net: dsa: bcm_sf2: Propagate error value from mdio_write
atl1e: checking the status of atl1e_write_phy_reg
tipc: fix a missing check of genlmsg_put
net: marvell: fix a missing check of acpi_match_device
netfilter: nf_tables: fix a missing check of nla_put_failure
Nikolay Aleksandrov (1):
net: rtnetlink: address is mandatory for rtnl_fdb_get
Pablo Neira Ayuso (2):
netfilter: nf_conncount: move all list iterations under spinlock
netfilter: nf_conncount: speculative garbage collection on empty lists
Robert P. J. Day (2):
phy.h: fix obvious errors in doc and kerneldoc content
include/linux/phy/phy.h: fix minor kerneldoc errors
Scott Wood (1):
fsl/fman: Use GFP_ATOMIC in {memac,tgec}_add_hash_mac_address()
Shawn Bohrer (1):
netfilter: nf_conncount: replace CONNCOUNT_LOCK_SLOTS with CONNCOUNT_SLOTS
Stefano Brivio (1):
ipv6: route: Fix return value of ip6_neigh_lookup() on neigh_create()
error
Su Yanjun (1):
ipv6: fix
Re: [GIT PULL] Please pull NFS client updates for 4.21
On Thu, 2019-01-03 at 15:53 +1100, NeilBrown wrote: > On Wed, Jan 02 2019, Linus Torvalds wrote: > > > On Wed, Jan 2, 2019 at 2:42 PM Schumaker, Anna > > wrote: > > > We also were unable to track down a maintainer for Neil Brown's > > > changes to > > > the generic cred code that are prerequisites to his RPC cred > > > cleanup patches. > > > We've been asking around for several months without any response, > > > so > > > hopefully it's okay to include those patches in this pull > > > request. > > > > Looks ok to me, although I wonder what the semantics of > > cred_fscmp() > > are across namespaces? > > > > IOW, it seems potentially a bit suspicious to do cred_fscmp() if > > the > > two creds have different namnespaces? Hmm? > > > > Is there some reason that can't happen, or some reason it doesn't > > matter? > > > > Linus > > Interesting question. > For the current use in NFS, it is consistent with existing practice > to > ignore the name space. > NFS file accesses (when using the normal uid-based access checks) > always > use the manifest uid of the process - the one returned by getuid() > (or > more accurately, getfsuid()). > Maybe this is wrong? Maybe we should always use from_kuid() or > whatever > to get the uid/gid to send over the wire? > > Anna/Trond: do you have thoughts on this? If a process in a user > namespace accesses a file over NFS, should the UID presented to the > server be the one in that name-space, or the one you get by mapping > to > the global name-space? > Or should we map to the namespace that was active when the filesystem > was mounted? > > I don't think cred_fscmp() should do any of this mapping, but maybe > it > should treat creds from different namespaces as different - as a > precaution. > > Thanks, > NeilBrown The values being compared are in cred_fscmp() are all of type kuid_t or kgid_t so that means they have already been mapped from the user namespace into the kernel uid/gid space. When we put those kuid/kgid values onto the wire, we currently always use the init namespace rather than the user namespace of the mount process. When using strong authentication (i.e. krb5) then none of this matters, since the server performs its own mapping of the presented RPCSEC_GSS session into a credential. That mapping is independent of the user namespace on the client, it just depends on which krb5 principal the process used to identify itself. The problem case is limited to when we're using the weak AUTH_UNIX authentication, since the server is then implicitly trusting the client to protect against identity spoofing. This is particularly true if the NFS server is being accessed through NAT, in which case it has very limited possibilities for discriminating between containers on the same client using the export table because they will all originate from the same source IP address. I think that for these cases, using the init namespace is the right thing to do for the same reason we use it with local filesystems: if we try to use a different namespace then unprivileged userspace processes might be able to manipulate the mapping to spoof the identities of privileged users or groups, or otherwise gain access to files to which they normally should not have access. Does that argument make sense? -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.mykleb...@hammerspace.com signature.asc Description: This is a digitally signed message part
[PATCH v1 1/2] virtio-balloon: tweak config_changed implementation
virtio-ccw has deadlock issues with reading config registers inside the
interrupt context, so we tweak the virtballoon_changed implementation
by moving the config read operations into the related workqueue contexts.
Signed-off-by: Wei Wang
---
drivers/virtio/virtio_balloon.c | 54 -
1 file changed, 26 insertions(+), 28 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 728ecd1..9a82a11 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -394,33 +394,15 @@ static void virtballoon_changed(struct virtio_device
*vdev)
{
struct virtio_balloon *vb = vdev->priv;
unsigned long flags;
- s64 diff = towards_target(vb);
-
- if (diff) {
- spin_lock_irqsave(>stop_update_lock, flags);
- if (!vb->stop_update)
- queue_work(system_freezable_wq,
- >update_balloon_size_work);
- spin_unlock_irqrestore(>stop_update_lock, flags);
- }
- if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
- virtio_cread(vdev, struct virtio_balloon_config,
-free_page_report_cmd_id, >cmd_id_received);
- if (vb->cmd_id_received == VIRTIO_BALLOON_CMD_ID_DONE) {
- /* Pass ULONG_MAX to give back all the free pages */
- return_free_pages_to_mm(vb, ULONG_MAX);
- } else if (vb->cmd_id_received != VIRTIO_BALLOON_CMD_ID_STOP &&
- vb->cmd_id_received !=
- virtio32_to_cpu(vdev, vb->cmd_id_active)) {
- spin_lock_irqsave(>stop_update_lock, flags);
- if (!vb->stop_update) {
- queue_work(vb->balloon_wq,
- >report_free_page_work);
- }
- spin_unlock_irqrestore(>stop_update_lock, flags);
- }
+ spin_lock_irqsave(>stop_update_lock, flags);
+ if (!vb->stop_update) {
+ queue_work(system_freezable_wq,
+ >update_balloon_size_work);
+ if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
+ queue_work(vb->balloon_wq, >report_free_page_work);
}
+ spin_unlock_irqrestore(>stop_update_lock, flags);
}
static void update_balloon_size(struct virtio_balloon *vb)
@@ -637,11 +619,9 @@ static int send_free_pages(struct virtio_balloon *vb)
return 0;
}
-static void report_free_page_func(struct work_struct *work)
+static void virtio_balloon_report_free_page(struct virtio_balloon *vb)
{
int err;
- struct virtio_balloon *vb = container_of(work, struct virtio_balloon,
-report_free_page_work);
struct device *dev = >vdev->dev;
/* Start by sending the received cmd id to host with an outbuf. */
@@ -659,6 +639,24 @@ static void report_free_page_func(struct work_struct *work)
dev_err(dev, "Failed to send a stop id, err = %d\n", err);
}
+static void report_free_page_func(struct work_struct *work)
+{
+ struct virtio_balloon *vb = container_of(work, struct virtio_balloon,
+report_free_page_work);
+
+ virtio_cread(vb->vdev, struct virtio_balloon_config,
+free_page_report_cmd_id, >cmd_id_received);
+
+ if (vb->cmd_id_received == VIRTIO_BALLOON_CMD_ID_DONE) {
+ /* Pass ULONG_MAX to give back all the free pages */
+ return_free_pages_to_mm(vb, ULONG_MAX);
+ } else if (vb->cmd_id_received != VIRTIO_BALLOON_CMD_ID_STOP &&
+ vb->cmd_id_received !=
+ virtio32_to_cpu(vb->vdev, vb->cmd_id_active)) {
+ virtio_balloon_report_free_page(vb);
+ }
+}
+
#ifdef CONFIG_BALLOON_COMPACTION
/*
* virtballoon_migratepage - perform the balloon page migration on behalf of
--
2.7.4
[PATCH v1 2/2] virtio-balloon: improve update_balloon_size_func
There is no need to update the balloon actual register when there is no ballooning request. This patch avoids update_balloon_size when diff is 0. Signed-off-by: Wei Wang --- drivers/virtio/virtio_balloon.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index 9a82a11..4884b85 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -435,9 +435,12 @@ static void update_balloon_size_func(struct work_struct *work) update_balloon_size_work); diff = towards_target(vb); + if (!diff) + return; + if (diff > 0) diff -= fill_balloon(vb, diff); - else if (diff < 0) + else diff += leak_balloon(vb, -diff); update_balloon_size(vb); -- 2.7.4
[PATCH v1 0/2] virtio-balloon: tweak config_changed
Since virtio-ccw doesn't work with accessing to the config registers inside an interrupt context, this patch series avoids that issue by moving the config register accesses to the related workqueue contexts. Wei Wang (2): virtio-balloon: tweak config_changed implementation virtio-balloon: improve update_balloon_size_func drivers/virtio/virtio_balloon.c | 59 + 1 file changed, 30 insertions(+), 29 deletions(-) -- 2.7.4
Re: [PATCH v2 2/2] mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures (i929)
Hi Olof, Eduardo,
On 03/01/19 1:26 AM, Eduardo Valentin wrote:
> On Wed, Jan 02, 2019 at 10:29:31AM -0800, Olof Johansson wrote:
>> Hi,
>>
>>
>> On Wed, Dec 12, 2018 at 1:20 AM Ulf Hansson wrote:
>>>
>>> + Thermal maintainers
>>>
>>> On Tue, 11 Dec 2018 at 15:20, Faiz Abbas wrote:
>>>>
>>>> Errata i929 in certain OMAP5/DRA7XX/AM57XX silicon revisions
>>>> (SPRZ426D - November 2014 - Revised February 2018 [1]) mentions
>>>> unexpected tuning pattern errors. A small failure band may be present
>>>> in the tuning range which may be missed by the current algorithm.
>>>> Furthermore, the failure bands vary with temperature leading to
>>>> different optimum tuning values for different temperatures.
>>>>
>>>> As suggested in the related Application Report (SPRACA9B - October 2017
>>>> - Revised July 2018 [2]), tuning should be done in two stages.
>>>> In stage 1, assign the optimum ratio in the maximum pass window for the
>>>> current temperature. In stage 2, if the chosen value is close to the
>>>> small failure band, move away from it in the appropriate direction.
>>>>
>>>> References:
>>>> [1] http://www.ti.com/lit/pdf/sprz426
>>>> [2] http://www.ti.com/lit/pdf/SPRACA9
>>>>
>>>> Signed-off-by: Faiz Abbas
>>>> Acked-by: Adrian Hunter
>>>> ---
>>>> drivers/mmc/host/Kconfig | 2 +
>>>> drivers/mmc/host/sdhci-omap.c | 90 ++-
>>>> 2 files changed, 91 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
>>>> index 5fa580cec831..d8f984483ab0 100644
>>>> --- a/drivers/mmc/host/Kconfig
>>>> +++ b/drivers/mmc/host/Kconfig
>>>> @@ -977,6 +977,8 @@ config MMC_SDHCI_XENON
>>>> config MMC_SDHCI_OMAP
>>>> tristate "TI SDHCI Controller Support"
>>>> depends on MMC_SDHCI_PLTFM && OF
>>>> + select THERMAL
>>>> + select TI_SOC_THERMAL
>>>> help
>>>> This selects the Secure Digital Host Controller Interface (SDHCI)
>>>> support present in TI's DRA7 SOCs. The controller supports
>>>> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
>>>> index f588ab679cb0..b75c55011fcb 100644
>>>> --- a/drivers/mmc/host/sdhci-omap.c
>>>> +++ b/drivers/mmc/host/sdhci-omap.c
>>>> @@ -27,6 +27,7 @@
>>>> #include
>>>> #include
>>>> #include
>>>> +#include
>>>>
>>>> #include "sdhci-pltfm.h"
>>>>
>>>> @@ -286,15 +287,19 @@ static int sdhci_omap_execute_tuning(struct mmc_host
>>>> *mmc, u32 opcode)
>>>> struct sdhci_host *host = mmc_priv(mmc);
>>>> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>>> struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host);
>>>> + struct thermal_zone_device *thermal_dev;
>>>> struct device *dev = omap_host->dev;
>>>> struct mmc_ios *ios = >ios;
>>>> u32 start_window = 0, max_window = 0;
>>>> + bool single_point_failure = false;
>>>> bool dcrc_was_enabled = false;
>>>> u8 cur_match, prev_match = 0;
>>>> u32 length = 0, max_len = 0;
>>>> u32 phase_delay = 0;
>>>> + int temperature;
>>>> int ret = 0;
>>>> u32 reg;
>>>> + int i;
>>>>
>>>> /* clock tuning is not needed for upto 52MHz */
>>>> if (ios->clock <= 5200)
>>>> @@ -304,6 +309,16 @@ static int sdhci_omap_execute_tuning(struct mmc_host
>>>> *mmc, u32 opcode)
>>>> if (ios->timing == MMC_TIMING_UHS_SDR50 && !(reg & CAPA2_TSDR50))
>>>> return 0;
>>>>
>>>> + thermal_dev = thermal_zone_get_zone_by_name("cpu_thermal");
>>>
>>> I couldn't find a corresponding call to a put function, like
>>> "thermal_zone_put()" or whatever, which made me realize that the
>>> thermal zone API is incomplete. Or depending on how you put it, it
>>> lacks object reference counting, unless I am missing something.
>>>
>>>
Re: [PATCH] RISC-V: Add _TIF_NEED_RESCHED check for kernel thread when CONFIG_PREEMPT=y
On Thu, Jan 03, 2019 at 11:32:33AM +0800, Vincent Chen wrote: > The cond_resched() can be used to yield the CPU resource if > CONFIG_PREEMPT is not defined. Otherwise, cond_resched() is a dummy > function. In order to avoid kernel thread occupying entire CPU, > when CONFIG_PREEMPT=y, the kernel thread needs to follow the > rescheduling mechanism like a user thread. > > Signed-off-by: Vincent Chen This patch seems to do the trick. I no longer see a problem with CONFIG_PREEMPT=y and the various lock torture tests enabled, as previously reported. Nice catch and fix. Tested-by: Guenter Roeck Guenter > --- > arch/riscv/kernel/asm-offsets.c |1 + > arch/riscv/kernel/entry.S | 18 +- > 2 files changed, 18 insertions(+), 1 deletions(-) > > diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c > index 6a92a2f..dac9834 100644 > --- a/arch/riscv/kernel/asm-offsets.c > +++ b/arch/riscv/kernel/asm-offsets.c > @@ -39,6 +39,7 @@ void asm_offsets(void) > OFFSET(TASK_STACK, task_struct, stack); > OFFSET(TASK_TI, task_struct, thread_info); > OFFSET(TASK_TI_FLAGS, task_struct, thread_info.flags); > + OFFSET(TASK_TI_PREEMPT_COUNT, task_struct, thread_info.preempt_count); > OFFSET(TASK_TI_KERNEL_SP, task_struct, thread_info.kernel_sp); > OFFSET(TASK_TI_USER_SP, task_struct, thread_info.user_sp); > OFFSET(TASK_TI_CPU, task_struct, thread_info.cpu); > diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S > index 13d4826..728b72d 100644 > --- a/arch/riscv/kernel/entry.S > +++ b/arch/riscv/kernel/entry.S > @@ -144,6 +144,10 @@ _save_context: > REG_L x2, PT_SP(sp) > .endm > > +#if !IS_ENABLED(CONFIG_PREEMPT) > +#define resume_kernel restore_all > +#endif > + > ENTRY(handle_exception) > SAVE_ALL > > @@ -228,7 +232,7 @@ ret_from_exception: > REG_L s0, PT_SSTATUS(sp) > csrc sstatus, SR_SIE > andi s0, s0, SR_SPP > - bnez s0, restore_all > + bnez s0, resume_kernel > > resume_userspace: > /* Interrupts must be disabled here so flags are checked atomically */ > @@ -250,6 +254,18 @@ restore_all: > RESTORE_ALL > sret > > +#if IS_ENABLED(CONFIG_PREEMPT) > +resume_kernel: > + REG_L s0, TASK_TI_PREEMPT_COUNT(tp) > + bnez s0, restore_all > +need_resched: > + REG_L s0, TASK_TI_FLAGS(tp) > + andi s0, s0, _TIF_NEED_RESCHED > + beqz s0, restore_all > + call preempt_schedule_irq > + j need_resched > +#endif > + > work_pending: > /* Enter slow path for supplementary processing */ > la ra, ret_from_exception
knifeshack (Linux Property rights)
Let's say you had an old knife shack. Called Knife Shack InC. (you ain't incorporated, you just call it that, looks nice on the sign). On an old dusty road, telephone pole bout ready to fall down next typhoon hit. Behind yo knoif shack there is quite a body of water, now it's murky, but it is infact quite deep. An old sink hole, now filled beyond filling with the dandruff of the ages. No outlets, so the water just pools and infiltrates the surrounding properties. You own this little piece of the world, owned it for a few generations, bought it off of the old landlords when they were selling mineral rights and then decided to get rid of the rest too. They went up north. A reverse carpet-bagging situation. You don't have much. You have a house on another piece of property, quite aways up the road, and this shack, and this sinkhole. You actually are quite the property owner, but it ain't worth shit. That's what erryone tell you anyhow. The old big house been turned into an old folks home a decaded ago, shame, it's a piece of shit like your property now - least that's what everyone say. Pope's on TV, old fan from the 50s still working, You could get a flat screen but the power supplies can't handle the brown outs here, old TV still works fine, you use it like a radio anyway. Guy comes into your fish shack. You ain't never seen him in your life, you tell yourself. You know him however, he lives somewhat close, comes in from time to time, looks around, he in a suit, he never buys from you anything, he has a reputation, suits getting dusty, the pinstripes are wider than that which the people on TV wear. He comes up to you. You're playing with a knife of yours, spinning it on it's tip. It's a fish skinning knife with a gutting hook on the back. It is quite a large one. The blade is a full 15 inches, thick, you could work on the sand sharks with this, if you ever took the hour and ahalf drive down to the beach. You have a sign on your counter: "We's generous". Sometimes people ask you what that means. The man in the suit approaches you: first time for everthing. S: "Ay, I'd like that knife" You tell him it isn't for sale. S: "I ain neva said I thoughts it was, whass 'Wes generous' mean anyhow" You tell him that you will lend him the knife if he wishes. S: "Aight" He takes possession of the knife. He's a fisher he says. The man in the striped suit leaves. Months go by. You see the man sometimes, he tells you how the knife you licensed to him is getting great use, he fishes alot you see. He then inquires about that murky seemingly bottomless sinkhole out back. He wishes to be-able to dump some fishing refuse in it. S: "We's generous, right?" You grant him license to travel over your land to the sinkhole and dump the fishing refuse into the sinkhole. Time passes. You notice your knife has become more resplendent. Each time the stripped suited man, this fisher, catches a fish, it seems, he is in the habit of tacking a red five pointed star from Russia onto the handle. Each time the man comes into your shack you notice that there are more and more red stars, additionally, between the stars is now a dark red lacquer. It looks quite stunning, a battle worn cleaver; shouting it's victory against countless ensnared aquatic beings. Time, again, passes. Two police officers show up. Not the state troopers who sometimes come by the shop, no these are from one of the towns. P1: "You sell guttin knives here" You respond in the affirmative. P1: "You ever sold a rather large red gutting knife, tack handled" He seems to be getting agitated. You say no, but you have licensed a fisher to use a knife you own, and while it was not originally tack-handled, nor red, now it would indeed match such a description. P1: "You fking piece of shit, you get us back that knife or you are going down as an accomplice, you understand that you coal bla.." The second police man interrupts him. They start to head out. The second police man informs you that they will be by the store three days from now, as well as one week from now. To please reassert possession of the knife in that time. A month goes by and they do not come. Three months later you are arrested and interrogated in the harshest possible terms. You wonder if you can father children anymore. You are informed that the prosecutor has agreed to prosecute you as an accomplice, however if you come into possession of the knife, they may reconsider. Soon thereafter the suited man appears in your store. You tell him that you are ending the license you had extended to him, regarding both the knife and the permission to dump in the sinkhole. He contends that the knife is irrevocable: He relys upon the knife to execute his job of fishing. Furthermore he has put tacks in the knife, and if he were to return the knife to you his tack work would go to waste from his point of view. Additionally he tells you that he also relys on your extended license to dump the
Re: knifeshack (Linux Property rights) -- Why dislike short story?
On 2019-01-02 02:32, Mike Galbraith wrote: Take your medication. Why don't you like my short story?
Re: knifeshack (Linux Property rights)
On 2019-01-02 02:32, Mike Galbraith wrote: Take your medication. Don't like the story? Why what is wrong with it. Was it the entrance, the middle, or the conclusion? It simply explains licensing in a way you might find helpful, as it relates to linux.
(as you know) The FSF require contributors to their projects to assign ownership of the works to them...
A license without an attached interest is revocable by the owner of the property. The FSF require contributors to their projects to assign ownership of the works to them: For the FSF the license is not enough. Put two and two together.
Re: [RESEND PATCH V3 0/5] arm64/mm: Enable HugeTLB migration
On 12/18/2018 01:54 PM, Anshuman Khandual wrote: > This patch series enables HugeTLB migration support for all supported > huge page sizes at all levels including contiguous bit implementation. > Following HugeTLB migration support matrix has been enabled with this > patch series. All permutations have been tested except for the 16GB. > > CONT PTEPMDCONT PMDPUD > ------ > 4K: 64K 2M 32M 1G > 16K: 2M32M 1G > 64K: 2M 512M 16G > > First the series adds migration support for PUD based huge pages. It > then adds a platform specific hook to query an architecture if a > given huge page size is supported for migration while also providing > a default fallback option preserving the existing semantics which just > checks for (PMD|PUD|PGDIR)_SHIFT macros. The last two patches enables > HugeTLB migration on arm64 and subscribe to this new platform specific > hook by defining an override. > > The second patch differentiates between movability and migratability > aspects of huge pages and implements hugepage_movable_supported() which > can then be used during allocation to decide whether to place the huge > page in movable zone or not. > > This is just a resend for the previous version (V3) after the rebase > on current mainline kernel. Also added all the tags previous version > had received. > > Changes in V3: > > - Re-ordered patches 1 and 2 per Michal > - s/Movability/Migratability/ in unmap_and_move_huge_page() per Naoya > > Changes in V2: (https://lkml.org/lkml/2018/10/12/190) > > - Added a new patch which differentiates migratability and movability > of huge pages and implements hugepage_movable_supported() function > as suggested by Michal Hocko. > > Anshuman Khandual (5): > mm/hugetlb: Distinguish between migratability and movability > mm/hugetlb: Enable PUD level huge page migration > mm/hugetlb: Enable arch specific huge page size support for migration > arm64/mm: Enable HugeTLB migration > arm64/mm: Enable HugeTLB migration for contiguous bit HugeTLB pages > Hello Andrew, Just wondering if there are any updates on this series ? Is there something we need to improve or fix some where in this series for it to get merged. Please do let us know. Thank you. - Anshuman
Re: [PATCH] memcg: localize memcg_kmem_enabled() check
Hi Shakeel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20 next-20190102]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Shakeel-Butt/memcg-localize-memcg_kmem_enabled-check/20190103-120255
config: x86_64-randconfig-x013-201900 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
mm/page_alloc.c: In function 'free_pages_prepare':
>> mm/page_alloc.c:1059:3: error: implicit declaration of function
>> '__memcg_kmem_uncharge'; did you mean 'memcg_kmem_uncharge'?
>> [-Werror=implicit-function-declaration]
__memcg_kmem_uncharge(page, order);
^
memcg_kmem_uncharge
In file included from include/asm-generic/bug.h:5:0,
from arch/x86/include/asm/bug.h:83,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:9,
from mm/page_alloc.c:18:
mm/page_alloc.c: In function '__alloc_pages_nodemask':
>> mm/page_alloc.c:4553:15: error: implicit declaration of function
>> '__memcg_kmem_charge'; did you mean 'memcg_kmem_charge'?
>> [-Werror=implicit-function-declaration]
unlikely(__memcg_kmem_charge(page, gfp_mask, order) != 0)) {
^
include/linux/compiler.h:77:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
^
cc1: some warnings being treated as errors
vim +1059 mm/page_alloc.c
1024
1025 static __always_inline bool free_pages_prepare(struct page *page,
1026 unsigned int order, bool
check_free)
1027 {
1028 int bad = 0;
1029
1030 VM_BUG_ON_PAGE(PageTail(page), page);
1031
1032 trace_mm_page_free(page, order);
1033
1034 /*
1035 * Check tail pages before head page information is cleared to
1036 * avoid checking PageCompound for order-0 pages.
1037 */
1038 if (unlikely(order)) {
1039 bool compound = PageCompound(page);
1040 int i;
1041
1042 VM_BUG_ON_PAGE(compound && compound_order(page) !=
order, page);
1043
1044 if (compound)
1045 ClearPageDoubleMap(page);
1046 for (i = 1; i < (1 << order); i++) {
1047 if (compound)
1048 bad += free_tail_pages_check(page, page
+ i);
1049 if (unlikely(free_pages_check(page + i))) {
1050 bad++;
1051 continue;
1052 }
1053 (page + i)->flags &= ~PAGE_FLAGS_CHECK_AT_PREP;
1054 }
1055 }
1056 if (PageMappingFlags(page))
1057 page->mapping = NULL;
1058 if (memcg_kmem_enabled() && PageKmemcg(page))
> 1059 __memcg_kmem_uncharge(page, order);
1060 if (check_free)
1061 bad += free_pages_check(page);
1062 if (bad)
1063 return false;
1064
1065 page_cpupid_reset_last(page);
1066 page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP;
1067 reset_page_owner(page, order);
1068
1069 if (!PageHighMem(page)) {
1070 debug_check_no_locks_freed(page_address(page),
1071 PAGE_SIZE << order);
1072 debug_check_no_obj_freed(page_address(page),
1073 PAGE_SIZE << order);
1074 }
1075 arch_free_page(page, order);
1076 kernel_poison_pages(page, 1 << order, 0);
1077 kernel_map_pages(page, 1 << order, 0);
1078 kasan_free_nondeferred_pages(page, order);
1079
1080 return true;
1081 }
1082
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [GIT PULL] Please pull NFS client updates for 4.21
On Wed, Jan 02 2019, Linus Torvalds wrote: > On Wed, Jan 2, 2019 at 2:42 PM Schumaker, Anna > wrote: >> >> We also were unable to track down a maintainer for Neil Brown's changes to >> the generic cred code that are prerequisites to his RPC cred cleanup patches. >> We've been asking around for several months without any response, so >> hopefully it's okay to include those patches in this pull request. > > Looks ok to me, although I wonder what the semantics of cred_fscmp() > are across namespaces? > > IOW, it seems potentially a bit suspicious to do cred_fscmp() if the > two creds have different namnespaces? Hmm? > > Is there some reason that can't happen, or some reason it doesn't matter? > > Linus Interesting question. For the current use in NFS, it is consistent with existing practice to ignore the name space. NFS file accesses (when using the normal uid-based access checks) always use the manifest uid of the process - the one returned by getuid() (or more accurately, getfsuid()). Maybe this is wrong? Maybe we should always use from_kuid() or whatever to get the uid/gid to send over the wire? Anna/Trond: do you have thoughts on this? If a process in a user namespace accesses a file over NFS, should the UID presented to the server be the one in that name-space, or the one you get by mapping to the global name-space? Or should we map to the namespace that was active when the filesystem was mounted? I don't think cred_fscmp() should do any of this mapping, but maybe it should treat creds from different namespaces as different - as a precaution. Thanks, NeilBrown signature.asc Description: PGP signature
Re: [RFC RESEND PATCH 0/7] Add driver for dvfsrc and add support for active state of scpsys on mt8183
On 02-01-19, 22:09, Henry Chen wrote: > The patchsets add support for MediaTek hardware module named DVFSRC > (dynamic voltage and frequency scaling resource collector). The DVFSRC is > a HW module which is used to collect all the requests from both software > and hardware and turn into the decision of minimum operating voltage and > minimum DRAM frequency to fulfill those requests. > > So, This series is to implement the dvfsrc driver to collect all the > requests of operating voltage or DRAM bandwidth from other device drivers > likes GPU/Camera through 2 frameworks basically: > > 1. PM_QOS_MEMORY_BANDWIDTH from PM QOS: to aggregate the bandwidth >requirements from different clients > 2. Active state management of power domains[1]: to handle the operating >voltage opp requirement from different power domains Honestly speaking I wasn't sure if anyone apart from Qcom will ever use this feature when I wrote it first and I am quite surprised and happy to see your patches. They are mostly very neat and clean patches and I don't have complaints with most of them. Lets see what comments others provide on them. Thanks. -- viresh
Re: [PATCH V1] i2c: tegra: Fix Maximum transfer size
Hi Sowjanya,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tegra/for-next]
[also build test WARNING on v4.20 next-20190102]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Sowjanya-Komatineni/i2c-tegra-Fix-Maximum-transfer-size/20190103-082727
base: https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git for-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All warnings (new ones prefixed by >>):
>> drivers/i2c/busses/i2c-tegra.c:839:18: warning: large integer implicitly
>> truncated to unsigned type [-Woverflow]
.max_read_len = 65536,
^
drivers/i2c/busses/i2c-tegra.c:840:19: warning: large integer implicitly
truncated to unsigned type [-Woverflow]
.max_write_len = 65536,
^
>> drivers/i2c/busses/i2c-tegra.c:854:12: warning: initialization discards
>> 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
.quirks = _i2c_quirks,
^
drivers/i2c/busses/i2c-tegra.c:868:12: warning: initialization discards
'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
.quirks = _i2c_quirks,
^
drivers/i2c/busses/i2c-tegra.c:882:12: warning: initialization discards
'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
.quirks = _i2c_quirks,
^
drivers/i2c/busses/i2c-tegra.c:896:12: warning: initialization discards
'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
.quirks = _i2c_quirks,
^
drivers/i2c/busses/i2c-tegra.c:910:12: warning: initialization discards
'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
.quirks = _i2c_quirks,
^
drivers/i2c/busses/i2c-tegra.c:924:12: warning: initialization discards
'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
.quirks = _i2c_quirks,
^
vim +839 drivers/i2c/busses/i2c-tegra.c
836
837 static const struct i2c_adapter_quirks tegra194_i2c_quirks = {
838 .flags = I2C_AQ_NO_ZERO_LEN,
> 839 .max_read_len = 65536,
840 .max_write_len = 65536,
841 };
842
843 static const struct tegra_i2c_hw_feature tegra20_i2c_hw = {
844 .has_continue_xfer_support = false,
845 .has_per_pkt_xfer_complete_irq = false,
846 .has_single_clk_source = false,
847 .clk_divisor_hs_mode = 3,
848 .clk_divisor_std_fast_mode = 0,
849 .clk_divisor_fast_plus_mode = 0,
850 .has_config_load_reg = false,
851 .has_multi_master_mode = false,
852 .has_slcg_override_reg = false,
853 .has_mst_fifo = false,
> 854 .quirks = _i2c_quirks,
855 };
856
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v3] driver: uio: fix possible memory leak in uio_open
On 2019/1/3 22:28, liujian wrote:
Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered")
Signed-off-by: liujian
---
v1->v2:
rename the "err_infoopen" to "err_idev_info"
v2->3:
put the extra info after the "--"
Looks good to me.
Thanks.
BRs
drivers/uio/uio.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 5c10fc7..aab3520 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -496,18 +496,19 @@ static int uio_open(struct inode *inode, struct file
*filep)
if (!idev->info) {
mutex_unlock(>info_lock);
ret = -EINVAL;
- goto err_alloc_listener;
+ goto err_idev_info;
}
if (idev->info && idev->info->open)
ret = idev->info->open(idev->info, inode);
mutex_unlock(>info_lock);
if (ret)
- goto err_infoopen;
+ goto err_idev_info;
return 0;
-err_infoopen:
+err_idev_info:
+ filep->private_data = NULL;
kfree(listener);
err_alloc_listener:
Re: [RFC RESEND PATCH 4/7] arm64: dts: mt8183: add performance state support of scpsys
On 02-01-19, 22:09, Henry Chen wrote:
> Add support for performance state of scpsys on mt8183 platform.
>
> Signed-off-by: Henry Chen
> ---
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 47926a7..e396410 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
>
> / {
> compatible = "mediatek,mt8183";
> @@ -243,6 +244,26 @@
> "vpu-3", "vpu-4", "vpu-5";
> infracfg = <>;
> smi_comm = <_common>;
> + operating-points-v2 = <_opp_table>;
> + dvfsrc_opp_table: opp-table {
> + compatible = "operating-points-v2-mtk-level";
> +
> + dvfsrc_vol_min: opp1 {
> + mtk,level = ;
> + };
> +
> + dvfsrc_freq_medium: opp2 {
> + mtk,level = ;
> + };
> +
> + dvfsrc_freq_max: opp3 {
> + mtk,level = ;
> + };
> +
> + dvfsrc_vol_max: opp4 {
> + mtk,level = ;
> + };
> + };
> };
I don't see a patch which makes use of this OPP table using the required-opps
thing. Where is that ?
--
viresh
[PATCH v3] driver: uio: fix possible memory leak in uio_open
Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered")
Signed-off-by: liujian
---
v1->v2:
rename the "err_infoopen" to "err_idev_info"
v2->3:
put the extra info after the "--"
drivers/uio/uio.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 5c10fc7..aab3520 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -496,18 +496,19 @@ static int uio_open(struct inode *inode, struct file
*filep)
if (!idev->info) {
mutex_unlock(>info_lock);
ret = -EINVAL;
- goto err_alloc_listener;
+ goto err_idev_info;
}
if (idev->info && idev->info->open)
ret = idev->info->open(idev->info, inode);
mutex_unlock(>info_lock);
if (ret)
- goto err_infoopen;
+ goto err_idev_info;
return 0;
-err_infoopen:
+err_idev_info:
+ filep->private_data = NULL;
kfree(listener);
err_alloc_listener:
--
2.7.4
Re: [PATCH] fsi:fsi-sbefifo: Fix possible concurrency use-after-free bugs in sbefifo_user_release
On Thu, 2019-01-03 at 14:27 +1100, Benjamin Herrenschmidt wrote: > On Wed, 2019-01-02 at 09:34 +, David Howells wrote: > > Jia-Ju Bai wrote: > > > > > + mutex_lock(>file_lock); > > > sbefifo_release_command(user); > > > free_page((unsigned long)user->cmd_page); > > > + mutex_unlock(>file_lock); > > > > It shouldn't be necessary to do the free_page() call inside the locked > > section. > > True. However, I didn't realize read/write could be concurrent with > release so we have another problem. > > I assume when release is called, no new read/write can be issued, I am > correct ? So all we have to protect against is a read/write that has > started prior to release being called, right ? Hrm... looking briefly at the vfs, read/write are wrapped in fdget/fdput, so release shouldn't happen concurrently or am I missing something here ? Cheers, Ben.
Re: [PATCH] Initialise mmu_notifier_range correctly
On Wed, Jan 02, 2019 at 07:32:08PM -0800, John Hubbard wrote:
> Having the range struct declared in separate places from the
> mmu_notifier_range_init()
> calls is not great. But I'm not sure I see a way to make it significantly
> cleaner, given
> that __follow_pte_pmd uses the range pointer as a way to decide to issue the
> mmn calls.
Yeah, I don't think there's anything we can do. But I started reviewing
the comments, and they don't make sense together:
/*
* Note because we provide range to follow_pte_pmd it will
* call mmu_notifier_invalidate_range_start() on our behalf
* before taking any lock.
*/
if (follow_pte_pmd(vma->vm_mm, address, ,
, , ))
continue;
/*
* No need to call mmu_notifier_invalidate_range() as we are
* downgrading page table protection not changing it to point
* to a new page.
*
* See Documentation/vm/mmu_notifier.rst
*/
So if we don't call mmu_notifier_invalidate_range, why are we calling
mmu_notifier_invalidate_range_start and mmu_notifier_invalidate_range_end?
ie, why not this ...
diff --git a/fs/dax.c b/fs/dax.c
index 6959837cc465..905340149924 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -777,7 +777,6 @@ static void dax_entry_mkclean(struct address_space
*mapping, pgoff_t index,
i_mmap_lock_read(mapping);
vma_interval_tree_foreach(vma, >i_mmap, index, index) {
- struct mmu_notifier_range range;
unsigned long address;
cond_resched();
@@ -787,12 +786,7 @@ static void dax_entry_mkclean(struct address_space
*mapping, pgoff_t index,
address = pgoff_address(index, vma);
- /*
-* Note because we provide start/end to follow_pte_pmd it will
-* call mmu_notifier_invalidate_range_start() on our behalf
-* before taking any lock.
-*/
- if (follow_pte_pmd(vma->vm_mm, address, ,
+ if (follow_pte_pmd(vma->vm_mm, address, NULL,
, , ))
continue;
@@ -834,8 +828,6 @@ static void dax_entry_mkclean(struct address_space
*mapping, pgoff_t index,
unlock_pte:
pte_unmap_unlock(ptep, ptl);
}
-
- mmu_notifier_invalidate_range_end();
}
i_mmap_unlock_read(mapping);
}
Re: [alsa-devel] [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit
On Thursday, January 3, 2019 5:20:27 AM IST Pierre-Louis Bossart wrote: > > On 1/2/19 4:58 PM, Sinan Kaya wrote: > > On Wed, Jan 2, 2019 at 10:50 PM Pierre-Louis Bossart > > wrote: > >> > >>> This is pointing to a kconfig issue on ia64 arch. > >>> > >>> arch/ia64/Kconfig:128:error: recursive dependency detected! > >>> arch/ia64/Kconfig:128:choice contains symbol IA64_HP_SIM > >>> arch/ia64/Kconfig:202:symbol IA64_HP_SIM is part of choice PM > >>> > >>> IA64_HP_SIM is both a choice and is selected. > >>> > >>> I did allyesconfig and disabled PCI afterwards to find all the issues > >>> on this patchset. > >> Are you saying there's a newer series that fixes this issue for both > >> allyesconfig and allmodconfig? > >> > >> if yes, then we're good. > > > > No, I haven't fixed ia64 kconfig issue. That's somebody else's job. I > > used allyesconfig to find out all compilation issues on x86 arch to > > come up with this patchset. > > Nothing makes me cringe more than "somebody else's job" statements. In > this case, there is obviously a correlation with your ACPI changes since > the circular dependency happens because of the ACPI symbol. > > arch/ia64/Kconfig:126:error: recursive dependency detected! > arch/ia64/Kconfig:126:choice contains symbol IA64_HP_SIM > arch/ia64/Kconfig:200:symbol IA64_HP_SIM is part of choice PM > kernel/power/Kconfig:144:symbol PM is selected by PM_SLEEP > kernel/power/Kconfig:104:symbol PM_SLEEP depends on HIBERNATE_CALLBACKS > kernel/power/Kconfig:31:symbol HIBERNATE_CALLBACKS is selected by > HIBERNATION > kernel/power/Kconfig:34:symbol HIBERNATION depends on SWAP > init/Kconfig:250:symbol SWAP depends on BLOCK > block/Kconfig:5:symbol BLOCK is selected by UBIFS_FS > fs/ubifs/Kconfig:1:symbol UBIFS_FS depends on MISC_FILESYSTEMS > fs/Kconfig:220:symbol MISC_FILESYSTEMS is selected by ACPI_APEI > drivers/acpi/apei/Kconfig:8:symbol ACPI_APEI depends on ACPI > drivers/acpi/Kconfig:9:symbol ACPI depends on ARCH_SUPPORTS_ACPI > LOOK HERE > drivers/acpi/Kconfig:6:symbol ARCH_SUPPORTS_ACPI is selected by > IA64_HP_SIM > arch/ia64/Kconfig:200:symbol IA64_HP_SIM is part of choice > > At any rate, a 3 mn git bisect tells me the circular dependency is > exposed by this change: > > f3fd6cd74fedf99b6060f75df00943fda13b65f2 is the first bad commit > commit f3fd6cd74fedf99b6060f75df00943fda13b65f2 > Author: Chandan Rajendra > Date: Sat Dec 8 12:21:38 2018 +0530 > > fscrypt: remove filesystem specific build config option > > In order to have a common code base for fscrypt "post read" processing > for all filesystems which support encryption, this commit removes > filesystem specific build config option (e.g. > CONFIG_EXT4_FS_ENCRYPTION) > and replaces it with a build option (i.e. CONFIG_FS_ENCRYPTION) whose > value affects all the filesystems making use of fscrypt. > > Signed-off-by: Chandan Rajendra > Signed-off-by: Theodore Ts'o > FWIW, The patch at https://patchwork.kernel.org/patch/10725883/ fixes this problem by removing "select BLOCK if FS_ENCRYPTION" from fs/ubifs/Kconfig. -- chandan
Re: [PATCH] cpufreq / Documentation: Update cpufreq MAINTAINERS entry
On 02-01-19, 12:13, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Update the MAINTAINERS entry for cpufreq by making it clear that it > is not just drivers and adding current documentation records to it. > > Signed-off-by: Rafael J. Wysocki > --- > MAINTAINERS |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > Index: linux-pm/MAINTAINERS > === > --- linux-pm.orig/MAINTAINERS > +++ linux-pm/MAINTAINERS > @@ -3888,7 +3888,7 @@ L: net...@vger.kernel.org > S: Maintained > F: drivers/net/ethernet/ti/cpmac.c > > -CPU FREQUENCY DRIVERS > +CPU FREQUENCY SCALING FRAMEWORK > M: "Rafael J. Wysocki" > M: Viresh Kumar > L: linux...@vger.kernel.org > @@ -3896,6 +3896,8 @@ S: Maintained > T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > T: git git://git.linaro.org/people/vireshk/linux.git (For ARM Updates) > B: https://bugzilla.kernel.org > +F: Documentation/admin-guide/pm/cpufreq.rst > +F: Documentation/admin-guide/pm/intel_pstate.rst > F: Documentation/cpu-freq/ > F: Documentation/devicetree/bindings/cpufreq/ > F: drivers/cpufreq/ Acked-by: Viresh Kumar -- viresh
[PATCH] RISC-V: Add _TIF_NEED_RESCHED check for kernel thread when CONFIG_PREEMPT=y
The cond_resched() can be used to yield the CPU resource if CONFIG_PREEMPT is not defined. Otherwise, cond_resched() is a dummy function. In order to avoid kernel thread occupying entire CPU, when CONFIG_PREEMPT=y, the kernel thread needs to follow the rescheduling mechanism like a user thread. Signed-off-by: Vincent Chen --- arch/riscv/kernel/asm-offsets.c |1 + arch/riscv/kernel/entry.S | 18 +- 2 files changed, 18 insertions(+), 1 deletions(-) diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c index 6a92a2f..dac9834 100644 --- a/arch/riscv/kernel/asm-offsets.c +++ b/arch/riscv/kernel/asm-offsets.c @@ -39,6 +39,7 @@ void asm_offsets(void) OFFSET(TASK_STACK, task_struct, stack); OFFSET(TASK_TI, task_struct, thread_info); OFFSET(TASK_TI_FLAGS, task_struct, thread_info.flags); + OFFSET(TASK_TI_PREEMPT_COUNT, task_struct, thread_info.preempt_count); OFFSET(TASK_TI_KERNEL_SP, task_struct, thread_info.kernel_sp); OFFSET(TASK_TI_USER_SP, task_struct, thread_info.user_sp); OFFSET(TASK_TI_CPU, task_struct, thread_info.cpu); diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index 13d4826..728b72d 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -144,6 +144,10 @@ _save_context: REG_L x2, PT_SP(sp) .endm +#if !IS_ENABLED(CONFIG_PREEMPT) +#define resume_kernel restore_all +#endif + ENTRY(handle_exception) SAVE_ALL @@ -228,7 +232,7 @@ ret_from_exception: REG_L s0, PT_SSTATUS(sp) csrc sstatus, SR_SIE andi s0, s0, SR_SPP - bnez s0, restore_all + bnez s0, resume_kernel resume_userspace: /* Interrupts must be disabled here so flags are checked atomically */ @@ -250,6 +254,18 @@ restore_all: RESTORE_ALL sret +#if IS_ENABLED(CONFIG_PREEMPT) +resume_kernel: + REG_L s0, TASK_TI_PREEMPT_COUNT(tp) + bnez s0, restore_all +need_resched: + REG_L s0, TASK_TI_FLAGS(tp) + andi s0, s0, _TIF_NEED_RESCHED + beqz s0, restore_all + call preempt_schedule_irq + j need_resched +#endif + work_pending: /* Enter slow path for supplementary processing */ la ra, ret_from_exception -- 1.7.1
Re: [PATCH] libceph: protect pending flags in ceph_con_keepalive()
On Wed, Jan 02, 2019 at 04:42:47PM +0100, Ilya Dryomov wrote:
> On Thu, Dec 27, 2018 at 8:08 PM Myungho Jung wrote:
> >
> > con_flag_test_and_set() sets CON_FLAG_KEEPALIVE_PENDING and
> > CON_FLAG_WRITE_PENDING flags without protection in ceph_con_keepalive().
> > It triggers WARN_ON() in clear_standby() if the flags are set after
> > con_fault() changes connection state to CON_STATE_STANDBY. Move
> > con_flag_test_and_set() to be called before releasing the lock and store
> > the condition to check after the critical section.
> >
> > Reported-by: syzbot+acdeb633f6211ccdf...@syzkaller.appspotmail.com
> > Signed-off-by: Myungho Jung
> > ---
> > net/ceph/messenger.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c
> > index 2f126eff275d..e15da22d4f37 100644
> > --- a/net/ceph/messenger.c
> > +++ b/net/ceph/messenger.c
> > @@ -3216,12 +3216,16 @@ void ceph_msg_revoke_incoming(struct ceph_msg *msg)
> > */
> > void ceph_con_keepalive(struct ceph_connection *con)
> > {
> > + bool pending;
> > +
> > dout("con_keepalive %p\n", con);
> > mutex_lock(>mutex);
> > clear_standby(con);
> > + pending = (con_flag_test_and_set(con,
> > +CON_FLAG_KEEPALIVE_PENDING) == 0 &&
> > + con_flag_test_and_set(con, CON_FLAG_WRITE_PENDING) == 0);
> > mutex_unlock(>mutex);
> > - if (con_flag_test_and_set(con, CON_FLAG_KEEPALIVE_PENDING) == 0 &&
> > - con_flag_test_and_set(con, CON_FLAG_WRITE_PENDING) == 0)
> > + if (pending)
> > queue_con(con);
> > }
> > EXPORT_SYMBOL(ceph_con_keepalive);
>
> Hi Myungho,
>
> Were you able to reproduce? If so, did you use the syzkaller output or
> something else?
>
> Thanks,
>
> Ilya
Hi Ilya,
I reproduced on vm using syzkaller utils and verified the fix by syzbot.
Thanks,
Myungho
Re: [PATCH] Initialise mmu_notifier_range correctly
On 1/2/19 5:56 PM, Jerome Glisse wrote:
> On Wed, Jan 02, 2019 at 04:21:26PM -0800, Matthew Wilcox wrote:
>>
>> One of the paths in follow_pte_pmd() initialised the mmu_notifier_range
>> incorrectly.
>>
>> Signed-off-by: Matthew Wilcox
>> Fixes: ac46d4f3c432 ("mm/mmu_notifier: use structure for
>> invalidate_range_start/end calls v2")
>> Tested-by: Dave Chinner
>
> Reviewed-by: Jérôme Glisse
>
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 2dd2f9ab57f4..21a650368be0 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -4078,8 +4078,8 @@ static int __follow_pte_pmd(struct mm_struct *mm,
>> unsigned long address,
>> goto out;
>>
>> if (range) {
>> -range->start = address & PAGE_MASK;
>> -range->end = range->start + PAGE_SIZE;
>> +mmu_notifier_range_init(range, mm, address & PAGE_MASK,
>> + (address & PAGE_MASK) + PAGE_SIZE);
>> mmu_notifier_invalidate_range_start(range);
>> }
>> ptep = pte_offset_map_lock(mm, pmd, address, ptlp);
>
Looks correct to me, as well.
Having the range struct declared in separate places from the
mmu_notifier_range_init()
calls is not great. But I'm not sure I see a way to make it significantly
cleaner, given
that __follow_pte_pmd uses the range pointer as a way to decide to issue the
mmn calls.
thanks,
--
John Hubbard
NVIDIA
Re: [alsa-devel] [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit
+Tony On Wed, Jan 2, 2019 at 11:50 PM Pierre-Louis Bossart wrote: > > > On 1/2/19 4:58 PM, Sinan Kaya wrote: > > On Wed, Jan 2, 2019 at 10:50 PM Pierre-Louis Bossart > > wrote: > >> > >>> This is pointing to a kconfig issue on ia64 arch. > >>> > >>> arch/ia64/Kconfig:128:error: recursive dependency detected! > >>> arch/ia64/Kconfig:128:choice contains symbol IA64_HP_SIM > >>> arch/ia64/Kconfig:202:symbol IA64_HP_SIM is part of choice PM > >>> > >>> IA64_HP_SIM is both a choice and is selected. > >>> > >>> I did allyesconfig and disabled PCI afterwards to find all the issues > >>> on this patchset. > >> Are you saying there's a newer series that fixes this issue for both > >> allyesconfig and allmodconfig? > >> > >> if yes, then we're good. > > > > No, I haven't fixed ia64 kconfig issue. That's somebody else's job. I > > used allyesconfig to find out all compilation issues on x86 arch to > > come up with this patchset. > > Nothing makes me cringe more than "somebody else's job" statements. In > this case, there is obviously a correlation with your ACPI changes since > the circular dependency happens because of the ACPI symbol. > I agree that it needs to be fixed. I am not convinced that the issue is related to my change. Your log is pointing to an inconsistency in ia64 kconfig. > arch/ia64/Kconfig:126:error: recursive dependency detected! > arch/ia64/Kconfig:126:choice contains symbol IA64_HP_SIM > arch/ia64/Kconfig:200:symbol IA64_HP_SIM is part of choice PM > kernel/power/Kconfig:144:symbol PM is selected by PM_SLEEP > kernel/power/Kconfig:104:symbol PM_SLEEP depends on HIBERNATE_CALLBACKS > kernel/power/Kconfig:31:symbol HIBERNATE_CALLBACKS is selected by > HIBERNATION > kernel/power/Kconfig:34:symbol HIBERNATION depends on SWAP > init/Kconfig:250:symbol SWAP depends on BLOCK > block/Kconfig:5:symbol BLOCK is selected by UBIFS_FS > fs/ubifs/Kconfig:1:symbol UBIFS_FS depends on MISC_FILESYSTEMS > fs/Kconfig:220:symbol MISC_FILESYSTEMS is selected by ACPI_APEI > drivers/acpi/apei/Kconfig:8:symbol ACPI_APEI depends on ACPI > drivers/acpi/Kconfig:9:symbol ACPI depends on ARCH_SUPPORTS_ACPI > LOOK HERE I am still having hard time seeing how this issue is exposed by removing PCI dependency from ACPi. Rafael, Tony: can you help me? > drivers/acpi/Kconfig:6:symbol ARCH_SUPPORTS_ACPI is selected by > IA64_HP_SIM > arch/ia64/Kconfig:200:symbol IA64_HP_SIM is part of choice > > At any rate, a 3 mn git bisect tells me the circular dependency is > exposed by this change: > > f3fd6cd74fedf99b6060f75df00943fda13b65f2 is the first bad commit > commit f3fd6cd74fedf99b6060f75df00943fda13b65f2 > Author: Chandan Rajendra > Date: Sat Dec 8 12:21:38 2018 +0530 > > fscrypt: remove filesystem specific build config option > > In order to have a common code base for fscrypt "post read" processing > for all filesystems which support encryption, this commit removes > filesystem specific build config option (e.g. > CONFIG_EXT4_FS_ENCRYPTION) > and replaces it with a build option (i.e. CONFIG_FS_ENCRYPTION) whose > value affects all the filesystems making use of fscrypt. > > Signed-off-by: Chandan Rajendra > Signed-off-by: Theodore Ts'o > > -Pierre > >
Re: [PATCH] fsi:fsi-sbefifo: Fix possible concurrency use-after-free bugs in sbefifo_user_release
On Wed, 2019-01-02 at 09:34 +, David Howells wrote: > Jia-Ju Bai wrote: > > > + mutex_lock(>file_lock); > > sbefifo_release_command(user); > > free_page((unsigned long)user->cmd_page); > > + mutex_unlock(>file_lock); > > It shouldn't be necessary to do the free_page() call inside the locked > section. True. However, I didn't realize read/write could be concurrent with release so we have another problem. I assume when release is called, no new read/write can be issued, I am correct ? So all we have to protect against is a read/write that has started prior to release being called, right ? In that case, what can happen is that release() wins the race on the mutex, frees everything, then read or write starts using feed stuff. This is nasty to fix because the mutex is in the user structure, so even looking at the mutex is racy if release is called. The right fix, would be, I think, for "user" (pointed to by file- >private_data) to be protected by a kref. That doesn't close it completely as the free in release() can still lead to the structure becoming re-used before read/write tries to get the kref but after it has NULL checked the private data. So to make that solid, I would also RCU-defer the actual freeing and use RCU around dereferencing file->private_data Now, I yet have to see other chardevs do any of the above, do that mean they are all hopelessly racy ? Cheers, Ben.
Re: possible deadlock in __wake_up_common_lock
On 1/2/19 8:28 PM, Tetsuo Handa wrote: > On 2019/01/03 3:19, Qian Cai wrote: >> On 1/2/19 1:06 PM, Mel Gorman wrote: >> >>> While I recognise there is no test case available, how often does this >>> trigger in syzbot as it would be nice to have some confirmation any >>> patch is really fixing the problem. >> >> I think I did manage to trigger this every time running a mmap() workload >> causing swapping and a low-memory situation [1]. >> >> [1] >> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/oom/oom01.c > > wakeup_kswapd() is called because tlb_next_batch() is doing GFP_NOWAIT > allocation. But since tlb_next_batch() can tolerate allocation failure, > does below change in tlb_next_batch() help? > > #define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM) > > - batch = (void *)__get_free_pages(GFP_NOWAIT | __GFP_NOWARN, 0); > + batch = (void *)__get_free_pages(__GFP_NOWARN, 0); No. In oom01 case, it is from, do_anonymous_page __alloc_zeroed_user_highpage alloc_page_vma(GFP_HIGHUSER ... GFP_HIGHUSER -> GFP_USER -> __GFP_RECLAIM -> ___GFP_KSWAPD_RECLAIM Then, it has this new code in steal_suitable_fallback() via 1c30844d2df (mm: reclaim small amounts of memory when an external fragmentation event occurs) /* * Boost watermarks to increase reclaim pressure to reduce * the likelihood of future fallbacks. Wake kswapd now as * the node may be balanced overall and kswapd will not * wake naturally. */ boost_watermark(zone); if (alloc_flags & ALLOC_KSWAPD) wakeup_kswapd(zone, 0, 0, zone_idx(zone));
[PATCH v2 2/2] USB: storage: add quirk for SMI SM3350
The SMI SM3350 USB-UFS bridge controller cannot handle long sense request correctly and will make the chip refuse to do read/write when requested long sense. Add a bad sense quirk for it. Signed-off-by: Icenowy Zheng --- drivers/usb/storage/unusual_devs.h | 12 1 file changed, 12 insertions(+) diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index f7f83b21dc74..ea0d27a94afe 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -1265,6 +1265,18 @@ UNUSUAL_DEV( 0x090c, 0x1132, 0x, 0x, USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_FIX_CAPACITY ), +/* + * Reported by Icenowy Zheng + * The SMI SM3350 USB-UFS bridge controller will enter a wrong state + * that do not process read/write command if a long sense is requested, + * so force to use 18-byte sense. + */ +UNUSUAL_DEV( 0x090c, 0x3350, 0x, 0x, + "SMI", + "SM3350 UFS-to-USB-Mass-Storage bridge", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_BAD_SENSE ), + /* * Reported by Paul Hartman * This card reader returns "Illegal Request, Logical Block Address -- 2.18.1
Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions
On 1/2/19 5:55 PM, Jerome Glisse wrote:
> On Wed, Dec 19, 2018 at 12:08:56PM +0100, Jan Kara wrote:
>> On Tue 18-12-18 21:07:24, Jerome Glisse wrote:
>>> On Tue, Dec 18, 2018 at 03:29:34PM -0800, John Hubbard wrote:
OK, so let's take another look at Jerome's _mapcount idea all by itself
(using
*only* the tracking pinned pages aspect), given that it is the lightest
weight
solution for that.
So as I understand it, this would use page->_mapcount to store both the
real
mapcount, and the dma pinned count (simply added together), but only do so
for
file-backed (non-anonymous) pages:
__get_user_pages()
{
...
get_page(page);
if (!PageAnon)
atomic_inc(page->_mapcount);
...
}
put_user_page(struct page *page)
{
...
if (!PageAnon)
atomic_dec(>_mapcount);
put_page(page);
...
}
...and then in the various consumers of the DMA pinned count, we use
page_mapped(page)
to see if any mapcount remains, and if so, we treat it as DMA pinned. Is
that what you
had in mind?
>>>
>>> Mostly, with the extra two observations:
>>> [1] We only need to know the pin count when a write back kicks in
>>> [2] We need to protect GUP code with wait_for_write_back() in case
>>> GUP is racing with a write back that might not the see the
>>> elevated mapcount in time.
>>>
>>> So for [2]
>>>
>>> __get_user_pages()
>>> {
>>> get_page(page);
>>>
>>> if (!PageAnon) {
>>> atomic_inc(page->_mapcount);
>>> + if (PageWriteback(page)) {
>>> + // Assume we are racing and curent write back will not see
>>> + // the elevated mapcount so wait for current write back and
>>> + // force page fault
>>> + wait_on_page_writeback(page);
>>> + // force slow path that will fault again
>>> + }
>>> }
>>> }
>>
>> This is not needed AFAICT. __get_user_pages() gets page reference (and it
>> should also increment page->_mapcount) under PTE lock. So at that point we
>> are sure we have writeable PTE nobody can change. So page_mkclean() has to
>> block on PTE lock to make PTE read-only and only after going through all
>> PTEs like this, it can check page->_mapcount. So the PTE lock provides
>> enough synchronization.
>>
>>> For [1] only needing pin count during write back turns page_mkclean into
>>> the perfect spot to check for that so:
>>>
>>> int page_mkclean(struct page *page)
>>> {
>>> int cleaned = 0;
>>> + int real_mapcount = 0;
>>> struct address_space *mapping;
>>> struct rmap_walk_control rwc = {
>>> .arg = (void *),
>>> .rmap_one = page_mkclean_one,
>>> .invalid_vma = invalid_mkclean_vma,
>>> + .mapcount = _mapcount,
>>> };
>>>
>>> BUG_ON(!PageLocked(page));
>>>
>>> if (!page_mapped(page))
>>> return 0;
>>>
>>> mapping = page_mapping(page);
>>> if (!mapping)
>>> return 0;
>>>
>>> // rmap_walk need to change to count mapping and return value
>>> // in .mapcount easy one
>>> rmap_walk(page, );
>>>
>>> // Big fat comment to explain what is going on
>>> + if ((page_mapcount(page) - real_mapcount) > 0) {
>>> + SetPageDMAPined(page);
>>> + } else {
>>> + ClearPageDMAPined(page);
>>> + }
>>
>> This is the detail I'm not sure about: Why cannot rmap_walk_file() race
>> with e.g. zap_pte_range() which decrements page->_mapcount and thus the
>> check we do in page_mkclean() is wrong?
>>
>
> Ok so i found a solution for that. First GUP must wait for racing
> write back. If GUP see a valid write-able PTE and the page has
> write back flag set then it must back of as if the PTE was not
> valid to force fault. It is just a race with page_mkclean and we
> want ordering between the two. Note this is not strictly needed
> so we can relax that but i believe this ordering is better to do
> in GUP rather then having each single user of GUP test for this
> to avoid the race.
>
> GUP increase mapcount only after checking that it is not racing
> with writeback it also set a page flag (SetPageDMAPined(page)).
>
> When clearing a write-able pte we set a special entry inside the
> page table (might need a new special swap type for this) and change
> page_mkclean_one() to clear to 0 those special entry.
>
>
> Now page_mkclean:
>
> int page_mkclean(struct page *page)
> {
> int cleaned = 0;
> + int real_mapcount = 0;
> struct address_space *mapping;
> struct rmap_walk_control rwc = {
> .arg = (void *),
> .rmap_one = page_mkclean_one,
> .invalid_vma = invalid_mkclean_vma,
> + .mapcount = _mapcount,
> };
> + int mapcount1, mapcount2;
>
> BUG_ON(!PageLocked(page));
>
> if (!page_mapped(page))
> return 0;
>
> mapping = page_mapping(page);
> if (!mapping)
>
[PATCH v2 0/2] USB Storage quirk for SMI SM3350
SMI SM3350 UFS-USB bridge controller cannot handle REQUEST SENSE command with long sense (96-bytes) well, and will even trap the controller into a state that refuses to do read/write command. Currently Linux uncondintionally set US_FL_SANE_SENSE for devices claiming SPC3+, which makes simply add US_FL_BAD_SENSE for SM3350 fail (as it claims SPC4). Fix this conflicting quirk issue, and add the quirk for SM3350. Icenowy Zheng (2): USB: storage: don't insert sane sense for SPC3+ when bad sense specified USB: storage: add quirk for SMI SM3350 drivers/usb/storage/scsiglue.c | 8 ++-- drivers/usb/storage/unusual_devs.h | 12 2 files changed, 18 insertions(+), 2 deletions(-) -- 2.18.1
[PATCH v2 1/2] USB: storage: don't insert sane sense for SPC3+ when bad sense specified
Currently the code will set US_FL_SANE_SENSE flag unconditionally if device claims SPC3+, however we should allow US_FL_BAD_SENSE flag to prevent this behavior, because SMI SM3350 UFS-USB bridge controller, which claims SPC4, will show strange behavior with 96-byte sense (put the chip into a wrong state that cannot read/write anything). Check the presence of US_FL_BAD_SENSE when assuming US_FL_SANE_SENSE on SPC4+ devices. Signed-off-by: Icenowy Zheng --- Changes in v2: - Changed the comment to note the check. drivers/usb/storage/scsiglue.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c index fde2e71a6ade..a73ea495d5a7 100644 --- a/drivers/usb/storage/scsiglue.c +++ b/drivers/usb/storage/scsiglue.c @@ -235,8 +235,12 @@ static int slave_configure(struct scsi_device *sdev) if (!(us->fflags & US_FL_NEEDS_CAP16)) sdev->try_rc_10_first = 1; - /* assume SPC3 or latter devices support sense size > 18 */ - if (sdev->scsi_level > SCSI_SPC_2) + /* +* assume SPC3 or latter devices support sense size > 18 +* unless US_FL_BAD_SENSE quirk is specified. +*/ + if (sdev->scsi_level > SCSI_SPC_2 && + !(us->fflags & US_FL_BAD_SENSE)) us->fflags |= US_FL_SANE_SENSE; /* -- 2.18.1
[PATCH] vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel
Recently we run a network test over ipcomp virtual tunnel.We find that
if a ipv4 packet needs fragment, then the peer can't receive
it.
We deep into the code and find that when packet need fragment the smaller
fragment will be encapsulated by ipip not ipcomp. So when the ipip packet
goes into xfrm, it's skb->dev is not properly set. The ipv4 reassembly code
always set skb'dev to the last fragment's dev. After ipv4 defrag processing,
when the kernel rp_filter parameter is set, the skb will be drop by -EXDEV
error.
This patch adds compatible support for the ipip process in ipcomp virtual
tunnel.
Signed-off-by: Su Yanjun
---
net/ipv4/ip_vti.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index de31b30..63de2f6 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -65,6 +65,9 @@ static int vti_input(struct sk_buff *skb, int nexthdr, __be32
spi,
XFRM_TUNNEL_SKB_CB(skb)->tunnel.ip4 = tunnel;
+ if (iph->protocol == IPPROTO_IPIP)
+ skb->dev = tunnel->dev;
+
return xfrm_input(skb, nexthdr, spi, encap_type);
}
@@ -76,10 +79,15 @@ static int vti_input(struct sk_buff *skb, int nexthdr,
__be32 spi,
static int vti_rcv(struct sk_buff *skb)
{
+ __be32 spi = 0;
+
XFRM_SPI_SKB_CB(skb)->family = AF_INET;
XFRM_SPI_SKB_CB(skb)->daddroff = offsetof(struct iphdr, daddr);
+
+ if (ip_hdr(skb)->protocol == IPPROTO_IPIP)
+ spi = ip_hdr(skb)->saddr;
- return vti_input(skb, ip_hdr(skb)->protocol, 0, 0);
+ return vti_input(skb, ip_hdr(skb)->protocol, spi, 0);
}
static int vti_rcv_cb(struct sk_buff *skb, int err)
@@ -429,6 +437,12 @@ static struct xfrm4_protocol vti_ipcomp4_protocol
__read_mostly = {
.priority = 100,
};
+static struct xfrm_tunnel ipip_handler __read_mostly = {
+ .handler= vti_rcv,
+ .err_handler= vti4_err,
+ .priority = 0,
+};
+
static int __net_init vti_init_net(struct net *net)
{
int err;
@@ -597,6 +611,13 @@ static int __init vti_init(void)
if (err < 0)
goto xfrm_proto_comp_failed;
+ msg = "ipip tunnel";
+ err = xfrm4_tunnel_register(_handler, AF_INET);
+ if (err < 0) {
+ pr_info("%s: cant't register tunnel\n",__func__);
+ goto xfrm_tunnel_failed;
+ }
+
msg = "netlink interface";
err = rtnl_link_register(_link_ops);
if (err < 0)
@@ -606,6 +627,8 @@ static int __init vti_init(void)
rtnl_link_failed:
xfrm4_protocol_deregister(_ipcomp4_protocol, IPPROTO_COMP);
+xfrm_tunnel_failed:
+ xfrm4_tunnel_deregister(_handler, AF_INET);
xfrm_proto_comp_failed:
xfrm4_protocol_deregister(_ah4_protocol, IPPROTO_AH);
xfrm_proto_ah_failed:
--
2.7.4
[PATCH v2] netfilter: account ebt_table_info to kmemcg
The [ip,ip6,arp]_tables use x_tables_info internally and the underlying
memory is already accounted to kmemcg. Do the same for ebtables. The
syzbot, by using setsockopt(EBT_SO_SET_ENTRIES), was able to OOM the
whole system from a restricted memcg, a potential DoS.
By accounting the ebt_table_info, the memory used for ebt_table_info can
be contained within the memcg of the allocating process. However the
lifetime of ebt_table_info is independent of the allocating process and
is tied to the network namespace. So, the oom-killer will not be able to
relieve the memory pressure due to ebt_table_info memory. The memory for
ebt_table_info is allocated through vmalloc. Currently vmalloc does not
handle the oom-killed allocating process correctly and one large
allocation can bypass memcg limit enforcement. So, with this patch,
at least the small allocations will be contained. For large allocations,
we need to fix vmalloc.
Reported-by: syzbot+7713f3aa67be76b15...@syzkaller.appspotmail.com
Signed-off-by: Shakeel Butt
Cc: Florian Westphal
Cc: Michal Hocko
Cc: Kirill Tkhai
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc: Roopa Prabhu
Cc: Nikolay Aleksandrov
Cc: Andrew Morton
Cc: Linux MM
Cc: netfilter-de...@vger.kernel.org
Cc: coret...@netfilter.org
Cc: bri...@lists.linux-foundation.org
Cc: LKML
---
Changelog since v1:
- More descriptive commit message.
net/bridge/netfilter/ebtables.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 491828713e0b..5e55cef0cec3 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1137,14 +1137,16 @@ static int do_replace(struct net *net, const void
__user *user,
tmp.name[sizeof(tmp.name) - 1] = 0;
countersize = COUNTER_OFFSET(tmp.nentries) * nr_cpu_ids;
- newinfo = vmalloc(sizeof(*newinfo) + countersize);
+ newinfo = __vmalloc(sizeof(*newinfo) + countersize, GFP_KERNEL_ACCOUNT,
+ PAGE_KERNEL);
if (!newinfo)
return -ENOMEM;
if (countersize)
memset(newinfo->counters, 0, countersize);
- newinfo->entries = vmalloc(tmp.entries_size);
+ newinfo->entries = __vmalloc(tmp.entries_size, GFP_KERNEL_ACCOUNT,
+PAGE_KERNEL);
if (!newinfo->entries) {
ret = -ENOMEM;
goto free_newinfo;
--
2.20.1.415.g653613c723-goog
linux-next: Tree for Jan 3
Hi all, Please do not add any material destined for the next merge window to your linux-next included trees until after -rc1 has been released. News: there will be no linux-next release tomorrow. Changes since 20190102: The vfs tree still had its build failure for which I applied a patch. The vhost tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 1094 1217 files changed, 37511 insertions(+), 17642 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 293 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (85f78456f286 Merge tag '9p-for-4.21' of git://github.com/martinetd/linux) Merging fixes/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging kbuild-current/fixes (e1ef035d272e Merge tag 'armsoc-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging arc-current/for-curr (5fac3149be6f ARC: adjust memblock_reserve of kernel memory) Merging arm-current/fixes (c2a3831df6dc ARM: 8816/1: dma-mapping: fix potential uninitialized return) Merging arm64-fixes/for-next/fixes (3238c359acee arm64: dma-mapping: Fix FORCE_CONTIGUOUS buffer clearing) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (f460772291f8 KVM: PPC: Book3S HV: radix: Fix uninitialized var build error) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (d63967e475ae isdn: fix kernel-infoleak in capi_unlocked_ioctl) Merging bpf/master (8b6b25cf93b7 selftests/bpf: fix error printing in test_devmap()) Merging ipsec/master (3061169a47ee Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging netfilter/master (a007232066f6 netfilter: nf_conncount: fix argument order to find_next_bit) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (53884577fbce ath10k: skip sending quiet mode cmd for WCN3990) Merging mac80211/master (1d51b4b1d3f2 Merge tag 'm68k-for-v4.20-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k) Merging rdma-fixes/for-rc (37fbd834b4e4 IB/core: Fix oops in netdev_next_upper_dev_rcu()) Merging sound-current/for-linus (3e9ad24b0e91 ALSA: hda - Revert DSP detection on legacy HD-audio driver) Merging sound-asoc-fixes/for-linus (6cb3c5b355ab Merge branch 'asoc-4.20' into asoc-linus) Merging regmap-fixes/for-linus (8fe28cb58bcb Linux 4.20) Merging regulator-fixes/for-linus (c8c6b9fda37f Merge branch 'regulator-4.20' into regulator-linus) Merging spi-fixes/for-linus (21929ad56551 Merge branch 'spi-4.20' into spi-linus) Merging pci-current/for-linus (1063a5148ac9 PCI/AER: Queue one GHES event, not several uninitialized ones) Merging driver-core.current/driver-core-linus (8e143b90e4d4 Merge tag 'iommu-updates-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu) Merging tty.current/tty-linus (8e143b90e4d4 Merge tag 'iommu-updates-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu) Merging u
RE: [PATCH] net: tsn: add an netlink interface between kernel and application layer
Hi Vinicius, Thanks! As comments below. Br, Po Liu > -Original Message- > From: Vinicius Costa Gomes [mailto:vinicius.go...@intel.com] > Sent: 2019年1月3日 3:02 > To: Po Liu ; net...@vger.kernel.org; linux- > ker...@vger.kernel.org > Cc: da...@davemloft.net; haus...@cisco.com; nicolas.fe...@microchip.com; > gre...@linuxfoundation.org; Mingkai Hu ; Roy Zang > > Subject: RE: [PATCH] net: tsn: add an netlink interface between kernel and > application layer > > Hi Po Liu, > > PO LIU writes: > > > Hi Vinicius, > > > > Thank you very much for your feedback. > > > > I know the CBS is used to be most important part of AVB. And qdiscs is good > tool to configure qos. > > > > But as you know, the TSN family is a cluster of protocols and much extending > the AVB. The protocols have different functionalities and they may have more > than hundred parameters. For example NXP ls1028a support > Qbv/Qci/Qbu/Qav and also the 8021CB (not included in this patch yet). > > > > Some protocols target to configure the traffic class(like Qav CBS). > > Some to config the port(like Qbv). But some for the whole ethernet > > controller(like Qci, the control entries for the whole controller, > > which input ports and which output ports). > > Reading your email, now I understand your point a little better. You are > interested in multi-port devices. I admit that I am not too familiar with how > multi-port devices are exposed in Linux, I was only focused on the end-station > use cases, until now. > > > > > So I do think all the TSN configuration should not mix in the ethernet > > driver itself. I mean the driver should separate a xxx_tsn.c(for I210, > > may igb_tsn.c) to maintain the tsn operations. > > > As far as using qdiscs or the interface of generic netlink. I think > > both could configuring the TSN protocols interface layer. Just what I > > provided the patch net/tsn/genl_tsn.c. But I do believe it is better > > using a standalone TSN middle layer to maintain the TSN capability > > ports. Because the TSN ports include not only the end station and also > > the switch. LS1028 is such a kind of device. > > I think this is the "interesting" part of the discussion. From my point of > view the > question now is: > > "We already have an acceptable way to expoose TSN features for end stations. > What can we do for multi-port devices?" [Po Liu] correct, that is what we expect to do. There could be with more than one ethernet controllers(or switch) with TSN capability. Ether pci plug in, or SOC chips. This patch try to manage all. > > What are the options here? From a quick look, it seems that extending > switchdev is a possible solution. What else? [Po Liu] that's it. Could extend it. > > Thinking a little more, if all the ports have netdevices associated with them, > then it could be that exposing those features via qdiscs could be considered > still. > Perhaps taking a look at how tc-flower offloading is done can give some ideas. [Po Liu] I did using the tc-flower at application layer to filter the frames to different queue. I avoid to using the qos but only using the multiq to make all traffic classes to be exposed to user space. I am trying to understand what your patch working on the qdisc and how it help for TSN. > > And about the process, usually when a new interface is proposed, the patches > are directed to net-next and have the RFC tag, so the readers (and their > tools) > know what to expect. [Po Liu] thanks for the mention, I would update. > > > > > And your advises are precious for us. Let's make out an easy and > > flexible interface for TSN. > > > > Br, > > Po Liu > > > > Cheers, > -- > Vinicius
[PATCH -next] um: Remove duplicated include from vector_user.c
Remove duplicated include. Signed-off-by: YueHaibing --- arch/um/drivers/vector_user.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/um/drivers/vector_user.c b/arch/um/drivers/vector_user.c index d2c17dd..b3f7b3c 100644 --- a/arch/um/drivers/vector_user.c +++ b/arch/um/drivers/vector_user.c @@ -16,14 +16,12 @@ #include #include #include -#include #include #include #include #include #include #include -#include #include #include #include @@ -31,7 +29,6 @@ #include #include #include -#include #include "vector_user.h" #define ID_GRE 0
Re: [GIT PULL] Mailbox changes for v4.21
The pull request you sent on Tue, 1 Jan 2019 23:34:36 -0600: > git://git.linaro.org/landing-teams/working/fujitsu/integration.git > tags/mailbox-v4.21 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/35ddb06a467538434b4139fbf5c02a2ef073162a Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PULL] virtio, vhost: features, fixes, cleanups
The pull request you sent on Wed, 2 Jan 2019 16:23:23 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d548e65904ae43b0637d200a2441fc94e0589c30 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] one more clk change for the merge window
The pull request you sent on Wed, 2 Jan 2019 09:53:42 -0800: > https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git > tags/clk-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0f2107daec8137e1ea8bcd6df1323ffe46a2e873 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [git pull] Input updates for v4.21-rc0
The pull request you sent on Wed, 2 Jan 2019 17:06:36 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/645ff1e8e704c4f33ab1fcd3c87f95cb9b6d7144 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Device properties framework fixes for v4.21-rc1
The pull request you sent on Wed, 2 Jan 2019 11:33:42 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > devprop-4.21-rc1-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/01766d27d265afe7e93a8aa033afae5635d5aba0 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] s390 patches for the 4.21 merge window
The pull request you sent on Wed, 2 Jan 2019 08:43:54 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-4.21-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/04a17edeca524b71dbb5be41a7002d247fbf34c0 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] UML changes for 4.21
The pull request you sent on Wed, 02 Jan 2019 23:52:26 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus-4.21-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6aa293d8ff0939802a6c86cee6cd152c1b0a7a0d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH v2] driver: uio: fix possible memory leak in uio_open
v1->v2:
rename the "err_infoopen" to "err_idev_info"
Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered")
Signed-off-by: liujian
---
drivers/uio/uio.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 5c10fc7..aab3520 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -496,18 +496,19 @@ static int uio_open(struct inode *inode, struct file
*filep)
if (!idev->info) {
mutex_unlock(>info_lock);
ret = -EINVAL;
- goto err_alloc_listener;
+ goto err_idev_info;
}
if (idev->info && idev->info->open)
ret = idev->info->open(idev->info, inode);
mutex_unlock(>info_lock);
if (ret)
- goto err_infoopen;
+ goto err_idev_info;
return 0;
-err_infoopen:
+err_idev_info:
+ filep->private_data = NULL;
kfree(listener);
err_alloc_listener:
--
2.7.4
Re: [PATCH V2] thermal: Fix locking in cooling device sysfs update cur_state
On 三, 2019-01-02 at 21:29 -0500, Thara Gopinath wrote: > On 11/27/2018 05:43 PM, Thara Gopinath wrote: > > > > Sysfs interface to update cooling device cur_state does not > > currently holding cooling device lock sometimes leading to > > stale values in cur_state if getting updated simultanelously > > from user space and thermal framework. Adding the proper locking > > code fixes this issue. > > > > Signed-off-by: Thara Gopinath > > --- > > > > V1->V2: Rearranged the code as per Daniel's review comment > Hi Eduardo, Daniel > > Any comments on this ? > it's already in my tree, and will be included in my pull request which will be sent out soon. thanks, rui > Regards > Thara > > > > > > > drivers/thermal/thermal_sysfs.c | 11 +++ > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/thermal/thermal_sysfs.c > > b/drivers/thermal/thermal_sysfs.c > > index 2241cea..aa99edb 100644 > > --- a/drivers/thermal/thermal_sysfs.c > > +++ b/drivers/thermal/thermal_sysfs.c > > @@ -712,11 +712,14 @@ cur_state_store(struct device *dev, struct > > device_attribute *attr, > > if ((long)state < 0) > > return -EINVAL; > > > > + mutex_lock(>lock); > > + > > result = cdev->ops->set_cur_state(cdev, state); > > - if (result) > > - return result; > > - thermal_cooling_device_stats_update(cdev, state); > > - return count; > > + if (!result) > > + thermal_cooling_device_stats_update(cdev, state); > > + > > + mutex_unlock(>lock); > > + return result ? result : count; > > } > > > > static struct device_attribute > > > >
[PATCH] In function rt274_i2c_probe(), if the regmap_read fails. The variable "val" could leave uninitialized but used in if statement.
Signed-off-by: Yizhuo
---
sound/soc/codecs/rt274.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/rt274.c b/sound/soc/codecs/rt274.c
index 8f92e5c4dd9d..940658cac063 100644
--- a/sound/soc/codecs/rt274.c
+++ b/sound/soc/codecs/rt274.c
@@ -1113,7 +1113,7 @@ static int rt274_i2c_probe(struct i2c_client *i2c,
struct rt274_priv *rt274;
int ret;
- unsigned int val;
+ unsigned int val = ~0;
rt274 = devm_kzalloc(>dev, sizeof(*rt274),
GFP_KERNEL);
@@ -1128,9 +1128,9 @@ static int rt274_i2c_probe(struct i2c_client *i2c,
return ret;
}
- regmap_read(rt274->regmap,
+ ret = regmap_read(rt274->regmap,
RT274_GET_PARAM(AC_NODE_ROOT, AC_PAR_VENDOR_ID), );
- if (val != RT274_VENDOR_ID) {
+ if (ret || val != RT274_VENDOR_ID) {
dev_err(>dev,
"Device with ID register %#x is not rt274\n", val);
return -ENODEV;
--
2.17.1
Re: [PATCH v5 6/6] arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile
On Fri, 2018-12-28 at 16:11 -0600, Rob Herring wrote:
> On Fri, Dec 28, 2018 at 04:09:41PM +0800, Erin Lo wrote:
> > From: Ben Ho
> >
> > Add basic chip support for Mediatek 8183, include
> > pinctrl file, uart node with correct uart clocks, pwrap device
> > M4U, smi-common and smi-larbs.
> >
> > Add clock controller nodes, include topckgen, infracfg,
> > apmixedsys and subsystem.
> >
> > Add power controller and scpsys node.
> >
> > Signed-off-by: Ben Ho
> > Signed-off-by: Erin Lo
> > Signed-off-by: Seiya Wang
> > Signed-off-by: Zhiyong Tao
> > Signed-off-by: Weiyi Lu
> > Signed-off-by: Yong Wu
> > Signed-off-by: Mengqi Zhang
> > Signed-off-by: Hsin-Hsiung Wang
> > Signed-off-by: Eddie Huang
> > ---
> > arch/arm64/boot/dts/mediatek/Makefile |1 +
> > arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 136 +++
> > arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h | 1120
> > +
> > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 547
> > 4 files changed, 1804 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/Makefile
> > b/arch/arm64/boot/dts/mediatek/Makefile
> > index e8f952f..458bbc4 100644
> > --- a/arch/arm64/boot/dts/mediatek/Makefile
> > +++ b/arch/arm64/boot/dts/mediatek/Makefile
> > @@ -7,3 +7,4 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
> > dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
> > dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-bananapi-bpi-r64.dtb
> > dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
> > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > new file mode 100644
> > index 000..5d308cb
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > @@ -0,0 +1,136 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright (c) 2018 MediaTek Inc.
> > + * Author: Ben Ho
> > + *Erin Lo
> > + */
> > +
> > +/dts-v1/;
> > +#include "mt8183.dtsi"
> > +
> > +/ {
> > + model = "MediaTek MT8183 evaluation board";
> > + compatible = "mediatek,mt8183-evb", "mediatek,mt8183";
> > +
> > + aliases {
> > + serial0 =
> > + };
> > +
> > + memory@4000 {
> > + device_type = "memory";
> > + reg = <0 0x4000 0 0x8000>;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:921600n8";
> > + };
> > +};
> > +
> > + {
> > + spi_pins_0: spi0@0{
>
> Build your dtb with W=1 and fix the warnings.
I will do it next time.
Thank you~
>
> > + pins_spi{
> > + pinmux = ,
> > +,
> > +,
> > +;
> > + bias-disable;
> > + };
> > + };
> > +
> > + spi_pins_1: spi1@0{
> > + pins_spi{
> > + pinmux = ,
> > +,
> > +,
> > +;
> > + bias-disable;
> > + };
> > + };
> > +
> > + spi_pins_2: spi2@0{
> > + pins_spi{
> > + pinmux = ,
> > +,
> > +,
> > +;
> > + bias-disable;
> > + };
> > + };
> > +
> > + spi_pins_3: spi3@0{
> > + pins_spi{
> > + pinmux = ,
> > +,
> > +,
> > +;
> > + bias-disable;
> > + };
> > + };
> > +
> > + spi_pins_4: spi4@0{
> > + pins_spi{
> > + pinmux = ,
> > +,
> > +,
> > +;
> > + bias-disable;
> > + };
> > + };
> > +
> > + spi_pins_5: spi5@0{
> > + pins_spi{
> > + pinmux = ,
> > +,
> > +,
> > +;
> > + bias-disable;
> > + };
> > + };
> > +};
> > +
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_pins_0>;
> > + mediatek,pad-select = <0>;
> > + status = "okay";
> > +};
> > +
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_pins_1>;
> > + mediatek,pad-select = <0>;
> > + status = "okay";
> > +};
> > +
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_pins_2>;
> > + mediatek,pad-select = <0>;
> > + status = "okay";
> > +};
> > +
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_pins_3>;
> > + mediatek,pad-select = <0>;
> > + status = "okay";
> > +};
> > +
> > + {
> > + pinctrl-names =
Re: [GIT PULL] nfsd
The pull request you sent on Wed, 2 Jan 2019 15:43:07 -0500: > git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.21 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e45428a436765fcd154d461a2739b5640916dc00 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull NFS client updates for 4.21
The pull request you sent on Wed, 2 Jan 2019 22:42:32 +: > git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.21-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e6b92572808467f35fd159d47c45b650de29e722 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: Shaohua Li
On 1/3/19 1:13 AM, Jens Axboe wrote: Hi, I've got some very sad news to share with you - over Christmas, Shaohua Li passed away after battling cancer for most of last year. It is really a sad news and a big lost for the community consider Shaohua's great contribution! As you know, Shaohua acted as the maintainer for md. He remained dedicated to that through the difficult times. With his passing, we obviously have a void that needs to be filled. It is better if there is a small team to maintain md in future since nobody have broad/deep knowledge as Neil or Shaohua, also people in the team can cover/backup each other, see [1]. For now, I'll act as interim maintainer for md until we can find a good permanent solution. I'll queue up reviewed patches in a separate branch, in the block tree, and help review fixes. I'm subscribed to linux-raid, but please do CC me as well. Thanks, I think there are some patches in shli/md/for-next which supposed to be merge to 4.21, could you please help to merge them to your branch? And I suppose you will send a patch to CREDITS for Shaohua. [1]. https://lkml.org/lkml/2015/12/21/9 Regards, Guoqing
Re: [PATCH V2] thermal: Fix locking in cooling device sysfs update cur_state
On 11/27/2018 05:43 PM, Thara Gopinath wrote: > Sysfs interface to update cooling device cur_state does not > currently holding cooling device lock sometimes leading to > stale values in cur_state if getting updated simultanelously > from user space and thermal framework. Adding the proper locking > code fixes this issue. > > Signed-off-by: Thara Gopinath > --- > > V1->V2: Rearranged the code as per Daniel's review comment Hi Eduardo, Daniel Any comments on this ? Regards Thara > > drivers/thermal/thermal_sysfs.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c > index 2241cea..aa99edb 100644 > --- a/drivers/thermal/thermal_sysfs.c > +++ b/drivers/thermal/thermal_sysfs.c > @@ -712,11 +712,14 @@ cur_state_store(struct device *dev, struct > device_attribute *attr, > if ((long)state < 0) > return -EINVAL; > > + mutex_lock(>lock); > + > result = cdev->ops->set_cur_state(cdev, state); > - if (result) > - return result; > - thermal_cooling_device_stats_update(cdev, state); > - return count; > + if (!result) > + thermal_cooling_device_stats_update(cdev, state); > + > + mutex_unlock(>lock); > + return result ? result : count; > } > > static struct device_attribute >
Re: [RFC PATCH 6/7] soc: mediatek: add MT8183 dvfsrc support
On Wed, Jan 2, 2019 at 10:01 PM Henry Chen wrote:
>
> Add dvfsrc driver for MT8183
>
> Signed-off-by: Henry Chen
> ---
> drivers/soc/mediatek/Kconfig | 15 ++
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-dvfsrc.c | 473
> ++
> 3 files changed, 489 insertions(+)
> create mode 100644 drivers/soc/mediatek/mtk-dvfsrc.c
>
> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> index a7d0667..f956f03 100644
> --- a/drivers/soc/mediatek/Kconfig
> +++ b/drivers/soc/mediatek/Kconfig
> @@ -12,6 +12,21 @@ config MTK_INFRACFG
> INFRACFG controller contains various infrastructure registers not
> directly associated to any device.
>
> +config MTK_DVFSRC
> + bool "MediaTek DVFSRC Support"
> + depends on ARCH_MEDIATEK
> + default ARCH_MEDIATEK
> + select REGMAP
> + select MTK_INFRACFG
> + select PM_GENERIC_DOMAINS if PM
> + depends on MTK_SCPSYS
> + help
> + Say yes here to add support for the MediaTek DVFSRC found
> + on different MediaTek SoCs. The DVFSRC is a proprietary
> + hardware which is used to collect all the requests from
> + system and turn into the decision of minimum Vcore voltage
> + and minimum DRAM frequency to fulfill those requests.
> +
> config MTK_PMIC_WRAP
> tristate "MediaTek PMIC Wrapper Support"
> depends on RESET_CONTROLLER
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index 9dc6670..5c010b9 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -1,3 +1,4 @@
> +obj-$(CONFIG_MTK_DVFSRC) += mtk-dvfsrc.o
> obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o mtk-scpsys-ext.o
> obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> diff --git a/drivers/soc/mediatek/mtk-dvfsrc.c
> b/drivers/soc/mediatek/mtk-dvfsrc.c
> new file mode 100644
> index 000..af462a3
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-dvfsrc.c
> @@ -0,0 +1,473 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 MediaTek Inc.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Alphabetical order.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "mtk-scpsys.h"
> +
> +#define DVFSRC_IDLE0x00
> +#define DVFSRC_GET_TARGET_LEVEL(x) (((x) >> 0) & 0x)
> +#define DVFSRC_GET_CURRENT_LEVEL(x)(((x) >> 16) & 0x)
> +
> +/* macro for irq */
> +#define DVFSRC_IRQ_TIMEOUT_EN BIT(1)
> +
> +struct dvfsrc_opp {
> + int vcore_opp;
> + int dram_opp;
> +};
> +
> +struct dvfsrc_domain {
> + int id;
> + int state;
> +};
> +
> +struct mtk_dvfsrc;
> +struct dvfsrc_soc_data {
> + const int *regs;
> + int num_opp;
> + int num_domains;
> + int dram_sft;
> + int vcore_sft;
> + const struct dvfsrc_opp **opps;
> + struct dvfsrc_domain *domains;
> + void (*init_soc)(struct mtk_dvfsrc *dvfsrc);
> + int (*get_target_level)(struct mtk_dvfsrc *dvfsrc);
> + int (*get_current_level)(struct mtk_dvfsrc *dvfsrc);
> +};
> +
> +struct mtk_dvfsrc {
> + struct device *dev;
> + struct clk *clk_dvfsrc;
> + const struct dvfsrc_soc_data *dvd;
> + int dram_type;
> + int irq;
> + void __iomem *regs;
> + struct mutex lock; /* generic mutex for dvfsrc driver */
> +
> + struct notifier_block qos_notifier;
> + struct notifier_block scpsys_notifier;
> +};
> +
> +static u32 dvfsrc_read(struct mtk_dvfsrc *dvfs, u32 offset)
> +{
> + return readl(dvfs->regs + dvfs->dvd->regs[offset]);
> +}
> +
> +static void dvfsrc_write(struct mtk_dvfsrc *dvfs, u32 offset, u32 val)
> +{
> + writel(val, dvfs->regs + dvfs->dvd->regs[offset]);
> +}
> +
> +enum dvfsrc_regs {
> + DVFSRC_BASIC_CONTROL,
> + DVFSRC_SW_REQ,
> + DVFSRC_SW_REQ2,
> + DVFSRC_EMI_REQUEST,
> + DVFSRC_EMI_REQUEST2,
> + DVFSRC_EMI_REQUEST3,
> + DVFSRC_EMI_QOS0,
> + DVFSRC_EMI_QOS1,
> + DVFSRC_EMI_QOS2,
> + DVFSRC_EMI_MD2SPM0,
> + DVFSRC_EMI_MD2SPM1,
> + DVFSRC_VCORE_REQUEST,
> + DVFSRC_VCORE_REQUEST2,
> + DVFSRC_VCORE_MD2SPM0,
> + DVFSRC_INT,
> + DVFSRC_INT_EN,
> + DVFSRC_INT_CLR,
> + DVFSRC_TIMEOUT_NEXTREQ,
> + DVFSRC_LEVEL,
> + DVFSRC_LEVEL_LABEL_0_1,
> + DVFSRC_LEVEL_LABEL_2_3,
> + DVFSRC_LEVEL_LABEL_4_5,
> + DVFSRC_LEVEL_LABEL_6_7,
> + DVFSRC_LEVEL_LABEL_8_9,
> + DVFSRC_LEVEL_LABEL_10_11,
> + DVFSRC_LEVEL_LABEL_12_13,
> + DVFSRC_LEVEL_LABEL_14_15,
> + DVFSRC_SW_BW_0,
> + DVFSRC_QOS_EN,
> + DVFSRC_FORCE,
> + DVFSRC_LAST,
> + DVFSRC_RSRV_0,
> + DVFSRC_RSRV_1,
> +};
> +
Re: Please help!: Keyboard backlight not working on my NP900X5N laptop
On Thu, Jan 03, 2019 at 12:20:15AM +0100, Jan Vlietland wrote: > Hi guys, > > Sorry but still walking with this bug under my arm. > > I can't find the right group to file the bug on bugzilla and also on > freenode I cannot find the right group. > > Please help! Hi Jan, I responded to your original email from Dec 31. You will need to allow more time for people to respond as many of us are doing this work on our own time - and this was New Year's Eve/Day. General rule of thumb is to give people a week before following up. We make an effort to respond within 48 business hours, but I find that pretty difficult to keep up with myself. Let's continue the discussion in the original thread. -- Darren Hart VMware Open Source Technology Center
Re: [PATCH] x86/retpoline: change RETPOLINE into CONFIG_RETPOLINE
On 2019/1/3 1:23, Nadav Amit wrote:
On Jan 1, 2019, at 5:17 PM, Zhenzhong Duan wrote:
On 2019/1/1 7:42, Nadav Amit wrote:
A recent enhancement intentionally fails the kernel build if the
compiler does not support retpolines and CONFIG_RETPOLINE is set.
However, the patch that introduced it did not change RETPOLINE macro
references into CONFIG_RETPOLINE ones. As a result, indirect branches
that are used by init functions are not kept (i.e., they use
retpolines), and modules that do not use retpolines are marked as
retpoline-safe.
Fix it be changing RETPOLINE into CONFIG_RETPOLINE.
Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler
support")
Cc: Peter Zijlstra
Cc: Zhenzhong Duan
Cc: Thomas Gleixner
Cc: David Woodhouse
Cc: Andy Lutomirski
Cc: Masahiro Yamada
Cc: sta...@vger.kernel.org
Signed-off-by: Nadav Amit
---
arch/x86/kernel/cpu/bugs.c | 2 +-
include/linux/compiler-gcc.h | 2 +-
include/linux/module.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 8654b8b0c848..1de0f4170178 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -215,7 +215,7 @@ static enum spectre_v2_mitigation spectre_v2_enabled
__ro_after_init =
static enum spectre_v2_user_mitigation spectre_v2_user __ro_after_init =
SPECTRE_V2_USER_NONE;
-#ifdef RETPOLINE
+#ifdef CONFIG_RETPOLINE
static bool spectre_v2_bad_module;
bool retpoline_module_ok(bool has_retpoline)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 2010493e1040..977ddf2774f9 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -68,7 +68,7 @@
*/
#define uninitialized_var(x) x = x
-#ifdef RETPOLINE
+#ifdef CONFIG_RETPOLINE
#define __noretpoline __attribute__((__indirect_branch__("keep")))
#endif
diff --git a/include/linux/module.h b/include/linux/module.h
index fce6b4335e36..0c575f51fe57 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -817,7 +817,7 @@ static inline void module_bug_finalize(const Elf_Ehdr *hdr,
static inline void module_bug_cleanup(struct module *mod) {}
#endif/* CONFIG_GENERIC_BUG */
-#ifdef RETPOLINE
+#ifdef CONFIG_RETPOLINE
extern bool retpoline_module_ok(bool has_retpoline);
#else
static inline bool retpoline_module_ok(bool has_retpoline)
Someone sent a similar patch last month, see below link, you missed the change
in scripts/mod/modpost.c
Indeed. I missed this patch since it wasn’t on tip (and Google wasn’t
helpful either).
I wonder why it has still not been applied.
See https://lkml.org/lkml/2018/12/21/244
--
Thanks
Zhenzhong
Re: [PATCH -next] IB/qib: Add missing err handle for qib_user_sdma_rb_insert
On 2019/1/3 3:07, Jason Gunthorpe wrote:
> On Wed, Jan 02, 2019 at 08:40:50PM +0200, Leon Romanovsky wrote:
>> On Wed, Jan 02, 2019 at 10:12:24AM -0700, Jason Gunthorpe wrote:
>>> On Fri, Dec 21, 2018 at 10:19:38AM +0800, YueHaibing wrote:
It should goto err handle if qib_user_sdma_rb_insert fails,
other than success return.
Fixes: 67810e8c3c01 ("RDMA/qib: Remove all occurrences of BUG_ON()")
Signed-off-by: YueHaibing
drivers/infiniband/hw/qib/qib_user_sdma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/infiniband/hw/qib/qib_user_sdma.c
b/drivers/infiniband/hw/qib/qib_user_sdma.c
index 31c523b..e87c0a7 100644
+++ b/drivers/infiniband/hw/qib/qib_user_sdma.c
@@ -237,6 +237,8 @@ qib_user_sdma_queue_create(struct device *dev, int
unit, int ctxt, int sctxt)
ret = qib_user_sdma_rb_insert(_user_sdma_rb_root,
sdma_rb_node);
+ if (ret == 0)
+ goto err_rb;
}
>>>
>>> This doesn't look right, what about undoing the kmalloc directly
>>> above?
>>
>> Back then, I came to conclusion that qib_user_sdma_rb_insert() never
>> returns 0. Otherwise, Dennis would see that BUG_ON() for a long time
>> ago.
>
> It fails if the index is in the RB tree, which would indicate a
> programming bug.
>
> The way to replace the BUG_ON is something like:
>
Oh, yes, I forget kfree this mem.
> if (WARN_ON(ret == 0)) {
> kfree()
> goto err_rb;
> }
>
> Jason
>
> .
>
Re: [PATCH v9 1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support
Hi, While you are making changes, here are a few more: On 1/2/19 5:39 PM, Nicolas Boichat wrote: > diff --git a/drivers/dma/mediatek/Kconfig b/drivers/dma/mediatek/Kconfig > index 27bac0b..1a523c87 100644 > --- a/drivers/dma/mediatek/Kconfig > +++ b/drivers/dma/mediatek/Kconfig > @@ -1,4 +1,15 @@ > > +config DMA_MTK_UART > + tristate "MediaTek SoCs APDMA support for UART" > + depends on OF && SERIAL_8250_MT6577 > + select DMA_ENGINE > + select DMA_VIRTUAL_CHANNELS > + help > + Support for the UART DMA engine found on MediaTek MTK SoCs. > + when SERIAL_8250_MT6577 is enabled, and if you want to use DMA, When > + you can enable the config. the DMA engine can only be used The > + with MediaTek SoCs. > + Also, use tabs to indent instead of spaces. The lines (tristate, depends, select, and help) should be indented with one tab. The help text lines should be indented with one tab + 2 spaces. > config MTK_HSDMA > tristate "MediaTek High-Speed DMA controller support" > depends on ARCH_MEDIATEK || COMPILE_TEST thanks, -- ~Randy
Re: Keyboard backlight not working on my NP900X5N laptop
On Mon, Dec 31, 2018 at 08:40:43PM +0100, Jan Vlietland wrote:
> Hi all,
>
Hey Jan,
> Greg K-H suggested to mail you guys.
>
> I installed Linux 4.20.0-rc7 (downloaded, compiled and installed) on a
> Samsung NP900X5N laptop and have noticed 3 bugs. 2 of them I found in
> Bugzilla and replied on them (i915 and Nouveau issues). I am currently
> discussing them with an intel engineer.
>
> On other bug I haven't found so therefore a mail directly to you guys as
> maintainers.
>
> On my other machine, a Samsung NP900X4D (just bought it in the USA, 2017
> model), the samsung-laptop.ko module is enabling the use of the keyboard
> backlight keys.
>
> It is not working on my new machine NP900X5N. My samsung-laptop.ko driver
> isn't loading. If I try to load it manually it complains about 'no such
> device".
>
> My Linux kernel is working in CSM mode. The module is still not loaded.
>
That's correct.
> As it is weekend I did some more reading and debugging of the module. To my
> understanding the module checks the model and type of the laptop. The known
> models and types are stored in the struct:
>
> static struct dmi_system_id __initdata samsung_dmi_table[]
>
> I wondr if the NP900X5N notebook is included in this list.
>
> With dmidecode -t chassis it shows:
> Getting SMBIOS data from sysfs.
> SMBIOS 3.0.0 present.
>
> Handle 0x0003, DMI type 3, 22 bytes
> Chassis Information
> Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
> Type: Notebook
> Lock: Not Present
> Version: N/A
> Serial Number: 0F4C91CJ900346
> Asset Tag: No Asset Tag
> Boot-up State: Safe
> Power Supply State: Safe
> Thermal State: Other
> Security Status: None
> OEM Information: 0x
> Height: Unspecified
> Number Of Power Cords: 1
> Contained Elements: 0
> SKU Number: Chassis
>
> If I use the -u flag. The notebook value is 0x0A, not 0x10!!!
>
> Could that be the reason for not loading?
Seems likely.
>
> .matches = {
> DMI_MATCH(DMI_SYS_VENDOR,
> "SAMSUNG ELECTRONICS CO., LTD."),
> DMI_MATCH(DMI_CHASSIS_TYPE, "10"), /* Notebook */
> },
>
> Maybe another reason could that that either the i915 and Nouveau modules are
> not working well. I get black screens with the i915 and MMIO faults with the
> nouveau driver. That is another issue that I need to tackle.
>
I would expect a different error than "no such device" in that case.
I think your first thought was correct.
As a simple test, I'd suggest replacing "10" with "0A" in the existing
DMI_CHASSIS_TYPE match, recompile, and see if it loads and works
correctly. Would you be able to test this?
> Oh happy new year :-)
Happy New Year!
--
Darren Hart
VMware Open Source Technology Center
Re: KASAN: use-after-free Read in posix_lock_inode
On Wed, Jan 02 2019, Jeff Layton wrote: > On Thu, 2019-01-03 at 11:04 +1100, NeilBrown wrote: >> On Wed, Jan 02 2019, Jeff Layton wrote: >> >> > On Wed, 2019-01-02 at 02:31 -0800, syzbot wrote: >> > > Hello, >> > > >> > > syzbot found the following crash on: >> > > >> > > HEAD commit:e1ef035d272e Merge tag 'armsoc-defconfig' of >> > > git://git.ker.. >> > > git tree: upstream >> > > console output: https://syzkaller.appspot.com/x/log.txt?x=16bb4c4b40 >> > > kernel config: >> > > https://syzkaller.appspot.com/x/.config?x=9c6a26e22579190b >> > > dashboard link: >> > > https://syzkaller.appspot.com/bug?extid=239d99847eb49ecb3899 >> > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) >> > > syz repro: >> > > https://syzkaller.appspot.com/x/repro.syz?x=128aa37740 >> > > >> > > IMPORTANT: if you fix the bug, please add the following tag to the >> > > commit: >> > > Reported-by: syzbot+239d99847eb49ecb3...@syzkaller.appspotmail.com >> > > >> > > IPv6: ADDRCONF(NETDEV_UP): vxcan1: link is not ready >> > > IPv6: ADDRCONF(NETDEV_UP): vxcan1: link is not ready >> > > 8021q: adding VLAN 0 to HW filter on device batadv0 >> > > 8021q: adding VLAN 0 to HW filter on device batadv0 >> > > == >> > > BUG: KASAN: use-after-free in what_owner_is_waiting_for fs/locks.c:1000 >> > > [inline] >> > > BUG: KASAN: use-after-free in posix_locks_deadlock fs/locks.c:1023 >> > > [inline] >> > > BUG: KASAN: use-after-free in posix_lock_inode+0x1f9e/0x2750 >> > > fs/locks.c:1163 >> > > Read of size 8 at addr 88808791b000 by task syz-executor2/10100 >> > > >> > > CPU: 1 PID: 10100 Comm: syz-executor2 Not tainted 4.20.0+ #3 >> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >> > > Google 01/01/2011 >> > > Call Trace: >> > > __dump_stack lib/dump_stack.c:77 [inline] >> > > dump_stack+0x1db/0x2d0 lib/dump_stack.c:113 >> > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 >> > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 >> > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 >> > > what_owner_is_waiting_for fs/locks.c:1000 [inline] >> > > posix_locks_deadlock fs/locks.c:1023 [inline] >> > > posix_lock_inode+0x1f9e/0x2750 fs/locks.c:1163 >> > > posix_lock_file fs/locks.c:1346 [inline] >> > > vfs_lock_file fs/locks.c:2314 [inline] >> > > vfs_lock_file+0xc7/0xf0 fs/locks.c:2309 >> > > do_lock_file_wait.part.0+0xe5/0x260 fs/locks.c:2328 >> > > do_lock_file_wait fs/locks.c:2324 [inline] >> > > fcntl_setlk+0x2f1/0xfe0 fs/locks.c:2413 >> > > do_fcntl+0x843/0x12b0 fs/fcntl.c:370 >> > > __do_sys_fcntl fs/fcntl.c:463 [inline] >> > > __se_sys_fcntl fs/fcntl.c:448 [inline] >> > > __x64_sys_fcntl+0x16d/0x1e0 fs/fcntl.c:448 >> > > do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 >> > > entry_SYSCALL_64_after_hwframe+0x49/0xbe >> > > RIP: 0033:0x457ec9 >> > > Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 >> > > f7 >> > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 >> > > ff >> > > ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 >> > > RSP: 002b:7f58bbb50c78 EFLAGS: 0246 ORIG_RAX: 0048 >> > > RAX: ffda RBX: 0003 RCX: 00457ec9 >> > > RDX: 2140 RSI: 0007 RDI: 0003 >> > > RBP: 0073bf00 R08: R09: >> > > R10: R11: 0246 R12: 7f58bbb516d4 >> > > R13: 004be5f0 R14: 004ceab0 R15: >> > > >> > > Allocated by task 10100: >> > > save_stack+0x45/0xd0 mm/kasan/common.c:73 >> > > set_track mm/kasan/common.c:85 [inline] >> > > kasan_kmalloc mm/kasan/common.c:482 [inline] >> > > kasan_kmalloc+0xcf/0xe0 mm/kasan/common.c:455 >> > > kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:397 >> > > kmem_cache_alloc+0x12d/0x710 mm/slab.c:3541 >> > > kmem_cache_zalloc include/linux/slab.h:730 [inline] >> > > locks_alloc_lock+0x8e/0x2f0 fs/locks.c:344 >> > > fcntl_setlk+0xa9/0xfe0 fs/locks.c:2362 >> > > do_fcntl+0x843/0x12b0 fs/fcntl.c:370 >> > > __do_sys_fcntl fs/fcntl.c:463 [inline] >> > > __se_sys_fcntl fs/fcntl.c:448 [inline] >> > > __x64_sys_fcntl+0x16d/0x1e0 fs/fcntl.c:448 >> > > do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 >> > > entry_SYSCALL_64_after_hwframe+0x49/0xbe >> > > >> > > Freed by task 10100: >> > > save_stack+0x45/0xd0 mm/kasan/common.c:73 >> > > set_track mm/kasan/common.c:85 [inline] >> > > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:444 >> > > kasan_slab_free+0xe/0x10 mm/kasan/common.c:452 >> > > __cache_free mm/slab.c:3485 [inline] >> > > kmem_cache_free+0x86/0x260 mm/slab.c:3747 >> > > locks_free_lock+0x27a/0x3f0 fs/locks.c:381 >> > > fcntl_setlk+0x7b5/0xfe0 fs/locks.c:2439 >> > > do_fcntl+0x843/0x12b0 fs/fcntl.c:370 >> > >
[PATCH] memcg: schedule high reclaim for remote memcgs on high_work
If a memcg is over high limit, memory reclaim is scheduled to run on
return-to-userland. However it is assumed that the memcg is the current
process's memcg. With remote memcg charging for kmem or swapping in a
page charged to remote memcg, current process can trigger reclaim on
remote memcg. So, schduling reclaim on return-to-userland for remote
memcgs will ignore the high reclaim altogether. So, punt the high
reclaim of remote memcgs to high_work.
Signed-off-by: Shakeel Butt
---
mm/memcontrol.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index e9db1160ccbc..47439c84667a 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2302,19 +2302,23 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t
gfp_mask,
* reclaim on returning to userland. We can perform reclaim here
* if __GFP_RECLAIM but let's always punt for simplicity and so that
* GFP_KERNEL can consistently be used during reclaim. @memcg is
-* not recorded as it most likely matches current's and won't
-* change in the meantime. As high limit is checked again before
-* reclaim, the cost of mismatch is negligible.
+* not recorded as the return-to-userland high reclaim will only reclaim
+* from current's memcg (or its ancestor). For other memcgs we punt them
+* to work queue.
*/
do {
if (page_counter_read(>memory) > memcg->high) {
- /* Don't bother a random interrupted task */
- if (in_interrupt()) {
+ /*
+* Don't bother a random interrupted task or if the
+* memcg is not current's memcg's ancestor.
+*/
+ if (in_interrupt() ||
+ !mm_match_cgroup(current->mm, memcg)) {
schedule_work(>high_work);
- break;
+ } else {
+ current->memcg_nr_pages_over_high += batch;
+ set_notify_resume(current);
}
- current->memcg_nr_pages_over_high += batch;
- set_notify_resume(current);
break;
}
} while ((memcg = parent_mem_cgroup(memcg)));
--
2.20.1.415.g653613c723-goog
Re: [PATCH] Initialise mmu_notifier_range correctly
On Wed, Jan 02, 2019 at 04:21:26PM -0800, Matthew Wilcox wrote:
>
> One of the paths in follow_pte_pmd() initialised the mmu_notifier_range
> incorrectly.
>
> Signed-off-by: Matthew Wilcox
> Fixes: ac46d4f3c432 ("mm/mmu_notifier: use structure for
> invalidate_range_start/end calls v2")
> Tested-by: Dave Chinner
Reviewed-by: Jérôme Glisse
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 2dd2f9ab57f4..21a650368be0 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4078,8 +4078,8 @@ static int __follow_pte_pmd(struct mm_struct *mm,
> unsigned long address,
> goto out;
>
> if (range) {
> - range->start = address & PAGE_MASK;
> - range->end = range->start + PAGE_SIZE;
> + mmu_notifier_range_init(range, mm, address & PAGE_MASK,
> + (address & PAGE_MASK) + PAGE_SIZE);
> mmu_notifier_invalidate_range_start(range);
> }
> ptep = pte_offset_map_lock(mm, pmd, address, ptlp);
Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions
On Wed, Dec 19, 2018 at 12:08:56PM +0100, Jan Kara wrote:
> On Tue 18-12-18 21:07:24, Jerome Glisse wrote:
> > On Tue, Dec 18, 2018 at 03:29:34PM -0800, John Hubbard wrote:
> > > OK, so let's take another look at Jerome's _mapcount idea all by itself
> > > (using
> > > *only* the tracking pinned pages aspect), given that it is the lightest
> > > weight
> > > solution for that.
> > >
> > > So as I understand it, this would use page->_mapcount to store both the
> > > real
> > > mapcount, and the dma pinned count (simply added together), but only do
> > > so for
> > > file-backed (non-anonymous) pages:
> > >
> > >
> > > __get_user_pages()
> > > {
> > > ...
> > > get_page(page);
> > >
> > > if (!PageAnon)
> > > atomic_inc(page->_mapcount);
> > > ...
> > > }
> > >
> > > put_user_page(struct page *page)
> > > {
> > > ...
> > > if (!PageAnon)
> > > atomic_dec(>_mapcount);
> > >
> > > put_page(page);
> > > ...
> > > }
> > >
> > > ...and then in the various consumers of the DMA pinned count, we use
> > > page_mapped(page)
> > > to see if any mapcount remains, and if so, we treat it as DMA pinned. Is
> > > that what you
> > > had in mind?
> >
> > Mostly, with the extra two observations:
> > [1] We only need to know the pin count when a write back kicks in
> > [2] We need to protect GUP code with wait_for_write_back() in case
> > GUP is racing with a write back that might not the see the
> > elevated mapcount in time.
> >
> > So for [2]
> >
> > __get_user_pages()
> > {
> > get_page(page);
> >
> > if (!PageAnon) {
> > atomic_inc(page->_mapcount);
> > + if (PageWriteback(page)) {
> > + // Assume we are racing and curent write back will not see
> > + // the elevated mapcount so wait for current write back and
> > + // force page fault
> > + wait_on_page_writeback(page);
> > + // force slow path that will fault again
> > + }
> > }
> > }
>
> This is not needed AFAICT. __get_user_pages() gets page reference (and it
> should also increment page->_mapcount) under PTE lock. So at that point we
> are sure we have writeable PTE nobody can change. So page_mkclean() has to
> block on PTE lock to make PTE read-only and only after going through all
> PTEs like this, it can check page->_mapcount. So the PTE lock provides
> enough synchronization.
>
> > For [1] only needing pin count during write back turns page_mkclean into
> > the perfect spot to check for that so:
> >
> > int page_mkclean(struct page *page)
> > {
> > int cleaned = 0;
> > + int real_mapcount = 0;
> > struct address_space *mapping;
> > struct rmap_walk_control rwc = {
> > .arg = (void *),
> > .rmap_one = page_mkclean_one,
> > .invalid_vma = invalid_mkclean_vma,
> > + .mapcount = _mapcount,
> > };
> >
> > BUG_ON(!PageLocked(page));
> >
> > if (!page_mapped(page))
> > return 0;
> >
> > mapping = page_mapping(page);
> > if (!mapping)
> > return 0;
> >
> > // rmap_walk need to change to count mapping and return value
> > // in .mapcount easy one
> > rmap_walk(page, );
> >
> > // Big fat comment to explain what is going on
> > + if ((page_mapcount(page) - real_mapcount) > 0) {
> > + SetPageDMAPined(page);
> > + } else {
> > + ClearPageDMAPined(page);
> > + }
>
> This is the detail I'm not sure about: Why cannot rmap_walk_file() race
> with e.g. zap_pte_range() which decrements page->_mapcount and thus the
> check we do in page_mkclean() is wrong?
>
Ok so i found a solution for that. First GUP must wait for racing
write back. If GUP see a valid write-able PTE and the page has
write back flag set then it must back of as if the PTE was not
valid to force fault. It is just a race with page_mkclean and we
want ordering between the two. Note this is not strictly needed
so we can relax that but i believe this ordering is better to do
in GUP rather then having each single user of GUP test for this
to avoid the race.
GUP increase mapcount only after checking that it is not racing
with writeback it also set a page flag (SetPageDMAPined(page)).
When clearing a write-able pte we set a special entry inside the
page table (might need a new special swap type for this) and change
page_mkclean_one() to clear to 0 those special entry.
Now page_mkclean:
int page_mkclean(struct page *page)
{
int cleaned = 0;
+ int real_mapcount = 0;
struct address_space *mapping;
struct rmap_walk_control rwc = {
.arg = (void *),
.rmap_one = page_mkclean_one,
.invalid_vma = invalid_mkclean_vma,
+ .mapcount = _mapcount,
};
+ int mapcount1, mapcount2;
BUG_ON(!PageLocked(page));
if (!page_mapped(page))
return 0;
mapping = page_mapping(page);
if (!mapping)
return 0;
+ mapcount1 = page_mapcount(page);
// rmap_walk need to change to
Re: [RFC PATCH 3/7] soc: mediatek: add support for the performance state
On Wed, Jan 2, 2019 at 10:01 PM Henry Chen wrote:
>
> Support power domain performance state, add header file for scp event.
>
> Signed-off-by: Henry Chen
> ---
> drivers/soc/mediatek/mtk-scpsys.c | 60
> +++
> drivers/soc/mediatek/mtk-scpsys.h | 22 ++
> 2 files changed, 82 insertions(+)
> create mode 100644 drivers/soc/mediatek/mtk-scpsys.h
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c
> b/drivers/soc/mediatek/mtk-scpsys.c
> index 58d84fe..90102ae 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -11,7 +11,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
>
> @@ -22,6 +24,7 @@
> #include
> #include
> #include
> +#include "mtk-scpsys.h"
>
> #define MTK_POLL_DELAY_US 10
> #define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
> @@ -187,6 +190,18 @@ struct scp_soc_data {
> bool bus_prot_reg_update;
> };
>
> +BLOCKING_NOTIFIER_HEAD(scpsys_notifier_list);
> +
> +int register_scpsys_notifier(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_register(_notifier_list, nb);
> +}
> +
> +int unregister_scpsys_notifier(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_unregister(_notifier_list, nb);
> +}
> +
> static int scpsys_domain_is_on(struct scp_domain *scpd)
> {
> struct scp *scp = scpd->scp;
> @@ -536,6 +551,48 @@ static void init_clks(struct platform_device *pdev,
> struct clk **clk)
> clk[i] = devm_clk_get(>dev, clk_names[i]);
> }
>
> +static int mtk_pd_set_performance(struct generic_pm_domain *genpd,
> + unsigned int state)
> +{
> + int i;
> + struct scp_domain *scpd =
> + container_of(genpd, struct scp_domain, genpd);
nit: This (just) fits in 80 chars.
> + struct scp_event_data scpe;
> + struct scp *scp = scpd->scp;
> + struct genpd_onecell_data *pd_data = >pd_data;
> +
> + for (i = 0; i < pd_data->num_domains; i++) {
> + if (genpd == pd_data->domains[i]) {
> + dev_dbg(scp->dev, "%d. %s = %d\n",
> + i, genpd->name, state);
> + break;
> + }
> + }
Do we need a sanity check here, if i == pd_data->num_domains?
> +
> + scpe.event_type = MTK_SCPSYS_PSTATE;
> + scpe.genpd = genpd;
> + scpe.domain_id = i;
> + blocking_notifier_call_chain(_notifier_list, state, );
> +
> + return 0;
> +}
> +
> +static unsigned int mtk_pd_get_performance(struct generic_pm_domain *genpd,
> + struct dev_pm_opp *opp)
> +{
> + struct device_node *np;
> + unsigned int state;
> +
> + np = dev_pm_opp_get_of_node(opp);
> +
> + if (of_property_read_u32(np, "mtk,level", ))
> + return 0;
> +
> + of_node_put(np);
> +
> + return state;
> +}
> +
> static struct scp *init_scp(struct platform_device *pdev,
> const struct scp_domain_data *scp_domain_data, int
> num,
> const struct scp_ctrl_reg *scp_ctrl_reg,
> @@ -659,6 +716,9 @@ static struct scp *init_scp(struct platform_device *pdev,
> genpd->power_on = scpsys_power_on;
> if (MTK_SCPD_CAPS(scpd, MTK_SCPD_ACTIVE_WAKEUP))
> genpd->flags |= GENPD_FLAG_ACTIVE_WAKEUP;
> +
> + genpd->set_performance_state = mtk_pd_set_performance;
> + genpd->opp_to_performance_state = mtk_pd_get_performance;
> }
>
> return scp;
> diff --git a/drivers/soc/mediatek/mtk-scpsys.h
> b/drivers/soc/mediatek/mtk-scpsys.h
> new file mode 100644
> index 000..c1e8325
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-scpsys.h
> @@ -0,0 +1,22 @@
> +/* SPDX-License-Identifier: GPL-2.0
> + *
> + * Copyright (c) 2018 MediaTek Inc.
> + */
> +
> +#ifndef __MTK_SCPSYS_H__
> +#define __MTK_SCPSYS_H__
> +
> +struct scp_event_data {
> + int event_type;
> + int domain_id;
> + struct generic_pm_domain *genpd;
> +};
> +
> +enum scp_event_type {
> + MTK_SCPSYS_PSTATE,
> +};
> +
> +int register_scpsys_notifier(struct notifier_block *nb);
> +int unregister_scpsys_notifier(struct notifier_block *nb);
> +
> +#endif /* __MTK_SCPSYS_H__ */
> --
> 1.9.1
>
[PATCH] kbuild: remove unnecessary stubs for archheader and archscripts
Make simply skips a missing rule when it is marked as .PHONY. Remove the dummy targets. Signed-off-by: Masahiro Yamada --- Makefile | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/Makefile b/Makefile index 62c9890..0f0f689 100644 --- a/Makefile +++ b/Makefile @@ -1159,11 +1159,7 @@ export INSTALL_HDR_PATH = $(objtree)/usr # If we do an all arch process set dst to include/arch-$(SRCARCH) hdr-dst = $(if $(KBUILD_HEADERS), dst=include/arch-$(SRCARCH), dst=include) -PHONY += archheaders -archheaders: - -PHONY += archscripts -archscripts: +PHONY += archheaders archscripts PHONY += __headers __headers: $(version_h) scripts_basic uapi-asm-generic archheaders archscripts -- 2.7.4
linux-next: manual merge of the vhost tree with Linus' tree
Hi all,
Today's linux-next merge of the vhost tree got a conflict in:
drivers/virtio/virtio_ring.c
between commit:
138fd2514863 ("virtio_ring: add _split suffix for split ring functions")
and various other commits
from Linus' tree and commit:
7f86a211fabe ("virtio: use dependent_ptr_mb")
from the vhost tree.
I fixed it up (I think, basically I added the changes form the latter
to the _split and _packed versions of the function - 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 --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index cd7e755484e3..982e1ed4ecdf 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -676,6 +676,7 @@ static void *virtqueue_get_buf_ctx_split(struct virtqueue
*_vq,
void *ret;
unsigned int i;
u16 last_used;
+ bool more;
START_USE(vq);
@@ -684,14 +685,15 @@ static void *virtqueue_get_buf_ctx_split(struct virtqueue
*_vq,
return NULL;
}
- if (!more_used_split(vq)) {
+ more = more_used_split(vq);
+ if (!more) {
pr_debug("No more buffers in queue\n");
END_USE(vq);
return NULL;
}
/* Only get used array entries after they have been exposed by host. */
- virtio_rmb(vq->weak_barriers);
+ vq = dependent_ptr_mb(vq, more);
last_used = (vq->last_used_idx & (vq->split.vring.num - 1));
i = virtio32_to_cpu(_vq->vdev,
@@ -1340,6 +1342,7 @@ static void *virtqueue_get_buf_ctx_packed(struct
virtqueue *_vq,
struct vring_virtqueue *vq = to_vvq(_vq);
u16 last_used, id;
void *ret;
+ bool more;
START_USE(vq);
@@ -1348,14 +1351,15 @@ static void *virtqueue_get_buf_ctx_packed(struct
virtqueue *_vq,
return NULL;
}
- if (!more_used_packed(vq)) {
+ more = more_used_packed(vq);
+ if (!more) {
pr_debug("No more buffers in queue\n");
END_USE(vq);
return NULL;
}
/* Only get used elements after they have been exposed by host. */
- virtio_rmb(vq->weak_barriers);
+ vq = dependent_ptr_mb(vq, more);
last_used = vq->last_used_idx;
id = le16_to_cpu(vq->packed.vring.desc[last_used].id);
pgpJKuRMAjN9k.pgp
Description: OpenPGP digital signature
Re: [PATCH v9 1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support
On Wed, Jan 2, 2019 at 10:13 AM Long Cheng wrote:
>
> In DMA engine framework, add 8250 uart dma to support MediaTek uart.
> If MediaTek uart enabled(SERIAL_8250_MT6577), and want to improve
> the performance, can enable the function.
>
> Signed-off-by: Long Cheng
> ---
> drivers/dma/mediatek/8250_mtk_dma.c | 652
> +++
> drivers/dma/mediatek/Kconfig| 11 +
> drivers/dma/mediatek/Makefile |1 +
> 3 files changed, 664 insertions(+)
> create mode 100644 drivers/dma/mediatek/8250_mtk_dma.c
>
> diff --git a/drivers/dma/mediatek/8250_mtk_dma.c
> b/drivers/dma/mediatek/8250_mtk_dma.c
> new file mode 100644
> index 000..dbf811e
> --- /dev/null
> +++ b/drivers/dma/mediatek/8250_mtk_dma.c
> @@ -0,0 +1,652 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * MediaTek 8250 DMA driver.
> + *
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Long Cheng
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "../virt-dma.h"
> +
> +#define MTK_UART_APDMA_CHANNELS(CONFIG_SERIAL_8250_NR_UARTS
> * 2)
> +
> +#define VFF_EN_B BIT(0)
> +#define VFF_STOP_B BIT(0)
> +#define VFF_FLUSH_BBIT(0)
> +#define VFF_4G_SUPPORT_B BIT(0)
> +#define VFF_RX_INT_EN0_B BIT(0) /*rx valid size >= vff thre*/
> +#define VFF_RX_INT_EN1_B BIT(1)
> +#define VFF_TX_INT_EN_BBIT(0) /*tx left size >= vff thre*/
> +#define VFF_WARM_RST_B BIT(0)
> +#define VFF_RX_INT_FLAG_CLR_B (BIT(0) | BIT(1))
> +#define VFF_TX_INT_FLAG_CLR_B 0
> +#define VFF_STOP_CLR_B 0
> +#define VFF_INT_EN_CLR_B 0
> +#define VFF_4G_SUPPORT_CLR_B 0
> +
> +/* interrupt trigger level for tx */
> +#define VFF_TX_THRE(n) ((n) * 7 / 8)
> +/* interrupt trigger level for rx */
> +#define VFF_RX_THRE(n) ((n) * 3 / 4)
> +
> +#define VFF_RING_SIZE 0xU
Well, the size is actually 0x1. Maybe call this VFF_RING_SIZE_MASK?
> +/* invert this bit when wrap ring head again*/
> +#define VFF_RING_WRAP 0x1U
> +
> +#define VFF_INT_FLAG 0x00
> +#define VFF_INT_EN 0x04
> +#define VFF_EN 0x08
> +#define VFF_RST0x0c
> +#define VFF_STOP 0x10
> +#define VFF_FLUSH 0x14
> +#define VFF_ADDR 0x1c
> +#define VFF_LEN0x24
> +#define VFF_THRE 0x28
> +#define VFF_WPT0x2c
> +#define VFF_RPT0x30
> +/*TX: the buffer size HW can read. RX: the buffer size SW can read.*/
nit: Spaces after /* and before */ (and a lot more occurences below,
please fix them all).
> +#define VFF_VALID_SIZE 0x3c
> +/*TX: the buffer size SW can write. RX: the buffer size HW can write.*/
> +#define VFF_LEFT_SIZE 0x40
> +#define VFF_DEBUG_STATUS 0x50
> +#define VFF_4G_SUPPORT 0x54
> +
> +struct mtk_uart_apdmadev {
> + struct dma_device ddev;
> + struct clk *clk;
> + bool support_33bits;
> + unsigned int dma_irq[MTK_UART_APDMA_CHANNELS];
> +};
> +
> +struct mtk_uart_apdma_desc {
> + struct virt_dma_desc vd;
> +
> + unsigned int avail_len;
> +};
> +
> +struct mtk_chan {
> + struct virt_dma_chan vc;
> + struct dma_slave_config cfg;
> + void __iomem *base;
> + struct mtk_uart_apdma_desc *desc;
> +
> + bool requested;
> +
> + unsigned int rx_status;
> +};
> +
> +static inline struct mtk_uart_apdmadev *
> +to_mtk_uart_apdma_dev(struct dma_device *d)
> +{
> + return container_of(d, struct mtk_uart_apdmadev, ddev);
> +}
> +
> +static inline struct mtk_chan *to_mtk_uart_apdma_chan(struct dma_chan *c)
> +{
> + return container_of(c, struct mtk_chan, vc.chan);
> +}
> +
> +static inline struct mtk_uart_apdma_desc *to_mtk_uart_apdma_desc
> + (struct dma_async_tx_descriptor *t)
> +{
> + return container_of(t, struct mtk_uart_apdma_desc, vd.tx);
> +}
> +
> +static void mtk_uart_apdma_write(struct mtk_chan *c,
> + unsigned int reg, unsigned int val)
> +{
> + writel(val, c->base + reg);
> +}
> +
> +static unsigned int mtk_uart_apdma_read(struct mtk_chan *c, unsigned int reg)
> +{
> + return readl(c->base + reg);
> +}
> +
> +static void mtk_uart_apdma_desc_free(struct virt_dma_desc *vd)
> +{
> + struct dma_chan *chan = vd->tx.chan;
> + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
> +
> + kfree(c->desc);
> +}
> +
> +static void mtk_uart_apdma_start_tx(struct mtk_chan *c)
> +{
> + unsigned int len, send, left, wpt, d_wpt, tmp;
> + int ret;
> +
> + left = mtk_uart_apdma_read(c, VFF_LEFT_SIZE);
> + if (!left) {
> + mtk_uart_apdma_write(c, VFF_INT_EN, VFF_TX_INT_EN_B);
>
[PATCH v2] kbuild: remove unnecessary in-subshell execution
The commands surrounded by ( ) are executed in a subshell, but in
most cases, we do not need to spawn an extra subshell.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- fix build error of CONFIG_MODVERSIONS
scripts/Makefile.build | 4 ++--
scripts/Makefile.lib | 28 ++--
scripts/mkcompile_h| 4 ++--
3 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index fd03d60..778e4fb 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -312,11 +312,11 @@ $(real-obj-m:.o=.s): modkern_aflags :=
$(KBUILD_AFLAGS_MODULE) $(AFLAGS_MODULE)
#
# These mirror gensymtypes_c and co above, keep them in synch.
cmd_gensymtypes_S = \
-(echo "\#include " ;\
+ { echo "\#include " ;\
echo "\#include " ; \
$(CPP) $(a_flags) $< | \
grep "\<___EXPORT_SYMBOL\>" | \
- sed
's/.*___EXPORT_SYMBOL[[:space:]]*\([a-zA-Z0-9_]*\)[[:space:]]*,.*/EXPORT_SYMBOL(\1);/'
) | \
+ sed
's/.*___EXPORT_SYMBOL[[:space:]]*\([a-zA-Z0-9_]*\)[[:space:]]*,.*/EXPORT_SYMBOL(\1);/'
; } | \
$(CPP) -D__GENKSYMS__ $(c_flags) -xc - |\
$(GENKSYMS) $(if $(1), -T $(2)) \
$(patsubst y,-R,$(CONFIG_MODULE_REL_CRCS)) \
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 12b88d0..b44ae6c 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -270,7 +270,7 @@ DTC_FLAGS += $(DTC_FLAGS_$(basetarget))
# Generate an assembly file to wrap the output of the device tree compiler
quiet_cmd_dt_S_dtb= DTB $@
cmd_dt_S_dtb= \
-( \
+{ \
echo '\#include '; \
echo '.section .dtb.init.rodata,"a"'; \
echo '.balign STRUCT_ALIGNMENT';\
@@ -280,7 +280,7 @@ cmd_dt_S_dtb=
\
echo '__dtb_$(subst -,_,$(*F))_end:'; \
echo '.global __dtb_$(subst -,_,$(*F))_end';\
echo '.balign STRUCT_ALIGNMENT';\
-) > $@
+} > $@
$(obj)/%.dtb.S: $(obj)/%.dtb FORCE
$(call if_changed,dt_S_dtb)
@@ -334,23 +334,23 @@ printf "%08x\n" $$dec_size |
\
)
quiet_cmd_bzip2 = BZIP2 $@
-cmd_bzip2 = (cat $(filter-out FORCE,$^) | \
- bzip2 -9 && $(call size_append, $(filter-out FORCE,$^))) > $@
+ cmd_bzip2 = cat $(filter-out FORCE,$^) | \
+ bzip2 -9 && $(call size_append, $(filter-out FORCE,$^)) > $@
# Lzma
# ---
quiet_cmd_lzma = LZMA$@
-cmd_lzma = (cat $(filter-out FORCE,$^) | \
- lzma -9 && $(call size_append, $(filter-out FORCE,$^))) > $@
+ cmd_lzma = cat $(filter-out FORCE,$^) | \
+ lzma -9 && $(call size_append, $(filter-out FORCE,$^)) > $@
quiet_cmd_lzo = LZO $@
-cmd_lzo = (cat $(filter-out FORCE,$^) | \
- lzop -9 && $(call size_append, $(filter-out FORCE,$^))) > $@
+ cmd_lzo = cat $(filter-out FORCE,$^) | \
+ lzop -9 && $(call size_append, $(filter-out FORCE,$^)) > $@
quiet_cmd_lz4 = LZ4 $@
-cmd_lz4 = (cat $(filter-out FORCE,$^) | \
- lz4c -l -c1 stdin stdout && $(call size_append, $(filter-out
FORCE,$^))) > $@
+ cmd_lz4 = cat $(filter-out FORCE,$^) | \
+ lz4c -l -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))
> $@
# U-Boot mkimage
# ---
@@ -392,13 +392,13 @@ quiet_cmd_uimage = UIMAGE $@
# big dictionary would increase the memory usage too much in the multi-call
# decompression mode. A BCJ filter isn't used either.
quiet_cmd_xzkern = XZKERN $@
-cmd_xzkern = (cat $(filter-out FORCE,$^) | \
+ cmd_xzkern = cat $(filter-out FORCE,$^) | \
sh $(srctree)/scripts/xz_wrap.sh && \
- $(call size_append, $(filter-out FORCE,$^))) > $@
+ $(call size_append, $(filter-out FORCE,$^)) > $@
quiet_cmd_xzmisc = XZMISC $@
-cmd_xzmisc = (cat $(filter-out FORCE,$^) | \
- xz --check=crc32 --lzma2=dict=1MiB) > $@
+ cmd_xzmisc = cat $(filter-out FORCE,$^) | \
+ xz --check=crc32 --lzma2=dict=1MiB > $@
# ASM offsets
# ---
diff --git a/scripts/mkcompile_h b/scripts/mkcompile_h
index 87f1fc9..2339f86 100755
--- a/scripts/mkcompile_h
+++ b/scripts/mkcompile_h
@@ -62,7 +62,7 @@ UTS_TRUNCATE="cut -b -$UTS_LEN"
# Generate a temporary compile.h
-( echo /\* This file is auto generated, version
Re: [PATCH v2] misc: mic: fix a DMA pool free failure
On Tue, 2018-12-04 at 09:16 -0600, Wenwen Wang wrote:
> In _scif_prog_signal(), a DMA pool is allocated if the MIC Coprocessor is
> not X100, i.e., the boolean variable 'x100' is false. This DMA pool will be
> freed eventually through the callback function scif_prog_signal_cb() with
> the parameter of 'status', which actually points to the start of DMA pool.
> Specifically, in scif_prog_signal_cb(), the 'ep' field and the
> 'src_dma_addr' field of 'status' are used to free the DMA pool by invoking
> dma_pool_free(). Given that 'status' points to the start address of the DMA
> pool, both 'status->ep' and 'status->src_dma_addr' are in the DMA pool. And
> so, the device has the permission to access them. Even worse, a malicious
> device can modify them. As a result, dma_pool_free() will not succeed.
>
> To avoid the above issue, this patch introduces a new data structure, i.e.,
> scif_cb_arg, to store the arguments required by the call back function. A
> variable 'cb_arg' is allocated in _scif_prog_signal() to pass the
> arguments. 'cb_arg' will be freed after dma_pool_free() in
> scif_prog_signal_cb().
>
Thanks for incorporating the previous feedback Wenwen.
Reviewed-by: Sudeep Dutt
> Signed-off-by: Wenwen Wang
> ---
> drivers/misc/mic/scif/scif_fence.c | 22 +-
> drivers/misc/mic/scif/scif_rma.h | 13 +
> 2 files changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/misc/mic/scif/scif_fence.c
> b/drivers/misc/mic/scif/scif_fence.c
> index 7bb929f..2e7ce6a 100644
> --- a/drivers/misc/mic/scif/scif_fence.c
> +++ b/drivers/misc/mic/scif/scif_fence.c
> @@ -195,10 +195,11 @@ static inline void *scif_get_local_va(off_t off, struct
> scif_window *window)
>
> static void scif_prog_signal_cb(void *arg)
> {
> - struct scif_status *status = arg;
> + struct scif_cb_arg *cb_arg = arg;
>
> - dma_pool_free(status->ep->remote_dev->signal_pool, status,
> - status->src_dma_addr);
> + dma_pool_free(cb_arg->ep->remote_dev->signal_pool, cb_arg->status,
> + cb_arg->src_dma_addr);
> + kfree(cb_arg);
> }
>
> static int _scif_prog_signal(scif_epd_t epd, dma_addr_t dst, u64 val)
> @@ -209,6 +210,7 @@ static int _scif_prog_signal(scif_epd_t epd, dma_addr_t
> dst, u64 val)
> bool x100 = !is_dma_copy_aligned(chan->device, 1, 1, 1);
> struct dma_async_tx_descriptor *tx;
> struct scif_status *status = NULL;
> + struct scif_cb_arg *cb_arg = NULL;
> dma_addr_t src;
> dma_cookie_t cookie;
> int err;
> @@ -257,8 +259,16 @@ static int _scif_prog_signal(scif_epd_t epd, dma_addr_t
> dst, u64 val)
> goto dma_fail;
> }
> if (!x100) {
> + cb_arg = kmalloc(sizeof(*cb_arg), GFP_KERNEL);
> + if (!cb_arg) {
> + err = -ENOMEM;
> + goto dma_fail;
> + }
> + cb_arg->src_dma_addr = src;
> + cb_arg->status = status;
> + cb_arg->ep = ep;
> tx->callback = scif_prog_signal_cb;
> - tx->callback_param = status;
> + tx->callback_param = cb_arg;
> }
> cookie = tx->tx_submit(tx);
> if (dma_submit_error(cookie)) {
> @@ -270,9 +280,11 @@ static int _scif_prog_signal(scif_epd_t epd, dma_addr_t
> dst, u64 val)
> dma_async_issue_pending(chan);
> return 0;
> dma_fail:
> - if (!x100)
> + if (!x100) {
> dma_pool_free(ep->remote_dev->signal_pool, status,
> src - offsetof(struct scif_status, val));
> + kfree(cb_arg);
> + }
> alloc_fail:
> return err;
> }
> diff --git a/drivers/misc/mic/scif/scif_rma.h
> b/drivers/misc/mic/scif/scif_rma.h
> index fa67222..84af303 100644
> --- a/drivers/misc/mic/scif/scif_rma.h
> +++ b/drivers/misc/mic/scif/scif_rma.h
> @@ -206,6 +206,19 @@ struct scif_status {
> };
>
> /*
> + * struct scif_cb_arg - Stores the argument of the callback func
> + *
> + * @src_dma_addr: Source buffer DMA address
> + * @status: DMA status
> + * @ep: SCIF endpoint
> + */
> +struct scif_cb_arg {
> + dma_addr_t src_dma_addr;
> + struct scif_status *status;
> + struct scif_endpt *ep;
> +};
> +
> +/*
> * struct scif_window - Registration Window for Self and Remote
> *
> * @nr_pages: Number of pages which is defined as a s64 instead of an int
Re: possible deadlock in __wake_up_common_lock
On 2019/01/03 3:19, Qian Cai wrote: > On 1/2/19 1:06 PM, Mel Gorman wrote: > >> While I recognise there is no test case available, how often does this >> trigger in syzbot as it would be nice to have some confirmation any >> patch is really fixing the problem. > > I think I did manage to trigger this every time running a mmap() workload > causing swapping and a low-memory situation [1]. > > [1] > https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/oom/oom01.c wakeup_kswapd() is called because tlb_next_batch() is doing GFP_NOWAIT allocation. But since tlb_next_batch() can tolerate allocation failure, does below change in tlb_next_batch() help? #define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM) - batch = (void *)__get_free_pages(GFP_NOWAIT | __GFP_NOWARN, 0); + batch = (void *)__get_free_pages(__GFP_NOWARN, 0);
Re: KASAN: use-after-free Read in posix_lock_inode
On Thu, 2019-01-03 at 11:04 +1100, NeilBrown wrote: > On Wed, Jan 02 2019, Jeff Layton wrote: > > > On Wed, 2019-01-02 at 02:31 -0800, syzbot wrote: > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit:e1ef035d272e Merge tag 'armsoc-defconfig' of > > > git://git.ker.. > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=16bb4c4b40 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=9c6a26e22579190b > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=239d99847eb49ecb3899 > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=128aa37740 > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > Reported-by: syzbot+239d99847eb49ecb3...@syzkaller.appspotmail.com > > > > > > IPv6: ADDRCONF(NETDEV_UP): vxcan1: link is not ready > > > IPv6: ADDRCONF(NETDEV_UP): vxcan1: link is not ready > > > 8021q: adding VLAN 0 to HW filter on device batadv0 > > > 8021q: adding VLAN 0 to HW filter on device batadv0 > > > == > > > BUG: KASAN: use-after-free in what_owner_is_waiting_for fs/locks.c:1000 > > > [inline] > > > BUG: KASAN: use-after-free in posix_locks_deadlock fs/locks.c:1023 > > > [inline] > > > BUG: KASAN: use-after-free in posix_lock_inode+0x1f9e/0x2750 > > > fs/locks.c:1163 > > > Read of size 8 at addr 88808791b000 by task syz-executor2/10100 > > > > > > CPU: 1 PID: 10100 Comm: syz-executor2 Not tainted 4.20.0+ #3 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > > Google 01/01/2011 > > > Call Trace: > > > __dump_stack lib/dump_stack.c:77 [inline] > > > dump_stack+0x1db/0x2d0 lib/dump_stack.c:113 > > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 > > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 > > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 > > > what_owner_is_waiting_for fs/locks.c:1000 [inline] > > > posix_locks_deadlock fs/locks.c:1023 [inline] > > > posix_lock_inode+0x1f9e/0x2750 fs/locks.c:1163 > > > posix_lock_file fs/locks.c:1346 [inline] > > > vfs_lock_file fs/locks.c:2314 [inline] > > > vfs_lock_file+0xc7/0xf0 fs/locks.c:2309 > > > do_lock_file_wait.part.0+0xe5/0x260 fs/locks.c:2328 > > > do_lock_file_wait fs/locks.c:2324 [inline] > > > fcntl_setlk+0x2f1/0xfe0 fs/locks.c:2413 > > > do_fcntl+0x843/0x12b0 fs/fcntl.c:370 > > > __do_sys_fcntl fs/fcntl.c:463 [inline] > > > __se_sys_fcntl fs/fcntl.c:448 [inline] > > > __x64_sys_fcntl+0x16d/0x1e0 fs/fcntl.c:448 > > > do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 > > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > > RIP: 0033:0x457ec9 > > > Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 > > > f7 > > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > > > > > > ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > > > RSP: 002b:7f58bbb50c78 EFLAGS: 0246 ORIG_RAX: 0048 > > > RAX: ffda RBX: 0003 RCX: 00457ec9 > > > RDX: 2140 RSI: 0007 RDI: 0003 > > > RBP: 0073bf00 R08: R09: > > > R10: R11: 0246 R12: 7f58bbb516d4 > > > R13: 004be5f0 R14: 004ceab0 R15: > > > > > > Allocated by task 10100: > > > save_stack+0x45/0xd0 mm/kasan/common.c:73 > > > set_track mm/kasan/common.c:85 [inline] > > > kasan_kmalloc mm/kasan/common.c:482 [inline] > > > kasan_kmalloc+0xcf/0xe0 mm/kasan/common.c:455 > > > kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:397 > > > kmem_cache_alloc+0x12d/0x710 mm/slab.c:3541 > > > kmem_cache_zalloc include/linux/slab.h:730 [inline] > > > locks_alloc_lock+0x8e/0x2f0 fs/locks.c:344 > > > fcntl_setlk+0xa9/0xfe0 fs/locks.c:2362 > > > do_fcntl+0x843/0x12b0 fs/fcntl.c:370 > > > __do_sys_fcntl fs/fcntl.c:463 [inline] > > > __se_sys_fcntl fs/fcntl.c:448 [inline] > > > __x64_sys_fcntl+0x16d/0x1e0 fs/fcntl.c:448 > > > do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 > > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > > > > > Freed by task 10100: > > > save_stack+0x45/0xd0 mm/kasan/common.c:73 > > > set_track mm/kasan/common.c:85 [inline] > > > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:444 > > > kasan_slab_free+0xe/0x10 mm/kasan/common.c:452 > > > __cache_free mm/slab.c:3485 [inline] > > > kmem_cache_free+0x86/0x260 mm/slab.c:3747 > > > locks_free_lock+0x27a/0x3f0 fs/locks.c:381 > > > fcntl_setlk+0x7b5/0xfe0 fs/locks.c:2439 > > > do_fcntl+0x843/0x12b0 fs/fcntl.c:370 > > > __do_sys_fcntl fs/fcntl.c:463 [inline] > > > __se_sys_fcntl fs/fcntl.c:448 [inline] > > > __x64_sys_fcntl+0x16d/0x1e0 fs/fcntl.c:448 > > >
[PATCH] kbuild: use assignment instead of define ... endef for filechk_* rules
You do not have to use define ... endef for filechk_* rules. For simple cases, the use of assignment looks cleaner, IMHO. I updated the usage for scripts/Kbuild.include in case somebody misunderstands the 'define ... endif' is the requirement. Signed-off-by: Masahiro Yamada --- Kbuild | 4 +--- Makefile | 3 +-- arch/s390/kernel/syscalls/Makefile | 12 +++- arch/s390/tools/Makefile | 7 ++- scripts/Kbuild.include | 8 scripts/kconfig/Makefile | 4 +--- 6 files changed, 12 insertions(+), 26 deletions(-) diff --git a/Kbuild b/Kbuild index 06b801e..65db5be 100644 --- a/Kbuild +++ b/Kbuild @@ -26,9 +26,7 @@ timeconst-file := include/generated/timeconst.h targets += $(timeconst-file) -define filechk_gentimeconst - echo $(CONFIG_HZ) | bc -q $< -endef +filechk_gentimeconst = echo $(CONFIG_HZ) | bc -q $< $(timeconst-file): kernel/time/timeconst.bc FORCE $(call filechk,gentimeconst) diff --git a/Makefile b/Makefile index 62c9890..39355d1 100644 --- a/Makefile +++ b/Makefile @@ -1041,9 +1041,8 @@ PHONY += $(vmlinux-dirs) $(vmlinux-dirs): prepare $(Q)$(MAKE) $(build)=$@ need-builtin=1 -define filechk_kernel.release +filechk_kernel.release = \ echo "$(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion $(srctree))" -endef # Store (new) KERNELRELEASE string in include/config/kernel.release include/config/kernel.release: $(srctree)/Makefile FORCE diff --git a/arch/s390/kernel/syscalls/Makefile b/arch/s390/kernel/syscalls/Makefile index 4d929ed..b98f250 100644 --- a/arch/s390/kernel/syscalls/Makefile +++ b/arch/s390/kernel/syscalls/Makefile @@ -24,17 +24,11 @@ uapi: $(uapi-hdrs-y) _dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)') \ $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') -define filechk_syshdr - $(CONFIG_SHELL) '$(systbl)' -H -a $(syshdr_abi_$(basetarget)) -f "$2" < $< -endef +filechk_syshdr = $(CONFIG_SHELL) '$(systbl)' -H -a $(syshdr_abi_$(basetarget)) -f "$2" < $< -define filechk_sysnr - $(CONFIG_SHELL) '$(systbl)' -N -a $(sysnr_abi_$(basetarget)) < $< -endef +filechk_sysnr = $(CONFIG_SHELL) '$(systbl)' -N -a $(sysnr_abi_$(basetarget)) < $< -define filechk_syscalls - $(CONFIG_SHELL) '$(systbl)' -S < $< -endef +filechk_syscalls = $(CONFIG_SHELL) '$(systbl)' -S < $< syshdr_abi_unistd_32 := common,32 $(uapi)/unistd_32.h: $(syscall) FORCE diff --git a/arch/s390/tools/Makefile b/arch/s390/tools/Makefile index cf4846a..2342b84 100644 --- a/arch/s390/tools/Makefile +++ b/arch/s390/tools/Makefile @@ -20,13 +20,10 @@ HOSTCFLAGS_gen_opcode_table.o += -Wall $(LINUXINCLUDE) # Ensure output directory exists _dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') -define filechk_facility-defs.h - $(obj)/gen_facilities -endef +filechk_facility-defs.h = $(obj)/gen_facilities -define filechk_dis-defs.h +filechk_dis-defs.h = \ $(obj)/gen_opcode_table < $(srctree)/arch/$(ARCH)/tools/opcodes.txt -endef $(kapi)/facility-defs.h: $(obj)/gen_facilities FORCE $(call filechk,facility-defs.h) diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include index 74a3fe7..525bff6 100644 --- a/scripts/Kbuild.include +++ b/scripts/Kbuild.include @@ -41,11 +41,11 @@ kecho := $($(quiet)kecho) ### # filechk is used to check if the content of a generated file is updated. # Sample usage: -# define filechk_sample -# echo $KERNELRELEASE -# endef -# version.h : Makefile +# +# filechk_sample = echo $(KERNELRELEASE) +# version.h: FORCE # $(call filechk,sample) +# # The rule defined shall write to stdout the content of the new file. # The existing file will be compared with the new one. # - If no file exist it is created diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile index ec204fa..679e62e 100644 --- a/scripts/kconfig/Makefile +++ b/scripts/kconfig/Makefile @@ -201,9 +201,7 @@ HOSTCFLAGS_gconf.o = $(shell . $(obj)/.gconf-cfg && echo $$cflags) $(obj)/gconf.o: $(obj)/.gconf-cfg # check if necessary packages are available, and configure build flags -define filechk_conf_cfg - $(CONFIG_SHELL) $< -endef +filechk_conf_cfg = $(CONFIG_SHELL) $< $(obj)/.%conf-cfg: $(src)/%conf-cfg.sh FORCE $(call filechk,conf_cfg) -- 2.7.4
Re: [PATCH 4/4] kbuild: make LINUX_VERSION_CODE in more readable
On Mon, Dec 31, 2018 at 5:25 PM Masahiro Yamada wrote: > > Makefile does not need to calculate LINUX_VERSION_CODE. > Let's leave it to the preprocessor. > > This commit changes include/generated/uapi/linux/version.h as follows: > > Before: > > #define LINUX_VERSION_CODE 267264 > #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) > > After: > > #define LINUX_VERSION_CODE KERNEL_VERSION(4, 20, 0) > #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) > > The latter is more human-readable in my opinion. > > Signed-off-by: Masahiro Yamada I retract this patch because it would cause a build error. > --- > > Makefile | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index 437d603..1ebf5ed 100644 > --- a/Makefile > +++ b/Makefile > @@ -1131,8 +1131,7 @@ define filechk_utsrelease.h > endef > > define filechk_version.h > - echo \#define LINUX_VERSION_CODE $(shell \ > - expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \ > + echo '#define LINUX_VERSION_CODE KERNEL_VERSION($(VERSION), > $(PATCHLEVEL), $(SUBLEVEL))'; \ > echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))' > endef > > -- > 2.7.4 > -- Best Regards Masahiro Yamada
[PATCH 4/5] arch: remove redundant generic-y defines
Now that Kbuild automatically creates asm-generic wrappers for missing mandatory headers, it is redundant to list the same headers in generic-y and mandatory-y. Suggested-by: Sam Ravnborg Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg --- Changes in v2: - update csky as well - resolve merge conflicts arch/alpha/include/uapi/asm/Kbuild | 6 -- arch/arc/include/uapi/asm/Kbuild| 24 arch/arm/include/uapi/asm/Kbuild| 17 - arch/arm64/include/uapi/asm/Kbuild | 17 - arch/c6x/include/uapi/asm/Kbuild| 26 -- arch/csky/include/uapi/asm/Kbuild | 27 --- arch/h8300/include/uapi/asm/Kbuild | 26 -- arch/hexagon/include/uapi/asm/Kbuild| 23 --- arch/ia64/include/uapi/asm/Kbuild | 6 -- arch/m68k/include/uapi/asm/Kbuild | 19 --- arch/microblaze/include/uapi/asm/Kbuild | 25 - arch/mips/include/uapi/asm/Kbuild | 2 -- arch/nds32/include/uapi/asm/Kbuild | 25 - arch/nios2/include/uapi/asm/Kbuild | 25 - arch/openrisc/include/uapi/asm/Kbuild | 27 --- arch/parisc/include/uapi/asm/Kbuild | 6 -- arch/powerpc/include/uapi/asm/Kbuild| 6 -- arch/riscv/include/uapi/asm/Kbuild | 27 --- arch/s390/include/uapi/asm/Kbuild | 15 --- arch/sh/include/uapi/asm/Kbuild | 18 -- arch/sparc/include/uapi/asm/Kbuild | 2 -- arch/unicore32/include/uapi/asm/Kbuild | 28 arch/x86/include/uapi/asm/Kbuild| 2 -- arch/xtensa/include/uapi/asm/Kbuild | 9 - 24 files changed, 408 deletions(-) diff --git a/arch/alpha/include/uapi/asm/Kbuild b/arch/alpha/include/uapi/asm/Kbuild index 50dea7f..439f515 100644 --- a/arch/alpha/include/uapi/asm/Kbuild +++ b/arch/alpha/include/uapi/asm/Kbuild @@ -1,9 +1,3 @@ include include/uapi/asm-generic/Kbuild.asm generated-y += unistd_32.h -generic-y += bpf_perf_event.h -generic-y += ipcbuf.h -generic-y += msgbuf.h -generic-y += poll.h -generic-y += sembuf.h -generic-y += shmbuf.h diff --git a/arch/arc/include/uapi/asm/Kbuild b/arch/arc/include/uapi/asm/Kbuild index 42ac23e..0febf1a 100644 --- a/arch/arc/include/uapi/asm/Kbuild +++ b/arch/arc/include/uapi/asm/Kbuild @@ -1,28 +1,4 @@ include include/uapi/asm-generic/Kbuild.asm -generic-y += auxvec.h -generic-y += bitsperlong.h -generic-y += bpf_perf_event.h -generic-y += errno.h -generic-y += fcntl.h -generic-y += ioctl.h -generic-y += ioctls.h -generic-y += ipcbuf.h generic-y += kvm_para.h -generic-y += mman.h -generic-y += msgbuf.h -generic-y += param.h -generic-y += poll.h -generic-y += posix_types.h -generic-y += resource.h -generic-y += sembuf.h -generic-y += shmbuf.h -generic-y += siginfo.h -generic-y += socket.h -generic-y += sockios.h -generic-y += stat.h -generic-y += statfs.h -generic-y += termbits.h -generic-y += termios.h -generic-y += types.h generic-y += ucontext.h diff --git a/arch/arm/include/uapi/asm/Kbuild b/arch/arm/include/uapi/asm/Kbuild index 393fe32..eee8f7d 100644 --- a/arch/arm/include/uapi/asm/Kbuild +++ b/arch/arm/include/uapi/asm/Kbuild @@ -4,20 +4,3 @@ include include/uapi/asm-generic/Kbuild.asm generated-y += unistd-common.h generated-y += unistd-oabi.h generated-y += unistd-eabi.h - -generic-y += bitsperlong.h -generic-y += bpf_perf_event.h -generic-y += errno.h -generic-y += ioctl.h -generic-y += ipcbuf.h -generic-y += msgbuf.h -generic-y += param.h -generic-y += poll.h -generic-y += resource.h -generic-y += sembuf.h -generic-y += shmbuf.h -generic-y += siginfo.h -generic-y += socket.h -generic-y += sockios.h -generic-y += termbits.h -generic-y += termios.h diff --git a/arch/arm64/include/uapi/asm/Kbuild b/arch/arm64/include/uapi/asm/Kbuild index eb43543..87eea29 100644 --- a/arch/arm64/include/uapi/asm/Kbuild +++ b/arch/arm64/include/uapi/asm/Kbuild @@ -1,21 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 include include/uapi/asm-generic/Kbuild.asm -generic-y += errno.h -generic-y += ioctl.h -generic-y += ioctls.h -generic-y += ipcbuf.h generic-y += kvm_para.h -generic-y += mman.h -generic-y += msgbuf.h -generic-y += poll.h -generic-y += resource.h -generic-y += sembuf.h -generic-y += shmbuf.h -generic-y += socket.h -generic-y += sockios.h -generic-y += swab.h -generic-y += termbits.h -generic-y += termios.h -generic-y += types.h -generic-y += siginfo.h diff --git a/arch/c6x/include/uapi/asm/Kbuild b/arch/c6x/include/uapi/asm/Kbuild index 633f386..0febf1a 100644 --- a/arch/c6x/include/uapi/asm/Kbuild +++ b/arch/c6x/include/uapi/asm/Kbuild @@ -1,30 +1,4 @@ include include/uapi/asm-generic/Kbuild.asm -generic-y += auxvec.h -generic-y += bitsperlong.h -generic-y += bpf_perf_event.h -generic-y += errno.h
[PATCH 5/5] kbuild: warn redundant generic-y
The generic-y is redundant under the following condition: - arch has its own implementation - the same header is added to generated-y - the same header is added to mandatory-y If a redundant generic-y is found, the warning like follows is displayed: scripts/Makefile.asm-generic:20: redundant generic-y found in arch/arm/include/asm/Kbuild: timex.h I fixed up arch Kbuild files found by this. Suggested-by: Sam Ravnborg Signed-off-by: Masahiro Yamada --- Changes in v2: None arch/arc/include/asm/Kbuild | 4 arch/arm/include/asm/Kbuild | 1 - arch/h8300/include/asm/Kbuild| 1 - arch/openrisc/include/asm/Kbuild | 2 -- arch/parisc/include/asm/Kbuild | 2 -- arch/powerpc/include/asm/Kbuild | 1 - arch/s390/include/asm/Kbuild | 1 - arch/um/include/asm/Kbuild | 2 -- arch/xtensa/include/asm/Kbuild | 1 - scripts/Makefile.asm-generic | 6 ++ 10 files changed, 6 insertions(+), 15 deletions(-) diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild index feed50c..caa2702 100644 --- a/arch/arc/include/asm/Kbuild +++ b/arch/arc/include/asm/Kbuild @@ -3,23 +3,19 @@ generic-y += bugs.h generic-y += compat.h generic-y += device.h generic-y += div64.h -generic-y += dma-mapping.h generic-y += emergency-restart.h generic-y += extable.h -generic-y += fb.h generic-y += ftrace.h generic-y += hardirq.h generic-y += hw_irq.h generic-y += irq_regs.h generic-y += irq_work.h -generic-y += kmap_types.h generic-y += local.h generic-y += local64.h generic-y += mcs_spinlock.h generic-y += mm-arch-hooks.h generic-y += msi.h generic-y += parport.h -generic-y += pci.h generic-y += percpu.h generic-y += preempt.h generic-y += topology.h diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild index 1d66db9..a8a4eb7 100644 --- a/arch/arm/include/asm/Kbuild +++ b/arch/arm/include/asm/Kbuild @@ -18,7 +18,6 @@ generic-y += segment.h generic-y += serial.h generic-y += simd.h generic-y += sizes.h -generic-y += timex.h generic-y += trace_clock.h generated-y += mach-types.h diff --git a/arch/h8300/include/asm/Kbuild b/arch/h8300/include/asm/Kbuild index a5d0b29..ed6f2bf 100644 --- a/arch/h8300/include/asm/Kbuild +++ b/arch/h8300/include/asm/Kbuild @@ -17,7 +17,6 @@ generic-y += fb.h generic-y += ftrace.h generic-y += futex.h generic-y += hardirq.h -generic-y += hash.h generic-y += hw_irq.h generic-y += irq_regs.h generic-y += irq_work.h diff --git a/arch/openrisc/include/asm/Kbuild b/arch/openrisc/include/asm/Kbuild index eb87cd8..5be3f32 100644 --- a/arch/openrisc/include/asm/Kbuild +++ b/arch/openrisc/include/asm/Kbuild @@ -15,7 +15,6 @@ generic-y += fb.h generic-y += ftrace.h generic-y += hardirq.h generic-y += hw_irq.h -generic-y += irq.h generic-y += irq_regs.h generic-y += irq_work.h generic-y += kdebug.h @@ -34,7 +33,6 @@ generic-y += qrwlock_types.h generic-y += qrwlock.h generic-y += sections.h generic-y += segment.h -generic-y += string.h generic-y += switch_to.h generic-y += topology.h generic-y += trace_clock.h diff --git a/arch/parisc/include/asm/Kbuild b/arch/parisc/include/asm/Kbuild index 0b1e354..6f49e77 100644 --- a/arch/parisc/include/asm/Kbuild +++ b/arch/parisc/include/asm/Kbuild @@ -1,7 +1,6 @@ generated-y += syscall_table_32.h generated-y += syscall_table_64.h generated-y += syscall_table_c32.h -generic-y += barrier.h generic-y += current.h generic-y += device.h generic-y += div64.h @@ -20,7 +19,6 @@ generic-y += percpu.h generic-y += preempt.h generic-y += seccomp.h generic-y += segment.h -generic-y += topology.h generic-y += trace_clock.h generic-y += user.h generic-y += vga.h diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild index 77ff7fb..a0c132b 100644 --- a/arch/powerpc/include/asm/Kbuild +++ b/arch/powerpc/include/asm/Kbuild @@ -5,7 +5,6 @@ generated-y += syscall_table_spu.h generic-y += div64.h generic-y += export.h generic-y += irq_regs.h -generic-y += irq_work.h generic-y += local64.h generic-y += mcs_spinlock.h generic-y += preempt.h diff --git a/arch/s390/include/asm/Kbuild b/arch/s390/include/asm/Kbuild index e323977..12d77cb 100644 --- a/arch/s390/include/asm/Kbuild +++ b/arch/s390/include/asm/Kbuild @@ -20,7 +20,6 @@ generic-y += local.h generic-y += local64.h generic-y += mcs_spinlock.h generic-y += mm-arch-hooks.h -generic-y += preempt.h generic-y += rwsem.h generic-y += trace_clock.h generic-y += unaligned.h diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild index b10dde6..00bcbe2 100644 --- a/arch/um/include/asm/Kbuild +++ b/arch/um/include/asm/Kbuild @@ -10,9 +10,7 @@ generic-y += exec.h generic-y += extable.h generic-y += ftrace.h generic-y += futex.h -generic-y += hardirq.h generic-y += hw_irq.h -generic-y += io.h generic-y += irq_regs.h generic-y += irq_work.h generic-y += kdebug.h diff --git a/arch/xtensa/include/asm/Kbuild b/arch/xtensa/include/asm/Kbuild index e255683..322b2fd 100644 ---
[PATCH 1/5] riscv: remove redundant kernel-space generic-y
This commit removes redundant generic-y defines in arch/riscv/include/asm/Kbuild. [1] It is redundant to define the same generic-y in both arch/$(ARCH)/include/asm/Kbuild and arch/$(ARCH)/include/uapi/asm/Kbuild. Remove the following generic-y: errno.h fcntl.h ioctl.h ioctls.h ipcbuf.h mman.h msgbuf.h param.h poll.h posix_types.h resource.h sembuf.h setup.h shmbuf.h signal.h socket.h sockios.h stat.h statfs.h swab.h termbits.h termios.h types.h [2] It is redundant to define generic-y when arch-specific implementation exists in arch/$(ARCH)/include/asm/*.h Remove the following generic-y: cacheflush.h module.h Signed-off-by: Masahiro Yamada --- Changes in v2: - rebase on Linus' tree arch/riscv/include/asm/Kbuild | 25 - 1 file changed, 25 deletions(-) diff --git a/arch/riscv/include/asm/Kbuild b/arch/riscv/include/asm/Kbuild index 6a646d9..cccd12c 100644 --- a/arch/riscv/include/asm/Kbuild +++ b/arch/riscv/include/asm/Kbuild @@ -1,5 +1,4 @@ generic-y += bugs.h -generic-y += cacheflush.h generic-y += checksum.h generic-y += compat.h generic-y += cputime.h @@ -9,16 +8,11 @@ generic-y += dma.h generic-y += dma-contiguous.h generic-y += dma-mapping.h generic-y += emergency-restart.h -generic-y += errno.h generic-y += exec.h generic-y += fb.h -generic-y += fcntl.h generic-y += hardirq.h generic-y += hash.h generic-y += hw_irq.h -generic-y += ioctl.h -generic-y += ioctls.h -generic-y += ipcbuf.h generic-y += irq_regs.h generic-y += irq_work.h generic-y += kdebug.h @@ -27,34 +21,15 @@ generic-y += kvm_para.h generic-y += local.h generic-y += local64.h generic-y += mm-arch-hooks.h -generic-y += mman.h -generic-y += module.h -generic-y += msgbuf.h generic-y += mutex.h -generic-y += param.h generic-y += percpu.h -generic-y += poll.h -generic-y += posix_types.h generic-y += preempt.h -generic-y += resource.h generic-y += scatterlist.h generic-y += sections.h -generic-y += sembuf.h generic-y += serial.h -generic-y += setup.h -generic-y += shmbuf.h generic-y += shmparam.h -generic-y += signal.h -generic-y += socket.h -generic-y += sockios.h -generic-y += stat.h -generic-y += statfs.h -generic-y += swab.h -generic-y += termbits.h -generic-y += termios.h generic-y += topology.h generic-y += trace_clock.h -generic-y += types.h generic-y += unaligned.h generic-y += user.h generic-y += vga.h -- 2.7.4
[PATCH 2/5] arch: remove stale comments "UAPI Header export list"
These comments are leftovers of commit fcc8487d477a ("uapi: export all
headers under uapi directories").
Prior to that commit, exported headers must be explicitly added to
header-y. Now, all headers under the uapi/ directories are exported.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
arch/alpha/include/uapi/asm/Kbuild | 1 -
arch/arc/include/uapi/asm/Kbuild| 1 -
arch/arm/include/uapi/asm/Kbuild| 1 -
arch/arm64/include/uapi/asm/Kbuild | 1 -
arch/c6x/include/uapi/asm/Kbuild| 1 -
arch/h8300/include/uapi/asm/Kbuild | 1 -
arch/hexagon/include/uapi/asm/Kbuild| 1 -
arch/ia64/include/uapi/asm/Kbuild | 1 -
arch/m68k/include/uapi/asm/Kbuild | 1 -
arch/microblaze/include/uapi/asm/Kbuild | 1 -
arch/mips/include/uapi/asm/Kbuild | 1 -
arch/nds32/include/uapi/asm/Kbuild | 1 -
arch/nios2/include/uapi/asm/Kbuild | 1 -
arch/openrisc/include/uapi/asm/Kbuild | 1 -
arch/parisc/include/uapi/asm/Kbuild | 1 -
arch/powerpc/include/uapi/asm/Kbuild| 1 -
arch/riscv/include/uapi/asm/Kbuild | 1 -
arch/s390/include/uapi/asm/Kbuild | 1 -
arch/sh/include/uapi/asm/Kbuild | 1 -
arch/sparc/include/uapi/asm/Kbuild | 1 -
arch/unicore32/include/uapi/asm/Kbuild | 1 -
arch/x86/include/uapi/asm/Kbuild| 1 -
arch/xtensa/include/uapi/asm/Kbuild | 1 -
include/uapi/linux/Kbuild | 2 --
24 files changed, 25 deletions(-)
diff --git a/arch/alpha/include/uapi/asm/Kbuild
b/arch/alpha/include/uapi/asm/Kbuild
index 6a3a0ce..50dea7f 100644
--- a/arch/alpha/include/uapi/asm/Kbuild
+++ b/arch/alpha/include/uapi/asm/Kbuild
@@ -1,4 +1,3 @@
-# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm
generated-y += unistd_32.h
diff --git a/arch/arc/include/uapi/asm/Kbuild b/arch/arc/include/uapi/asm/Kbuild
index 170b5db..42ac23e 100644
--- a/arch/arc/include/uapi/asm/Kbuild
+++ b/arch/arc/include/uapi/asm/Kbuild
@@ -1,4 +1,3 @@
-# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm
generic-y += auxvec.h
diff --git a/arch/arm/include/uapi/asm/Kbuild b/arch/arm/include/uapi/asm/Kbuild
index 4d1cc18..393fe32 100644
--- a/arch/arm/include/uapi/asm/Kbuild
+++ b/arch/arm/include/uapi/asm/Kbuild
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm
generated-y += unistd-common.h
diff --git a/arch/arm64/include/uapi/asm/Kbuild
b/arch/arm64/include/uapi/asm/Kbuild
index 6c5adf4..eb43543 100644
--- a/arch/arm64/include/uapi/asm/Kbuild
+++ b/arch/arm64/include/uapi/asm/Kbuild
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm
generic-y += errno.h
diff --git a/arch/c6x/include/uapi/asm/Kbuild b/arch/c6x/include/uapi/asm/Kbuild
index 26644e1..633f386 100644
--- a/arch/c6x/include/uapi/asm/Kbuild
+++ b/arch/c6x/include/uapi/asm/Kbuild
@@ -1,4 +1,3 @@
-# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm
generic-y += auxvec.h
diff --git a/arch/h8300/include/uapi/asm/Kbuild
b/arch/h8300/include/uapi/asm/Kbuild
index 2f65f78..c1a994e 100644
--- a/arch/h8300/include/uapi/asm/Kbuild
+++ b/arch/h8300/include/uapi/asm/Kbuild
@@ -1,4 +1,3 @@
-# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm
generic-y += auxvec.h
diff --git a/arch/hexagon/include/uapi/asm/Kbuild
b/arch/hexagon/include/uapi/asm/Kbuild
index 41a176d..bcc65a2 100644
--- a/arch/hexagon/include/uapi/asm/Kbuild
+++ b/arch/hexagon/include/uapi/asm/Kbuild
@@ -1,4 +1,3 @@
-# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm
generic-y += auxvec.h
diff --git a/arch/ia64/include/uapi/asm/Kbuild
b/arch/ia64/include/uapi/asm/Kbuild
index ccce0ea..3536c78 100644
--- a/arch/ia64/include/uapi/asm/Kbuild
+++ b/arch/ia64/include/uapi/asm/Kbuild
@@ -1,4 +1,3 @@
-# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm
generated-y += unistd_64.h
diff --git a/arch/m68k/include/uapi/asm/Kbuild
b/arch/m68k/include/uapi/asm/Kbuild
index b645291..2d75dbc 100644
--- a/arch/m68k/include/uapi/asm/Kbuild
+++ b/arch/m68k/include/uapi/asm/Kbuild
@@ -1,4 +1,3 @@
-# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm
generated-y += unistd_32.h
diff --git a/arch/microblaze/include/uapi/asm/Kbuild
b/arch/microblaze/include/uapi/asm/Kbuild
index b6656d9..c95da41 100644
--- a/arch/microblaze/include/uapi/asm/Kbuild
+++ b/arch/microblaze/include/uapi/asm/Kbuild
@@ -1,4 +1,3 @@
-# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm
generated-y += unistd_32.h
diff --git a/arch/mips/include/uapi/asm/Kbuild
b/arch/mips/include/uapi/asm/Kbuild
index ed4bd03..215d808 100644
--- a/arch/mips/include/uapi/asm/Kbuild
+++ b/arch/mips/include/uapi/asm/Kbuild
@@ -1,4 +1,3 @@
-# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm
generated-y += unistd_n32.h
diff --git
[PATCH 3/5] kbuild: generate asm-generic wrappers if mandatory headers are missing
Some time ago, Sam pointed out a certain degree of overwrap between generic-y and mandatory-y. (https://lkml.org/lkml/2017/7/10/121) I tweaked the meaning of mandatory-y a little bit; now it defines the minimum set of ASM headers that all architectures must have. If arch does not have specific implementation of a mandatory header, Kbuild will let it fallback to the asm-generic one by automatically generating a wrapper. This will allow to drop lots of redundant generic-y defines. Previously, "mandatory" was used in the context of UAPI, but I guess this can be extended to kernel space ASM headers. Suggested-by: Sam Ravnborg Signed-off-by: Masahiro Yamada Acked-by: Sam Ravnborg --- Changes in v2: - Filter-out $(generiated-y) from $(mandatory-y) because ARCH may generate mandatory headers by other means Documentation/kbuild/makefiles.txt | 9 ++--- scripts/Makefile.asm-generic | 4 scripts/Makefile.headersinst | 7 --- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 8da26c6..bf28c47 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -1296,9 +1296,12 @@ See subsequent chapter for the syntax of the Kbuild file. --- 7.4 mandatory-y - mandatory-y is essentially used by include/uapi/asm-generic/Kbuild.asm - to define the minimum set of headers that must be exported in - include/asm. + mandatory-y is essentially used by include/(uapi/)asm-generic/Kbuild.asm + to define the minimum set of ASM headers that all architectures must have. + + This works like optional generic-y. If a mandatory header is missing + in arch/$(ARCH)/include/(uapi/)/asm, Kbuild will automatically generate + a wrapper of the asm-generic one. The convention is to list one subdir per line and preferably in alphabetic order. diff --git a/scripts/Makefile.asm-generic b/scripts/Makefile.asm-generic index 760323e..a62d282 100644 --- a/scripts/Makefile.asm-generic +++ b/scripts/Makefile.asm-generic @@ -14,6 +14,10 @@ src := $(subst /generated,,$(obj)) include scripts/Kbuild.include +# If arch does not implement mandatory headers, fallback to asm-generic ones. +mandatory-y := $(filter-out $(generated-y), $(mandatory-y)) +generic-y += $(foreach f, $(mandatory-y), $(if $(wildcard $(srctree)/$(src)/$(f)),,$(f))) + generic-y := $(addprefix $(obj)/, $(generic-y)) generated-y := $(addprefix $(obj)/, $(generated-y)) diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst index 45927fc..3d1ebaa 100644 --- a/scripts/Makefile.headersinst +++ b/scripts/Makefile.headersinst @@ -56,13 +56,6 @@ check-file:= $(installdir)/.check all-files := $(header-files) $(genhdr-files) output-files := $(addprefix $(installdir)/, $(all-files)) -ifneq ($(mandatory-y),) -missing := $(filter-out $(all-files),$(mandatory-y)) -ifneq ($(missing),) -$(error Some mandatory headers ($(missing)) are missing in $(obj)) -endif -endif - # Work out what needs to be removed oldheaders:= $(patsubst $(installdir)/%,%,$(wildcard $(installdir)/*.h)) unwanted := $(filter-out $(all-files),$(oldheaders)) -- 2.7.4
[git pull] Input updates for v4.21-rc0
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. A tiny pull request this merge window unfortunately, should get more material in for the next release. - new driver for Raspberry Pi's touchscreen (firmware interface) - miscellaneous input driver fixes Changelog: - Colin Ian King (1): Input: drv2667 - fix indentation issues Dan Carpenter (1): Input: nomadik-ske-keypad - fix a loop timeout test Hardik Singh Rathore (1): Input: touchscreen - fix coding style issue Linus Walleij (1): Input: ad7879 - drop platform data support Lubomir Rintel (5): dt-bindings: marvell,mmp2: Add clock id for the SP clock clk: mmp2: add SP clock Input: olpc_apsp - drop CONFIG_OLPC dependency Input: olpc_apsp - check FIFO status on open(), not probe() Input: olpc_apsp - enable the SP clock Nicolas Saenz Julienne (1): Input: add official Raspberry Pi's touchscreen driver Patrick Dreyer (1): Input: elan_i2c - add ACPI ID for touchpad in ASUS Aspire F5-573G Sanjeev Chugh (1): Input: atmel_mxt_ts - don't try to free unallocated kernel memory Uwe Kleine-König (1): Input: rotary-encoder - don't log EPROBE_DEFER to kernel log YueHaibing (1): Input: olpc_apsp - remove set but not used variable 'np' Diffstat: .../input/touchscreen/raspberrypi,firmware-ts.txt | 26 +++ .../devicetree/bindings/serio/olpc,ap-sp.txt | 4 + drivers/clk/mmp/clk-of-mmp2.c | 4 + drivers/input/keyboard/nomadik-ske-keypad.c| 2 +- drivers/input/misc/drv2667.c | 6 +- drivers/input/misc/rotary_encoder.c| 6 +- drivers/input/mouse/elan_i2c_core.c| 1 + drivers/input/serio/Kconfig| 1 - drivers/input/serio/olpc_apsp.c| 28 ++- drivers/input/touchscreen/Kconfig | 12 ++ drivers/input/touchscreen/Makefile | 1 + drivers/input/touchscreen/ad7879.c | 109 +++--- drivers/input/touchscreen/atmel_mxt_ts.c | 4 +- drivers/input/touchscreen/ektf2127.c | 2 +- drivers/input/touchscreen/gunze.c | 4 +- drivers/input/touchscreen/inexio.c | 4 +- drivers/input/touchscreen/mtouch.c | 4 +- drivers/input/touchscreen/raspberrypi-ts.c | 227 + include/dt-bindings/clock/marvell,mmp2.h | 1 + include/linux/platform_data/ad7879.h | 42 20 files changed, 347 insertions(+), 141 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt create mode 100644 drivers/input/touchscreen/raspberrypi-ts.c delete mode 100644 include/linux/platform_data/ad7879.h Thanks. -- Dmitry
Re: [PATCH 2/2] m68k: generate uapi header and syscall table header files
Hi Firoz, Thank you for the patch! Yet something to improve: [auto build test ERROR on m68k/for-next] [also build test ERROR on next-20190102] [cannot apply to v4.20] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Firoz-Khan/m68k-remove-nargs-from-__SYSCALL/20190103-001423 base: https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git for-next config: m68k-multi_defconfig (attached as .config) compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=m68k All errors (new ones prefixed by >>): >> make[2]: *** No rule to make target 'scripts/syscalltbl.sh', needed by >> 'arch/m68k/include/generated/asm/syscall_table.h'. >> make[2]: *** No rule to make target 'scripts/syscallhdr.sh', needed by >> 'arch/m68k/include/generated/uapi/asm/unistd_32.h'. make[2]: Target 'all' not remade because of errors. make[1]: *** [archheaders] Error 2 make[1]: Target 'prepare' not remade because of errors. make: *** [sub-make] Error 2 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
