Re: [PATCH] printk: use console_trylock() in console_cpu_notify()
On Wed 2017-01-25 16:02:36, Petr Mladek wrote:
> On Sat 2017-01-21 19:47:29, Sergey Senozhatsky wrote:
> > There is no need to always call blocking console_lock() in
> > console_cpu_notify(), it's quite possible that console_sem can
> > be locked by other CPU on the system, either already printing
> > or soon to begin printing the messages. console_lock() in this
> > case can simply block CPU hotplug for unknown period of time
> > (console_unlock() is time unbound). Not that hotplug is very
> > fast, but still, with other CPUs being online and doing
> > printk() console_cpu_notify() can stuck.
> >
> > Use console_trylock() instead and opt-out if console_sem is
> > already acquired from another CPU, since that CPU will do
> > the printing for us.
> >
> > Signed-off-by: Sergey Senozhatsky
> > ---
> > kernel/printk/printk.c | 11 ++-
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index 7180088cbb23..772eb16436ce 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -2028,15 +2028,16 @@ void resume_console(void)
> > * @cpu: unused
> > *
> > * If printk() is called from a CPU that is not online yet, the messages
> > - * will be spooled but will not show up on the console. This function is
> > - * called when a new CPU comes online (or fails to come up), and ensures
> > - * that any such output gets printed.
> > + * will be printed on the console only if there are CON_ANYTIME consoles.
> > + * This function is called when a new CPU comes online (or fails to come
> > + * up) or goes offline.
> > */
> > static int console_cpu_notify(unsigned int cpu)
> > {
> > if (!cpuhp_tasks_frozen) {
> > - console_lock();
> > - console_unlock();
> > + /* If trylock fails, someone else is doing the printing */
> > + if (console_trylock())
> > + console_unlock();
> > }
> > return 0;
> > }
>
> All in all. The change looks fine to me because it most likely
> improves the performance[1] and does not affect the reliability
> that much.
>
> [1] https://lkml.kernel.org/r/20170119120744.GB435@tigerII.localdomain
Acked-by: Petr Mladek
I am going to add this patch into printk.git for 4.12.
Best Regards,
Petr
Re: [PATCH v3 02/12] irqchip: mtk-sysirq: extend intpol base to arbitrary number
On 19/03/17 15:26, Mars Cheng wrote: > Originally driver only supports one base. However, MT6797 has > more than one bases to configure interrupt polarity. To support > possible design change, here comes a solution to use arbitrary > number of bases. > > Signed-off-by: Mars Cheng Acked-by: Marc Zyngier What is the merge strategy for this? I'm happy to take the irqchip stuff through my tree, but there is much more in this series... Thanks, M. -- Jazz is not dead. It just smells funny...
Re: [PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail
> As this may set kvm->buses[bus_idx] to NULL, don't you also need to
> guard for bus == NULL in kvm_io_bus_destroy()? (I looked at the code on
> kvm/queue.)
very right, so something like this?
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e1be4b4..ef1aa7f 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -728,7 +728,8 @@ static void kvm_destroy_vm(struct kvm *kvm)
spin_unlock(&kvm_lock);
kvm_free_irq_routing(kvm);
for (i = 0; i < KVM_NR_BUSES; i++) {
- kvm_io_bus_destroy(kvm->buses[i]);
+ if (kvm->buses[i])
+ kvm_io_bus_destroy(kvm->buses[i]);
kvm->buses[i] = NULL;
}
kvm_coalesced_mmio_free(kvm);
Thanks!
>
>> synchronize_srcu_expedited(&kvm->srcu);
>> kfree(bus);
>> -return r;
>> +return;
>> }
>
--
Thanks,
David
Re: next build: 208 builds: 9 failed, 199 passed, 857 errors, 444 warnings (next-20170323)
On Thu, Mar 23, 2017 at 6:46 AM, kernelci.org bot wrote:
> acs5k_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
>
> Warnings:
> :1328:2: warning: #warning syscall arch_prctl not implemented [-Wcpp]
> :1328:2: warning: #warning syscall arch_prctl not implemented [-Wcpp]
patch sent today, we don't really want this syscall except on x86
> allmodconfig (arm64) — FAIL, 6 errors, 5 warnings, 0 section mismatches
>
> Errors:
> ERROR (phandle_references): Reference to non-existent node or label
> "pwm_f_clk_pins"
> ERROR (phandle_references): Reference to non-existent node or label
> "pwm_ao_a_3_pins"
> ERROR: Input tree has errors, aborting (use -f to force output)
> ERROR (phandle_references): Reference to non-existent node or label
> "pwm_f_clk_pins"
> ERROR (phandle_references): Reference to non-existent node or label
> "pwm_ao_a_3_pins"
> ERROR: Input tree has errors, aborting (use -f to force output)
Kevin has already backed out the commit that caused this.
> Warnings:
> :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
Should get fixed in the next few days when the patch gets picked up for arm64.
> drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects argument
> of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long
> long unsigned int}' [-Wformat=]
patch sent today
> include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer
> implicitly truncated to unsigned type [-Woverflow]
> include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer
> implicitly truncated to unsigned type [-Woverflow]
I sent this one a few days ago
> allmodconfig (x86) — PASS, 0 errors, 11 warnings, 0 section mismatches
>
> Warnings:
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects
> argument of type 'long int', but argument 4 has type 'long long int'
> [-Wformat=]
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects
> argument of type 'long int', but argument 5 has type 'long long int'
> [-Wformat=]
This one too.
> cavium_octeon_defconfig (mips) — FAIL, 830 errors, 3 warnings, 0 section
> mismatches
>
> Errors:
> arch/mips/include/asm/octeon/cvmx-mio-defs.h:78:3: error: expected
> specifier-qualifier-list before '__BITFIELD_FIELD'
> arch/mips/include/asm/octeon/cvmx-mio-defs.h:95:3: error: expected
> specifier-qualifier-list before '__BITFIELD_FIELD'
Maybe caused by 4cd156de2ca8 ("MIPS: Octeon: Remove unused MIO types
and macros.")
I have not looked in detail
> net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is
> larger than 2048 bytes [-Wframe-larger-than=]
> net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is
> larger than 2048 bytes [-Wframe-larger-than=]
> net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is
> larger than 2048 bytes [-Wframe-larger-than=]
> net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is
> larger than 2048 bytes [-Wframe-larger-than=]
Still need to rework my patches.
Arnd
Re: [PATCH v2 4/7] arm: dts: r7s72100: Add pin controller node
Hi Geert,
On Wed, Mar 22, 2017 at 02:12:04PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi
> wrote:
> > Add pin controller node with 12 gpio controller sub-nodes to
> > r7s72100 dtsi.
> >
> > Signed-off-by: Jacopo Mondi
>
> Reviewed-by: Geert Uytterhoeven
>
> > --- a/arch/arm/boot/dts/r7s72100.dtsi
> > +++ b/arch/arm/boot/dts/r7s72100.dtsi
> > @@ -183,6 +183,86 @@
> > };
> > };
> >
> > + pinctrl: pinctrl@fcfe3000 {
> > + compatible = "renesas,r7s72100-ports";
> > +
> > + #pinctrl-cells = <1>;
> > +
> > + reg = <0xfcfe3000 0x4248>;
>
> How did you get to 0x4248? I had expected 0x4230.
> Not that it matters much, Linux rounds it up to a multiple of PAGE_SIZE
> anyway.
>
I guess I probably confused hex and dec values, as the correct
calculation here would have been (4200 + C * 4)
That 4248 value is what you get with (4200 + 12 * 4) so I probably
typed 12 in the calculator instead of C :)
I'll change this even if it does not make any difference..
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH v3 03/12] irqchip: mtk-sysirq: prevent unnecessary visibility when set_type
On 19/03/17 15:26, Mars Cheng wrote: > This prevent unnecessary visibility when configuring trigger type > > Signed-off-by: Mars Cheng Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny...
Re: [PATCH] arm64: kconfig: allow support for memory failure handling
On 23/03/17 14:33, James Morse wrote: Hi Punit, On 01/02/17 21:38, Tyler Baicar wrote: From: "Jonathan (Zhixiong) Zhang" If ACPI_APEI and MEMORY_FAILURE is configured, select ACPI_APEI_MEMORY_FAILURE. This enables memory failure recovery when such memory failure is reported through ACPI APEI. APEI (ACPI Platform Error Interfaces) provides a means for the platform to convey error information to the kernel. Declare ARCH_SUPPORTS_MEMORY_FAILURE, as arm64 does support memory failure recovery attempt. Am I right in thinking we should wait for the hugepage issue you found with hwpoison [0] to be fixed before arm64 can have ARCH_SUPPORTS_MEMORY_FAILURE? We should at the least fix the huge_pte_offset() issue discovered in [0] before we enable memory failure handling. Earlier today I posted a RFC[1] fix for it based on Catalin's suggestion. (If so, can this patch become part of that series to they are obviously related!) Good point - I can include the patches enabling memory failure handling on ARM64 if Tyler's fine with it. Thanks, Punit [1] https://lkml.org/lkml/2017/3/23/293 Thanks, James [0] https://www.spinics.net/lists/arm-kernel/msg568995.html diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index f92778d..4cd12a0 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -15,6 +15,8 @@ config ARM64 select ARCH_HAS_SG_CHAIN select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST select ARCH_USE_CMPXCHG_LOCKREF +select ACPI_APEI_MEMORY_FAILURE if ACPI_APEI && MEMORY_FAILURE +select ARCH_SUPPORTS_MEMORY_FAILURE select ARCH_SUPPORTS_ATOMIC_RMW select ARCH_SUPPORTS_NUMA_BALANCING select ARCH_WANT_COMPAT_IPC_PARSE_VERSION IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: [PATCH v4 1/4] pinctrl: rockchip: remove unnecessary locking
Hello John-
One quick question below. Apologies if this has been covered, but just
want to be sure.
On Thu, Mar 23, 2017 at 10:59:28AM +, John Keeping wrote:
> regmap_update_bits does its own locking and everything else accessed
> here is a local variable so there is no need to lock around it.
>
> Signed-off-by: John Keeping
> Reviewed-by: Heiko Stuebner
> Tested-by: Heiko Stuebner
> ---
> v3: unchanged
> v2.1:
> - Remove RK2928 locking in rockchip_set_pull()
> v2:
> - Also remove locking in rockchip_set_schmitt()
> ---
> drivers/pinctrl/pinctrl-rockchip.c | 33 ++---
> 1 file changed, 2 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-rockchip.c
> b/drivers/pinctrl/pinctrl-rockchip.c
> index bd4b63f66220..6568c867bdcd 100644
> --- a/drivers/pinctrl/pinctrl-rockchip.c
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
[..]
> @@ -1185,17 +1177,14 @@ static int rockchip_set_drive_perpin(struct
> rockchip_pin_bank *bank,
> rmask = BIT(15) | BIT(31);
> data |= BIT(31);
> ret = regmap_update_bits(regmap, reg, rmask, data);
> - if (ret) {
> - spin_unlock_irqrestore(&bank->slock, flags);
> + if (ret)
> return ret;
> - }
>
> rmask = 0x3 | (0x3 << 16);
> temp |= (0x3 << 16);
> reg += 0x4;
> ret = regmap_update_bits(regmap, reg, rmask, temp);
Killing the lock here means the writes to to this pair of registers (reg
and reg + 4) can be observed non-atomically. Have you convinced
yourself that this isn't a problem?
Julia
signature.asc
Description: PGP signature
[PATCH] drivers/misc: aspeed-lpc-ctrl: fix printk format warning again
The format string is still broken after the first attempt to fix it:
drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_probe':
drivers/misc/aspeed-lpc-ctrl.c:232:17: error: format '%x' expects argument of
type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long
unsigned int}' [-Werror=format=]
We can actually just print the resource structure directly here.
Fixes: 132c93d4215c ("drivers/misc: Aspeed LPC control fix compile error and
warning")
Signed-off-by: Arnd Bergmann
---
drivers/misc/aspeed-lpc-ctrl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-lpc-ctrl.c
index c654651a7b6d..b5439643f54b 100644
--- a/drivers/misc/aspeed-lpc-ctrl.c
+++ b/drivers/misc/aspeed-lpc-ctrl.c
@@ -229,8 +229,7 @@ static int aspeed_lpc_ctrl_probe(struct platform_device
*pdev)
if (rc)
dev_err(dev, "Unable to register device\n");
else
- dev_info(dev, "Loaded at %pap (0x%08x)\n",
- &lpc_ctrl->mem_base, lpc_ctrl->mem_size);
+ dev_info(dev, "Loaded at %pr\n", &resm);
return rc;
}
--
2.9.0
[PATCH] bna: avoid writing uninitialized data into hw registers
The latest gcc-7 snapshot warns about bfa_ioc_send_enable/bfa_ioc_send_disable
writing undefined values into the hardware registers:
drivers/net/ethernet/brocade/bna/bfa_ioc.c: In function
'bfa_iocpf_sm_disabling_entry':
arch/arm/include/asm/io.h:109:22: error: '*((void *)&disable_req+4)' is used
uninitialized in this function [-Werror=uninitialized]
arch/arm/include/asm/io.h:109:22: error: '*((void *)&disable_req+8)' is used
uninitialized in this function [-Werror=uninitialized]
The two functions look like they should do the same thing, but only one
of them initializes the time stamp and clscode field. The fact that we
only get a warning for one of the two functions seems to be arbitrary,
based on the inlining decisions in the compiler.
To address this, I'm making both functions do the same thing:
- set the clscode from the ioc structure in both
- set the time stamp from ktime_get_real_seconds (which also
avoids the signed-integer overflow in 2038 and extends the
well-defined behavior until 2106).
- zero-fill the reserved field
Fixes: 8b230ed8ec96 ("bna: Brocade 10Gb Ethernet device driver")
Signed-off-by: Arnd Bergmann
---
drivers/net/ethernet/brocade/bna/bfa_ioc.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.c
b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
index 9e59663a6ead..0f6811860ad5 100644
--- a/drivers/net/ethernet/brocade/bna/bfa_ioc.c
+++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
@@ -1930,13 +1930,13 @@ static void
bfa_ioc_send_enable(struct bfa_ioc *ioc)
{
struct bfi_ioc_ctrl_req enable_req;
- struct timeval tv;
bfi_h2i_set(enable_req.mh, BFI_MC_IOC, BFI_IOC_H2I_ENABLE_REQ,
bfa_ioc_portid(ioc));
enable_req.clscode = htons(ioc->clscode);
- do_gettimeofday(&tv);
- enable_req.tv_sec = ntohl(tv.tv_sec);
+ enable_req.rsvd = htons(0);
+ /* overflow in 2106 */
+ enable_req.tv_sec = ntohl(ktime_get_real_seconds());
bfa_ioc_mbox_send(ioc, &enable_req, sizeof(struct bfi_ioc_ctrl_req));
}
@@ -1947,6 +1947,10 @@ bfa_ioc_send_disable(struct bfa_ioc *ioc)
bfi_h2i_set(disable_req.mh, BFI_MC_IOC, BFI_IOC_H2I_DISABLE_REQ,
bfa_ioc_portid(ioc));
+ disable_req.clscode = htons(ioc->clscode);
+ disable_req.rsvd = htons(0);
+ /* overflow in 2106 */
+ disable_req.tv_sec = ntohl(ktime_get_real_seconds());
bfa_ioc_mbox_send(ioc, &disable_req, sizeof(struct bfi_ioc_ctrl_req));
}
--
2.9.0
Hello,
Dear Friend, Can you be able to assist in handling this transaction? More details will be sent to you as soon as i receive your response. An approval will be granted to you as soon as you apply for the release of the fund to you. I need your urgent assistance in transferring the sum of US$5 Million (Five million U.S Dollars) to your account. My requirements below, before we can proceed into this transaction: 1. Full name: . 2. Current Address: ... 3. Phone Number: . 4. E-mail Address: . 4. Occupation: 5. Age: ... 6. Country: Waiting for your urgent response. Mr. Simpore Rachidi.
net/sched: GPF in qdisc_hash_add
Hello, I've hit the following GPF while running syzkaller on commit 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected kmalloc failure, most likely it's the root cause. FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 2 PID: 12732 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #365 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0x1b8/0x28d lib/dump_stack.c:52 fail_dump lib/fault-inject.c:52 [inline] should_fail+0x804/0x8c0 lib/fault-inject.c:154 should_failslab+0xec/0x120 mm/failslab.c:31 slab_pre_alloc_hook mm/slab.h:434 [inline] slab_alloc_node mm/slab.c:3315 [inline] kmem_cache_alloc_node_trace+0x200/0x720 mm/slab.c:3679 __do_kmalloc_node mm/slab.c:3699 [inline] __kmalloc_node+0x33/0x70 mm/slab.c:3707 kmalloc_node include/linux/slab.h:532 [inline] kzalloc_node include/linux/slab.h:674 [inline] qdisc_alloc+0xf4/0x670 net/sched/sch_generic.c:604 qdisc_create_dflt+0x59/0x160 net/sched/sch_generic.c:652 attach_one_default_qdisc net/sched/sch_generic.c:767 [inline] netdev_for_each_tx_queue include/linux/netdevice.h:1948 [inline] attach_default_qdiscs net/sched/sch_generic.c:786 [inline] dev_activate+0x58d/0x920 net/sched/sch_generic.c:829 __dev_open+0x25b/0x360 net/core/dev.c:1348 __dev_change_flags+0x159/0x3d0 net/core/dev.c:6460 dev_change_flags+0x88/0x140 net/core/dev.c:6525 dev_ifsioc+0x51f/0x9b0 net/core/dev_ioctl.c:254 dev_ioctl+0x1fe/0x1030 net/core/dev_ioctl.c:532 sock_do_ioctl+0x94/0xb0 net/socket.c:902 sock_ioctl+0x2c2/0x440 net/socket.c:993 vfs_ioctl fs/ioctl.c:45 [inline] do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685 SYSC_ioctl fs/ioctl.c:700 [inline] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691 entry_SYSCALL_64_fastpath+0x1f/0xc2 RIP: 0033:0x445b79 RSP: 002b:7f68665cf858 EFLAGS: 0286 ORIG_RAX: 0010 RAX: ffda RBX: 00708000 RCX: 00445b79 RDX: 2000 RSI: 8914 RDI: 0019 RBP: 0086 R08: R09: R10: R11: 0286 R12: 004a7e31 R13: R14: 7f68665cf618 R15: 7f68665cf788 kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 2 PID: 12732 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #365 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: 880062b7a2c0 task.stack: 88003348 RIP: 0010:qdisc_hash_add.part.19+0xb6/0x3c0 net/sched/sch_api.c:280 RSP: 0018:880033487820 EFLAGS: 00010202 RAX: dc00 RBX: 85357e00 RCX: c90002b24000 RDX: 007a RSI: 835a523a RDI: 03d0 RBP: 8800334878b8 R08: fbfff0a6afeb R09: fbfff0a6afeb R10: 0001 R11: fbfff0a6afea R12: 85357e48 R13: 110006690f06 R14: 880033487890 R15: FS: 7f68665d0700() GS:88006e20() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 004c2d44 CR3: 3c6f8000 CR4: 26e0 Call Trace: qdisc_hash_add+0x76/0x90 net/sched/sch_api.c:279 attach_default_qdiscs net/sched/sch_generic.c:798 [inline] dev_activate+0x6ca/0x920 net/sched/sch_generic.c:829 __dev_open+0x25b/0x360 net/core/dev.c:1348 __dev_change_flags+0x159/0x3d0 net/core/dev.c:6460 dev_change_flags+0x88/0x140 net/core/dev.c:6525 dev_ifsioc+0x51f/0x9b0 net/core/dev_ioctl.c:254 dev_ioctl+0x1fe/0x1030 net/core/dev_ioctl.c:532 sock_do_ioctl+0x94/0xb0 net/socket.c:902 sock_ioctl+0x2c2/0x440 net/socket.c:993 vfs_ioctl fs/ioctl.c:45 [inline] do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685 SYSC_ioctl fs/ioctl.c:700 [inline] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691 entry_SYSCALL_64_fastpath+0x1f/0xc2 RIP: 0033:0x445b79 RSP: 002b:7f68665cf858 EFLAGS: 0286 ORIG_RAX: 0010 RAX: ffda RBX: 00708000 RCX: 00445b79 RDX: 2000 RSI: 8914 RDI: 0019 RBP: 0086 R08: R09: R10: R11: 0286 R12: 004a7e31 R13: R14: 7f68665cf618 R15: 7f68665cf788 Code: 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 5a 02 00 00 4d 8b 3f 48 b8 00 00 00 00 00 fc ff df 49 8d bf d0 03 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c2 02 00 00 49 81 bf d0 03 00 00 00 7e 35 85 RIP: qdisc_hash_add.part.19+0xb6/0x3c0 net/sched/sch_api.c:280 RSP: 880033487820 ---[ end trace 1529d12967754f9c ]---
Re: [RFC] Add option to mount only a pids subset
Again, I can't really review this, I know nothing about vfs, but since
nobody else replied...
On 03/20, Alexey Gladkov wrote:
>
> @@ -97,7 +169,23 @@ static struct dentry *proc_mount(struct file_system_type
> *fs_type,
> ns = task_active_pid_ns(current);
> }
>
> - return mount_ns(fs_type, flags, data, ns, ns->user_ns, proc_fill_super);
> + root = mount_ns(fs_type, flags, data, ns, ns->user_ns, proc_fill_super);
> +
> + if (!IS_ERR(root)) {
> + if (!proc_fill_options(data, &opts))
> + return ERR_PTR(-EINVAL);
So we have to call proc_fill_options() twice, not good... Yes, I understand
why, but perhaps we factor it out somehow, we can pack options + pid_ns into
sb->s_fs_info. Nevermind, this is minor.
> + if (opts.pid_only) {
> + int ret;
> +
> + if (!ns->pidfs && (ret = fill_pidfs_root(root->d_sb)))
> + return ERR_PTR(ret);
> +
> + root = ns->pidfs;
Afaics this lacks dget(ns->pidfs) which should pair with dput(mnt.mnt_root)
in cleanup_mnt(). IIUC otherwise ns->pidfs can go away after umount, OTOH,
if we return ns->pidfs then dget(sb->s_root) in mount_ns() is not balanced.
But this all is fixeable.
So with this change "mount -opidonly" creates another IS_ROOT() dentry which
is not equal to sb->s_root. I simply do not know if this is technically
correct or not... but, say, the "Only bind mounts can have disconnected paths"
comment in path_connected() makes me worry ;)
And this obviously means that /path-to-pidonly-mnt/ won't share dentries with
the normal /proc mount. Not really good imo even if not really wrong... Lets
look at proc_flush_task(). The exiting task will flush its $pid dentries in
/proc/ but not in /path-to-pidonly-mnt/ iiuc. Again, not really a bug, but
still...
Oleg.
Re: [PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail
On Thu, 23 Mar 2017 15:34:41 +0100
David Hildenbrand wrote:
> No caller currently checks the return value of
> kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on
> freeing their device. A stale reference will remain in the io_bus,
> getting at least used again, when the iobus gets teared down on
> kvm_destroy_vm() - leading to use after free errors.
>
> There is nothing the callers could do, except retrying over and over
> again.
>
> So let's simply remove the bus altogether, print an error and make
> sure no one can access this broken bus again (returning -ENOMEM on any
> attempt to access it).
>
> Fixes: e93f8a0f821e ("KVM: convert io_bus to SRCU")
> Cc: sta...@vger.kernel.org # 3.4+
> Reported-by: Dmitry Vyukov
> Signed-off-by: David Hildenbrand
> /* Caller must hold slots_lock. */
> -int kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
> - struct kvm_io_device *dev)
> +void kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
> +struct kvm_io_device *dev)
> {
> - int i, r;
> + int i;
> struct kvm_io_bus *new_bus, *bus;
>
> bus = kvm->buses[bus_idx];
> -
> - /*
> - * It's possible the bus being released before hand. If so,
> - * we're done here.
> - */
> if (!bus)
> - return 0;
> + return;
>
> - r = -ENOENT;
> for (i = 0; i < bus->dev_count; i++)
> if (bus->range[i].dev == dev) {
> - r = 0;
> break;
> }
>
> - if (r)
> - return r;
> + if (i == bus->dev_count)
> + return;
>
> new_bus = kmalloc(sizeof(*bus) + ((bus->dev_count - 1) *
> sizeof(struct kvm_io_range)), GFP_KERNEL);
> - if (!new_bus)
> - return -ENOMEM;
> + if (!new_bus) {
> + pr_err("kvm: failed to shrink bus, removing it completely\n");
> + goto broken;
> + }
>
> memcpy(new_bus, bus, sizeof(*bus) + i * sizeof(struct kvm_io_range));
> new_bus->dev_count--;
> memcpy(new_bus->range + i, bus->range + i + 1,
> (new_bus->dev_count - i) * sizeof(struct kvm_io_range));
>
> +broken:
> rcu_assign_pointer(kvm->buses[bus_idx], new_bus);
As this may set kvm->buses[bus_idx] to NULL, don't you also need to
guard for bus == NULL in kvm_io_bus_destroy()? (I looked at the code on
kvm/queue.)
> synchronize_srcu_expedited(&kvm->srcu);
> kfree(bus);
> - return r;
> + return;
> }
Re: [RFC] Add option to mount only a pids subset
Hi Alexey, On Mon, Mar 20, 2017 at 1:58 PM, Alexey Gladkov wrote: > > > Al Viro, this patch looks better ? > > == Overview == > > Some of the container virtualization systems are mounted /proc inside > the container. This is done in most cases to operate with information > about the processes. Knowing that /proc filesystem is not fully > virtualized they are mounted on top of dangerous places empty files or > directories (for exmaple /proc/sys, /proc/kcore, /sys/firmware, etc.). > > The structure of this filesystem is dynamic and any module can create a > new object which will not necessarily be virtualized. There are > proprietary modules that aren't in the mainline whose work we can not > verify. > > This opens up a potential threat to the system. The developers of the > virtualization system can't predict all dangerous places in /proc by > definition. > > A more effective solution would be to mount into the container only what > is necessary and ignore the rest. > > Right now there is the opportunity to pass in the container any port of > the /proc filesystem using mount --bind expect the pids. > > This patch allows to mount only the part of /proc related to pids without > rest objects. Since this is an option for /proc, flags applied to /proc > have an effect on this subset of filesystem. I just sent a patch that also has to deal with proc hidepid here: https://lkml.org/lkml/2017/3/23/505 I'm not sure if that's the right approach, it is still buggy, however seems that your patch also stores the mount option inside the pid_namespace which may get propagated to all mounts inside same pidns ? I didn't have enough time but maybe if they are related we can work it out together ? Thank you! -- tixxdz
Re: [PATCH v2] HV: properly delay KVP packets when negotiation is in progress
Long Li writes:
> The host may send multiple negotiation packets (due to timeout) before
> the KVP user-mode daemon is connected. We need to defer processing
> those packets until the daemon is negotiated and connected. It's okay
> for guest to respond to all negotiation packets.
>
> In addition, the host may send multiple staged KVP requests as soon as
> negotiation is done. We need to properly process those packets using
> one tasklet for exclusive access to ring buffer.
>
> This patch is based on the work of Nick Meier
>
>
> The patch v2 has incorporated suggestion from Vitaly Kuznetsov
> .
>
> Signed-off-by: Long Li
> ---
> drivers/hv/hv_kvp.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
> index de26371..845b70b 100644
> --- a/drivers/hv/hv_kvp.c
> +++ b/drivers/hv/hv_kvp.c
> @@ -113,7 +113,7 @@ static void kvp_poll_wrapper(void *channel)
> {
> /* Transaction is finished, reset the state here to avoid races. */
> kvp_transaction.state = HVUTIL_READY;
> - hv_kvp_onchannelcallback(channel);
> + tasklet_schedule(&((struct vmbus_channel*)channel)->callback_event);
> }
There is one more function in the code which calls
hv_kvp_onchannelcallback():
static void kvp_host_handshake_func(struct work_struct *dummy)
{
hv_poll_channel(kvp_transaction.recv_channel, hv_kvp_onchannelcallback);
}
we can't replace hv_kvp_onchannelcallback with kvp_poll_wrapper here as
we don't want to reset kvp_transaction.state but it seems this should
also get updated, e.g. hv_poll_channel() here can be replaced with the
direct
tasklet_schedule(&((struct vmbus_channel*)channel)->callback_event);
call. This will ensure hv_kvp_onchannelcallback() calls are always
serialized.
>
> static void kvp_register_done(void)
> @@ -628,16 +628,17 @@ void hv_kvp_onchannelcallback(void *context)
>NEGO_IN_PROGRESS,
>NEGO_FINISHED} host_negotiatied = NEGO_NOT_STARTED;
>
> - if (host_negotiatied == NEGO_NOT_STARTED &&
> - kvp_transaction.state < HVUTIL_READY) {
> + if (kvp_transaction.state < HVUTIL_READY) {
> /*
>* If userspace daemon is not connected and host is asking
>* us to negotiate we need to delay to not lose messages.
>* This is important for Failover IP setting.
>*/
> - host_negotiatied = NEGO_IN_PROGRESS;
> - schedule_delayed_work(&kvp_host_handshake_work,
> + if (host_negotiatied == NEGO_NOT_STARTED) {
> + host_negotiatied = NEGO_IN_PROGRESS;
> + schedule_delayed_work(&kvp_host_handshake_work,
> HV_UTIL_NEGO_TIMEOUT * HZ);
> + }
> return;
> }
> if (kvp_transaction.state > HVUTIL_READY)
> @@ -705,6 +706,7 @@ void hv_kvp_onchannelcallback(void *context)
> VM_PKT_DATA_INBAND, 0);
>
> host_negotiatied = NEGO_FINISHED;
> + hv_poll_channel(kvp_transaction.recv_channel, kvp_poll_wrapper);
> }
>
> }
--
Vitaly
[PATCH V2] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF
ACPI_IPMI driver currently depends on IPMI System Interface (IPMI_SI) driver to be enabled. IPMI_SI driver only handles KCS, SMIC and BT BMC interfaces. IPMI_SSIF is an alternative BMC communication method. It allows BMC to be accessed over an I2C bus instead of a standard interface. Enabling ACPI_IPMI over IPMI_SSIF with this change. Signed-off-by: Sinan Kaya --- drivers/acpi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 83e5f7e..dc22c8a 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -256,7 +256,7 @@ config ACPI_PROCESSOR config ACPI_IPMI tristate "IPMI" - depends on IPMI_SI + depends on IPMI_SI || IPMI_SSIF default n help This driver enables the ACPI to access the BMC controller. And it -- 1.9.1
Re: loop: WARNING in sysfs_remove_group
On Thu, Mar 23, 2017 at 03:09:44PM +0100, Dmitry Vyukov wrote: > Hello, > > I've got the following WARNING while running syzkaller on > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected > kmalloc failure, most likely it's the root cause. > > FAULT_INJECTION: forcing a failure. > name failslab, interval 1, probability 0, space 0, times 0 > CPU: 3 PID: 21172 Comm: syz-executor4 Not tainted 4.11.0-rc3+ #364 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:16 [inline] > dump_stack+0x1b8/0x28d lib/dump_stack.c:52 > fail_dump lib/fault-inject.c:45 [inline] > should_fail+0x78a/0x870 lib/fault-inject.c:154 > should_failslab+0xec/0x120 mm/failslab.c:31 > slab_pre_alloc_hook mm/slab.h:434 [inline] > slab_alloc mm/slab.c:3394 [inline] > kmem_cache_alloc+0x200/0x720 mm/slab.c:3570 > kmem_cache_zalloc include/linux/slab.h:653 [inline] > __kernfs_new_node+0xd1/0x430 fs/kernfs/dir.c:629 > kernfs_new_node+0x80/0xf0 fs/kernfs/dir.c:661 > kernfs_create_dir_ns+0x41/0x140 fs/kernfs/dir.c:933 > kernfs_create_dir include/linux/kernfs.h:477 [inline] > internal_create_group+0xf7/0x8f0 fs/sysfs/group.c:124 > sysfs_create_group+0x1f/0x30 fs/sysfs/group.c:156 > loop_sysfs_init drivers/block/loop.c:802 [inline] Looks we should have handled failure of loop_sys_init(). Thanks, Ming
Re: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc
Hi Geert,
thanks for review
On Wed, Mar 22, 2017 at 11:33:50AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi
> wrote:
> > Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
>
> for the Renesas ...
>
> > controller.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > .../bindings/pinctrl/renesas,rza1-pinctrl.txt | 144
> > +
> > 1 file changed, 144 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
> > b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
> > new file mode 100644
> > index 000..0474860
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
> > @@ -0,0 +1,144 @@
> > +Renesas RZ/A1 combined Pin and GPIO controller
> > +
> > +Renesas SoCs of RZ/A1 family feature a combined Pin and GPIO controller
>
> the RZ/A1 family
>
> > +hardware controller, named "Ports" in the hardware reference manual.
>
> bogus "hardware controller"
>
> > +Sub-nodes
> > +-
> > +
> > +The child nodes of the pin controller node describe a pin multiplexing
> > +function or a gpio controller alternatively.
> > +
> > +- Pin multiplexing sub-nodes:
> > + A pin multiplexing sub-node describes how to configure a set of
> > + (or a single) pin in some desired alternate function mode.
> > + A single sub-node may define several pin configurations groups.
> > +
> > + Required properties:
> > +- renesas,pins
>
> Just "pins"?
>
You know, I've been thinking about this, bu the "pins" property
definition in pinctrl-bidings is the following one:
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
---
- pins takes a list of pin names or IDs as a required argument. The
specific binding for the hardware defines:
- Whether the entries are integers or strings, and their
meaning.
---
And all examples there assume one "pin name" or "ID" per pin.
Now, we use 2 values per each pin (the pin ID and the alternate
function number), so to me this is different from what the generic
binding describes.
Also, pinctrl-single, and pinctrl-imx which have and ABI similar to
the one this driver define, use "pinctrl-single,pins" and "fsl,pins"
respectively as property names.
So either they have to be updated yet, or we should keep using
"renesas,pins" for our own defined ABI.
Maybe Linus or other pinctrl people can give some suggestion here.
Thanks
j
> > + describes an array of pin multiplexing configurations.
> > + When a pin has to be configured in alternate function mode, use this
> > + property to identify the pin by its global index, and provide its
> > + alternate function configuration description along with it.
> > + When multiple pins are required to be configured as part of the same
> > + alternate function (odds are single-pin alternate functions exist)
> > they
> > + shall be specified as members of the same argument list of a single
> > + "renesas-pins" property.
> > + Helper macros to ease calculating the pin index from its position
> > + (port where it sits on and pin offset), and alternate function
> > + configuration options are provided in pin controller header file at:
>
> the pin ... file
>
> > + include/dt-bindings/pinctrl/r7s72100-pinctrl.h
>
> Hence I'd include that file in this patch, as it's part of the bindings.
>
> > + Example:
> > + A serial communication interface with a TX output pin and a RX input pin.
>
> an RX
>
> > +
> > + &pinctrl {
> > + scif2_pins: serial2 {
> > + renesas,pins = ,
> > + ;
>
> Single line?
>
> > + };
> > + }
> > +
> > + Pin #0 on port #3 is configured in alternate function #6.
> > + Pin #2 on port #3 is configured in alternate function #4.
>
> as alternate function
>
> > +
> > + Example 2:
> > + I2c master: both SDA and SCL pins need bi-directional operations
> > +
> > + &pinctrl {
> > + i2c2_pins: i2c2 {
> > + renesas,pins = ,
> > + ;
> > + };
> > + }
> > +
> > + Pin #4 on port #1 is configured in alternate function #1.
> > + Pin #5 on port #1 is configured in alternate function #1.
>
> as alternate function
>
> > + Both need to work in bi-directional mode.
> > +
> > + Example 3:
> > + Multi-function timer input and output compare pins.
> > + The hardware manual prescribes this pins to have input/output direction
> > + specified by software. Configure TIOC0A as input and TIOC0B as output.
> > +
> > + &pinctrl {
> > + tioc0_pins: tioc0 {
> > + renesas,pins = ,
> > + ;
> > + };
> > + }
> > +
> > + Pin #0 on port #4 is configured in alternate function #2 with IO
> > direction
> > + specifie
Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller
Hello, On Thu, Mar 23, 2017 at 10:32:54AM +, Patrick Bellasi wrote: > > But then we would lose out on being able to attach capacity > > constraints to specific tasks or groups of tasks? > > Yes, right. If CGroups are not available than you cannot specify > per-task constraints. This is just a system-wide global tunable. > > Question is: does this overall proposal makes sense outside the scope > of task groups classification? (more on that afterwards) I think it does, given that it's a per-thread property which requires internal application knowledge to tune. > > I think the concern raised is more about whether CGroups is the right > > interface to use for attaching capacity constraints to task or groups > > of tasks, or is there a better way to attach such constraints? > > Notice that CGroups based classification allows to easily enforce > the concept of "delegation containment". I think this feature should > be nice to have whatever interface we choose. > > However, potentially we can define a proper per-task API; are you > thinking to something specifically? I don't think the overall outcome was too good when we used cgroup as the direct way of configuring certain attributes - it either excludes the possibility of easily accessible API from application side or conflicts with the attributes set through such API. It's a lot clearer when cgroup just sets what's allowed under the hierarchy. This is also in line with the aspect that cgroup for the most part is a scoping mechanism - it's the most straight-forward to implement and use when the behavior inside cgroup matches a system without cgroup, just scoped. It shows up here too. If you take out the cgroup part, you're left with an interface which is hardly useful. cgroup isn't scoping the global system here. It's becoming the primary interface for this feature which most likely isn't a good sign. So, my suggestion is to implement it as a per-task API. If the feature calls for scoped restrictions, we definitely can add cgroup support for that but I'm really not convinced about using cgroup as the primary interface for this. Thanks. -- tejun
Re: netlink: NULL timer crash
On Thu, 2017-03-23 at 07:53 -0700, Eric Dumazet wrote:
> Nice !
>
> Looks like neigh->ops->solicit is NULL
Apparently we allow admins to do really stupid things with neighbours
on tunnels.
Following patch should avoid the crash.
Anyone has better ideas ?
net/ipv4/arp.c |5 +
net/ipv6/ndisc.c |4
2 files changed, 9 insertions(+)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index
51b27ae09fbd725bcd8030982e5850215ac4ce5c..963191b12e28041bf5df6f37f222a7155f83a414
100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -146,8 +146,13 @@ static const struct neigh_ops arp_hh_ops = {
.connected_output = neigh_resolve_output,
};
+static void arp_no_solicit(struct neighbour *neigh, struct sk_buff *skb)
+{
+}
+
static const struct neigh_ops arp_direct_ops = {
.family = AF_INET,
+ .solicit = arp_no_solicit,
.output = neigh_direct_output,
.connected_output = neigh_direct_output,
};
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index
7ebac630d3c603186be2fc0dcbaac7d7e74bfde6..86f290b749d5ca0db4310b17ebeff35d847540c7
100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -99,9 +99,13 @@ static const struct neigh_ops ndisc_hh_ops = {
.connected_output = neigh_resolve_output,
};
+static void ndisc_no_solicit(struct neighbour *neigh, struct sk_buff *skb)
+{
+}
static const struct neigh_ops ndisc_direct_ops = {
.family = AF_INET6,
+ .solicit = ndisc_no_solicit,
.output = neigh_direct_output,
.connected_output = neigh_direct_output,
};
[PATCH v3] extcon: intel-cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon driver
Add a driver for charger detection / control on the Intel Cherrytrail
Whiskey Cove PMIC.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Improve wait for charger detection loop, use jiffies to get an accurate timeout
-Sort registers by address, remove duplicate definition
-Return IRQ_NONE on interrupt handling errors
-Various small style cleanups
-Fix reporting no charger cable being present when detecting the same
charger type 2 times in a row
-Reset to autonomous / hw-mode on probe-error and on remove
Changes in v3:
-Add intel prefix to Kconfig symbol and filename
-Clarified "Unhandled charger type" warning msg
-Dropped usb_id sysfs attribute
---
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile | 1 +
drivers/extcon/extcon-intel-cht-wc.c | 352 +++
3 files changed, 360 insertions(+)
create mode 100644 drivers/extcon/extcon-intel-cht-wc.c
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 96bbae5..bcf2cf6 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -52,6 +52,13 @@ config EXTCON_INTEL_INT3496
This ACPI device is typically found on Intel Baytrail or Cherrytrail
based tablets, or other Baytrail / Cherrytrail devices.
+config EXTCON_INTEL_CHT_WC
+ tristate "Intel Cherrytrail Whiskey Cove PMIC extcon driver"
+ depends on INTEL_SOC_PMIC_CHTWC
+ help
+ Say Y here to enable extcon support for charger detection / control
+ on the Intel Cherrytrail Whiskey Cove PMIC.
+
config EXTCON_MAX14577
tristate "Maxim MAX14577/77836 EXTCON Support"
depends on MFD_MAX14577
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 237ac3f..ecfa958 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-arizona.o
obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_INTEL_INT3496) += extcon-intel-int3496.o
+obj-$(CONFIG_EXTCON_INTEL_CHT_WC) += extcon-intel-cht-wc.o
obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o
obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
diff --git a/drivers/extcon/extcon-intel-cht-wc.c
b/drivers/extcon/extcon-intel-cht-wc.c
new file mode 100644
index 000..a245d96
--- /dev/null
+++ b/drivers/extcon/extcon-intel-cht-wc.c
@@ -0,0 +1,352 @@
+/*
+ * Extcon charger detection driver for Intel Cherrytrail Whiskey Cove PMIC
+ * Copyright (C) 2017 Hans de Goede
+ *
+ * Based on various non upstream patches to support the CHT Whiskey Cove PMIC:
+ * Copyright (C) 2013-2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CHT_WC_PHYCTRL 0x5e07
+
+#define CHT_WC_CHGRCTRL0 0x5e16
+#define CHT_WC_CHGRCTRL0_CHGRRESET BIT(0)
+#define CHT_WC_CHGRCTRL0_EMRGCHREN BIT(1)
+#define CHT_WC_CHGRCTRL0_EXTCHRDIS BIT(2)
+#define CHT_WC_CHGRCTRL0_SWCONTROL BIT(3)
+#define CHT_WC_CHGRCTRL0_TTLCK_MASKBIT(4)
+#define CHT_WC_CHGRCTRL0_CCSM_OFF_MASK BIT(5)
+#define CHT_WC_CHGRCTRL0_DBPOFF_MASK BIT(6)
+#define CHT_WC_CHGRCTRL0_WDT_NOKICKBIT(7)
+
+#define CHT_WC_CHGRCTRL1 0x5e17
+
+#define CHT_WC_USBSRC 0x5e29
+#define CHT_WC_USBSRC_STS_MASK GENMASK(1, 0)
+#define CHT_WC_USBSRC_STS_SUCCESS 2
+#define CHT_WC_USBSRC_STS_FAIL 3
+#define CHT_WC_USBSRC_TYPE_SHIFT 2
+#define CHT_WC_USBSRC_TYPE_MASKGENMASK(5, 2)
+#define CHT_WC_USBSRC_TYPE_NONE0
+#define CHT_WC_USBSRC_TYPE_SDP 1
+#define CHT_WC_USBSRC_TYPE_DCP 2
+#define CHT_WC_USBSRC_TYPE_CDP 3
+#define CHT_WC_USBSRC_TYPE_ACA 4
+#define CHT_WC_USBSRC_TYPE_SE1 5
+#define CHT_WC_USBSRC_TYPE_MHL 6
+#define CHT_WC_USBSRC_TYPE_FLOAT_DP_DN 7
+#define CHT_WC_USBSRC_TYPE_OTHER 8
+#define CHT_WC_USBSRC_TYPE_DCP_EXTPHY 9
+
+#define CHT_WC_PWRSRC_IRQ 0x6e03
+#define CHT_WC_PWRSRC_IRQ_MASK 0x6e0f
+#define CHT_WC_PWRSRC_STS 0x6e1e
+#define CHT_WC_PWRSRC_VBUS BIT(0)
+#define CHT_WC_PWRSRC_DC BIT(1)
+#define CHT_WC_PWRSRC_BAT BIT(2)
+#define CHT_WC_PWRSRC_ID_GND BIT(3)
+#define CHT_WC_PWRSRC_ID_FLOAT BIT(4)
+
+enum cht_wc_usb_id {
+ USB_ID_OTG,
+ USB_ID_GND,
+ USB_ID_
Re: [PATCH] staging: media: atomisp: fix build error
On Thu, 2017-03-23 at 21:12 +0800, Geliang Tang wrote: > Fix the following build error: > > CC drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o > drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2: > error: excess elements in array initializer [-Werror] > "i", /* ion */ > ^~~ NAK I've sent a patch to sort this out properly we shouldn't be using string arrays for single char values to start with... Alan
[PATCH] proc: allow to change proc mount options per mount
As per the discussion with Andy, and following what Al Viro suggested
maybe this can work ? the patch is still buggy on top of Linus' tree 093b995e3b
Currently hidepid mount option is propagated to all proc mounts that are
in the same pid namespace. This patch make it possible to have proc
mounts with different options inside the same pid namespace.
Since this may break userspace or code that checks/expects some device
identifiers, this mode is only supported when theo ption "version=2" is
passed.
[Buggy patch]
[tixxdz@fedora-kvm linux]$ sudo mount -t proc none /test
[tixxdz@fedora-kvm linux]$ sudo mount -t proc -o hidepid=2,version=2 none /test2
[tixxdz@fedora-kvm linux]$ ls -l /proc | head -6
total 0
dr-xr-xr-x. 9 rootroot 0 Mar 23 17:25 1
dr-xr-xr-x. 9 rootroot 0 Mar 23 17:25 10
dr-xr-xr-x. 9 rootroot 0 Mar 23 17:25 100
dr-xr-xr-x. 9 gdm gdm 0 Mar 23 17:25 1005
dr-xr-xr-x. 9 rootroot 0 Mar 23 17:25 101
[tixxdz@fedora-kvm linux]$ ls -l /test | head -16
total 0
dr-xr-xr-x. 9 rootroot 0 Mar 23 17:25 1
dr-xr-xr-x. 9 rootroot 0 Mar 23 17:25 10
dr-xr-xr-x. 9 rootroot 0 Mar 23 17:25 100
dr-xr-xr-x. 9 gdm gdm 0 Mar 23 17:25 1005
dr-xr-xr-x. 9 rootroot 0 Mar 23 17:25 101
[tixxdz@fedora-kvm linux]$ ls -l /test2 | head -6
total 0
dr-xr-xr-x. 9 tixxdz tixxdz 0 Mar 23 17:27 1182
dr-xr-xr-x. 9 tixxdz tixxdz 0 Mar 23 17:27 1197
dr-xr-xr-x. 9 tixxdz tixxdz 0 Mar 23 17:27 1199
dr-xr-xr-x. 9 tixxdz tixxdz 0 Mar 23 17:27 1222
dr-xr-xr-x. 9 tixxdz tixxdz 0 Mar 23 17:27 1225
Signed-off-by: Djalal Harouni
---
fs/locks.c | 6 +-
fs/proc/base.c | 51 +-
fs/proc/generic.c | 5 ++
fs/proc/inode.c | 10 +--
fs/proc/root.c | 181 ++--
fs/proc/self.c | 8 ++-
fs/proc/thread_self.c | 6 +-
fs/proc_namespace.c | 14 ++--
include/linux/proc_fs.h | 9 +++
9 files changed, 248 insertions(+), 42 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 2681132..dab5058 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -2617,7 +2617,8 @@ static void lock_get_status(struct seq_file *f, struct
file_lock *fl,
unsigned int fl_pid;
if (fl->fl_nspid) {
- struct pid_namespace *proc_pidns =
file_inode(f->file)->i_sb->s_fs_info;
+ struct proc_fs_info *fs_info =
proc_sb(file_inode(f->file)->i_sb);
+ struct pid_namespace *proc_pidns = fs_info->pid_ns;
/* Don't let fl_pid change based on who is reading the file */
fl_pid = pid_nr_ns(fl->fl_nspid, proc_pidns);
@@ -2701,7 +2702,8 @@ static int locks_show(struct seq_file *f, void *v)
{
struct locks_iterator *iter = f->private;
struct file_lock *fl, *bfl;
- struct pid_namespace *proc_pidns = file_inode(f->file)->i_sb->s_fs_info;
+ struct proc_fs_info *fs_info = proc_sb(file_inode(f->file)->i_sb);
+ struct pid_namespace *proc_pidns = fs_info->pid_ns;
fl = hlist_entry(v, struct file_lock, fl_link);
diff --git a/fs/proc/base.c b/fs/proc/base.c
index c87b6b9..74b389d 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -681,13 +681,24 @@ int proc_setattr(struct dentry *dentry, struct iattr
*attr)
* May current process learn task's sched/cmdline info (for hide_pid_min=1)
* or euid/egid (for hide_pid_min=2)?
*/
-static bool has_pid_permissions(struct pid_namespace *pid,
+static bool has_pid_permissions(struct proc_fs_info *fs_info,
struct task_struct *task,
int hide_pid_min)
{
- if (pid->hide_pid < hide_pid_min)
+ int hide_pid;
+ kgid_t pid_gid;
+ int version = fs_info->version;
+
+ if (version == 2) {
+ hide_pid = fs_info->hide_pid;
+ pid_gid = fs_info->pid_gid;
+ } else {
+ hide_pid = fs_info->pid_ns->hide_pid;
+ pid_gid = fs_info->pid_ns->pid_gid;
+ }
+ if (hide_pid < hide_pid_min)
return true;
- if (in_group_p(pid->pid_gid))
+ if (in_group_p(pid_gid))
return true;
return ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
}
@@ -695,14 +706,15 @@ static bool has_pid_permissions(struct pid_namespace *pid,
static int proc_pid_permission(struct inode *inode, int mask)
{
- struct pid_namespace *pid = inode->i_sb->s_fs_info;
+ struct proc_fs_info *fs_info = proc_sb(inode->i_sb);
+ struct pid_namespace *pid = fs_info->pid_ns;
struct task_struct *task;
bool has_perms;
task = get_proc_task(inode);
if (!task)
return -ESRCH;
- has_perms = has_pid_permissio
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
- Are we going to support resizing BAR when kernel modesetting is not enabled and we are running in console under VBIOS control (VESA/VGA)? No, initial I've tried to resize the PCI BAR during probing without the help of the driver at all. But the VESA/EFI/VBIOS don't seem to be able to handle addresses above 4GB for some reason. So the approach is to let the driver kick the VESA/EFI drivers out and then resize when we know that nobody is accessing the BAR. That's the only approach I've found without either blacklisting VESA/EFI drivers or crashing the system during the resize. - Should we restore PCI configuration if amdgpu will be unloaded? Yeah, thought about the as well. I'm just not sure how to do it. There is a lot of stuff we need to save and reset when the driver unloads for not much gain. - In function amdgpu_resize_bar0(): If resizing for "max" size failed should we try other sizes? What do you think? Probably not worth it. If we get the BAR moved to a 64bit address we should have enough address space in almost all cases, so setting it to the maximum should succeed. But I think we could add another parameter to allow limiting the resized size for all corner cases and for testing. Regards, Christian. Am 23.03.2017 um 15:30 schrieb Sagalovitch, Serguei: Christian, - Are we going to support resizing BAR when kernel modesetting is not enabled and we are running in console under VBIOS control (VESA/VGA)? - Should we restore PCI configuration if amdgpu will be unloaded? - In function amdgpu_resize_bar0(): If resizing for "max" size failed should we try other sizes? What do you think? Sincerely yours, Serguei Sagalovitch From: amd-gfx on behalf of Zhang, Jerry Sent: March 15, 2017 10:41 PM To: Alex Deucher Cc: Zhou, David(ChunMing); Ayyappa Ch; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; dri-de...@lists.freedesktop.org; platform-driver-...@vger.kernel.org; Christian König; helg...@kernel.org; amd-...@lists.freedesktop.org Subject: RE: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access Thanks for your info. I see. Regards, Jerry (Junwei Zhang) Linux Base Graphics SRDC Software Development _ -Original Message- From: Alex Deucher [mailto:alexdeuc...@gmail.com] Sent: Thursday, March 16, 2017 10:25 To: Zhang, Jerry Cc: Christian König; Zhou, David(ChunMing); Ayyappa Ch; linux- p...@vger.kernel.org; linux-kernel@vger.kernel.org; dri- de...@lists.freedesktop.org; platform-driver-...@vger.kernel.org; helg...@kernel.org; amd-...@lists.freedesktop.org Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access On Wed, Mar 15, 2017 at 10:19 PM, Zhang, Jerry wrote: -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Christian K?nig Sent: Wednesday, March 15, 2017 17:29 To: Zhou, David(ChunMing); Ayyappa Ch Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; amd- g...@lists.freedesktop.org; platform-driver-...@vger.kernel.org; helg...@kernel.org; dri-de...@lists.freedesktop.org Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access Yes, exactly that. (I'm not familiar with PCI too much.) Is there any restrict for PCI device? I'm concerning if any PCI couldn't support it on some motherboard. It depends on the PCI root bridge. This patch set only implements support for AMD root bridges. Intel and other vendors would need similar code. Alex Christian. Am 15.03.2017 um 09:25 schrieb Zhou, David(ChunMing): Does that means we don't need invisible vram later? David -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Christian K?nig Sent: Wednesday, March 15, 2017 3:38 PM To: Ayyappa Ch Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; amd-...@lists.freedesktop.org; platform-driver-...@vger.kernel.org; helg...@kernel.org; dri-de...@lists.freedesktop.org Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access Carizzo is an APU and resizing BARs isn't needed nor supported there. The CPU can access the full stolen VRAM directly on that hardware. As far as I know ASICs with support for this are Tonga, Fiji and all Polaris variants. Christian. Am 15.03.2017 um 08:23 schrieb Ayyappa Ch: Is it possible on Carrizo asics? Or only supports on newer asics? On Mon, Mar 13, 2017 at 6:11 PM, Christian König wrote: From: Christian König Try to resize BAR0 to let CPU access all of VRAM. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 + drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +--- drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +--- 4 files changed, 40 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index 3b81ded..90
Re: [tpmdd-devel] [PATCH v2 4/7] tpm: infrastructure for TPM spaces
On Wed, Mar 22, 2017 at 04:09:21PM -0400, Ken Goldman wrote: > On 2/22/2017 12:39 PM, James Bottomley wrote: > > > > Right at the moment the kernel use of tpm2 looks like > > > > acquire chip->tpm_mutex > > load key > > process key > > unload key > > release chip->tpm_mutex > > > > While it does this, there's no need for it to have a RM interface > > because what it does between the acquisition and drop of the mutex > > can't be seen by or have any effect on userspace (whether it uses the > > RM or not). So currently, the question doesn't arise, which is the > > situation you see. > > 1 - This appears to depend on the RM not releasing the mutex until all > objects are swapped out. Correct? Same for sessions? Yes. > 2 - A startauthsession can cause a regap error. Does the above depend on > the RM doing early regapping so the RM won't see that error? We are not trying to resolve that for 4.12. It can happen. > 3 - There's also the problem where the TPM saved session slots (typically > 64) are full. My intuition is that the best solution is for the RM to > reserve 3 slots for the kernel. Maybe but at the moment kernel does not use sessions. /Jarkko
Re: [PATCH] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF
On 03/23/2017 10:53 AM, Sinan Kaya wrote: > + depends on IPMI_SI||IPMI_SSIF Blank spaces around ||. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls
On Thu, Mar 23, 2017 at 12:11:06PM +0100, Uwe Kleine-König wrote: > Hello, > > On Thu, Mar 23, 2017 at 11:20:39AM +0100, Geert Uytterhoeven wrote: > > But having the error breaks setups where the GPIO is optional and does > > not exist. > > so the right way forward is to check harder in the situation where > -ENOSYS was returned before to determine if there is really no GPIO to > be used. "Oh, there are hints that there is no GPIO (GPIOLIB=n), so lets > assume there isn't." is wrong. > > Can we please properly fix the problem instead of papering over it? I think I once already said what would need to _attempt_ to fix it "properly". You would need to implement custom parsing of ACPI tables in GPIOLIB (what if they disable ACPI by mistake?), do the same for OF, call board's manufacturer hotline to ensure that they indeed did not forget to describe GPIOs, etc, etc. Or you could trust that person responsible for selecting kernel configuration has a clue, and if GPIOLIB is disabled it was disabled for a reason. -- Dmitry
Re: [PATCH] checkpatch: Allow space leading blank lines in email headers
On Wed, Mar 22, 2017 at 11:28:40PM -0700, Joe Perches wrote:
> On Wed, 2017-03-22 at 23:20 -0700, Darren Hart wrote:
> > I do have an open question regarding how we're going about testing for the
> > end
> > of the header lines. Since we're not just testing for an empty line to
> > separate
> > headers and body, there is clearly more going on here - but I'm not sure
> > what it
> > is ... so I can't be sure this doesn't have an unintended consequence.
> >
> > > + $rawline =~ /^(?:commit\b|from\b|[\w-]+:)/i)) {
> >
> > This appears to be an unrelated change, introducing the non-capturing-group
> > (?:) and dropping the superfluous .*$ postfix. Did I get that right?
>
> Exactly right.
>
> The capturing of the initial bit of the match and
> testing of the rest of the line is simply unnecessary.
>
> I frequently make localized changes like that when I
> notice them. It's not a problem.
Thanks Joe. Your call, when I see unrelated changes in patches to me I ask that
they be broken out or at least mentioned in the commit log - which is why I
asked, in case it slipped in unintentionally.
The fix addresses my concern in what appears to be the simplest possible way,
and generally for long header fields, with minimal change.
In addition to my tested-by, feel free to include my review tag:
Reviewed-by: Darren Hart (VMware)
Thanks to both you and John for the time on this.
--
Darren Hart
VMware Open Source Technology Center
Re: [PATCH v4 1/5] crash: move crashkernel parsing and vmcore related code under CONFIG_CRASH_CORE
Hi Michael,
It's been a while since this patchset is Ack'ed.
Should this go through powerpc-tree or some other?
Thanks
Hari
On Thursday 05 January 2017 10:59 PM, Hari Bathini wrote:
Traditionally, kdump is used to save vmcore in case of a crash. Some
architectures like powerpc can save vmcore using architecture specific
support instead of kexec/kdump mechanism. Such architecture specific
support also needs to reserve memory, to be used by dump capture kernel.
crashkernel parameter can be a reused, for memory reservation, by such
architecture specific infrastructure.
But currently, code related to vmcoreinfo and parsing of crashkernel
parameter is built under CONFIG_KEXEC_CORE. This patch introduces
CONFIG_CRASH_CORE and moves the above mentioned code under this config,
allowing code reuse without dependency on CONFIG_KEXEC. There is no
functional change with this patch.
Signed-off-by: Hari Bathini
---
Changes from v3:
* Renamed log_buf_kexec_setup()to log_buf_vmcoreinfo_setup() instead of
log_buf_crash_setup().
Changes from v2:
* Used CONFIG_CRASH_CORE instead of CONFIG_KEXEC_CORE at
appropriate places in printk and ksysfs.
arch/Kconfig |4
include/linux/crash_core.h | 65 ++
include/linux/kexec.h | 57 --
include/linux/printk.h |4
kernel/Makefile|1
kernel/crash_core.c| 445
kernel/kexec_core.c| 404
kernel/ksysfs.c|8 +
kernel/printk/printk.c |6 -
9 files changed, 531 insertions(+), 463 deletions(-)
create mode 100644 include/linux/crash_core.h
create mode 100644 kernel/crash_core.c
diff --git a/arch/Kconfig b/arch/Kconfig
index 99839c2..82e6f99 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -2,7 +2,11 @@
# General architecture dependent options
#
+config CRASH_CORE
+ bool
+
config KEXEC_CORE
+ select CRASH_CORE
bool
config HAVE_IMA_KEXEC
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
new file mode 100644
index 000..18d0f94
--- /dev/null
+++ b/include/linux/crash_core.h
@@ -0,0 +1,65 @@
+#ifndef LINUX_CRASH_CORE_H
+#define LINUX_CRASH_CORE_H
+
+#include
+#include
+#include
+
+#define CRASH_CORE_NOTE_NAME "CORE"
+#define CRASH_CORE_NOTE_HEAD_BYTES ALIGN(sizeof(struct elf_note), 4)
+#define CRASH_CORE_NOTE_NAME_BYTES ALIGN(sizeof(CRASH_CORE_NOTE_NAME), 4)
+#define CRASH_CORE_NOTE_DESC_BYTES ALIGN(sizeof(struct elf_prstatus), 4)
+
+#define CRASH_CORE_NOTE_BYTES ((CRASH_CORE_NOTE_HEAD_BYTES * 2) + \
+CRASH_CORE_NOTE_NAME_BYTES + \
+CRASH_CORE_NOTE_DESC_BYTES)
+
+#define VMCOREINFO_BYTES (4096)
+#define VMCOREINFO_NOTE_NAME "VMCOREINFO"
+#define VMCOREINFO_NOTE_NAME_BYTES ALIGN(sizeof(VMCOREINFO_NOTE_NAME), 4)
+#define VMCOREINFO_NOTE_SIZE ((CRASH_CORE_NOTE_HEAD_BYTES * 2) + \
+VMCOREINFO_NOTE_NAME_BYTES + \
+VMCOREINFO_BYTES)
+
+typedef u32 note_buf_t[CRASH_CORE_NOTE_BYTES/4];
+
+void crash_save_vmcoreinfo(void);
+void arch_crash_save_vmcoreinfo(void);
+__printf(1, 2)
+void vmcoreinfo_append_str(const char *fmt, ...);
+phys_addr_t paddr_vmcoreinfo_note(void);
+
+#define VMCOREINFO_OSRELEASE(value) \
+ vmcoreinfo_append_str("OSRELEASE=%s\n", value)
+#define VMCOREINFO_PAGESIZE(value) \
+ vmcoreinfo_append_str("PAGESIZE=%ld\n", value)
+#define VMCOREINFO_SYMBOL(name) \
+ vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)&name)
+#define VMCOREINFO_SIZE(name) \
+ vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
+ (unsigned long)sizeof(name))
+#define VMCOREINFO_STRUCT_SIZE(name) \
+ vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
+ (unsigned long)sizeof(struct name))
+#define VMCOREINFO_OFFSET(name, field) \
+ vmcoreinfo_append_str("OFFSET(%s.%s)=%lu\n", #name, #field, \
+ (unsigned long)offsetof(struct name, field))
+#define VMCOREINFO_LENGTH(name, value) \
+ vmcoreinfo_append_str("LENGTH(%s)=%lu\n", #name, (unsigned long)value)
+#define VMCOREINFO_NUMBER(name) \
+ vmcoreinfo_append_str("NUMBER(%s)=%ld\n", #name, (long)name)
+#define VMCOREINFO_CONFIG(name) \
+ vmcoreinfo_append_str("CONFIG_%s=y\n", #name)
+
+extern u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE/4];
+extern size_t vmcoreinfo_size;
+extern size_t vmcoreinfo_max_size;
+
+int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
+ unsigned long long *crash_size, unsigned long long *crash_base);
+int parse_crashkernel_high(char *cmdline, unsigned long long system_ram,
+ unsigned long long *crash_size, unsigned long long *crash_base);
+int parse_crashkernel_low(char *cmdline, unsigned long long system
[ANNOUNCE] elkdat: an easy linux kernel development and test tool
elkdat is a tool to ease linux kernel development/test. It automatically setups linux kernel source repository and a VM for linux kernel development and test. In addition, It runs the following kinds of tests automatically just by one command. - build, install, boot you own kernel - run your own tests on your own kernel - test the all patches in a patchset - find a problematic commit with bisect NOTE: Actually these features are achieved by ktest. elkdat is just a ktest's wrapper. Special thanks to Steven Rostedt! Here are some examples. * Boot your own kernel ``` $ ./test boot ``` * Run your own test on your own kernel ``` $ ./test test /path/to/your/own/test ``` * Test whether all patches in your patcheset are bootable or not one by one ``` $ ./test patchcheck boot ``` * Find which commit introduces an un-bootable bug by bysect ``` ./test bisect boot ``` For more information, please refer to the following URL. https://github.com/satoru-takeuchi/elkdat Thanks, Satoru
Re: [PATCH] tpm2: fix off-by-one comparison and out-of-bounds read error
On Wed, Mar 22, 2017 at 04:12:49PM +0300, Dan Carpenter wrote:
> On Wed, Mar 22, 2017 at 11:45:37AM +, Colin Ian King wrote:
> > On 22/03/17 11:42, Jarkko Sakkinen wrote:
> > > On Mon, Mar 20, 2017 at 02:23:36PM +, Colin King wrote:
> > >> From: Colin Ian King
> > >>
> > >> The comparison of an out of range index into space->context_tbl is
> > >> off-by-one and should be using >= rather than > in the comparison.
> > >>
> > >> Detected by CoverityScan, CID#1419694 ("Out-of-bounds read")
> > >>
> > >> Fixes: 849246e7ce9ce ("tpm2: add session handle context saving and
> > >> restoring to the space code")
> > >> Signed-off-by: Colin Ian King
> > >> ---
> > >> drivers/char/tpm/tpm2-space.c | 2 +-
> > >> 1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/char/tpm/tpm2-space.c
> > >> b/drivers/char/tpm/tpm2-space.c
> > >> index d36d81e07076..009934269514 100644
> > >> --- a/drivers/char/tpm/tpm2-space.c
> > >> +++ b/drivers/char/tpm/tpm2-space.c
> > >> @@ -229,7 +229,7 @@ static bool tpm2_map_to_phandle(struct tpm_space
> > >> *space, void *handle)
> > >> int i;
> > >>
> > >> i = 0xFF - (vhandle & 0xFF);
> > >> -if (i > ARRAY_SIZE(space->context_tbl) ||
> > >> !space->context_tbl[i])
> > >> +if (i >= ARRAY_SIZE(space->context_tbl) ||
> > >> !space->context_tbl[i])
> > >> return false;
> > >>
> > >> phandle = space->context_tbl[i];
> > >> --
> > >> 2.11.0
> > >
> > > Thanks. If you don't mind, I would squash this to that patch?
> > >
> > > /Jarkko
> > >
> > Sure squash it, and maybe add a Reported-by: Colin Ian King
> > if that's OK with you.
>
> Reported-by isn't really correct though... We should have a Fixes-from:
> tag for squashed fixes.
>
> regards,
> dan carpenter
Hmm... Maybe so depending on how you interpret Reported-by but
Fixes-from is not something that is used at the moment, is it?
/Jarkko
[PATCH] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF
ACPI_IPMI driver currently depends on IPMI System Interface (IPMI_SI) driver to be enabled. IPMI_SI driver only handles KCS, SMIC and BT BMC interfaces. IPMI_SSIF is an alternative BMC communication method. It allows BMC to be accessed over an I2C bus instead of a standard interface. Enabling ACPI_IPMI over IPMI_SSIF with this change. Signed-off-by: Sinan Kaya --- drivers/acpi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 83e5f7e..8767062 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -256,7 +256,7 @@ config ACPI_PROCESSOR config ACPI_IPMI tristate "IPMI" - depends on IPMI_SI + depends on IPMI_SI||IPMI_SSIF default n help This driver enables the ACPI to access the BMC controller. And it -- 1.9.1
Re: [PATCH] tpm2: fix off-by-one comparison and out-of-bounds read error
On Wed, Mar 22, 2017 at 11:45:37AM +, Colin Ian King wrote:
> On 22/03/17 11:42, Jarkko Sakkinen wrote:
> > On Mon, Mar 20, 2017 at 02:23:36PM +, Colin King wrote:
> >> From: Colin Ian King
> >>
> >> The comparison of an out of range index into space->context_tbl is
> >> off-by-one and should be using >= rather than > in the comparison.
> >>
> >> Detected by CoverityScan, CID#1419694 ("Out-of-bounds read")
> >>
> >> Fixes: 849246e7ce9ce ("tpm2: add session handle context saving and
> >> restoring to the space code")
> >> Signed-off-by: Colin Ian King
> >> ---
> >> drivers/char/tpm/tpm2-space.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
> >> index d36d81e07076..009934269514 100644
> >> --- a/drivers/char/tpm/tpm2-space.c
> >> +++ b/drivers/char/tpm/tpm2-space.c
> >> @@ -229,7 +229,7 @@ static bool tpm2_map_to_phandle(struct tpm_space
> >> *space, void *handle)
> >>int i;
> >>
> >>i = 0xFF - (vhandle & 0xFF);
> >> - if (i > ARRAY_SIZE(space->context_tbl) || !space->context_tbl[i])
> >> + if (i >= ARRAY_SIZE(space->context_tbl) || !space->context_tbl[i])
> >>return false;
> >>
> >>phandle = space->context_tbl[i];
> >> --
> >> 2.11.0
> >
> > Thanks. If you don't mind, I would squash this to that patch?
> >
> > /Jarkko
> >
> Sure squash it, and maybe add a Reported-by: Colin Ian King
> if that's OK with you.
>
> Colin
Thanks I'll do that!
/Jarkko
Re: [tpmdd-devel] [PATCH] tpm/tpm_crb: fix unused warnings on suspend/resume functions
On Tue, Mar 21, 2017 at 10:05:36PM +, Winkler, Tomas wrote: > > On Thu, Mar 16, 2017 at 09:51:33PM -0400, Jérémy Lefaure wrote: > > > When PM_SLEEP is disabled crb_pm_suspend and crb_pm_resume are not > > > used by SET_SYSTEM_SLEEP_PM_OPS even if PM is enabled: > > > > > > drvers/char/tpm/tpm_crb.c:540:12: warning: ‘crb_pm_suspend’ defined > > > but not used [-Wunused-function] static int crb_pm_suspend(struct > > > device *dev) > > > ^ > > > drivers/char/tpm/tpm_crb.c:551:12: warning: ‘crb_pm_resume’ defined > > > but not used [-Wunused-function] static int crb_pm_resume(struct > > > device *dev) > > > ^ > > > > > > The preprocessor condition should be on CONFIG_PM_SLEEP, not on > > CONFIG_PM. > > > However, this patch fixes this warning by using __maybe_unused on > > > function that are in the preprocessor condition. > > > > > > Signed-off-by: Jérémy Lefaure > > > > Thanks. Please include also linux-kernel@vger.kernel.org in the future. > > > > Reviewed-by: Jarkko Saskkinen > > We should go with Arnd's patch, which is actually the same, but it > was already reviewed and has better commit messages. > Thanks > Tomas You are right about the commit message but where are the Reviewed-by tags? [1] [1] https://patchwork.kernel.org/patch/9633537/ /Jarkko
sg: random memory corruptions
Hello, The following program causes random assorted memory corruptions: https://gist.githubusercontent.com/dvyukov/da3463af2d1ff8c7d3624891b5d7427f/raw/09cf0f4af529f4506f9e0a9fa6bdb066a8777b9d/gistfile1.txt It does some ioctl's on /dev/sg0. general protection fault: [#1] SMP KASAN Modules linked in: CPU: 1 PID: 2843 Comm: rsyslogd Not tainted 4.11.0-rc3+ #365 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: 880062754300 task.stack: 880062fc8000 RIP: 0010:__read_once_size include/linux/compiler.h:254 [inline] RIP: 0010:radix_tree_load_root lib/radix-tree.c:602 [inline] RIP: 0010:__radix_tree_lookup+0x12c/0x5e0 lib/radix-tree.c:1040 RSP: :880062fced90 EFLAGS: 00010202 RAX: 00f37b916d5e RBX: 079bdc8b6ae8 RCX: 880062fcefa8 RDX: RSI: 0001622819596228 RDI: 079bdc8b6ae8 RBP: 880062fcef78 R08: ed000da135c2 R09: ed000da135c2 R10: 0001 R11: ed000da135c1 R12: 880062fcefa8 R13: dc00 R14: 079bdc8b6ae8 R15: 0001622819596228 FS: 7f773eae2700() GS:88006d08() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f773eae1e30 CR3: 64ac CR4: 001406e0 Call Trace: radix_tree_lookup_slot+0x78/0xe0 lib/radix-tree.c:1079 find_get_entry+0x186/0x990 mm/filemap.c:1190 pagecache_get_page+0x116/0xb60 mm/filemap.c:1298 find_get_page include/linux/pagemap.h:258 [inline] lookup_swap_cache+0x8d/0x110 mm/swap_state.c:296 do_swap_page+0x278/0x2110 mm/memory.c:2702 handle_pte_fault mm/memory.c:3727 [inline] __handle_mm_fault+0x1747/0x3e70 mm/memory.c:3841 handle_mm_fault+0x141/0x4f0 mm/memory.c:3878 __do_page_fault+0x503/0xb50 arch/x86/mm/fault.c:1397 trace_do_page_fault+0x145/0x720 arch/x86/mm/fault.c:1490 do_async_page_fault+0x72/0xc0 arch/x86/kernel/kvm.c:264 async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:1014 RIP: 0033:0x7f77411261fd RSP: 002b:7f773eae1e30 EFLAGS: 00010293 RAX: 0024 RBX: 020944d0 RCX: 7f77411261fd RDX: 0fff RSI: 7f77405225a0 RDI: 0004 RBP: R08: 0207f160 R09: 0401 R10: 0001 R11: 0293 R12: 0065e420 R13: 7f773eae29c0 R14: 7f774176b040 R15: 0003 Code: ff 42 c6 04 28 00 48 8d 85 d8 fe ff ff 48 c1 e8 03 42 c6 04 28 00 48 8b 85 48 fe ff ff c6 00 00 48 8b 85 40 fe ff ff 48 c1 e8 03 <42> 80 3c 28 00 0f 85 07 04 00 00 48 8b 85 38 fe ff ff 4c 8b 60 RIP: __read_once_size include/linux/compiler.h:254 [inline] RSP: 880062fced90 RIP: radix_tree_load_root lib/radix-tree.c:602 [inline] RSP: 880062fced90 RIP: __radix_tree_lookup+0x12c/0x5e0 lib/radix-tree.c:1040 RSP: 880062fced90 ---[ end trace 53d928cd2f7a08d4 ]--- BUG: unable to handle kernel paging request at 015281a4 IP: qlist_move_cache+0x74/0x100 mm/kasan/quarantine.c:274 PGD 0 Oops: [#1] SMP KASAN Modules linked in: CPU: 0 PID: 29 Comm: kworker/u8:1 Not tainted 4.11.0-rc3+ #365 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: netns cleanup_net task: 88006c096800 task.stack: 88006c098000 RIP: 0010:qlist_move_cache+0x74/0x100 mm/kasan/quarantine.c:274 RSP: 0018:88006c09f368 EFLAGS: 00010002 RAX: 015281a4 RBX: 77ff8000 RCX: 015281a4 RDX: 8800696dd200 RSI: 88006c09f388 RDI: 865cce58 RBP: 88006c09f378 R08: 88006c019340 R09: 8000 R10: 015281a4 R11: ea00 R12: ea00016892ef R13: 84fa9740 R14: 865d1760 R15: 8800696dd200 FS: () GS:88006d00() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 015281a4 CR3: 69898000 CR4: 001406f0 Call Trace: quarantine_remove_cache+0x79/0xf0 mm/kasan/quarantine.c:317 kasan_cache_shutdown+0x9/0x10 mm/kasan/kasan.c:451 shutdown_cache mm/slab_common.c:532 [inline] kmem_cache_destroy+0x52/0x120 mm/slab_common.c:830 tipc_server_stop+0x13f/0x190 net/tipc/server.c:636 tipc_topsrv_stop+0x200/0x360 net/tipc/subscr.c:397 tipc_exit_net+0x15/0x40 net/tipc/core.c:96 ops_exit_list.isra.4+0xae/0x150 net/core/net_namespace.c:141 cleanup_net+0x5c7/0xb60 net/core/net_namespace.c:463 process_one_work+0xb20/0x1b40 kernel/workqueue.c:2097 worker_thread+0x1b4/0x1340 kernel/workqueue.c:2231 kthread+0x359/0x420 kernel/kthread.c:229 ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430 Code: 00 8b 49 14 0f 84 87 00 00 00 4c 8b 47 08 49 89 00 48 89 47 08 48 c7 00 00 00 00 00 4c 89 d0 48 01 4f 10 4d 85 d2 74 64 48 89 c1 <4c> 8b 10 4c 01 c9 72 6d 49 89 d8 4c 01 c1 48 c1 e9 0c 4c 8d 04 RIP: qlist_move_cache+0x74/0x100 mm/kasan/quarantine.c:274 RSP: 88006c09f368 CR2: 015281a4 ---[ end trace 9db83f7c295b4f05 ]--- BUG: unable to handle kernel paging request at eba5308001e0 IP: virt_to_head_page include/linux/mm.h:570 [inline] IP: qlink_t
Re: deadlock in synchronize_srcu() in debugfs?
Hi, > Not yet. How reproducible is this? Apparently quite. I haven't tried myself - it happens during some automated test that I need to analyse further. > > We're observing that with our (backported, but very recent) driver > > against 4.9 (and 4.10, I think), > > Do I understand it correctly that this driver has been backported > from 4.11-rcX to 4.9/10 Yes. > and that there isn't any issue with 4.11-rcX? No, I can't say this, we haven't run that test. > > but there are no backports of any debugfs things so the backport > > itself doesn't seem like a likely problem. > > Right, there haven't been any SRCU related changes to debugfs after > 4.8. Right. > > sysrq-w shows a lot of tasks blocked on various locks (e.g. RTNL), > > but > > the ultimate problem is the wireless stack getting blocked on > > debugfs_remove_recursive(), in __synchronize_srcu(), in > > wait_for_completion() (while holding lots of locks, hence the other > > tasks getting stuck). > > Could you share a complete backtrace? For example, is the > debugfs_remove_recursive() called from any debugfs file's fops and > thus, possibly from within a SRCU read side critical section? No, it's called from netlink: [ 884.634857] wpa_supplicant D0 1769 1005 0x [ 884.634874] 8ca50633d140 8ca507b219c0 8ca5455d4cc0 [ 884.634898] 8ca54f599d98 97df431c36a0 878dadf3 8ca50001 [ 884.634927] 81ed67337c8469e4 8ca54f599d98 932a07b219c0 8ca507b219c0 [ 884.634952] Call Trace: [ 884.634969] [] ? __schedule+0x303/0xb00 [ 884.634985] [] schedule+0x3d/0x90 [ 884.635002] [] schedule_timeout+0x2fc/0x600 [ 884.635021] [] ? mark_held_locks+0x66/0x90 [ 884.635041] [] ? _raw_spin_unlock_irq+0x2c/0x40 [ 884.635059] [] wait_for_completion+0xdc/0x110 [ 884.635073] [] ? wake_up_q+0x80/0x80 [ 884.635091] [] __synchronize_srcu+0x11e/0x1c0 [ 884.635109] [] ? trace_raw_output_rcu_utilization+0x60/0x60 [ 884.635131] [] synchronize_srcu+0x32/0x40 [ 884.635145] [] debugfs_remove_recursive+0x17d/0x190 [ 884.635239] [] ieee80211_debugfs_key_remove+0x1e/0x30 [mac80211] [ 884.635333] [] __ieee80211_key_destroy+0x1b3/0x480 [mac80211] [ 884.635440] [] ieee80211_free_sta_keys+0x117/0x170 [mac80211] [ 884.635524] [] __sta_info_destroy_part2+0x4c/0x200 [mac80211] [ 884.635597] [] __sta_info_flush+0x10d/0x1a0 [mac80211] [ 884.635706] [] ieee80211_set_disassoc+0xcb/0x530 [mac80211] [ 884.635802] [] ieee80211_mgd_deauth+0x2e6/0x7b0 [mac80211] [ 884.635901] [] ieee80211_deauth+0x18/0x20 [mac80211] [ 884.636024] [] cfg80211_mlme_deauth+0x14f/0x3b0 [cfg80211] [ 884.636110] [] nl80211_deauthenticate+0xe5/0x130 [cfg80211] [ 884.636133] [] genl_family_rcv_msg+0x1bc/0x370 [ 884.636151] [] ? genl_family_rcv_msg+0x370/0x370 [ 884.636262] [] genl_rcv_msg+0x80/0xc0 [ 884.636275] [] netlink_rcv_skb+0xa7/0xc0 [ 884.636289] [] genl_rcv+0x28/0x40 [ 884.636303] [] netlink_unicast+0x15b/0x210 [ 884.636318] [] netlink_sendmsg+0x31a/0x3a0 [ 884.636335] [] sock_sendmsg+0x38/0x50 [ 884.636354] [] ___sys_sendmsg+0x26c/0x280 [ 884.636378] [] ? ring_buffer_unlock_commit+0x32/0x290 [ 884.636393] [] ? __buffer_unlock_commit+0x1e/0x40 [ 884.636407] [] ? tracing_mark_write+0x162/0x2b0 [ 884.636423] [] ? __lock_is_held+0x49/0x70 [ 884.636440] [] __sys_sendmsg+0x45/0x80 [ 884.636459] [] SyS_sendmsg+0x12/0x20 [ 884.636477] [] entry_SYSCALL_64_fastpath+0x23/0xc6 johannes
Re: deadlock in synchronize_srcu() in debugfs?
On Thu, 2017-03-23 at 08:37 -0700, Paul E. McKenney wrote: > I have not seen this, but my usual question for __synchronize_srcu() > is if some other task is blocked holding srcu_read_lock() for that > same srcu_struct. > Not as far as I can see - but that was the scenario I was outlining in my second email, I guess. I'll need to reproduce it and a get a fuller view of the system, I only have the "echo w > sysrq-trigger" output right now. Thanks, johannes
Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls
On Thu, Mar 23, 2017 at 07:43:25AM -0700, Dmitry Torokhov wrote:
> On Thu, Mar 23, 2017 at 02:41:53PM +0100, Linus Walleij wrote:
> > On Thu, Mar 23, 2017 at 1:34 PM, Uwe Kleine-König
> > wrote:
> >
> > > Maybe we can make gpiod_get_optional look like this:
> > >
> > > if (!dev->of_node && isnt_a_acpi_device(dev) &&
> > > !IS_ENABLED(GPIOLIB))
> > > return NULL;
> > > else
> > > return -ENOSYS;
> > >
> > > I don't know how isnt_a_acpi_device looks like, probably it involves
> > > CONFIG_ACPI and/or dev->acpi_node.
> > >
> > > This should be safe and still comfortable for legacy platforms, isn't it?
> >
> > I like the looks of this.
> >
> > Can we revert Dmitry's patch and apply something like this instead?
> >
> > Dmitry, how do you feel about this?
>
> I frankly do not see the point. It still makes driver code more complex
> for no good reason. I also think that not having optional GPIO is not an
> error, so returning value from error space is not correct. NULL is value
> from another space altogether.
>
> Uwe seems to be concerned about case that I find extremely unlikely. We
> are talking about a system that does not have GPIO support and behaves
> just fine, with the exception that it actually has (physically) a
> *single* GPIO, and that GPIO happens to be optional in a single driver,
> but in this particular system is actually needed (but that need
> manifests in a non-obvious way). And we have system integrator that has
> no idea what they are doing (no schematic, etc).
>
> I think that if there is one optional GPIO there will be mandatiry GPIOs
> in such system as well and selection of GPIOLIB will be forced early on
> in board bringup.
One more thing: if we keep reporting -ENOSYS in case of !CONFIG_GPIOLIB,
then most of the non platform-sepcific drivers will eventually gain code
silently coping with this -ENOSYS:
data->gpiod = gpiod_getptional(...);
if (IS_ERR(data->gpiod)) {
error = PTR_ERR(data->gpiod);
if (error != -ENOSYS)
return error;
data->gpiod = NULL; /* This GPIO _is_ optional */
}
which will negate Uwe's claim that it will help debugging issues.
Thanks.
--
Dmitry
[PATCH v3] kasan: report only the first error by default
From: Mark Rutland
Disable kasan after the first report. There are several reasons for this:
* Single bug quite often has multiple invalid memory accesses causing
storm in the dmesg.
* Write OOB access might corrupt metadata so the next report will print
bogus alloc/free stacktraces.
* Reports after the first easily could be not bugs by itself but just side
effects of the first one.
Given that multiple reports usually only do harm, it makes sense to disable
kasan after the first one. If user wants to see all the reports, the
boot-time parameter kasan_multi_shot must be used.
Signed-off-by: Mark Rutland
[ aryabinin: wrote changelog and doc, added missing include ]
Signed-off-by: Andrey Ryabinin
---
Changes since v2:
- Instead of using atomic report counter, use separate flags to
determine
whether we're in multi-shot mode, and whether a (oneshot) report
has been made.
Changes since v1:
- provide kasan_multi_shot boot parameter.
Documentation/admin-guide/kernel-parameters.txt | 6 +
include/linux/kasan.h | 3 +++
lib/test_kasan.c| 10 +++
mm/kasan/kasan.h| 5
mm/kasan/report.c | 36 +
5 files changed, 55 insertions(+), 5 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 2906987..f88d60e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1726,6 +1726,12 @@
kernel and module base offset ASLR (Address Space
Layout Randomization).
+ kasan_multi_shot
+ [KNL] Enforce KASAN (Kernel Address Sanitizer) to print
+ report on every invalid memory access. Without this
+ parameter KASAN will print report only for the first
+ invalid access.
+
keepinitrd [HW,ARM]
kernelcore= [KNL,X86,IA-64,PPC]
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 5734480c9..a5c7046 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -76,6 +76,9 @@ size_t ksize(const void *);
static inline void kasan_unpoison_slab(const void *ptr) { ksize(ptr); }
size_t kasan_metadata_size(struct kmem_cache *cache);
+bool kasan_save_enable_multi_shot(void);
+void kasan_restore_multi_shot(bool enabled);
+
#else /* CONFIG_KASAN */
static inline void kasan_unpoison_shadow(const void *address, size_t size) {}
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index 0b1d314..a25c976 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
/*
* Note: test functions are marked noinline so that their names appear in
@@ -474,6 +475,12 @@ static noinline void __init use_after_scope_test(void)
static int __init kmalloc_tests_init(void)
{
+ /*
+* Temporarily enable multi-shot mode. Otherwise, we'd only get a
+* report for the first case.
+*/
+ bool multishot = kasan_save_enable_multi_shot();
+
kmalloc_oob_right();
kmalloc_oob_left();
kmalloc_node_oob_right();
@@ -499,6 +506,9 @@ static int __init kmalloc_tests_init(void)
ksize_unpoisons_memory();
copy_user_test();
use_after_scope_test();
+
+ kasan_restore_multi_shot(multishot);
+
return -EAGAIN;
}
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index 7572917..1229298 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -96,11 +96,6 @@ static inline const void *kasan_shadow_to_mem(const void
*shadow_addr)
<< KASAN_SHADOW_SCALE_SHIFT);
}
-static inline bool kasan_report_enabled(void)
-{
- return !current->kasan_depth;
-}
-
void kasan_report(unsigned long addr, size_t size,
bool is_write, unsigned long ip);
void kasan_report_double_free(struct kmem_cache *cache, void *object,
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 718a10a..beee0e9 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -13,7 +13,9 @@
*
*/
+#include
#include
+#include
#include
#include
#include
@@ -354,6 +356,40 @@ static void kasan_report_error(struct kasan_access_info
*info)
kasan_end_report(&flags);
}
+static unsigned long kasan_flags;
+
+#define KASAN_BIT_REPORTED 0
+#define KASAN_BIT_MULTI_SHOT 1
+
+bool kasan_save_enable_multi_shot(void)
+{
+ return test_and_set_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags);
+}
+EXPORT_SYMBOL_GPL(kasan_save_enable_multi_shot);
+
+void kasan_restore_multi_shot(bool enabled)
+{
+ if (!enabled)
+ clear_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags);
+}
+EXPORT_SYMBOL_GPL(kasan_restore_multi_shot);
+
+static int __init kasan_set_multi_shot(char *str)
+{
+ set_bit(KASAN_BIT_M
Re: [PATCH v2 1/2] powerpc/powernv/cpuidle: Pass correct drv->cpumask for registration
* Rafael J. Wysocki [2017-03-23 16:28:31]: > On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan > wrote: > > drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init(). > > On PowerNV platform cpu_present could be less than cpu_possible in cases > > where firmware detects the cpu, but it is not available to the OS. When > > CONFIG_HOTPLUG_CPU=n, such cpus are not hotplugable at runtime and hence > > we skip creating cpu_device. > > > > This breaks cpuidle on powernv where register_cpu() is not called for > > cpus in cpu_possible_mask that cannot be hot-added at runtime. > > > > Trying cpuidle_register_device() on cpu without cpu_device will cause > > crash like this: > > > > cpu 0xf: Vector: 380 (Data SLB Access) at [c00ff1503490] > > pc: c022c8bc: string+0x34/0x60 > > lr: c022ed78: vsnprintf+0x284/0x42c > > sp: c00ff1503710 > >msr: 90009033 > >dar: 60006000 > > current = 0xc00ff148 > > paca= 0xcfe82d00 softe: 0irq_happened: 0x01 > > pid = 1, comm = swapper/8 > > Linux version 4.11.0-rc2 (sv@sagarika) (gcc version 4.9.4 > > (Buildroot 2017.02-4-gc28573e) ) #15 SMP Fri Mar 17 19:32:02 IST 2017 > > enter ? for help > > [link register ] c022ed78 vsnprintf+0x284/0x42c > > [c00ff1503710] c022ebb8 vsnprintf+0xc4/0x42c (unreliable) > > [c00ff1503800] c022ef40 vscnprintf+0x20/0x44 > > [c00ff1503830] c00ab61c vprintk_emit+0x94/0x2cc > > [c00ff15038a0] c00acc9c vprintk_func+0x60/0x74 > > [c00ff15038c0] c0619694 printk+0x38/0x4c > > [c00ff15038e0] c0224950 kobject_get+0x40/0x60 > > [c00ff1503950] c022507c kobject_add_internal+0x60/0x2c4 > > [c00ff15039e0] c0225350 kobject_init_and_add+0x70/0x78 > > [c00ff1503a60] c053c288 cpuidle_add_sysfs+0x9c/0xe0 > > [c00ff1503ae0] c053aeac cpuidle_register_device+0xd4/0x12c > > [c00ff1503b30] c053b108 cpuidle_register+0x98/0xcc > > [c00ff1503bc0] c085eaf0 powernv_processor_idle_init+0x140/0x1e0 > > [c00ff1503c60] c000cd60 do_one_initcall+0xc0/0x15c > > [c00ff1503d20] c0833e84 kernel_init_freeable+0x1a0/0x25c > > [c00ff1503dc0] c000d478 kernel_init+0x24/0x12c > > [c00ff1503e30] c000b564 ret_from_kernel_thread+0x5c/0x78 > > > > This patch fixes the bug by passing correct cpumask from > > powernv-cpuidle driver. > > > > Signed-off-by: Vaidyanathan Srinivasan > > That needs to be ACKed by someone familiar with powernv. Previous version at https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-March/155587.html I had not CCed linux-pm in the first post. Michael and Mikey have reviewed the previous version. Let me get an ack for you to proceed with the merge. Thanks, Vaidy
Re: [PATCH v2 2/2] cpuidle: Validate cpu_dev in cpuidle_add_sysfs
* Rafael J. Wysocki [2017-03-23 16:27:31]: > On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan > wrote: > > If a given cpu is not in cpu_present and cpu hotplug > > is disabled, arch can skip setting up the cpu_dev. > > > > Arch cpuidle driver should pass correct cpu mask > > for registration, but failing to do so by the driver > > causes error to propagate and crash like this: > > > > [ 30.076045] Unable to handle kernel paging request for > > data at address 0x0048 > > [ 30.076100] Faulting instruction address: 0xc07b2f30 > > cpu 0x4d: Vector: 300 (Data Access) at [c03feb18b670] > > pc: c07b2f30: kobject_get+0x20/0x70 > > lr: c07b3c94: kobject_add_internal+0x54/0x3f0 > > sp: c03feb18b8f0 > >msr: 90009033 > >dar: 48 > > dsisr: 4000 > > current = 0xc03fd2ed8300 > > paca= 0xcfbab500 softe: 0irq_happened: 0x01 > > pid = 1, comm = swapper/0 > > Linux version 4.11.0-rc2-svaidy+ (sv@sagarika) (gcc version 6.2.0 > > 20161005 (Ubuntu 6.2.0-5ubuntu12) ) #10 SMP Sun Mar 19 00:08:09 IST 2017 > > enter ? for help > > [c03feb18b960] c07b3c94 kobject_add_internal+0x54/0x3f0 > > [c03feb18b9f0] c07b43a4 kobject_init_and_add+0x64/0xa0 > > [c03feb18ba70] c0e284f4 cpuidle_add_sysfs+0xb4/0x130 > > [c03feb18baf0] c0e26038 cpuidle_register_device+0x118/0x1c0 > > [c03feb18bb30] c0e26c48 cpuidle_register+0x78/0x120 > > [c03feb18bbc0] c168fd9c powernv_processor_idle_init+0x110/0x1c4 > > [c03feb18bc40] c000cff8 do_one_initcall+0x68/0x1d0 > > [c03feb18bd00] c16242f4 kernel_init_freeable+0x280/0x360 > > [c03feb18bdc0] c000d864 kernel_init+0x24/0x160 > > [c03feb18be30] c000b4e8 ret_from_kernel_thread+0x5c/0x74 > > > > Validating cpu_dev fixes the crash and reports correct error message like: > > > > [ 30.163506] Failed to register cpuidle device for cpu136 > > [ 30.173329] Registration of powernv driver failed. > > > > Signed-off-by: Vaidyanathan Srinivasan > > The previous version is in linux-next already and I'm going to push it > for merging shortly. Thanks Rafael. The previous version is good for merge. --Vaidy
Re: [PATCH v4 1/4] syscalls: Restore address limit after a syscall
On Thu, Mar 23, 2017 at 8:32 AM, Borislav Petkov wrote: > On Thu, Mar 23, 2017 at 08:14:44AM -0700, Thomas Garnier wrote: >> Okay well then people are fine with a BUG_ON approach. I will do a >> next iteration tailored to that. I will also try to add the static >> inline suggestion from Peter. > > Would it be possible, please, to refrain from top-posting when replying > on the ML? > > You sometimes reply inline and after the text and sometimes at the top. > This subthread has both variants and it is really annoying to people > like me who try to follow the discussion. Sure, I will try to always reply inline. Sorry bad habits. -- Thomas
Re: [PATCH] x86/boot: Support uncompressed kernel
On (03/23/17 08:07), Yinghai Lu wrote: > On Thu, Mar 23, 2017 at 5:51 AM, Chao Peng > wrote: > > Compressed kernel has its own drawback: uncompressing takes time. Even > > though the time is short enough to ignore for most cases but for cases that > > time is critical this is still a big number. In our on-going optimization > > for kernel boot time, the measured overall kernel boot time is ~90ms while > > the uncompressing takes ~50ms with gzip. > > > > The patch adds a 'CONFIG_KERNEL_RAW' configure choice so the built binary > > can have no uncompressing at all. The experiment shows: > > > > kernel kernel sizetime in decompress_kernel > > compressed (gzip)3.3M 53ms > > uncompressed 14M3ms > > How about the time difference for bootloader to read kernel from > flash/disk/network to ram? there are also faster de-compressors than gzip out there. LZ4, for instance. LZ4, as far as I remember, can be quite fast, like ~10 times faster than gzip. have you tested it? -ss
Re: [PATCH v5] KVM: VMX: Fix enable VPID conditions
On Thu, Mar 23, 2017 at 5:30 AM, Wanpeng Li wrote:
> From: Wanpeng Li
>
> This can be reproduced by running L2 on L1, and disable VPID on L0
> if w/o commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2
> crash as below:
>
> KVM: entry failed, hardware error 0x7
> EAX= EBX= ECX= EDX=000306c3
> ESI= EDI= EBP= ESP=
> EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES = 9300
> CS =f000 9b00
> SS = 9300
> DS = 9300
> FS = 9300
> GS = 9300
> LDT= 8200
> TR = 8b00
> GDT=
> IDT=
> CR0=6010 CR2= CR3= CR4=
> DR0= DR1= DR2=
> DR3=
> DR6=0ff0 DR7=0400
> EFER=
>
> Reference SDM 30.3 INVVPID:
>
> Protected Mode Exceptions
> #UD
> - If not in VMX operation.
> - If the logical processor does not support VPIDs
> (IA32_VMX_PROCBASED_CTLS2[37]=0).
> - If the logical processor supports VPIDs (IA32_VMX_PROCBASED_CTLS2[37]=1)
> but does
> not support the INVVPID instruction (IA32_VMX_EPT_VPID_CAP[32]=0).
>
> So we should check both VPID enable bit in vmx exec control and INVVPID
> support bit
> in vmx capability MSRs to enable VPID. This patch adds the guarantee to not
> enable
> VPID if either INVVPID or single-context/all-context invalidation is not
> exposed in
> vmx capability MSRs.
>
> Reviewed-by: David Hildenbrand
Reviewed-by: Jim Mattson
> Cc: David Hildenbrand
> Cc: Jim Mattson
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Signed-off-by: Wanpeng Li
> ---
> arch/x86/kvm/vmx.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 8795a70..8925c76 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -1239,6 +1239,11 @@ static inline bool cpu_has_vmx_invvpid_global(void)
> return vmx_capability.vpid & VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT;
> }
>
> +static inline bool cpu_has_vmx_invvpid(void)
> +{
> + return vmx_capability.vpid & VMX_VPID_INVVPID_BIT;
> +}
> +
> static inline bool cpu_has_vmx_ept(void)
> {
> return vmcs_config.cpu_based_2nd_exec_ctrl &
> @@ -6518,8 +6523,10 @@ static __init int hardware_setup(void)
> if (boot_cpu_has(X86_FEATURE_NX))
> kvm_enable_efer_bits(EFER_NX);
>
> - if (!cpu_has_vmx_vpid())
> + if (!cpu_has_vmx_vpid() || !cpu_has_vmx_invvpid() ||
> + !(cpu_has_vmx_invvpid_single() ||
> cpu_has_vmx_invvpid_global()))
> enable_vpid = 0;
> +
> if (!cpu_has_vmx_shadow_vmcs())
> enable_shadow_vmcs = 0;
> if (enable_shadow_vmcs)
> --
> 2.7.4
>
Re: [PATCH v2 3/5] mm: use a dedicated workqueue for the free workers
On 03/22/2017 01:41 AM, Aaron Lu wrote: > On Wed, Mar 22, 2017 at 03:33:35PM +0900, Minchan Kim wrote: >> On Wed, Mar 15, 2017 at 05:00:02PM +0800, Aaron Lu wrote: >>> Introduce a workqueue for all the free workers so that user can fine >>> tune how many workers can be active through sysfs interface: max_active. >>> More workers will normally lead to better performance, but too many can >>> cause severe lock contention. >> >> Let me ask a question. >> >> How well can workqueue distribute the jobs in multiple CPU? > > I would say it's good enough for my needs. > After all, it doesn't need many kworkers to achieve the 50% time > decrease: 2-4 kworkers for EP and 4-8 kworkers for EX are enough from > previous attched data. It's also worth noting that we'd like to *also* like to look into increasing how scalable freeing pages to a given zone is.
Re: deadlock in synchronize_srcu() in debugfs?
On Thu, Mar 23, 2017 at 03:54:46PM +0100, Johannes Berg wrote: > Hi, > > Before I go hunting - has anyone seen a deadlock in synchronize_srcu() > in debugfs_remove() before? We're observing that with our (backported, > but very recent) driver against 4.9 (and 4.10, I think), but there are > no backports of any debugfs things so the backport itself doesn't seem > like a likely problem. > > sysrq-w shows a lot of tasks blocked on various locks (e.g. RTNL), but > the ultimate problem is the wireless stack getting blocked on > debugfs_remove_recursive(), in __synchronize_srcu(), in > wait_for_completion() (while holding lots of locks, hence the other > tasks getting stuck). I have not seen this, but my usual question for __synchronize_srcu() is if some other task is blocked holding srcu_read_lock() for that same srcu_struct. Thanx, Paul
Re: deadlock in synchronize_srcu() in debugfs?
Hi Johannes, On Thu, Mar 23 2017, Johannes Berg wrote: > Before I go hunting - has anyone seen a deadlock in synchronize_srcu() > in debugfs_remove() before? Not yet. How reproducible is this? > We're observing that with our (backported, but very recent) driver > against 4.9 (and 4.10, I think), Do I understand it correctly that this driver has been backported from 4.11-rcX to 4.9/10 and that there isn't any issue with 4.11-rcX? > but there are no backports of any debugfs things so the backport > itself doesn't seem like a likely problem. Right, there haven't been any SRCU related changes to debugfs after 4.8. > sysrq-w shows a lot of tasks blocked on various locks (e.g. RTNL), but > the ultimate problem is the wireless stack getting blocked on > debugfs_remove_recursive(), in __synchronize_srcu(), in > wait_for_completion() (while holding lots of locks, hence the other > tasks getting stuck). Could you share a complete backtrace? For example, is the debugfs_remove_recursive() called from any debugfs file's fops and thus, possibly from within a SRCU read side critical section? Thanks, Nicolai
Re: [PATCH V4] perf: qcom: Add L3 cache PMU driver
Hi Agustin,
Structurally, this looks good to me.
I have a few minor comments below; with those fixed up I think this is
ready to merge.
On Fri, Mar 17, 2017 at 10:24:17AM -0400, Agustin Vega-Frias wrote:
> +/*
> + * General constants
> + */
> +
> +/* Number of counters on each PMU */
> +#define L3_NUM_COUNTERS 8
> +/* Mask for the event type field within perf_event_attr.config and EVTYPE
> reg */
> +#define L3_MAX_EVTYPE0xFF
Given it's a mask, it would be better to name this L3_EVTYPE_MASK.
Perhaps L3_EVTYPE_MASK, then?
[...]
> +/* L3_HML3_PM_EVTYPEx */
> +#define EVSEL(__val) ((u32)((__val) & 0xFF))
This cast can go.
[...]
> +/* L3_M_BC_CR */
> +#define BC_RESET (((u32)1) << 1)
> +#define BC_ENABLE ((u32)1)
The u32 cast is somewhat unusual. Can we please do this as:
#define BC_RESET(1UL << 1)
#define BC_ENABLE (1UL << 0)
> +
> +/* L3_M_BC_SATROLL_CR */
> +#define BC_SATROLL_CR_RESET (0)
> +
> +/* L3_M_BC_CNTENSET */
> +#define PMCNTENSET(__cntr)(((u32)1) << ((__cntr) & 0x7))
Likewise:
#define PMCNTENSET(__cntr (1UL << ((__cntr) & 0x7))
... and so on for the other definitions of this form.
[...]
> +/*
> + * Events
> + */
> +
> +#define L3_CYCLES0x01
> +#define L3_READ_HIT 0x20
> +#define L3_READ_MISS 0x21
> +#define L3_READ_HIT_D0x22
> +#define L3_READ_MISS_D 0x23
> +#define L3_WRITE_HIT 0x24
> +#define L3_WRITE_MISS0x25
Can we please Please give these a L3_EVT_ (or L3_EVENT_) prefix?
Then we can add a NONE event for the odd counter in the long conter
case.
[...]
> +struct l3cache_event_ops {
> + struct perf_event *event;
> + /* Called to start event monitoring */
> + void (*start)(struct perf_event *event);
> + /* Called to stop event monitoring */
> + void (*stop)(struct perf_event *event, int flags);
> + /* Called to update the perf_event */
> + void (*update)(struct perf_event *event);
> +};
I believe the event field can go.
> +/*
> + * Implementation of long counter operations
> + *
> + * 64bit counters are implemented by chaining two of the 32bit physical
> + * counters. The PMU only supports chaining of adjacent even/odd pairs
> + * and for simplicity the driver always configures the odd counter to
> + * count the overflows of the lower-numbered even counter. Note that since
> + * the resulting hardware counter is 64bits no IRQs are required to maintain
> + * the software counter which is also 64bits.
> + */
This is a really useful comment; thanks for putting this together!
> +
> +static void qcom_l3_cache__64bit_counter_start(struct perf_event *event)
> +{
> + struct l3cache_pmu *l3pmu = to_l3cache_pmu(event->pmu);
> + int idx = event->hw.idx;
> + u32 evsel = get_event_type(event);
> + u32 gang = readl_relaxed(l3pmu->regs + L3_M_BC_GANG);
> +
> + /* Set the odd counter to count the overflows of the even counter */
> + writel_relaxed(gang | GANG_EN(idx + 1), l3pmu->regs + L3_M_BC_GANG);
Not a big deal, but could we organise this like:
/* Set the odd counter to count the overflows of the even counter */
gang = readl_relaxed(l3pmu->regs + L3_M_BC_GANG);
gang |= GANG_EN(idx + 1);
writel_relaxed(gang, l3pmu->regs + L3_M_BC_GANG);
... it makes it a little easier to spot the precise manipulation of the
register value, and easier to spot that this is an RMW sequence for the
same register.
> +
> + /* Initialize the hardware counters and reset prev_count*/
> + local64_set(&event->hw.prev_count, 0);
> + writel_relaxed(0, l3pmu->regs + L3_HML3_PM_EVCNTR(idx+1));
> + writel_relaxed(0, l3pmu->regs + L3_HML3_PM_EVCNTR(idx));
Nit: please use spaces around binary operators, i.e. s/idx+1/idx + 1/g.
[...]
> +static void qcom_l3_cache__64bit_counter_update(struct perf_event *event)
> +{
> + struct l3cache_pmu *l3pmu = to_l3cache_pmu(event->pmu);
> + int idx = event->hw.idx;
> + u32 hi, lo;
> + u64 prev, now;
Nit: s/now/new/ so as to match other drivers.
[...]
> +struct l3cache_event_ops event_ops_long = {
> + .start = qcom_l3_cache__64bit_counter_start,
> + .stop = qcom_l3_cache__64bit_counter_stop,
> + .update = qcom_l3_cache__64bit_counter_update,
> +};
Please make this static const.
> +struct l3cache_event_ops event_ops_std = {
> + .start = qcom_l3_cache__32bit_counter_start,
> + .stop = qcom_l3_cache__32bit_counter_stop,
> + .update = qcom_l3_cache__32bit_counter_update,
> +};
Likewise, please make this static const.
> +
> +/* Retrieve the appropriate operations for the given event */
> +static struct l3cache_event_ops *l3cache_event_get_ops(struct perf_event
> *event)
This will need to return a const pointer for the ops changes above.
[...]
> +static int qcom_l3_cache_pmu_probe(struct platform_device *pdev)
> +{
> + struct l3cache_pmu *l3pmu;
> + struct acp
[PATCH] ACPI / IPMI: change warning to debug on timeout
Getting timeout message from BMC when trying to read from a non-existent
FRU. This is expected but warning is not.
Let's reduce the warning to debug.
Signed-off-by: Sinan Kaya
---
drivers/acpi/acpi_ipmi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
index 747c2ba..1b64419 100644
--- a/drivers/acpi/acpi_ipmi.c
+++ b/drivers/acpi/acpi_ipmi.c
@@ -429,8 +429,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg,
void *user_msg_data)
if (msg->recv_type == IPMI_RESPONSE_RECV_TYPE &&
msg->msg.data_len == 1) {
if (msg->msg.data[0] == IPMI_TIMEOUT_COMPLETION_CODE) {
- dev_WARN_ONCE(dev, true,
- "Unexpected response (timeout).\n");
+ dev_dbg_once(dev, "Unexpected response (timeout).\n");
tx_msg->msg_done = ACPI_IPMI_TIMEOUT;
}
goto out_comp;
--
1.9.1
Re: [PATCH] hwmon: asus_atk0110.c fix uninitialized data access
On 23 March 2017 at 16:03, Arnd Bergmann wrote:
> The latest gcc-7 snapshot adds a warning to point out that when
> atk_read_value_old or atk_read_value_new fails, we copy
> uninitialized data into sensor->cached_value:
>
> drivers/hwmon/asus_atk0110.c: In function 'atk_input_show':
> drivers/hwmon/asus_atk0110.c:651:26: error: 'value' may be used uninitialized
> in this function [-Werror=maybe-uninitialized]
Ops, thanks for catching this.
>
> Adding an error check avoids this. All versions of the driver
> are affected.
>
> Fixes: 2c03d07ad54d ("hwmon: Add Asus ATK0110 support")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Luca Tettamanti
> ---
> drivers/hwmon/asus_atk0110.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/hwmon/asus_atk0110.c b/drivers/hwmon/asus_atk0110.c
> index cccef87963e0..975c43d446f8 100644
> --- a/drivers/hwmon/asus_atk0110.c
> +++ b/drivers/hwmon/asus_atk0110.c
> @@ -646,6 +646,9 @@ static int atk_read_value(struct atk_sensor_data *sensor,
> u64 *value)
> else
> err = atk_read_value_new(sensor, value);
>
> + if (err)
> + return err;
> +
> sensor->is_valid = true;
> sensor->last_updated = jiffies;
> sensor->cached_value = *value;
> --
> 2.9.0
>
Re: [PATCH v4 1/4] syscalls: Restore address limit after a syscall
On Thu, Mar 23, 2017 at 08:14:44AM -0700, Thomas Garnier wrote: > Okay well then people are fine with a BUG_ON approach. I will do a > next iteration tailored to that. I will also try to add the static > inline suggestion from Peter. Would it be possible, please, to refrain from top-posting when replying on the ML? You sometimes reply inline and after the text and sometimes at the top. This subthread has both variants and it is really annoying to people like me who try to follow the discussion. Thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] virtio_balloon: prevent uninitialized variable use
On 03/23/2017 06:17 PM, Arnd Bergmann wrote:
> The latest gcc-7.0.1 snapshot reports a new warning:
>
> virtio/virtio_balloon.c: In function 'update_balloon_stats':
> virtio/virtio_balloon.c:258:26: error: 'events[2]' is used uninitialized in
> this function [-Werror=uninitialized]
> virtio/virtio_balloon.c:260:26: error: 'events[3]' is used uninitialized in
> this function [-Werror=uninitialized]
> virtio/virtio_balloon.c:261:56: error: 'events[18]' is used uninitialized in
> this function [-Werror=uninitialized]
> virtio/virtio_balloon.c:262:56: error: 'events[17]' is used uninitialized in
> this function [-Werror=uninitialized]
>
> This seems absolutely right, so we should add an extra check to
> prevent copying uninitialized stack data into the statistics.
> From all I can tell, this has been broken since the statistics code
> was originally added in 2.6.34.
>
> Fixes: 9564e138b1f6 ("virtio: Add memory statistics reporting to the balloon
> driver (V4)")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Denis V. Lunev
> ---
> drivers/virtio/virtio_balloon.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 4e1191508228..cd5c54e2003d 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -254,12 +254,14 @@ static void update_balloon_stats(struct virtio_balloon
> *vb)
>
> available = si_mem_available();
>
> +#ifdef CONFIG_VM_EVENT_COUNTERS
> update_stat(vb, idx++, VIRTIO_BALLOON_S_SWAP_IN,
> pages_to_bytes(events[PSWPIN]));
> update_stat(vb, idx++, VIRTIO_BALLOON_S_SWAP_OUT,
> pages_to_bytes(events[PSWPOUT]));
> update_stat(vb, idx++, VIRTIO_BALLOON_S_MAJFLT, events[PGMAJFAULT]);
> update_stat(vb, idx++, VIRTIO_BALLOON_S_MINFLT, events[PGFAULT]);
> +#endif
> update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMFREE,
> pages_to_bytes(i.freeram));
> update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMTOT,
Re: [PATCH v3 00/12] Add Basic SoC support for MT6797
Hi Mars, On 23/03/17 00:46, Mars Cheng wrote: > Hi Matthias, Rob, Marc, Stephen > > gentle ping for this patch set. I appreciate that you're eager to see this reviewed, but less than 4 days between a posting and a reminder is a bit too eager. We're not machines! ;-) Thanks, M. -- Jazz is not dead. It just smells funny...
Re: deadlock in synchronize_srcu() in debugfs?
On Thu, 2017-03-23 at 15:54 +0100, Johannes Berg wrote: > Before I go hunting - has anyone seen a deadlock in > synchronize_srcu() in debugfs_remove() before? Isn't it possible for the following to happen? CPU1CPU2 mutex_lock(&M); full_proxy_xyz(); srcu_read_lock(&debugfs_srcu); real_fops->xyz(); mutex_lock(&M); debugfs_remove(F); synchronize_srcu(&debugfs_srcu); -> deadlock? I'm not convinced that this is the scenario I'm looking at, since then it seems I should see the mutex_lock(&M) on CPU 2 with a backtrace pointing to a full_proxy and the debugfs operation I recognize, but lots of debugfs files acquire locks and it seems likely that it's not always removed without holding those locks? Am I missing something? I'll see if I can add lockdep annotations. johannes
Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR
On Thu, Mar 23, 2017 at 2:23 PM, Evgenii Shatokhin
wrote:
> On 23.03.2017 03:27, Kees Cook wrote:
>>
>> This is a modified revert of commit 65fe935dd238 ("x86/KASLR, x86/power:
>> Remove x86 hibernation restrictions"), since it appears that 32-bit
>> hibernation still can't support KASLR. 64-bit is fine. Since people have
>> been running with KASLR by default on 32-bit since v4.8, this disables
>> hibernation (with a warning). Booting with "nokaslr" will disable KASLR
>> and enable hibernation.
>>
>> Reported-by: Evgenii Shatokhin
>> Signed-off-by: Kees Cook
>> Cc: sta...@vger.kernel.org # v4.8+
>
>
> The patch does not work as intended on my system, unfortunately.
>
> I tried the mainline kernel v4.11-rc3 and added this patch. With "nokaslr"
> in the kernel command line, the system fails to hibernate. It complains this
> way in the log:
>
> <...>
> kernel: PM: writing image.
> kernel: PM: Cannot find swap device, try swapon -a.
> kernel: PM: Cannot get swap writer
> kernel: PM: Basic memory bitmaps freed
> kernel: Restarting tasks ... done.
> systemd[1]: Time has been changed
> systemd[3948]: Time has been changed
> systemd[14825]: Time has been changed
> systemd[1]: systemd-hibernate.service: main process exited, code=exited,
> status=1/FAILURE
> systemd[1]: Failed to start Hibernate.
> <...>
>
> The swap device (swap file, actually) is available, however:
> -
> # swapon -s
> Filename Type SizeUsed Priority
> /swap file 6297596 0 -1
> -
>
> I built the same kernel without this patch then, added "nokaslr" in the
> kernel command line again, and the system hibernates and resumes fine.
With the patch applied and "nokaslr" in the kernel command line, what
shows up when you do
$ cat /sys/power/state
?
Thanks,
Rafael
Re: [PATCH v2 1/2] powerpc/powernv/cpuidle: Pass correct drv->cpumask for registration
On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan wrote: > drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init(). > On PowerNV platform cpu_present could be less than cpu_possible in cases > where firmware detects the cpu, but it is not available to the OS. When > CONFIG_HOTPLUG_CPU=n, such cpus are not hotplugable at runtime and hence > we skip creating cpu_device. > > This breaks cpuidle on powernv where register_cpu() is not called for > cpus in cpu_possible_mask that cannot be hot-added at runtime. > > Trying cpuidle_register_device() on cpu without cpu_device will cause > crash like this: > > cpu 0xf: Vector: 380 (Data SLB Access) at [c00ff1503490] > pc: c022c8bc: string+0x34/0x60 > lr: c022ed78: vsnprintf+0x284/0x42c > sp: c00ff1503710 >msr: 90009033 >dar: 60006000 > current = 0xc00ff148 > paca= 0xcfe82d00 softe: 0irq_happened: 0x01 > pid = 1, comm = swapper/8 > Linux version 4.11.0-rc2 (sv@sagarika) (gcc version 4.9.4 > (Buildroot 2017.02-4-gc28573e) ) #15 SMP Fri Mar 17 19:32:02 IST 2017 > enter ? for help > [link register ] c022ed78 vsnprintf+0x284/0x42c > [c00ff1503710] c022ebb8 vsnprintf+0xc4/0x42c (unreliable) > [c00ff1503800] c022ef40 vscnprintf+0x20/0x44 > [c00ff1503830] c00ab61c vprintk_emit+0x94/0x2cc > [c00ff15038a0] c00acc9c vprintk_func+0x60/0x74 > [c00ff15038c0] c0619694 printk+0x38/0x4c > [c00ff15038e0] c0224950 kobject_get+0x40/0x60 > [c00ff1503950] c022507c kobject_add_internal+0x60/0x2c4 > [c00ff15039e0] c0225350 kobject_init_and_add+0x70/0x78 > [c00ff1503a60] c053c288 cpuidle_add_sysfs+0x9c/0xe0 > [c00ff1503ae0] c053aeac cpuidle_register_device+0xd4/0x12c > [c00ff1503b30] c053b108 cpuidle_register+0x98/0xcc > [c00ff1503bc0] c085eaf0 powernv_processor_idle_init+0x140/0x1e0 > [c00ff1503c60] c000cd60 do_one_initcall+0xc0/0x15c > [c00ff1503d20] c0833e84 kernel_init_freeable+0x1a0/0x25c > [c00ff1503dc0] c000d478 kernel_init+0x24/0x12c > [c00ff1503e30] c000b564 ret_from_kernel_thread+0x5c/0x78 > > This patch fixes the bug by passing correct cpumask from > powernv-cpuidle driver. > > Signed-off-by: Vaidyanathan Srinivasan That needs to be ACKed by someone familiar with powernv. > --- > drivers/cpuidle/cpuidle-powernv.c | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/drivers/cpuidle/cpuidle-powernv.c > b/drivers/cpuidle/cpuidle-powernv.c > index a06df51..82f7b33 100644 > --- a/drivers/cpuidle/cpuidle-powernv.c > +++ b/drivers/cpuidle/cpuidle-powernv.c > @@ -175,6 +175,24 @@ static int powernv_cpuidle_driver_init(void) > drv->state_count += 1; > } > > + /* > +* On PowerNV platform cpu_present may be less that cpu_possible in > +* cases where firmware detects the cpu, but it is not available to > the > +* OS. If CONFIG_HOTPLUG_CPU=n then such CPUs are not hotplugable at > +* runtime and hence cpu_devices are not created for those cpus by > +* generic topology_init(). > +* > +* drv->cpumask defaults to cpu_possible_mask in > +* __cpuidle_driver_init(). This breaks cpuidle on powernv where > +* cpu_devices are not created for cpus in cpu_possible_mask that > +* cannot be hot-added later at runtime. > +* > +* Trying cpuidle_register_device() on a cpu without cpu_devices is > +* incorrect. Hence pass correct cpu mask to generic cpuidle driver. > +*/ > + > + drv->cpumask = (struct cpumask *)cpu_present_mask; > + > return 0; > } > > -- > 2.9.3 >
Re: [PATCH v2 2/2] cpuidle: Validate cpu_dev in cpuidle_add_sysfs
On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan wrote: > If a given cpu is not in cpu_present and cpu hotplug > is disabled, arch can skip setting up the cpu_dev. > > Arch cpuidle driver should pass correct cpu mask > for registration, but failing to do so by the driver > causes error to propagate and crash like this: > > [ 30.076045] Unable to handle kernel paging request for > data at address 0x0048 > [ 30.076100] Faulting instruction address: 0xc07b2f30 > cpu 0x4d: Vector: 300 (Data Access) at [c03feb18b670] > pc: c07b2f30: kobject_get+0x20/0x70 > lr: c07b3c94: kobject_add_internal+0x54/0x3f0 > sp: c03feb18b8f0 >msr: 90009033 >dar: 48 > dsisr: 4000 > current = 0xc03fd2ed8300 > paca= 0xcfbab500 softe: 0irq_happened: 0x01 > pid = 1, comm = swapper/0 > Linux version 4.11.0-rc2-svaidy+ (sv@sagarika) (gcc version 6.2.0 > 20161005 (Ubuntu 6.2.0-5ubuntu12) ) #10 SMP Sun Mar 19 00:08:09 IST 2017 > enter ? for help > [c03feb18b960] c07b3c94 kobject_add_internal+0x54/0x3f0 > [c03feb18b9f0] c07b43a4 kobject_init_and_add+0x64/0xa0 > [c03feb18ba70] c0e284f4 cpuidle_add_sysfs+0xb4/0x130 > [c03feb18baf0] c0e26038 cpuidle_register_device+0x118/0x1c0 > [c03feb18bb30] c0e26c48 cpuidle_register+0x78/0x120 > [c03feb18bbc0] c168fd9c powernv_processor_idle_init+0x110/0x1c4 > [c03feb18bc40] c000cff8 do_one_initcall+0x68/0x1d0 > [c03feb18bd00] c16242f4 kernel_init_freeable+0x280/0x360 > [c03feb18bdc0] c000d864 kernel_init+0x24/0x160 > [c03feb18be30] c000b4e8 ret_from_kernel_thread+0x5c/0x74 > > Validating cpu_dev fixes the crash and reports correct error message like: > > [ 30.163506] Failed to register cpuidle device for cpu136 > [ 30.173329] Registration of powernv driver failed. > > Signed-off-by: Vaidyanathan Srinivasan The previous version is in linux-next already and I'm going to push it for merging shortly. > --- > drivers/cpuidle/sysfs.c | 12 > 1 file changed, 12 insertions(+) > > diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c > index c5adc8c..f2c3bce 100644 > --- a/drivers/cpuidle/sysfs.c > +++ b/drivers/cpuidle/sysfs.c > @@ -615,6 +615,18 @@ int cpuidle_add_sysfs(struct cpuidle_device *dev) > struct device *cpu_dev = get_cpu_device((unsigned long)dev->cpu); > int error; > > + /* > +* Return error if cpu_device is not setup for this cpu. This > +* could happen if arch did not setup cpu_device since this > +* cpu is not in cpu_present mask and the driver did not send > +* correct cpu mask at registration. Without this check we > +* would end up passing bogus value for &cpu_dev->kobj in > +* kobject_init_and_add(). > +*/ > + > + if (!cpu_dev) > + return -ENODEV; > + > kdev = kzalloc(sizeof(*kdev), GFP_KERNEL); > if (!kdev) > return -ENOMEM; > -- > 2.9.3 >
Re: [PATCH] EDAC, pnd2_edac: fix build error without CONFIG_EDAC_DEBUG
On Thu, Mar 23, 2017 at 04:16:35PM +0100, Arnd Bergmann wrote:
> Calling into functions inside of the #ifdef causes an obvious compile error:
>
> drivers/edac/pnd2_edac.c: In function 'pnd2_init':
> drivers/edac/pnd2_edac.c:1521:2: error: implicit declaration of function
> 'setup_pnd2_debug'; did you mean 'setup_log_buf'?
> [-Werror=implicit-function-declaration]
> drivers/edac/pnd2_edac.c: In function 'pnd2_exit':
> drivers/edac/pnd2_edac.c:1529:2: error: implicit declaration of function
> 'teardown_pnd2_debug' [-Werror=implicit-function-declaration]
>
> This removes the #ifdef and instead uses an equivalent IS_ENABLED() check
> so the compiler can silently drop the functions but still build-test them
> and not need an #ifdef.
>
> Fixes: 5c71ad17f97e ("EDAC, pnd2_edac: Add new EDAC driver for Intel SoC
> platforms")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/edac/pnd2_edac.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Thanks Arnd, I'm already running randconfig builds on the fixes:
https://lkml.kernel.org/r/20170322172923.ga15...@nazgul.tnic
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH v2 2/2] cpuidle: Validate cpu_dev in cpuidle_add_sysfs
If a given cpu is not in cpu_present and cpu hotplug is disabled, arch can skip setting up the cpu_dev. Arch cpuidle driver should pass correct cpu mask for registration, but failing to do so by the driver causes error to propagate and crash like this: [ 30.076045] Unable to handle kernel paging request for data at address 0x0048 [ 30.076100] Faulting instruction address: 0xc07b2f30 cpu 0x4d: Vector: 300 (Data Access) at [c03feb18b670] pc: c07b2f30: kobject_get+0x20/0x70 lr: c07b3c94: kobject_add_internal+0x54/0x3f0 sp: c03feb18b8f0 msr: 90009033 dar: 48 dsisr: 4000 current = 0xc03fd2ed8300 paca= 0xcfbab500 softe: 0irq_happened: 0x01 pid = 1, comm = swapper/0 Linux version 4.11.0-rc2-svaidy+ (sv@sagarika) (gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) ) #10 SMP Sun Mar 19 00:08:09 IST 2017 enter ? for help [c03feb18b960] c07b3c94 kobject_add_internal+0x54/0x3f0 [c03feb18b9f0] c07b43a4 kobject_init_and_add+0x64/0xa0 [c03feb18ba70] c0e284f4 cpuidle_add_sysfs+0xb4/0x130 [c03feb18baf0] c0e26038 cpuidle_register_device+0x118/0x1c0 [c03feb18bb30] c0e26c48 cpuidle_register+0x78/0x120 [c03feb18bbc0] c168fd9c powernv_processor_idle_init+0x110/0x1c4 [c03feb18bc40] c000cff8 do_one_initcall+0x68/0x1d0 [c03feb18bd00] c16242f4 kernel_init_freeable+0x280/0x360 [c03feb18bdc0] c000d864 kernel_init+0x24/0x160 [c03feb18be30] c000b4e8 ret_from_kernel_thread+0x5c/0x74 Validating cpu_dev fixes the crash and reports correct error message like: [ 30.163506] Failed to register cpuidle device for cpu136 [ 30.173329] Registration of powernv driver failed. Signed-off-by: Vaidyanathan Srinivasan --- drivers/cpuidle/sysfs.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c index c5adc8c..f2c3bce 100644 --- a/drivers/cpuidle/sysfs.c +++ b/drivers/cpuidle/sysfs.c @@ -615,6 +615,18 @@ int cpuidle_add_sysfs(struct cpuidle_device *dev) struct device *cpu_dev = get_cpu_device((unsigned long)dev->cpu); int error; + /* +* Return error if cpu_device is not setup for this cpu. This +* could happen if arch did not setup cpu_device since this +* cpu is not in cpu_present mask and the driver did not send +* correct cpu mask at registration. Without this check we +* would end up passing bogus value for &cpu_dev->kobj in +* kobject_init_and_add(). +*/ + + if (!cpu_dev) + return -ENODEV; + kdev = kzalloc(sizeof(*kdev), GFP_KERNEL); if (!kdev) return -ENOMEM; -- 2.9.3
[PATCH v2 1/2] powerpc/powernv/cpuidle: Pass correct drv->cpumask for registration
drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init(). On PowerNV platform cpu_present could be less than cpu_possible in cases where firmware detects the cpu, but it is not available to the OS. When CONFIG_HOTPLUG_CPU=n, such cpus are not hotplugable at runtime and hence we skip creating cpu_device. This breaks cpuidle on powernv where register_cpu() is not called for cpus in cpu_possible_mask that cannot be hot-added at runtime. Trying cpuidle_register_device() on cpu without cpu_device will cause crash like this: cpu 0xf: Vector: 380 (Data SLB Access) at [c00ff1503490] pc: c022c8bc: string+0x34/0x60 lr: c022ed78: vsnprintf+0x284/0x42c sp: c00ff1503710 msr: 90009033 dar: 60006000 current = 0xc00ff148 paca= 0xcfe82d00 softe: 0irq_happened: 0x01 pid = 1, comm = swapper/8 Linux version 4.11.0-rc2 (sv@sagarika) (gcc version 4.9.4 (Buildroot 2017.02-4-gc28573e) ) #15 SMP Fri Mar 17 19:32:02 IST 2017 enter ? for help [link register ] c022ed78 vsnprintf+0x284/0x42c [c00ff1503710] c022ebb8 vsnprintf+0xc4/0x42c (unreliable) [c00ff1503800] c022ef40 vscnprintf+0x20/0x44 [c00ff1503830] c00ab61c vprintk_emit+0x94/0x2cc [c00ff15038a0] c00acc9c vprintk_func+0x60/0x74 [c00ff15038c0] c0619694 printk+0x38/0x4c [c00ff15038e0] c0224950 kobject_get+0x40/0x60 [c00ff1503950] c022507c kobject_add_internal+0x60/0x2c4 [c00ff15039e0] c0225350 kobject_init_and_add+0x70/0x78 [c00ff1503a60] c053c288 cpuidle_add_sysfs+0x9c/0xe0 [c00ff1503ae0] c053aeac cpuidle_register_device+0xd4/0x12c [c00ff1503b30] c053b108 cpuidle_register+0x98/0xcc [c00ff1503bc0] c085eaf0 powernv_processor_idle_init+0x140/0x1e0 [c00ff1503c60] c000cd60 do_one_initcall+0xc0/0x15c [c00ff1503d20] c0833e84 kernel_init_freeable+0x1a0/0x25c [c00ff1503dc0] c000d478 kernel_init+0x24/0x12c [c00ff1503e30] c000b564 ret_from_kernel_thread+0x5c/0x78 This patch fixes the bug by passing correct cpumask from powernv-cpuidle driver. Signed-off-by: Vaidyanathan Srinivasan --- drivers/cpuidle/cpuidle-powernv.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-powernv.c index a06df51..82f7b33 100644 --- a/drivers/cpuidle/cpuidle-powernv.c +++ b/drivers/cpuidle/cpuidle-powernv.c @@ -175,6 +175,24 @@ static int powernv_cpuidle_driver_init(void) drv->state_count += 1; } + /* +* On PowerNV platform cpu_present may be less that cpu_possible in +* cases where firmware detects the cpu, but it is not available to the +* OS. If CONFIG_HOTPLUG_CPU=n then such CPUs are not hotplugable at +* runtime and hence cpu_devices are not created for those cpus by +* generic topology_init(). +* +* drv->cpumask defaults to cpu_possible_mask in +* __cpuidle_driver_init(). This breaks cpuidle on powernv where +* cpu_devices are not created for cpus in cpu_possible_mask that +* cannot be hot-added later at runtime. +* +* Trying cpuidle_register_device() on a cpu without cpu_devices is +* incorrect. Hence pass correct cpu mask to generic cpuidle driver. +*/ + + drv->cpumask = (struct cpumask *)cpu_present_mask; + return 0; } -- 2.9.3
[PATCH v1 0/2] cpuidle: Fixes in cpuidle driver
When CONFIG_HOTPLUG_CPU=n and cpu_present is less than cpu_possible, then cpuidle-powernv not passing an explicit drv->cpu_mask allows generic cpuidle driver to try create sysfs objects for cpus that does not have cpu_devices created by calling register_cpu(). This caused kernel to access incorrect address and crash. The following patch series fixes the cpuidle-powernv driver and also adds additional checks in cpuidle_add_sysfs() This patch set is against v4.11-rc3. Changed from v1: Updated commit message and comments. Signed-off-by: Vaidyanathan Srinivasan
Re: [PATCH 3/4] RAS: Add a Corrected Errors Collector
On Wed, Mar 22, 2017 at 07:03:39PM +0100, Borislav Petkov wrote:
> Lemme try to write a small script exercising exactly that scenario to
> see whether I'm actually not talking crap here :-)
Ok, here's a snapshot from the CEC after letting it run for a couple of
hours in a guest with a script running twice in parallel and injecting
random PFNs. We have 0 offlined pages because a PFN number doesn't
repeat frequently enough to cause an overflow.
When I force the occurrence of a single PFN for 1023 and more times and
do that more than once, this happens:
[ 6629.091239] RAS: Soft-offlining pfn: 0x7fff
[ 6629.093036] __get_any_page: 0x7fff free buddy page
[ 6653.259476] RAS: Soft-offlining pfn: 0x7fff
[ 6653.260100] soft offline: 0x7fff page already poisoned
...
Stats:
CEs: 32614
offlined pages: 2
^
Flags: 0x0
Timer interval: 86400 seconds
Decays: 254
Action threshold: 1023
The "already poisoned" thing shouldn't happen in real life because once
the page frame is poisoned, it shouldn't generate MCEs.
Every 2.0s: head -n 40 array; tail -n 40 array
Thu Mar 23 17:15:15 2017
{ n: 512
000: [0056|c01]
001: [011f|801]
002: [0171|401]
003: [01ce|401]
004: [024a|401]
005: [026e|401]
006: [034d|c01]
007: [0395|c01]
008: [03b9|801]
009: [0458|003]
010: [045c|401]
011: [04f9|401]
012: [05d1|c01]
013: [0677|801]
014: [069d|401]
015: [06b3|401]
016: [06f5|c01]
017: [06fc|401]
018: [074d|401]
019: [0764|c01]
020: [08a8|801]
021: [0951|401]
022: [0994|401]
023: [0aa8|401]
024: [0ac7|801]
025: [0af2|801]
026: [0bb5|801]
027: [0bd5|401]
028: [0be0|c01]
029: [0c30|c01]
030: [0c61|801]
031: [0c8a|401]
032: [0d0d|801]
033: [0d2a|003]
034: [0d4d|401]
035: [0d87|c01]
036: [0da4|c01]
037: [0e06|401]
038: [0e23|c01]
...
480: [7d22|005]
481: [7d5f|002]
482: [7d9f|004]
483: [7db1|c01]
484: [7dbf|002]
485: [7dcf|002]
486: [7dd8|401]
487: [7df0|001]
488: [7df4|002]
489: [7e1f|003]
490: [7e35|801]
491: [7e73|003]
492: [7e77|401]
493: [7e80|002]
494: [7e9c|002]
495: [7eac|002]
496: [7ecb|002]
497: [7ed8|801]
498: [7edc|003]
499: [7ee3|801]
500: [7f05|004]
501: [7f15|002]
502: [7f51|004]
503: [7f5e|003]
504: [7f80|801]
505: [7f92|003]
506: [7fb2|002]
507: [7fd9|002]
508: [7fdf|002]
509: [7fe5|004]
510: [7ff4|801]
511: [7ffa|001]
}
Stats:
CEs: 30074
offlined pages: 0
Flags: 0x0
Timer interval: 86400 seconds
Decays: 234
Action threshold: 1023
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: usb: use-after-free write in usb_hcd_link_urb_to_ep
On Thu, Mar 23, 2017 at 4:04 PM, Alan Stern wrote: > On Thu, 23 Mar 2017, Dmitry Vyukov wrote: > >> > Putting these together: >> > >> > The memory was allocated in usb_internal_control_msg() line 93. >> > The later events occurred within the call in line 100 to >> > usb_start_wait_urb(). >> > >> > The invalid access occurred within usb_start_wait_urb() line 56. >> > >> > The memory was deallocated within usb_start_wait_urb() line 78. >> > >> > Since these routines don't involve any loops or backward jumps, this >> > says that the invalid access occurred before the memory was >> > deallocated! So why is it reported as a problem? >> >> >> My first guess would be that pid 3348 did 2 calls to open and the urb >> was somehow referenced across these calls. Is it possible? > > I don't think so. The URB gets allocated and deallocated separately > for each call. You can see this very plainly by reading the source > code for usb_internal_control_msg() and usb_start_wait_urb(). > > It's possible that the same memory location was allocated and > deallocated for two different calls at different times. That wouldn't > fool syzkaller, would it? Generally it does not fool KASAN because of heap memory quarantine. I will take a closer look tomorrow. Thanks for looking into this.
Re: [PATCH 03/15] extcon: cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon driver
Hi, On 21-03-17 06:16, Chanwoo Choi wrote: Hi, On 2017년 03월 21일 04:57, Hans de Goede wrote: Hi, On 20-03-17 02:33, Chanwoo Choi wrote: Hi, On 2017년 03월 17일 18:55, Hans de Goede wrote: Add a driver for charger detection / control on the Intel Cherrytrail Whiskey Cove PMIC. Signed-off-by: Hans de Goede --- drivers/extcon/Kconfig | 7 + drivers/extcon/Makefile| 1 + drivers/extcon/extcon-cht-wc.c | 356 + 3 files changed, 364 insertions(+) create mode 100644 drivers/extcon/extcon-cht-wc.c diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig index 96bbae5..4cace6b 100644 --- a/drivers/extcon/Kconfig +++ b/drivers/extcon/Kconfig @@ -52,6 +52,13 @@ config EXTCON_INTEL_INT3496 This ACPI device is typically found on Intel Baytrail or Cherrytrail based tablets, or other Baytrail / Cherrytrail devices. +config EXTCON_CHT_WC Need to reorder it alpabetically as the following Makefile. The idea is to have the items alphabetically listed in "make menuconfig" and the name of the menu item starts with Intel: If you want to locate it under the EXTCON_INTEL_INT3496, you should change the filename as following style: - extcon-intel-cht-wc.c I want to locate all entry alphabetically. Ok, will fix for v3 +tristate "Intel Cherrytrail Whiskey Cove PMIC extcon driver" +depends on INTEL_SOC_PMIC_CHTWC +help + Say Y here to enable extcon support for charger detection / control + on the Intel Cherrytrail Whiskey Cove PMIC. + config EXTCON_MAX14577 tristate "Maxim MAX14577/77836 EXTCON Support" depends on MFD_MAX14577 diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile index 237ac3f..160f88b 100644 --- a/drivers/extcon/Makefile +++ b/drivers/extcon/Makefile @@ -7,6 +7,7 @@ extcon-core-objs+= extcon.o devres.o obj-$(CONFIG_EXTCON_ADC_JACK)+= extcon-adc-jack.o obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-arizona.o obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o +obj-$(CONFIG_EXTCON_CHT_WC)+= extcon-cht-wc.o obj-$(CONFIG_EXTCON_GPIO)+= extcon-gpio.o obj-$(CONFIG_EXTCON_INTEL_INT3496) += extcon-intel-int3496.o obj-$(CONFIG_EXTCON_MAX14577)+= extcon-max14577.o diff --git a/drivers/extcon/extcon-cht-wc.c b/drivers/extcon/extcon-cht-wc.c new file mode 100644 index 000..896eee6 --- /dev/null +++ b/drivers/extcon/extcon-cht-wc.c @@ -0,0 +1,356 @@ +/* + * Extcon charger detection driver for Intel Cherrytrail Whiskey Cove PMIC + * Copyright (C) 2017 Hans de Goede + * + * Based on various non upstream patches to support the CHT Whiskey Cove PMIC: Maybe, you don't need to add ':' at the end of line. Th ':' is there because the following copyright line: + * Copyright (C) 2013-2015 Intel Corporation. All rights reserved. Comes from those various non upstream patches. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope 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. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define CHT_WC_PWRSRC_IRQ0x6e03 +#define CHT_WC_PWRSRC_IRQ_MASK0x6e0f +#define CHT_WC_PWRSRC_STS0x6e1e +#define CHT_WC_PWRSRC_VBUSBIT(0) +#define CHT_WC_PWRSRC_DCBIT(1) +#define CHT_WC_PWRSRC_BATBIT(2) +#define CHT_WC_PWRSRC_ID_GNDBIT(3) +#define CHT_WC_PWRSRC_ID_FLOATBIT(4) + +#define CHT_WC_PHYCTRL0x5e07 + +#define CHT_WC_CHGRCTRL00x5e16 + +#define CHT_WC_CHGRCTRL00x5e16 +#define CHT_WC_CHGRCTRL0_CHGRRESETBIT(0) +#define CHT_WC_CHGRCTRL0_EMRGCHRENBIT(1) +#define CHT_WC_CHGRCTRL0_EXTCHRDISBIT(2) +#define CHT_WC_CHGRCTRL0_SWCONTROLBIT(3) +#define CHT_WC_CHGRCTRL0_TTLCK_MASKBIT(4) +#define CHT_WC_CHGRCTRL0_CCSM_OFF_MASKBIT(5) +#define CHT_WC_CHGRCTRL0_DBPOFF_MASKBIT(6) +#define CHT_WC_CHGRCTRL0_WDT_NOKICKBIT(7) + +#define CHT_WC_CHGRCTRL10x5e17 + +#define CHT_WC_USBSRC0x5e29 +#define CHT_WC_USBSRC_STS_MASKGENMASK(1, 0) +#define CHT_WC_USBSRC_STS_SUCCESS2 +#define CHT_WC_USBSRC_STS_FAIL3 +#define CHT_WC_USBSRC_TYPE_SHIFT2 +#define CHT_WC_USBSRC_TYPE_MASKGENMASK(5, 2) +#define CHT_WC_USBSRC_TYPE_NONE0 +#define CHT_WC_USBSRC_TYPE_SDP1 +#define CHT_WC_USBSRC_TYPE_DCP2 +#define CHT_WC_USBSRC_TYPE_CDP3 +#define CHT_WC_USBSRC_TYPE_ACA4 +#define CHT_WC_USBSRC_TYPE_SE15 +#define CHT_WC_USBSRC_TYPE_MHL6 +#define CHT_WC_USBSRC_TYPE_FLOAT_DP_DN7 +#define CHT_WC_USBSRC_TYPE_OTHER8 +#define CHT_WC_USBSRC_TYPE_DCP_EXTPH
[PATCH v3 1/7] pinctrl: dt-bindings: Add documentation for Armada 37xx pin controllers
Document the device tree binding for the pin controllers found on the
Armada 37xx SoCs.
Update the binding documention of the xtal clk which is a subnode of this
syscon node.
Signed-off-by: Gregory CLEMENT
---
Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt |
7 +--
Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt |
183 -
2 files changed, 187 insertions(+), 3 deletions(-)
create mode 100644
Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
diff --git a/Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt
b/Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt
index a88f1f05fbd6..4c0807f28cfa 100644
--- a/Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt
+++ b/Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt
@@ -5,6 +5,7 @@ reading the gpio latch register.
This node must be a subnode of the node exposing the register address
of the GPIO block where the gpio latch is located.
+See Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
Required properties:
- compatible : shall be one of the following:
@@ -16,9 +17,9 @@ Optional properties:
output names ("xtal")
Example:
-gpio1: gpio@13800 {
- compatible = "marvell,armada-3700-gpio", "syscon", "simple-mfd";
- reg = <0x13800 0x1000>;
+pinctrl_nb: pinctrl-nb@13800 {
+ compatible = "armada3710-nb-pinctrl", "syscon", "simple-mfd";
+ reg = <0x13800 0x100>, <0x13C00 0x20>;
xtalclk: xtal-clk {
compatible = "marvell,armada-3700-xtal-clock";
diff --git
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
new file mode 100644
index ..2eda81e0bca1
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
@@ -0,0 +1,183 @@
+* Marvell Armada 37xx SoC pin and gpio controller
+
+Each Armada 37xx SoC come with two pin and gpio controller one for the
+south bridge and the other for the north bridge.
+
+Inside this set of register the gpio latch allows exposing some
+configuration of the SoC and especially the clock frequency of the
+xtal. Hence, this node is a represent as syscon allowing sharing the
+register between multiple hardware block.
+
+GPIO and pin controller:
+
+
+Main node:
+
+Refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning
+of the phrase "pin configuration node".
+
+Required properties for pinctrl driver:
+
+- compatible: "marvell,armada3710-sb-pinctrl", "syscon, "simple-mfd"
+ for the south bridge
+ "marvell,armada3710-nb-pinctrl", "syscon, "simple-mfd"
+ for the north bridge
+- reg: The first set of register are for pinctrl/gpio and the second
+ set for the interrupt controller
+- interrupts: list of the interrupt use by the gpio
+
+Available groups and functions for the North bridge:
+
+group: jtag
+ - pins 20-24
+ - functions jtag, gpio
+
+group sdio0
+ - pins 8-10
+ - functions sdio, gpio
+
+group emmc_nb
+ - pins 27-35
+ - functions emmc, gpio
+
+group pwm0
+ - pin 11 (GPIO1-11)
+ - functions pwm, gpio
+
+group pwm1
+ - pin 12
+ - functions pwm, gpio
+
+group pwm2
+ - pin 13
+ - functions pwm, gpio
+
+group pwm3
+ - pin 14
+ - functions pwm, gpio
+
+group pmic1
+ - pin 17
+ - functions pmic, gpio
+
+group pmic0
+ - pin 16
+ - functions pmic, gpio
+
+group i2c2
+ - pins 2-3
+ - functions i2c, gpio
+
+group i2c1
+ - pins 0-1
+ - functions i2c, gpio
+
+group spi_cs1
+ - pin 17
+ - functions spi, gpio
+
+group spi_cs2
+ - pin 18
+ - functions spi, gpio
+
+group spi_cs3
+ - pin 19
+ - functions spi, gpio
+
+group onewire
+ - pin 4
+ - functions onewire, gpio
+
+group uart1
+ - pins 25-26
+ - functions uart, gpio
+
+group spi_quad
+ - pins 15-16
+ - functions spi, gpio
+
+group uart_2
+ - pins 9-10
+ - functions uart, gpio
+
+Available groups and functions for the South bridge:
+
+group usb32_drvvbus0
+ - pin 36
+ - functions drvbus, gpio
+
+group usb2_drvvbus1
+ - pin 37
+ - functions drvbus, gpio
+
+group sdio_sb
+ - pins 60-64
+ - functions sdio, gpio
+
+group rgmii
+ - pins 42-55
+ - functions mii, gpio
+
+group pcie1
+ - pins 39-40
+ - functions pcie, gpio
+
+group ptp
+ - pins 56-58
+ - functions ptp, gpio
+
+group ptp_clk
+ - pin 57
+ - functions ptp, mii
+
+group ptp_trig
+ - pin 58
+ - functions ptp, mii
+
+group mii_col
+ - pin 59
+ - functions mii, mii_err
+
+GPIO subnode:
+
+Please refer to gpio.txt in this directory for details of gpio-ranges property
+and the common GPIO bindings used by client devices.
+
+Required properties for gpio driver under the gpio subnode:
+- interrupts: List of interrupt specifier for the controllers interrupt.
+- gpio-con
Re: [RFC v0 1/2] interconnect: Add generic interconnect controller API
On 03/23/2017 03:21 AM, Michael Turquette wrote:
Hi Georgi,
Quoting Georgi Djakov (2017-03-01 10:22:34)
diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt
b/Documentation/devicetree/bindings/interconnect/interconnect.txt
new file mode 100644
index ..c62d86e4c52d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -0,0 +1,91 @@
+Interconnect Provider Device Tree Bindings
+=
I agree with Rob to skip the DT bindings for now. However I did review
this privately in February and I'll re-post my review comments here for
when the bindings do get discussed at a later date:
Thanks!
+Optional properties:
+interconnect-port : A phandle and interconnect provider specifier as defined by
+ bindings of the interconnect provider specified by phandle.
+ This denotes the port to which the interconnect consumer is
+ wired. It is used when there are multiple interconnect providers
+ that have one or multiple links between them.
Go ahead and remove the interconnect-port property description from the
provider part of the binding. It should be sufficient to say,
"interconnect providers can also be interconnect consumers, such as in
the case where two network-on-chip fabrics interface directly".
Sounds good. Done.
+
+Example:
+
+ snoc: snoc@058 {
+ compatible = "qcom,msm-bus-snoc";
+ reg = <0x58 0x14000>;
+ #interconnect-cells = <1>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_SNOC_CLK>, <&rpmcc
RPM_SMD_SNOC_A_CLK>;
+ status = "okay";
+ interconnect-port = <&bimc MAS_SNOC_CFG>,
+ <&bimc SNOC_BIMC_0_MAS>,
+ <&bimc SNOC_BIMC_1_MAS>,
+ <&pnoc SNOC_PNOC_SLV>;
+ };
+ bimc: bimc@040 {
+ compatible = "qcom,msm-bus-bimc";
+ reg = <0x40 0x62000>;
+ #interconnect-cells = <1>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_BIMC_CLK>, <&rpmcc
RPM_SMD_BIMC_A_CLK>;
+ status = "okay";
+ interconnect-port = <&snoc BIMC_SNOC_MAS>;
+ };
+ pnoc: pnoc@50 {
+ compatible = "qcom,msm-bus-pnoc";
+ reg = <0x50 0x11000>;
+ #interconnect-cells = <1>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_PCNOC_CLK>, <&rpmcc
RPM_SMD_PCNOC_A_CLK>;
+ status = "okay";
+ interconnect-port = <&snoc PNOC_SNOC_SLV>;
+ };
+
+= interconnect consumers =
+
+The interconnect consumers are device nodes which consume the interconnect
+path(s) provided by the interconnect provider. There can be multiple
+interconnect providers on a SoC and the consumer may consume multiple paths
+from different providers depending on usecase and the components it has to
+interact with.
+
+Required-properties:
+interconnect-port : A phandle and interconnect provider specifier as defined by
+ bindings of the interconnect provider specified by phandle.
+ This denotes the port to which the interconnect consumer is
+ wired.
+interconnect-path : List of phandles to the data path endpoints.
More copy/paste from February review:
"Path" means everything between the endpoints (e.g. the details of the
graph traversal), whereas this DT property is really only meant to
defint the target endpoint. Let's rename it to interconnect-target.
When referring to endpoints I think we should some pairing terminology
like: src,dst or local,remote or initiator,target.
So how about:
s/interconnect-port/interconnect-sources/
s/interconnect-path/interconnect-targets/
This keeps things symmetrical and the (source,target) pair just makes
sense. I used plural as well since there can be multiple ports.
It might even make sense to shorten it with: source-ports, target-ports
Agree that the port/path pairs might be confusing. Currently my
favorites are interconnect-src and interconnect-dst.
+interconnect-path-names : List of interconnect path name strings sorted in the
+ same order as the interconnect-path property. Consumers drivers
+ will use interconnect-path-names to match the link names with
+ interconnect specifiers.
Let's not use string names. No reason to copy the clkdev-style of
resource lookups when an integer id will do just fine.
Yes, this is on my TODO list. Anyway for the platform data i will be
us
[PATCH v3 0/7] Add support for pinctrl/gpio on Armada 37xx
Hi, In this third version I finally managed to use gpio-ranges from the device tree. For the record, this series adds support for the pin and gpio controllers present on the Armada 37xx SoCs. Each Armada 37xx SoC comes with 2 pin controllers: one on the south bridge (managing 28 pins) and one on the north bridge (managing 36 pins). At the hardware level the controller configure the pins by group and not pin by pin. The gpio controller is also capable to handle interrupt from gpio. Changelog v2 -> v3 - use gpio-ranges (patch 4) - Document gpio-ranges usage (patch 1) - do not use anymore a global pin index (patch 3) v1 -> v2: - Update binding documentation making clear that mfd and syscon must be used (patch 1). - Split the fist patch adding pin controller support for Armada 37xx in arm64 part (for kconfig) and pinctrl part (patch 2 and 3) - Add MFD_SYSCON dependency (patch 3) - Add kerneldoc for the armada_37xx_pin_group struct (patch 3) - Rename _add_function() to armada_37xx_add_function() (patch 3) - Use an inline function to update the reg offset (patch 4) - Rename gpiolib_register to gpiochip_register (patch 4) - Add a comment about the two registers limit (patch 4) - Add explicit gpio node in the device tree (patch 4) - Convert the driver to use GPIOLIB_IRQCHIP (patch 5) - Add a critical section when accessing the hardware registers (patch 5) - Use the gpio subnode (patch 5) Thanks, Gregory Gregory CLEMENT (7): pinctrl: dt-bindings: Add documentation for Armada 37xx pin controllers arm64: marvell: enable the Armada 37xx pinctrl driver pinctrl: armada-37xx: Add pin controller support for Armada 37xx pinctrl: armada-37xx: Add gpio support pinctrl: aramda-37xx: Add irqchip support ARM64: dts: marvell: Add pinctrl nodes for Armada 3700 ARM64: dts: marvell: armada37xx: add pinctrl definition Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt | 7 +- Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt | 183 ++- arch/arm64/Kconfig.platforms | 2 +- arch/arm64/boot/dts/marvell/armada-3720-db.dts| 8 +- arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 73 +- drivers/pinctrl/Makefile | 2 +- drivers/pinctrl/mvebu/Kconfig | 7 +- drivers/pinctrl/mvebu/Makefile| 3 +- drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 910 - 9 files changed, 1187 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt create mode 100644 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c base-commit: c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201 -- git-series 0.9.1
[PATCH v3 2/7] arm64: marvell: enable the Armada 37xx pinctrl driver
This commit makes sure the driver for the Armada 37xx pin controller is enabled. Signed-off-by: Gregory CLEMENT --- arch/arm64/Kconfig.platforms | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 129cc5ae4091..f2bb1691264f 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -105,6 +105,8 @@ config ARCH_MVEBU select ARMADA_37XX_CLK select MVEBU_ODMI select MVEBU_PIC + select PINCTRL + select PINCTRL_ARMADA_37XX help This enables support for Marvell EBU familly, including: - Armada 3700 SoC Family -- git-series 0.9.1
Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest
On Thu, Mar 23, 2017 at 01:13:50PM +0800, Jason Wang wrote:
> >From 312859b596e83a2164a8430343d31fce2a5ad808 Mon Sep 17 00:00:00 2001
> From: Jason Wang
> Date: Thu, 23 Mar 2017 13:07:16 +0800
> Subject: [PATCH] virtio_pci: fix out of bound access for msix_names
>
> Signed-off-by: Jason Wang
I tested this, and it does appear to fix the crashes in
vp_modern_find_vqs. Therefore:
Tested-by: Richard W.M. Jones
Thanks,
Rich.
> drivers/virtio/virtio_pci_common.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/virtio/virtio_pci_common.c
> b/drivers/virtio/virtio_pci_common.c
> index df548a6..5905349 100644
> --- a/drivers/virtio/virtio_pci_common.c
> +++ b/drivers/virtio/virtio_pci_common.c
> @@ -147,7 +147,7 @@ static int vp_find_vqs_msix(struct virtio_device *vdev,
> unsigned nvqs,
> {
> struct virtio_pci_device *vp_dev = to_vp_device(vdev);
> const char *name = dev_name(&vp_dev->vdev.dev);
> - int i, err = -ENOMEM, allocated_vectors, nvectors;
> + int i, j, err = -ENOMEM, allocated_vectors, nvectors;
> unsigned flags = PCI_IRQ_MSIX;
> bool shared = false;
> u16 msix_vec;
> @@ -212,7 +212,7 @@ static int vp_find_vqs_msix(struct virtio_device *vdev,
> unsigned nvqs,
> if (!vp_dev->msix_vector_map)
> goto out_disable_config_irq;
>
> - allocated_vectors = 1; /* vector 0 is the config interrupt */
> + allocated_vectors = j = 1; /* vector 0 is the config interrupt */
> for (i = 0; i < nvqs; ++i) {
> if (!names[i]) {
> vqs[i] = NULL;
> @@ -236,18 +236,19 @@ static int vp_find_vqs_msix(struct virtio_device *vdev,
> unsigned nvqs,
> continue;
> }
>
> - snprintf(vp_dev->msix_names[i + 1],
> + snprintf(vp_dev->msix_names[j],
>sizeof(*vp_dev->msix_names), "%s-%s",
>dev_name(&vp_dev->vdev.dev), names[i]);
> err = request_irq(pci_irq_vector(vp_dev->pci_dev, msix_vec),
> vring_interrupt, IRQF_SHARED,
> - vp_dev->msix_names[i + 1], vqs[i]);
> + vp_dev->msix_names[j], vqs[i]);
> if (err) {
> /* don't free this irq on error */
> vp_dev->msix_vector_map[i] = VIRTIO_MSI_NO_VECTOR;
> goto out_remove_vqs;
> }
> vp_dev->msix_vector_map[i] = msix_vec;
> + j++;
>
> /*
>* Use a different vector for each queue if they are available,
> --
> 2.7.4
>
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
[PATCH v3 4/7] pinctrl: armada-37xx: Add gpio support
GPIO management is pretty simple and is part of the same IP than the pin
controller for the Armada 37xx SoCs. This patch adds the GPIO support to
the pinctrl-armada-37xx.c file, it also allows sharing common functions
between the gpiolib and the pinctrl drivers.
Signed-off-by: Gregory CLEMENT
---
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 127 ++---
1 file changed, 113 insertions(+), 14 deletions(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
index f2ff9801d0f4..31e921aa2f86 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -10,6 +10,7 @@
* without any warranty of any kind, whether express or implied.
*/
+#include
#include
#include
#include
@@ -24,6 +25,8 @@
#include "../pinctrl-utils.h"
#define OUTPUT_EN 0x0
+#define INPUT_VAL 0x10
+#define OUTPUT_VAL 0x18
#define OUTPUT_CTL 0x20
#define SELECTION 0x30
@@ -73,6 +76,7 @@ struct armada_37xx_pinctrl {
struct regmap *regmap;
struct armada_37xx_pin_data *data;
struct device *dev;
+ struct gpio_chipgpio_chip;
struct pinctrl_desc pctl;
struct pinctrl_dev *pctl_dev;
struct armada_37xx_pin_group*groups;
@@ -310,51 +314,99 @@ static int armada_37xx_pmx_set(struct pinctrl_dev
*pctldev,
return armada_37xx_pmx_set_by_name(pctldev, name, grp);
}
-static int armada_37xx_pmx_direction_input(struct armada_37xx_pinctrl *info,
- unsigned int offset)
+static inline void aramda_37xx_update_reg(unsigned int *reg,
+ unsigned int offset)
{
- unsigned int reg = OUTPUT_EN;
- unsigned int mask;
-
+ /* We never have more than 2 registers */
if (offset >= GPIO_PER_REG) {
offset -= GPIO_PER_REG;
- reg += sizeof(u32);
+ *reg += sizeof(u32);
}
+}
+
+static int armada_37xx_gpio_direction_input(struct gpio_chip *chip,
+ unsigned int offset)
+{
+ struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
+ unsigned int reg = OUTPUT_EN;
+ unsigned int mask;
+
+ aramda_37xx_update_reg(®, offset);
mask = BIT(offset);
return regmap_update_bits(info->regmap, reg, mask, 0);
}
+static int armada_37xx_gpio_get_direction(struct gpio_chip *chip,
+ unsigned int offset)
+{
+ struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
+ unsigned int reg = OUTPUT_EN;
+ unsigned int val, mask;
+
+ aramda_37xx_update_reg(®, offset);
+ mask = BIT(offset);
+
+ regmap_read(info->regmap, reg, &val);
+ return !(val & mask);
+}
-static int armada_37xx_pmx_direction_output(struct armada_37xx_pinctrl *info,
- unsigned int offset, int value)
+static int armada_37xx_gpio_direction_output(struct gpio_chip *chip,
+unsigned int offset, int value)
{
+ struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
unsigned int reg = OUTPUT_EN;
unsigned int mask;
- if (offset >= GPIO_PER_REG) {
- offset -= GPIO_PER_REG;
- reg += sizeof(u32);
- }
+ aramda_37xx_update_reg(®, offset);
mask = BIT(offset);
return regmap_update_bits(info->regmap, reg, mask, mask);
}
+static int armada_37xx_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
+ unsigned int reg = INPUT_VAL;
+ unsigned int val, mask;
+
+ aramda_37xx_update_reg(®, offset);
+ mask = BIT(offset);
+
+ regmap_read(info->regmap, reg, &val);
+
+ return (val & mask) != 0;
+}
+
+static void armada_37xx_gpio_set(struct gpio_chip *chip, unsigned int offset,
+int value)
+{
+ struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
+ unsigned int reg = OUTPUT_VAL;
+ unsigned int mask, val;
+
+ aramda_37xx_update_reg(®, offset);
+ mask = BIT(offset);
+ val = value ? mask : 0;
+
+ regmap_update_bits(info->regmap, reg, mask, val);
+}
+
static int armada_37xx_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned int offset, bool input)
{
struct armada_37xx_pinctrl *info = pinctrl_dev_get_drvdata(pctldev);
+ struct gpio_chip *chip = range->gc;
dev_dbg(info->dev, "gpio_direction for pin %u as %s-%d to %s\n",
offset, range->name, offset, input ? "input" : "output");
if (input)
-
[PATCH v3 3/7] pinctrl: armada-37xx: Add pin controller support for Armada 37xx
The Armada 37xx SoC come with 2 pin controllers: one on the south
bridge (managing 28 pins) and one on the north bridge (managing 36 pins).
At the hardware level the controller configure the pins by group and not
pin by pin. This constraint is reflected in the design of the driver:
only the group related functions are implemented.
Signed-off-by: Gregory CLEMENT
---
drivers/pinctrl/Makefile| 2 +-
drivers/pinctrl/mvebu/Kconfig | 7 +-
drivers/pinctrl/mvebu/Makefile | 3 +-
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 602 +-
4 files changed, 612 insertions(+), 2 deletions(-)
create mode 100644 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index a251f439626f..95080811f36f 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -44,7 +44,7 @@ obj-y += bcm/
obj-$(CONFIG_PINCTRL_BERLIN) += berlin/
obj-y += freescale/
obj-$(CONFIG_X86) += intel/
-obj-$(CONFIG_PINCTRL_MVEBU)+= mvebu/
+obj-y += mvebu/
obj-y += nomadik/
obj-$(CONFIG_PINCTRL_PXA) += pxa/
obj-$(CONFIG_ARCH_QCOM)+= qcom/
diff --git a/drivers/pinctrl/mvebu/Kconfig b/drivers/pinctrl/mvebu/Kconfig
index 170602407c0d..5bade32d3089 100644
--- a/drivers/pinctrl/mvebu/Kconfig
+++ b/drivers/pinctrl/mvebu/Kconfig
@@ -39,3 +39,10 @@ config PINCTRL_ORION
select PINCTRL_MVEBU
endif
+
+config PINCTRL_ARMADA_37XX
+ bool
+ select GENERIC_PINCONF
+ select MFD_SYSCON
+ select PINCONF
+ select PINMUX
diff --git a/drivers/pinctrl/mvebu/Makefile b/drivers/pinctrl/mvebu/Makefile
index 18270cd5ea43..60c245a60f39 100644
--- a/drivers/pinctrl/mvebu/Makefile
+++ b/drivers/pinctrl/mvebu/Makefile
@@ -1,4 +1,4 @@
-obj-y += pinctrl-mvebu.o
+obj-$(CONFIG_PINCTRL_MVEBU)+= pinctrl-mvebu.o
obj-$(CONFIG_PINCTRL_DOVE) += pinctrl-dove.o
obj-$(CONFIG_PINCTRL_KIRKWOOD) += pinctrl-kirkwood.o
obj-$(CONFIG_PINCTRL_ARMADA_370) += pinctrl-armada-370.o
@@ -6,4 +6,5 @@ obj-$(CONFIG_PINCTRL_ARMADA_375) += pinctrl-armada-375.o
obj-$(CONFIG_PINCTRL_ARMADA_38X) += pinctrl-armada-38x.o
obj-$(CONFIG_PINCTRL_ARMADA_39X) += pinctrl-armada-39x.o
obj-$(CONFIG_PINCTRL_ARMADA_XP) += pinctrl-armada-xp.o
+obj-$(CONFIG_PINCTRL_ARMADA_37XX) += pinctrl-armada-37xx.o
obj-$(CONFIG_PINCTRL_ORION) += pinctrl-orion.o
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
new file mode 100644
index ..f2ff9801d0f4
--- /dev/null
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -0,0 +1,602 @@
+/*
+ * Marvell 37xx SoC pinctrl driver
+ *
+ * Copyright (C) 2017 Marvell
+ *
+ * Gregory CLEMENT
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2 or later. This program is licensed "as is"
+ * without any warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../pinctrl-utils.h"
+
+#define OUTPUT_EN 0x0
+#define OUTPUT_CTL 0x20
+#define SELECTION 0x30
+
+#define NB_FUNCS 2
+#define GPIO_PER_REG 32
+
+/**
+ * struct armada_37xx_pin_group: represents group of pins of a pinmux function.
+ * The pins of a pinmux groups are composed of one or two groups of contiguous
+ * pins.
+ * @name: Name of the pin group, used to lookup the group.
+ * @start_pins:Index of the first pin of the main range of pins
belonging to
+ * the group
+ * @npins: Number of pins included in the first range
+ * @reg_mask: Bit mask matching the group in the selection register
+ * @extra_pins:Index of the first pin of the optional second range of
pins
+ * belonging to the group
+ * @npins: Number of pins included in the second optional range
+ * @funcs: A list of pinmux functions that can be selected for this group.
+ * @pins: Total number pins included in the group
+ */
+struct armada_37xx_pin_group {
+ const char *name;
+ unsigned intstart_pin;
+ unsigned intnpins;
+ u32 reg_mask;
+ unsigned intextra_pin;
+ unsigned intextra_npins;
+ const char *funcs[NB_FUNCS];
+ unsigned int*pins;
+};
+
+struct armada_37xx_pin_data {
+ u8 nr_pins;
+ char*name;
+ struct armada_37xx_pin_group*groups;
+ int ngroups;
+};
+
+struct armada_37xx_pmx_func {
+ const char *name;
+ const char **groups;
+ unsigned intngroups;
+};
+
+struct armada_37xx_pinctrl {
+ struct regmap *regmap;
+ struct armada_37xx_pin_data
Re: [PATCH] kasan: avoid -Wmaybe-uninitialized warning
On Thu, Mar 23, 2017 at 4:04 PM, Arnd Bergmann wrote:
> gcc-7 produces this warning:
>
> mm/kasan/report.c: In function 'kasan_report':
> mm/kasan/report.c:351:3: error: 'info.first_bad_addr' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
>print_shadow_for_address(info->first_bad_addr);
>^~
> mm/kasan/report.c:360:27: note: 'info.first_bad_addr' was declared here
>
> The code seems fine as we only print info.first_bad_addr when there is a
> shadow,
> and we always initialize it in that case, but this is relatively hard
> for gcc to figure out after the latest rework. Adding an intialization
> in the other code path gets rid of the warning.
>
> Fixes: b235b9808664 ("kasan: unify report headers")
> Signed-off-by: Arnd Bergmann
> ---
> mm/kasan/report.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 718a10a48a19..63de3069dceb 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -109,6 +109,8 @@ const char *get_wild_bug_type(struct kasan_access_info
> *info)
> {
> const char *bug_type = "unknown-crash";
>
> + info->first_bad_addr = (void *)(-1ul);
> +
> if ((unsigned long)info->access_addr < PAGE_SIZE)
> bug_type = "null-ptr-deref";
> else if ((unsigned long)info->access_addr < TASK_SIZE)
> --
> 2.9.0
>
Acked-by: Dmitry Vyukov
Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")
On Thu, Mar 23, 2017 at 03:56:22PM +0100, Christoph Hellwig wrote:
> Does the patch from Jason in the
>
> "[REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for
> virtqueues") causes crashes in guest"
>
> thread fix the issue for you?
In brief, yes it does. I followed up on that thread.
Thanks,
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
[PATCH v3 7/7] ARM64: dts: marvell: armada37xx: add pinctrl definition
Start to populate the device tree of the Armada 37xx with the pincontrol
configuration used on the board providing a dts.
Signed-off-by: Gregory CLEMENT
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 8 +-
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 31 +++-
2 files changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 86602c907a61..e749c5727490 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -63,6 +63,8 @@
};
&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
status = "okay";
};
@@ -73,6 +75,8 @@
&spi0 {
status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_quad_pins>;
m25p80@0 {
compatible = "jedec,spi-nor";
@@ -103,6 +107,8 @@
/* Exported on the micro USB connector CON32 through an FTDI */
&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
status = "okay";
};
@@ -128,6 +134,8 @@
};
ð0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
phy-mode = "rgmii-id";
phy = <&phy0>;
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index c02b13479458..2ac25f54d01d 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -186,6 +186,31 @@
clock-output-names = "xtal";
#clock-cells = <0>;
};
+
+ spi_quad_pins: spi-quad-pins {
+ groups = "spi_quad";
+ function = "spi";
+ };
+
+ i2c1_pins: i2c1-pins {
+ groups = "i2c1";
+ function = "i2c";
+ };
+
+ i2c2_pins: i2c2-pins {
+ groups = "i2c2";
+ function = "i2c";
+ };
+
+ uart1_pins: uart1-pins {
+ groups = "uart1";
+ function = "uart";
+ };
+
+ uart2_pins: uart2-pins {
+ groups = "uart2";
+ function = "uart";
+ };
};
pinctrl_sb: pinctrl-sb@18800 {
@@ -203,6 +228,12 @@
,
;
};
+
+ rgmii_pins: mii-pins {
+ groups = "rgmii";
+ function = "mii";
+ };
+
};
eth0: ethernet@3 {
--
git-series 0.9.1
[PATCH] x86/syscalls/32: ignore arch_prctl for other architectures
sys_arch_prctl is only provided on x86, and there is no reason
to add it elsewhere. However, including it on the 32-bit syscall
table caused a warning for most configurations on non-x86:
:1328:2: warning: #warning syscall arch_prctl not implemented [-Wcpp]
This adds an exception to the syscall table checking script.
Fixes: 79170fda313e ("x86/syscalls/32: Wire up arch_prctl on x86-32")
Signed-off-by: Arnd Bergmann
---
scripts/checksyscalls.sh | 1 +
1 file changed, 1 insertion(+)
Thomas, can you apply this on top of the x86 patch?
diff --git a/scripts/checksyscalls.sh b/scripts/checksyscalls.sh
index f7ad07128811..0cce56da3706 100755
--- a/scripts/checksyscalls.sh
+++ b/scripts/checksyscalls.sh
@@ -148,6 +148,7 @@ cat << EOF
#define __IGNORE_sysfs
#define __IGNORE_uselib
#define __IGNORE__sysctl
+#define __IGNORE_arch_prctl
/* ... including the "new" 32-bit uid syscalls */
#define __IGNORE_lchown32
--
2.9.0
[PATCH v3 6/7] ARM64: dts: marvell: Add pinctrl nodes for Armada 3700
Add the nodes for the two pin controller present in the Armada 37xx SoCs.
Initially the node was named gpio1 using the same name that for the
register range in the datasheet. However renaming it pinctr_nb (nb for
North Bridge) makes more sens.
Signed-off-by: Gregory CLEMENT
---
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 42 +++--
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index b48d668a6ab6..c02b13479458 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -157,10 +157,29 @@
#clock-cells = <1>;
};
- gpio1: gpio@13800 {
- compatible = "marvell,mvebu-gpio-3700",
+ pinctrl_nb: pinctrl-nb@13800 {
+ compatible = "marvell,armada3710-nb-pinctrl",
"syscon", "simple-mfd";
- reg = <0x13800 0x500>;
+ reg = <0x13800 0x100>, <0x13C00 0x20>;
+ gpionb: gpionb {
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl_nb 0 0 36>;
+ gpio-controller;
+ interrupts =
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ;
+
+ };
xtalclk: xtal-clk {
compatible =
"marvell,armada-3700-xtal-clock";
@@ -169,6 +188,23 @@
};
};
+ pinctrl_sb: pinctrl-sb@18800 {
+ compatible = "marvell,armada3710-sb-pinctrl",
+ "syscon", "simple-mfd";
+ reg = <0x18800 0x100>, <0x18C00 0x20>;
+ gpiosb: gpiosb {
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl_sb 0 0 29>;
+ gpio-controller;
+ interrupts =
+ ,
+ ,
+ ,
+ ,
+ ;
+ };
+ };
+
eth0: ethernet@3 {
compatible = "marvell,armada-3700-neta";
reg = <0x3 0x4000>;
--
git-series 0.9.1
[PATCH v3 5/7] pinctrl: aramda-37xx: Add irqchip support
The Armada 37xx SoCs can handle interrupt through GPIO. However it can
only manage the edge ones.
The way the interrupt are managed are classical so we can use the generic
interrupt chip model.
The only unusual "feature" is that many interrupts are connected to the
parent interrupt controller. But we do not take advantage of this and use
the chained irq with all of them.
Signed-off-by: Gregory CLEMENT
---
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 223 -
1 file changed, 216 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
index 31e921aa2f86..241bb45f3d90 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -13,7 +13,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -30,6 +32,11 @@
#define OUTPUT_CTL 0x20
#define SELECTION 0x30
+#define IRQ_EN 0x0
+#define IRQ_POL0x08
+#define IRQ_STATUS 0x10
+#define IRQ_WKUP 0x18
+
#define NB_FUNCS 2
#define GPIO_PER_REG 32
@@ -74,9 +81,12 @@ struct armada_37xx_pmx_func {
struct armada_37xx_pinctrl {
struct regmap *regmap;
+ void __iomem*base;
struct armada_37xx_pin_data *data;
struct device *dev;
struct gpio_chipgpio_chip;
+ struct irq_chip irq_chip;
+ spinlock_t irq_lock;
struct pinctrl_desc pctl;
struct pinctrl_dev *pctl_dev;
struct armada_37xx_pin_group*groups;
@@ -314,7 +324,7 @@ static int armada_37xx_pmx_set(struct pinctrl_dev *pctldev,
return armada_37xx_pmx_set_by_name(pctldev, name, grp);
}
-static inline void aramda_37xx_update_reg(unsigned int *reg,
+static inline void armada_37xx_update_reg(unsigned int *reg,
unsigned int offset)
{
/* We never have more than 2 registers */
@@ -324,6 +334,14 @@ static inline void aramda_37xx_update_reg(unsigned int
*reg,
}
}
+static inline void armada_37xx_irq_update_reg(unsigned int *reg,
+ struct irq_data *d)
+{
+ int offset = irqd_to_hwirq(d);
+
+ armada_37xx_update_reg(reg, offset);
+}
+
static int armada_37xx_gpio_direction_input(struct gpio_chip *chip,
unsigned int offset)
{
@@ -331,7 +349,7 @@ static int armada_37xx_gpio_direction_input(struct
gpio_chip *chip,
unsigned int reg = OUTPUT_EN;
unsigned int mask;
- aramda_37xx_update_reg(®, offset);
+ armada_37xx_update_reg(®, offset);
mask = BIT(offset);
return regmap_update_bits(info->regmap, reg, mask, 0);
@@ -344,7 +362,7 @@ static int armada_37xx_gpio_get_direction(struct gpio_chip
*chip,
unsigned int reg = OUTPUT_EN;
unsigned int val, mask;
- aramda_37xx_update_reg(®, offset);
+ armada_37xx_update_reg(®, offset);
mask = BIT(offset);
regmap_read(info->regmap, reg, &val);
@@ -359,7 +377,7 @@ static int armada_37xx_gpio_direction_output(struct
gpio_chip *chip,
unsigned int reg = OUTPUT_EN;
unsigned int mask;
- aramda_37xx_update_reg(®, offset);
+ armada_37xx_update_reg(®, offset);
mask = BIT(offset);
return regmap_update_bits(info->regmap, reg, mask, mask);
@@ -371,7 +389,7 @@ static int armada_37xx_gpio_get(struct gpio_chip *chip,
unsigned int offset)
unsigned int reg = INPUT_VAL;
unsigned int val, mask;
- aramda_37xx_update_reg(®, offset);
+ armada_37xx_update_reg(®, offset);
mask = BIT(offset);
regmap_read(info->regmap, reg, &val);
@@ -386,7 +404,7 @@ static void armada_37xx_gpio_set(struct gpio_chip *chip,
unsigned int offset,
unsigned int reg = OUTPUT_VAL;
unsigned int mask, val;
- aramda_37xx_update_reg(®, offset);
+ armada_37xx_update_reg(®, offset);
mask = BIT(offset);
val = value ? mask : 0;
@@ -447,6 +465,194 @@ static const struct gpio_chip armada_37xx_gpiolib_chip = {
.owner = THIS_MODULE,
};
+void armada_37xx_irq_ack(struct irq_data *d)
+{
+ struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
+ struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
+ u32 reg = IRQ_STATUS, mask = d->mask;
+ unsigned long flags;
+
+ armada_37xx_irq_update_reg(®, d);
+ spin_lock_irqsave(&info->irq_lock, flags);
+ writel(mask, info->base + reg);
+ spin_unlock_irqrestore(&info->irq_lock, flags);
+}
+
+void armada_37xx_irq_mask(struct irq_data *d)
+{
+ struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
+ struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
+ u32 val, reg = IRQ_EN, mask
[PATCH] virtio_balloon: prevent uninitialized variable use
The latest gcc-7.0.1 snapshot reports a new warning:
virtio/virtio_balloon.c: In function 'update_balloon_stats':
virtio/virtio_balloon.c:258:26: error: 'events[2]' is used uninitialized in
this function [-Werror=uninitialized]
virtio/virtio_balloon.c:260:26: error: 'events[3]' is used uninitialized in
this function [-Werror=uninitialized]
virtio/virtio_balloon.c:261:56: error: 'events[18]' is used uninitialized in
this function [-Werror=uninitialized]
virtio/virtio_balloon.c:262:56: error: 'events[17]' is used uninitialized in
this function [-Werror=uninitialized]
This seems absolutely right, so we should add an extra check to
prevent copying uninitialized stack data into the statistics.
>From all I can tell, this has been broken since the statistics code
was originally added in 2.6.34.
Fixes: 9564e138b1f6 ("virtio: Add memory statistics reporting to the balloon
driver (V4)")
Signed-off-by: Arnd Bergmann
---
drivers/virtio/virtio_balloon.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 4e1191508228..cd5c54e2003d 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -254,12 +254,14 @@ static void update_balloon_stats(struct virtio_balloon
*vb)
available = si_mem_available();
+#ifdef CONFIG_VM_EVENT_COUNTERS
update_stat(vb, idx++, VIRTIO_BALLOON_S_SWAP_IN,
pages_to_bytes(events[PSWPIN]));
update_stat(vb, idx++, VIRTIO_BALLOON_S_SWAP_OUT,
pages_to_bytes(events[PSWPOUT]));
update_stat(vb, idx++, VIRTIO_BALLOON_S_MAJFLT, events[PGMAJFAULT]);
update_stat(vb, idx++, VIRTIO_BALLOON_S_MINFLT, events[PGFAULT]);
+#endif
update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMFREE,
pages_to_bytes(i.freeram));
update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMTOT,
--
2.9.0
[PATCH] EDAC, pnd2_edac: fix build error without CONFIG_EDAC_DEBUG
Calling into functions inside of the #ifdef causes an obvious compile error:
drivers/edac/pnd2_edac.c: In function 'pnd2_init':
drivers/edac/pnd2_edac.c:1521:2: error: implicit declaration of function
'setup_pnd2_debug'; did you mean 'setup_log_buf'?
[-Werror=implicit-function-declaration]
drivers/edac/pnd2_edac.c: In function 'pnd2_exit':
drivers/edac/pnd2_edac.c:1529:2: error: implicit declaration of function
'teardown_pnd2_debug' [-Werror=implicit-function-declaration]
This removes the #ifdef and instead uses an equivalent IS_ENABLED() check
so the compiler can silently drop the functions but still build-test them
and not need an #ifdef.
Fixes: 5c71ad17f97e ("EDAC, pnd2_edac: Add new EDAC driver for Intel SoC
platforms")
Signed-off-by: Arnd Bergmann
---
drivers/edac/pnd2_edac.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/edac/pnd2_edac.c b/drivers/edac/pnd2_edac.c
index 14d39f05226e..25693a4c14c3 100644
--- a/drivers/edac/pnd2_edac.c
+++ b/drivers/edac/pnd2_edac.c
@@ -1389,7 +1389,6 @@ static struct notifier_block pnd2_mce_dec = {
.notifier_call = pnd2_mce_check_error,
};
-#ifdef CONFIG_EDAC_DEBUG
/*
* Write an address to this file to exercise the address decode
* logic in this driver.
@@ -1435,7 +1434,6 @@ static void teardown_pnd2_debug(void)
{
debugfs_remove_recursive(pnd2_test);
}
-#endif
static int pnd2_probe(void)
{
@@ -1518,7 +1516,8 @@ static int __init pnd2_init(void)
return -ENODEV;
mce_register_decode_chain(&pnd2_mce_dec);
- setup_pnd2_debug();
+ if (IS_ENABLED(CONFIG_EDAC_DEBUG))
+ setup_pnd2_debug();
return 0;
}
@@ -1526,7 +1525,8 @@ static int __init pnd2_init(void)
static void __exit pnd2_exit(void)
{
edac_dbg(2, "\n");
- teardown_pnd2_debug();
+ if (IS_ENABLED(CONFIG_EDAC_DEBUG))
+ teardown_pnd2_debug();
mce_unregister_decode_chain(&pnd2_mce_dec);
pnd2_remove();
}
--
2.9.0
[PATCH] ALSA: au88x0: avoid theoretical uninitialized access
The latest gcc-7.0.1 snapshot points out that we if nr_ch is zero, we never
initialize some variables:
sound/pci/au88x0/au88x0_core.c: In function 'vortex_adb_allocroute':
sound/pci/au88x0/au88x0_core.c:2304:68: error: 'mix[0]' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
sound/pci/au88x0/au88x0_core.c:2305:58: error: 'src[0]' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
I assume this can never happen in practice, but adding a check here doesn't
hurt either and avoids the warning. The code has been unchanged since
the start of git history.
Signed-off-by: Arnd Bergmann
---
sound/pci/au88x0/au88x0_core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/pci/au88x0/au88x0_core.c b/sound/pci/au88x0/au88x0_core.c
index e1af24f87566..c308a4f70550 100644
--- a/sound/pci/au88x0/au88x0_core.c
+++ b/sound/pci/au88x0/au88x0_core.c
@@ -2279,6 +2279,9 @@ vortex_adb_allocroute(vortex_t *vortex, int dma, int
nr_ch, int dir,
} else {
int src[2], mix[2];
+ if (nr_ch < 1)
+ return -EINVAL;
+
/* Get SRC and MIXER hardware resources. */
for (i = 0; i < nr_ch; i++) {
if ((mix[i] =
--
2.9.0
Re: [PATCH v4 1/4] syscalls: Restore address limit after a syscall
Okay well then people are fine with a BUG_ON approach. I will do a next iteration tailored to that. I will also try to add the static inline suggestion from Peter. On Wed, Mar 22, 2017 at 1:54 PM, H. Peter Anvin wrote: > On 03/22/17 13:49, Thomas Garnier wrote: >> >> We can default to BUGging. I think my approach was avoiding doing a >> BUG_ON just to avoid breaking people. >> > > Breaking on a potentially-exploitable bug is a feature. > > -hpa > > -- Thomas
Re: [PATCH 00/23] hisi_sas: error handling and other misc fixes and improvements
John Garry writes: John, > This patchset introduces a range of error handling > and other misc improvements for the HiSilicon SAS > controller, including: > - controller reset function > - softreset for SATA error handling > - fixes for slot free'ing > - v2 hw error handling improvements > - and other misc, more minor stuff Applied to 4.12/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] ARM: dts: at91: add envelope detector mux to the Axentia TSE-850
On 17/03/2017 at 23:24:46 +0100, Peter Rosin wrote: > The envelope detector can analyze 6 different signals, selectable with a > mux controlled by three gpio pins. > > Signed-off-by: Peter Rosin > --- > > Hi! > > This patch makes use of the mux subsystem and a couple of drivers > available in linux-next since a week or two. The stuff this depends > on has relevant acks, specifically on the DT bindings, so the bindings > should be stable and not cause trouble for this patch. Which is why I > thought I'd try to get this in for v4.12-rc1 along with that mux > subsystem series. > > Please consider applying. > > Cheers, > peda > > arch/arm/boot/dts/at91-tse850-3.dts | 29 - > 1 file changed, 28 insertions(+), 1 deletion(-) > Applied, thanks. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[GIT PULL] sound fixes for 4.11-rc4
Linus,
please pull sound fixes for v4.11-rc4 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-4.11-rc4
The topmost commit is 3f307834e695f59dac4337a40316bdecfb9d0508
sound fixes for 4.11-rc4
This contains the collection of small fixes for 4.11 that were pending
during my vacation:
- A few HD-audio quirks (more Dell headset support, docking station
support on HP laptops),
- A regression fix for the previous ctxfi DMA mask fix,
- A correction of the new CONFIG_SND_X86 menu entry, and
- A fix for the races in ALSA sequencer core spotted by syzkaller.
Hui Wang (1):
ALSA: hda - Adding a group of pin definition to fix headset problem
Jaroslav Kysela (2):
ALSA: hda - add support for docking station for HP 820 G2
ALSA: hda - add support for docking station for HP 840 G3
Takashi Iwai (3):
ALSA: ctxfi: Fix the incorrect check of dma_set_mask() call
ALSA: x86: Make CONFIG_SND_X86 bool
ALSA: seq: Fix racy cell insertions during snd_seq_pool_done()
---
sound/core/seq/seq_clientmgr.c | 1 +
sound/core/seq/seq_fifo.c | 3 +++
sound/core/seq/seq_memory.c| 17 +
sound/core/seq/seq_memory.h| 1 +
sound/pci/ctxfi/cthw20k1.c | 2 +-
sound/pci/hda/patch_conexant.c | 11 +++
sound/pci/hda/patch_realtek.c | 16 +++-
sound/x86/Kconfig | 3 ++-
8 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
index 4c935202ce23..f3b1d7f50b81 100644
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -1832,6 +1832,7 @@ static int snd_seq_ioctl_set_client_pool(struct
snd_seq_client *client,
info->output_pool != client->pool->size)) {
if (snd_seq_write_pool_allocated(client)) {
/* remove all existing cells */
+ snd_seq_pool_mark_closing(client->pool);
snd_seq_queue_client_leave_cells(client->number);
snd_seq_pool_done(client->pool);
}
diff --git a/sound/core/seq/seq_fifo.c b/sound/core/seq/seq_fifo.c
index 448efd4e980e..33980d1c8037 100644
--- a/sound/core/seq/seq_fifo.c
+++ b/sound/core/seq/seq_fifo.c
@@ -72,6 +72,9 @@ void snd_seq_fifo_delete(struct snd_seq_fifo **fifo)
return;
*fifo = NULL;
+ if (f->pool)
+ snd_seq_pool_mark_closing(f->pool);
+
snd_seq_fifo_clear(f);
/* wake up clients if any */
diff --git a/sound/core/seq/seq_memory.c b/sound/core/seq/seq_memory.c
index 1a1acf3ddda4..d4c61ec9be13 100644
--- a/sound/core/seq/seq_memory.c
+++ b/sound/core/seq/seq_memory.c
@@ -415,6 +415,18 @@ int snd_seq_pool_init(struct snd_seq_pool *pool)
return 0;
}
+/* refuse the further insertion to the pool */
+void snd_seq_pool_mark_closing(struct snd_seq_pool *pool)
+{
+ unsigned long flags;
+
+ if (snd_BUG_ON(!pool))
+ return;
+ spin_lock_irqsave(&pool->lock, flags);
+ pool->closing = 1;
+ spin_unlock_irqrestore(&pool->lock, flags);
+}
+
/* remove events */
int snd_seq_pool_done(struct snd_seq_pool *pool)
{
@@ -425,10 +437,6 @@ int snd_seq_pool_done(struct snd_seq_pool *pool)
return -EINVAL;
/* wait for closing all threads */
- spin_lock_irqsave(&pool->lock, flags);
- pool->closing = 1;
- spin_unlock_irqrestore(&pool->lock, flags);
-
if (waitqueue_active(&pool->output_sleep))
wake_up(&pool->output_sleep);
@@ -485,6 +493,7 @@ int snd_seq_pool_delete(struct snd_seq_pool **ppool)
*ppool = NULL;
if (pool == NULL)
return 0;
+ snd_seq_pool_mark_closing(pool);
snd_seq_pool_done(pool);
kfree(pool);
return 0;
diff --git a/sound/core/seq/seq_memory.h b/sound/core/seq/seq_memory.h
index 4a2ec779b8a7..32f959c17786 100644
--- a/sound/core/seq/seq_memory.h
+++ b/sound/core/seq/seq_memory.h
@@ -84,6 +84,7 @@ static inline int snd_seq_total_cells(struct snd_seq_pool
*pool)
int snd_seq_pool_init(struct snd_seq_pool *pool);
/* done pool - free events */
+void snd_seq_pool_mark_closing(struct snd_seq_pool *pool);
int snd_seq_pool_done(struct snd_seq_pool *pool);
/* create pool */
diff --git a/sound/pci/ctxfi/cthw20k1.c b/sound/pci/ctxfi/cthw20k1.c
index ab4cdab5cfa5..79edd88d5cd0 100644
--- a/sound/pci/ctxfi/cthw20k1.c
+++ b/sound/pci/ctxfi/cthw20k1.c
@@ -1905,7 +1905,7 @@ static int hw_card_start(struct hw *hw)
return err;
/* Set DMA transfer mask */
- if (dma_set_mask(&pci->dev, DMA_BIT_MASK(dma_bits))) {
+ if (!dma_set_mask(&pci->dev, DMA_BIT_MASK(dma_bits))) {
dma_set_coherent_mask(&pci->dev, DMA_BIT_MASK(dma_bits));
} else {
[GIT PULL] Btrfs
Hi Linus We have a small set of fixes for the next RC: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.11 Zygo tracked down a very old bug with inline compressed extents. I didn't tag this one for stable because I want to do individual tested backports. It's a little tricky and I'd rather do some extra testing on it along the way. Otherwise they are pretty obvious: Liu Bo (1) commits (+2/-1): Btrfs: fix regression in lock_delalloc_pages Dmitry V. Levin (1) commits (+0/-27): btrfs: remove btrfs_err_str function from uapi/linux/btrfs.h Zygo Blaxell (1) commits (+14/-0): btrfs: add missing memset while reading compressed inline extents Total: (3) commits (+16/-28) fs/btrfs/extent_io.c | 3 ++- fs/btrfs/inode.c | 14 ++ include/uapi/linux/btrfs.h | 27 --- 3 files changed, 16 insertions(+), 28 deletions(-)
Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")
Hi Christoph! Hi Michael!
(Mail roughly based on text from
https://bugzilla.kernel.org/show_bug.cgi?id=194911 )
I'm seeing random crashes during boot every few boot attempts when
running Linux 4.11-rc/mainline in a Fedora 26 guest under a CentOS7 host
(CPU: Intel(R) Pentium(R) CPU G3220) using KVM. Sometimes when the guest
actually booted the network did not work. To get some impressions of the
crashes I got see this gallery:
https://plus.google.com/+ThorstenLeemhuis/posts/FjyyGjNtrrG
Richard W.M. Jones and Adam Williamson see the same problems. See above
bug for details. It seems they ran into the problem in the past few
days, so I assume it's still present in mainline (I'm travelling
currently and haven't had time for proper tests since last last Friday
(pre-rc3); but I thought it's time to get the problem to the lists).
Long story short: Richard and I did bisections and we both found that
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=07ec51480b5e
("virtio_pci: use shared interrupts for virtqueues") is the first bad
commit. Any idea what might be wrong? Do you need more details from us
to fix this?
Ciao, Thorsten
P.S.: Sorry, I should have written this mail a few days ago after filing
above bug report, but I didn't get around to it :-/
[PATCH -v3 6/8] sched,tracing: Update trace_sched_pi_setprio()
Pass the PI donor task, instead of a numerical priority.
Numerical priorities are not sufficient to describe state ever since
SCHED_DEADLINE.
Annotate all sched tracepoints that are currently broken; fixing them
will bork userspace. *hate*.
Reviewed-by: Steven Rostedt
Signed-off-by: Peter Zijlstra (Intel)
---
include/trace/events/sched.h | 16 +---
kernel/sched/core.c |2 +-
2 files changed, 10 insertions(+), 8 deletions(-)
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -70,7 +70,7 @@ DECLARE_EVENT_CLASS(sched_wakeup_templat
TP_fast_assign(
memcpy(__entry->comm, p->comm, TASK_COMM_LEN);
__entry->pid= p->pid;
- __entry->prio = p->prio;
+ __entry->prio = p->prio; /* XXX SCHED_DEADLINE */
__entry->success= 1; /* rudiment, kill when possible */
__entry->target_cpu = task_cpu(p);
),
@@ -147,6 +147,7 @@ TRACE_EVENT(sched_switch,
memcpy(__entry->prev_comm, prev->comm, TASK_COMM_LEN);
__entry->next_pid = next->pid;
__entry->next_prio = next->prio;
+ /* XXX SCHED_DEADLINE */
),
TP_printk("prev_comm=%s prev_pid=%d prev_prio=%d prev_state=%s%s ==>
next_comm=%s next_pid=%d next_prio=%d",
@@ -181,7 +182,7 @@ TRACE_EVENT(sched_migrate_task,
TP_fast_assign(
memcpy(__entry->comm, p->comm, TASK_COMM_LEN);
__entry->pid= p->pid;
- __entry->prio = p->prio;
+ __entry->prio = p->prio; /* XXX SCHED_DEADLINE */
__entry->orig_cpu = task_cpu(p);
__entry->dest_cpu = dest_cpu;
),
@@ -206,7 +207,7 @@ DECLARE_EVENT_CLASS(sched_process_templa
TP_fast_assign(
memcpy(__entry->comm, p->comm, TASK_COMM_LEN);
__entry->pid= p->pid;
- __entry->prio = p->prio;
+ __entry->prio = p->prio; /* XXX SCHED_DEADLINE */
),
TP_printk("comm=%s pid=%d prio=%d",
@@ -253,7 +254,7 @@ TRACE_EVENT(sched_process_wait,
TP_fast_assign(
memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
__entry->pid= pid_nr(pid);
- __entry->prio = current->prio;
+ __entry->prio = current->prio; /* XXX SCHED_DEADLINE
*/
),
TP_printk("comm=%s pid=%d prio=%d",
@@ -413,9 +414,9 @@ DEFINE_EVENT(sched_stat_runtime, sched_s
*/
TRACE_EVENT(sched_pi_setprio,
- TP_PROTO(struct task_struct *tsk, int newprio),
+ TP_PROTO(struct task_struct *tsk, struct task_struct *pi_task),
- TP_ARGS(tsk, newprio),
+ TP_ARGS(tsk, pi_task),
TP_STRUCT__entry(
__array( char, comm, TASK_COMM_LEN )
@@ -428,7 +429,8 @@ TRACE_EVENT(sched_pi_setprio,
memcpy(__entry->comm, tsk->comm, TASK_COMM_LEN);
__entry->pid= tsk->pid;
__entry->oldprio= tsk->prio;
- __entry->newprio= newprio;
+ __entry->newprio= pi_task ? pi_task->prio : tsk->prio;
+ /* XXX SCHED_DEADLINE bits missing */
),
TP_printk("comm=%s pid=%d oldprio=%d newprio=%d",
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3634,7 +3634,7 @@ void rt_mutex_setprio(struct task_struct
goto out_unlock;
}
- trace_sched_pi_setprio(p, prio); /* broken */
+ trace_sched_pi_setprio(p, pi_task);
oldprio = p->prio;
if (oldprio == prio)
Re: [PATCH] x86/boot: Support uncompressed kernel
On Thu, Mar 23, 2017 at 5:51 AM, Chao Peng wrote: > Compressed kernel has its own drawback: uncompressing takes time. Even > though the time is short enough to ignore for most cases but for cases that > time is critical this is still a big number. In our on-going optimization > for kernel boot time, the measured overall kernel boot time is ~90ms while > the uncompressing takes ~50ms with gzip. > > The patch adds a 'CONFIG_KERNEL_RAW' configure choice so the built binary > can have no uncompressing at all. The experiment shows: > > kernel kernel sizetime in decompress_kernel > compressed (gzip)3.3M 53ms > uncompressed 14M3ms How about the time difference for bootloader to read kernel from flash/disk/network to ram? Thanks Yinghai
Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")
On 23.03.2017 15:56, Christoph Hellwig wrote:
> Does the patch from Jason in the
> "[REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for
> virtqueues") causes crashes in guest"
> thread fix the issue for you?
Ha, sorry, I'm travelling and wasn't aware that Laura earlier today did
what I should have done a few days ago: bring the issue to the proper
mailing lists.
I'll give the patch a try. Thx for pointing it out and sorry for the
noise. Ciao, Thorsten
Re: [PATCH] arm/arm64: KVM: send SIGBUS error to qemu
Hi Dongjiu Geng,
On 23/03/17 13:01, Dongjiu Geng wrote:
> when the pfn is KVM_PFN_ERR_HWPOISON, it indicates to send
> SIGBUS signal from KVM's fault-handling code to qemu, qemu
> can handle this signal according to the fault address.
I'm afraid I beat you to it on this one:
https://www.spinics.net/lists/arm-kernel/msg568919.html
(Are you the same gengdj who ask me to post that patch?:
https://lkml.org/lkml/2017/3/5/187 )
We don't need upstream KVM to do this until either arm or arm64 has
ARCH_SUPPORTS_MEMORY_FAILURE. Punit and Tyler have discovered problems with the
way arm64's hugepage and hwpoison interact:
https://www.spinics.net/lists/arm-kernel/msg568995.html
Some comments on the differences:
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 962616fd4ddd..1307ec400de3 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -1237,6 +1237,20 @@ static void coherent_cache_guest_page(struct kvm_vcpu
> *vcpu, kvm_pfn_t pfn,
> __coherent_cache_guest_page(vcpu, pfn, size);
> }
>
> +static void kvm_send_hwpoison_signal(unsigned long address,
> + struct task_struct *tsk)
> +{
> + siginfo_t info;
> +
> + info.si_signo = SIGBUS;
> + info.si_errno = 0;
> + info.si_code= BUS_MCEERR_AR;
> + info.si_addr= (void __user *)address;
> + info.si_addr_lsb = PAGE_SHIFT;
Any version of this patch should handle hugepage for the sizes KVM uses in its
stage2 mappings. By just passing PAGE_SHIFT you let the guest fault for each
page that makes up the hugepage.
> +
> + send_sig_info(SIGBUS, &info, tsk);
> +}
> +
> static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> struct kvm_memory_slot *memslot, unsigned long hva,
> unsigned long fault_status)
> @@ -1309,6 +1323,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
> phys_addr_t fault_ipa,
> if (is_error_noslot_pfn(pfn))
> return -EFAULT;
>
> + if (is_error_hwpoison_pfn(pfn)) {
> + kvm_send_hwpoison_signal(kvm_vcpu_gfn_to_hva(vcpu, gfn),
> + current);
> + return -EFAULT;
This will return -EFAULT from the KVM_RUN ioctl(). Is Qemu expected to know it
should try again? This is indistinguishable from the is_error_noslot_pfn() error
above.
x86 returns 0 from this path, kvm_handle_bad_page() in arch/x86/kvm/mmu.c as the
SIGBUS should arrive first. If the SIGBUS is handled the error has been resolved
and Qemu can call KVM_RUN again. Returning an error and sending SIGBUS suggests
there are two problems.
> + }
> +
> if (kvm_is_device_pfn(pfn)) {
> mem_type = PAGE_S2_DEVICE;
> flags |= KVM_S2PTE_FLAG_IS_IOMAP;
Thanks,
James
[PATCH] reiserfs: avoid a -Wmaybe-uninitialized warning
The latest gcc-7.0.1 snapshot warns about an unintialized variable use: In file included from fs/reiserfs/lbalance.c:8:0: fs/reiserfs/lbalance.c: In function 'leaf_item_bottle.isra.3': fs/reiserfs/reiserfs.h:1279:13: error: '*((void *)&n_ih+8).v' may be used uninitialized in this function [-Werror=maybe-uninitialized] v2->v = (v2->v & cpu_to_le64(15ULL << 60)) | cpu_to_le64(offset); ~~^~~ fs/reiserfs/reiserfs.h:1279:13: error: '*((void *)&n_ih+8).v' may be used uninitialized in this function [-Werror=maybe-uninitialized] v2->v = (v2->v & cpu_to_le64(15ULL << 60)) | cpu_to_le64(offset); This happens because the offset/type pair that is stored in ih.key.u.k_offset_v2 is actually uninitialized when we call set_le_ih_k_offset() and set_le_ih_k_type(). After we have called both, all data is correct, but the first of the two reads uninitialized data for the type field and writes it back before it gets overwritten. This works around the warning by initializing the k_offset_v2 through the slightly larger memcpy(). Signed-off-by: Arnd Bergmann --- fs/reiserfs/lbalance.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/reiserfs/lbalance.c b/fs/reiserfs/lbalance.c index 249594a821e0..8eed8f5f6881 100644 --- a/fs/reiserfs/lbalance.c +++ b/fs/reiserfs/lbalance.c @@ -475,7 +475,7 @@ static void leaf_item_bottle(struct buffer_info *dest_bi, * 'cpy_bytes'; create new item header; * n_ih = new item_header; */ - memcpy(&n_ih, ih, SHORT_KEY_SIZE); + memcpy(&n_ih, ih, KEY_SIZE); /* Endian safe, both le */ n_ih.ih_version = ih->ih_version; -- 2.9.0
[PATCH -v3 2/8] sched/rtmutex/deadline: Fix a PI crash for deadline tasks
From: Xunlei Pang
A crash happened while I was playing with deadline PI rtmutex.
BUG: unable to handle kernel NULL pointer dereference at 0018
IP: [] rt_mutex_get_top_task+0x1f/0x30
PGD 232a75067 PUD 230947067 PMD 0
Oops: [#1] SMP
CPU: 1 PID: 10994 Comm: a.out Not tainted
Call Trace:
[] enqueue_task+0x2c/0x80
[] activate_task+0x23/0x30
[] pull_dl_task+0x1d5/0x260
[] pre_schedule_dl+0x16/0x20
[] __schedule+0xd3/0x900
[] schedule+0x29/0x70
[] __rt_mutex_slowlock+0x4b/0xc0
[] rt_mutex_slowlock+0xd1/0x190
[] rt_mutex_timed_lock+0x53/0x60
[] futex_lock_pi.isra.18+0x28c/0x390
[] do_futex+0x190/0x5b0
[] SyS_futex+0x80/0x180
This is because rt_mutex_enqueue_pi() and rt_mutex_dequeue_pi()
are only protected by pi_lock when operating pi waiters, while
rt_mutex_get_top_task(), will access them with rq lock held but
not holding pi_lock.
In order to tackle it, we introduce new "pi_top_task" pointer
cached in task_struct, and add new rt_mutex_update_top_task()
to update its value, it can be called by rt_mutex_setprio()
which held both owner's pi_lock and rq lock. Thus "pi_top_task"
can be safely accessed by enqueue_task_dl() under rq lock.
Originally-From: Peter Zijlstra
Cc: Ingo Molnar
Cc: Juri Lelli
Acked-by: Steven Rostedt
Reviewed-by: Thomas Gleixner
Signed-off-by: Xunlei Pang
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/init_task.h |1 +
include/linux/sched.h |2 ++
include/linux/sched/rt.h |1 +
kernel/fork.c |1 +
kernel/locking/rtmutex.c | 29 +
kernel/sched/core.c |2 ++
6 files changed, 28 insertions(+), 8 deletions(-)
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -181,6 +181,7 @@ extern struct cred init_cred;
#ifdef CONFIG_RT_MUTEXES
# define INIT_RT_MUTEXES(tsk) \
.pi_waiters = RB_ROOT, \
+ .pi_top_task = NULL,\
.pi_waiters_leftmost = NULL,
#else
# define INIT_RT_MUTEXES(tsk)
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -775,6 +775,8 @@ struct task_struct {
/* PI waiters blocked on a rt_mutex held by this task: */
struct rb_root pi_waiters;
struct rb_node *pi_waiters_leftmost;
+ /* Updated under owner's pi_lock and rq lock */
+ struct task_struct *pi_top_task;
/* Deadlock detection and priority inheritance handling: */
struct rt_mutex_waiter *pi_blocked_on;
#endif
--- a/include/linux/sched/rt.h
+++ b/include/linux/sched/rt.h
@@ -21,6 +21,7 @@ static inline int rt_task(struct task_st
extern int rt_mutex_getprio(struct task_struct *p);
extern void rt_mutex_setprio(struct task_struct *p, int prio);
extern int rt_mutex_get_effective_prio(struct task_struct *task, int newprio);
+extern void rt_mutex_update_top_task(struct task_struct *p);
extern struct task_struct *rt_mutex_get_top_task(struct task_struct *task);
extern void rt_mutex_adjust_pi(struct task_struct *p);
static inline bool tsk_is_pi_blocked(struct task_struct *tsk)
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1438,6 +1438,7 @@ static void rt_mutex_init_task(struct ta
#ifdef CONFIG_RT_MUTEXES
p->pi_waiters = RB_ROOT;
p->pi_waiters_leftmost = NULL;
+ p->pi_top_task = NULL;
p->pi_blocked_on = NULL;
#endif
}
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -323,6 +323,19 @@ rt_mutex_dequeue_pi(struct task_struct *
}
/*
+ * Must hold both p->pi_lock and task_rq(p)->lock.
+ */
+void rt_mutex_update_top_task(struct task_struct *p)
+{
+ if (!task_has_pi_waiters(p)) {
+ p->pi_top_task = NULL;
+ return;
+ }
+
+ p->pi_top_task = task_top_pi_waiter(p)->task;
+}
+
+/*
* Calculate task priority from the waiter tree priority
*
* Return task->normal_prio when the waiter tree is empty or when
@@ -337,12 +350,12 @@ int rt_mutex_getprio(struct task_struct
task->normal_prio);
}
+/*
+ * Must hold either p->pi_lock or task_rq(p)->lock.
+ */
struct task_struct *rt_mutex_get_top_task(struct task_struct *task)
{
- if (likely(!task_has_pi_waiters(task)))
- return NULL;
-
- return task_top_pi_waiter(task)->task;
+ return task->pi_top_task;
}
/*
@@ -351,12 +364,12 @@ struct task_struct *rt_mutex_get_top_tas
*/
int rt_mutex_get_effective_prio(struct task_struct *task, int newprio)
{
- if (!task_has_pi_waiters(task))
+ struct task_struct *top_task = rt_mutex_get_top_task(task);
+
+ if (!top_task)
return newprio;
- if (task_top_pi_waiter(task)->task->prio <= newprio)
- return task_top_pi_waiter(task)->task->prio;
- return newprio;
+ return min(top_task->prio, newpri
[PATCH -v3 0/8] PI vs SCHED_DEADLINE fixes
Now that this pesky little problem with futexes is (hopefully) dealt with; https://lkml.kernel.org/r/20170322103547.756091...@infradead.org We can get on with fixing the actual bug this all started out with. These patches, started by Xunlei Pang, rework the PI infrastructure a bit fixing various problems it has, most notable a NULL deref in SCHED_DEADLINE. Once this is sorted; we can look at improving the tracing thing (Daniel Bristot and Julien Desfossez were working on that) and have a better foundation to look at bandwidth inheritance (Juri and co.).
[PATCH -v3 1/8] rtmutex: Deboost before waking up the top waiter
From: Xunlei Pang
We should deboost before waking the high-priority task, such that we
don't run two tasks with the same "state" (priority, deadline,
sched_class, etc).
In order to make sure the boosting task doesn't start running between
unlock and deboost (due to 'spurious' wakeup), we move the deboost
under the wait_lock, that way its serialized against the wait loop in
__rt_mutex_slowlock().
Doing the deboost early can however lead to priority-inversion if
current would get preempted after the deboost but before waking our
high-prio task, hence we disable preemption before doing deboost, and
enabling it after the wake up is over.
This gets us the right semantic order, but most importantly however;
this change ensures pointer stability for the next patch, where we
have rt_mutex_setprio() cache a pointer to the top-most waiter task.
If we, as before this change, do the wakeup first and then deboost,
this pointer might point into thin air.
[peterz: Changelog + patch munging]
Cc: Ingo Molnar
Cc: Juri Lelli
Acked-by: Steven Rostedt
Suggested-by: Peter Zijlstra
Signed-off-by: Xunlei Pang
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/futex.c |5 ---
kernel/locking/rtmutex.c| 59 +---
kernel/locking/rtmutex_common.h |2 -
3 files changed, 34 insertions(+), 32 deletions(-)
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1465,10 +1465,7 @@ static int wake_futex_pi(u32 __user *uad
out_unlock:
raw_spin_unlock_irq(&pi_state->pi_mutex.wait_lock);
- if (deboost) {
- wake_up_q(&wake_q);
- rt_mutex_adjust_prio(current);
- }
+ rt_mutex_postunlock(&wake_q, deboost);
return ret;
}
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -307,24 +307,6 @@ static void __rt_mutex_adjust_prio(struc
}
/*
- * Adjust task priority (undo boosting). Called from the exit path of
- * rt_mutex_slowunlock() and rt_mutex_slowlock().
- *
- * (Note: We do this outside of the protection of lock->wait_lock to
- * allow the lock to be taken while or before we readjust the priority
- * of task. We do not use the spin_xx_mutex() variants here as we are
- * outside of the debug path.)
- */
-void rt_mutex_adjust_prio(struct task_struct *task)
-{
- unsigned long flags;
-
- raw_spin_lock_irqsave(&task->pi_lock, flags);
- __rt_mutex_adjust_prio(task);
- raw_spin_unlock_irqrestore(&task->pi_lock, flags);
-}
-
-/*
* Deadlock detection is conditional:
*
* If CONFIG_DEBUG_RT_MUTEXES=n, deadlock detection is only conducted
@@ -985,6 +967,7 @@ static void mark_wakeup_next_waiter(stru
* lock->wait_lock.
*/
rt_mutex_dequeue_pi(current, waiter);
+ __rt_mutex_adjust_prio(current);
/*
* As we are waking up the top waiter, and the waiter stays
@@ -1321,6 +1304,16 @@ static bool __sched rt_mutex_slowunlock(
*/
mark_wakeup_next_waiter(wake_q, lock);
+ /*
+* We should deboost before waking the top waiter task such that
+* we don't run two tasks with the 'same' priority. This however
+* can lead to prio-inversion if we would get preempted after
+* the deboost but before waking our high-prio task, hence the
+* preempt_disable before unlock. Pairs with preempt_enable() in
+* rt_mutex_postunlock();
+*/
+ preempt_disable();
+
raw_spin_unlock_irqrestore(&lock->wait_lock, flags);
/* check PI boosting */
@@ -1370,6 +1363,18 @@ rt_mutex_fasttrylock(struct rt_mutex *lo
return slowfn(lock);
}
+/*
+ * Undo pi boosting (if necessary) and wake top waiter.
+ */
+void rt_mutex_postunlock(struct wake_q_head *wake_q, bool deboost)
+{
+ wake_up_q(wake_q);
+
+ /* Pairs with preempt_disable() in rt_mutex_slowunlock() */
+ if (deboost)
+ preempt_enable();
+}
+
static inline void
rt_mutex_fastunlock(struct rt_mutex *lock,
bool (*slowfn)(struct rt_mutex *lock,
@@ -1383,11 +1388,7 @@ rt_mutex_fastunlock(struct rt_mutex *loc
deboost = slowfn(lock, &wake_q);
- wake_up_q(&wake_q);
-
- /* Undo pi boosting if necessary: */
- if (deboost)
- rt_mutex_adjust_prio(current);
+ rt_mutex_postunlock(&wake_q, deboost);
}
/**
@@ -1513,6 +1514,13 @@ bool __sched __rt_mutex_futex_unlock(str
}
mark_wakeup_next_waiter(wake_q, lock);
+ /*
+* We've already deboosted, retain preempt_disabled when dropping
+* the wait_lock to avoid inversion until the wakeup. Matched
+* by rt_mutex_postunlock();
+*/
+ preempt_disable();
+
return true; /* deboost and wakeups */
}
@@ -1525,10 +1533,7 @@ void __sched rt_mutex_futex_unlock(struc
deboost = __rt_mutex_futex_unlock(lock, &wake_q);
raw_spin_unlock_irq(&lock->wait_lock);
- if (deboost) {
- wake_u
[PATCH -v3 4/8] rtmutex: Clean up
Previous patches changed the meaning of the return value of
rt_mutex_slowunlock(); update comments and code to reflect this.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/futex.c |7 ---
kernel/locking/rtmutex.c| 28 +---
kernel/locking/rtmutex_common.h |2 +-
3 files changed, 18 insertions(+), 19 deletions(-)
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1394,7 +1394,7 @@ static int wake_futex_pi(u32 __user *uad
{
u32 uninitialized_var(curval), newval;
struct task_struct *new_owner;
- bool deboost = false;
+ bool postunlock = false;
DEFINE_WAKE_Q(wake_q);
int ret = 0;
@@ -1455,12 +1455,13 @@ static int wake_futex_pi(u32 __user *uad
/*
* We've updated the uservalue, this unlock cannot fail.
*/
- deboost = __rt_mutex_futex_unlock(&pi_state->pi_mutex, &wake_q);
+ postunlock = __rt_mutex_futex_unlock(&pi_state->pi_mutex, &wake_q);
out_unlock:
raw_spin_unlock_irq(&pi_state->pi_mutex.wait_lock);
- rt_mutex_postunlock(&wake_q, deboost);
+ if (postunlock)
+ rt_mutex_postunlock(&wake_q);
return ret;
}
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1330,7 +1330,8 @@ static inline int rt_mutex_slowtrylock(s
/*
* Slow path to release a rt-mutex.
- * Return whether the current task needs to undo a potential priority boosting.
+ *
+ * Return whether the current task needs to call rt_mutex_postunlock().
*/
static bool __sched rt_mutex_slowunlock(struct rt_mutex *lock,
struct wake_q_head *wake_q)
@@ -1401,8 +1402,7 @@ static bool __sched rt_mutex_slowunlock(
raw_spin_unlock_irqrestore(&lock->wait_lock, flags);
- /* check PI boosting */
- return true;
+ return true; /* call rt_mutex_postunlock() */
}
/*
@@ -1449,15 +1449,14 @@ rt_mutex_fasttrylock(struct rt_mutex *lo
}
/*
- * Undo pi boosting (if necessary) and wake top waiter.
+ * Performs the wakeup of the the top-waiter and re-enables preemption.
*/
-void rt_mutex_postunlock(struct wake_q_head *wake_q, bool deboost)
+void rt_mutex_postunlock(struct wake_q_head *wake_q)
{
wake_up_q(wake_q);
/* Pairs with preempt_disable() in rt_mutex_slowunlock() */
- if (deboost)
- preempt_enable();
+ preempt_enable();
}
static inline void
@@ -1466,14 +1465,12 @@ rt_mutex_fastunlock(struct rt_mutex *loc
struct wake_q_head *wqh))
{
DEFINE_WAKE_Q(wake_q);
- bool deboost;
if (likely(rt_mutex_cmpxchg_release(lock, current, NULL)))
return;
- deboost = slowfn(lock, &wake_q);
-
- rt_mutex_postunlock(&wake_q, deboost);
+ if (slowfn(lock, &wake_q))
+ rt_mutex_postunlock(&wake_q);
}
/**
@@ -1593,19 +1590,20 @@ bool __sched __rt_mutex_futex_unlock(str
*/
preempt_disable();
- return true; /* deboost and wakeups */
+ return true; /* call postunlock() */
}
void __sched rt_mutex_futex_unlock(struct rt_mutex *lock)
{
DEFINE_WAKE_Q(wake_q);
- bool deboost;
+ bool postunlock;
raw_spin_lock_irq(&lock->wait_lock);
- deboost = __rt_mutex_futex_unlock(lock, &wake_q);
+ postunlock = __rt_mutex_futex_unlock(lock, &wake_q);
raw_spin_unlock_irq(&lock->wait_lock);
- rt_mutex_postunlock(&wake_q, deboost);
+ if (postunlock)
+ rt_mutex_postunlock(&wake_q);
}
/**
--- a/kernel/locking/rtmutex_common.h
+++ b/kernel/locking/rtmutex_common.h
@@ -122,7 +122,7 @@ extern void rt_mutex_futex_unlock(struct
extern bool __rt_mutex_futex_unlock(struct rt_mutex *lock,
struct wake_q_head *wqh);
-extern void rt_mutex_postunlock(struct wake_q_head *wake_q, bool deboost);
+extern void rt_mutex_postunlock(struct wake_q_head *wake_q);
#ifdef CONFIG_DEBUG_RT_MUTEXES
# include "rtmutex-debug.h"
[PATCH -v3 7/8] rtmutex: Fix PI chain order integrity
rt_mutex_waiter::prio is a copy of task_struct::prio which is updated
during the PI chain walk, such that the PI chain order isn't messed up
by (asynchronous) task state updates.
Currently rt_mutex_waiter_less() uses task state for deadline tasks;
this is broken, since the task state can, as said above, change
asynchronously, causing the RB tree order to change without actual
tree update -> FAIL.
Fix this by also copying the deadline into the rt_mutex_waiter state
and updating it along with its prio field.
Ideally we would also force PI chain updates whenever DL tasks update
their deadline parameter, but for first approximation this is less
broken than it was.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/locking/rtmutex.c| 29 +++--
kernel/locking/rtmutex_common.h |1 +
2 files changed, 28 insertions(+), 2 deletions(-)
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -172,8 +172,7 @@ rt_mutex_waiter_less(struct rt_mutex_wai
* then right waiter has a dl_prio() too.
*/
if (dl_prio(left->prio))
- return dl_time_before(left->task->dl.deadline,
- right->task->dl.deadline);
+ return dl_time_before(left->deadline, right->deadline);
return 0;
}
@@ -584,7 +583,26 @@ static int rt_mutex_adjust_prio_chain(st
/* [7] Requeue the waiter in the lock waiter tree. */
rt_mutex_dequeue(lock, waiter);
+
+ /*
+* Update the waiter prio fields now that we're dequeued.
+*
+* These values can have changed through either:
+*
+* sys_sched_set_scheduler() / sys_sched_setattr()
+*
+* or
+*
+* DL CBS enforcement advancing the effective deadline.
+*
+* Even though pi_waiters also uses these fields, and that tree is only
+* updated in [11], we can do this here, since we hold [L], which
+* serializes all pi_waiters access and rb_erase() does not care about
+* the values of the node being removed.
+*/
waiter->prio = task->prio;
+ waiter->deadline = task->dl.deadline;
+
rt_mutex_enqueue(lock, waiter);
/* [8] Release the task */
@@ -711,6 +729,8 @@ static int rt_mutex_adjust_prio_chain(st
static int try_to_take_rt_mutex(struct rt_mutex *lock, struct task_struct
*task,
struct rt_mutex_waiter *waiter)
{
+ lockdep_assert_held(&lock->wait_lock);
+
/*
* Before testing whether we can acquire @lock, we set the
* RT_MUTEX_HAS_WAITERS bit in @lock->owner. This forces all
@@ -838,6 +858,8 @@ static int task_blocks_on_rt_mutex(struc
struct rt_mutex *next_lock;
int chain_walk = 0, res;
+ lockdep_assert_held(&lock->wait_lock);
+
/*
* Early deadlock detection. We really don't want the task to
* enqueue on itself just to untangle the mess later. It's not
@@ -855,6 +877,7 @@ static int task_blocks_on_rt_mutex(struc
waiter->task = task;
waiter->lock = lock;
waiter->prio = task->prio;
+ waiter->deadline = task->dl.deadline;
/* Get the top priority waiter on the lock */
if (rt_mutex_has_waiters(lock))
@@ -972,6 +995,8 @@ static void remove_waiter(struct rt_mute
struct task_struct *owner = rt_mutex_owner(lock);
struct rt_mutex *next_lock;
+ lockdep_assert_held(&lock->wait_lock);
+
raw_spin_lock(¤t->pi_lock);
rt_mutex_dequeue(lock, waiter);
current->pi_blocked_on = NULL;
--- a/kernel/locking/rtmutex_common.h
+++ b/kernel/locking/rtmutex_common.h
@@ -33,6 +33,7 @@ struct rt_mutex_waiter {
struct rt_mutex *deadlock_lock;
#endif
int prio;
+ u64 deadline;
};
/*
[PATCH -v3 5/8] sched/rtmutex: Refactor rt_mutex_setprio()
With the introduction of SCHED_DEADLINE the whole notion that priority
is a single number is gone, therefore the @prio argument to
rt_mutex_setprio() doesn't make sense anymore.
So rework the code to pass a pi_task instead.
Note this also fixes a problem with pi_top_task caching; previously we
would not set the pointer (call rt_mutex_update_top_task) if the
priority didn't change, this could lead to a stale pointer.
As for the XXX, I think its fine to use pi_task->prio, because if it
differs from waiter->prio, a PI chain update is immenent.
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/sched/rt.h | 24 +++---
kernel/locking/rtmutex.c | 112 ---
kernel/sched/core.c | 66 ++-
3 files changed, 91 insertions(+), 111 deletions(-)
--- a/include/linux/sched/rt.h
+++ b/include/linux/sched/rt.h
@@ -18,28 +18,20 @@ static inline int rt_task(struct task_st
}
#ifdef CONFIG_RT_MUTEXES
-extern int rt_mutex_getprio(struct task_struct *p);
-extern void rt_mutex_setprio(struct task_struct *p, int prio);
-extern int rt_mutex_get_effective_prio(struct task_struct *task, int newprio);
-extern void rt_mutex_update_top_task(struct task_struct *p);
-extern struct task_struct *rt_mutex_get_top_task(struct task_struct *task);
+/*
+ * Must hold either p->pi_lock or task_rq(p)->lock.
+ */
+static inline struct task_struct *rt_mutex_get_top_task(struct task_struct *p)
+{
+ return p->pi_top_task;
+}
+extern void rt_mutex_setprio(struct task_struct *p, struct task_struct
*pi_task);
extern void rt_mutex_adjust_pi(struct task_struct *p);
static inline bool tsk_is_pi_blocked(struct task_struct *tsk)
{
return tsk->pi_blocked_on != NULL;
}
#else
-static inline int rt_mutex_getprio(struct task_struct *p)
-{
- return p->normal_prio;
-}
-
-static inline int rt_mutex_get_effective_prio(struct task_struct *task,
- int newprio)
-{
- return newprio;
-}
-
static inline struct task_struct *rt_mutex_get_top_task(struct task_struct
*task)
{
return NULL;
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -322,67 +322,16 @@ rt_mutex_dequeue_pi(struct task_struct *
RB_CLEAR_NODE(&waiter->pi_tree_entry);
}
-/*
- * Must hold both p->pi_lock and task_rq(p)->lock.
- */
-void rt_mutex_update_top_task(struct task_struct *p)
-{
- if (!task_has_pi_waiters(p)) {
- p->pi_top_task = NULL;
- return;
- }
-
- p->pi_top_task = task_top_pi_waiter(p)->task;
-}
-
-/*
- * Calculate task priority from the waiter tree priority
- *
- * Return task->normal_prio when the waiter tree is empty or when
- * the waiter is not allowed to do priority boosting
- */
-int rt_mutex_getprio(struct task_struct *task)
-{
- if (likely(!task_has_pi_waiters(task)))
- return task->normal_prio;
-
- return min(task_top_pi_waiter(task)->prio,
- task->normal_prio);
-}
-
-/*
- * Must hold either p->pi_lock or task_rq(p)->lock.
- */
-struct task_struct *rt_mutex_get_top_task(struct task_struct *task)
-{
- return task->pi_top_task;
-}
-
-/*
- * Called by sched_setscheduler() to get the priority which will be
- * effective after the change.
- */
-int rt_mutex_get_effective_prio(struct task_struct *task, int newprio)
+static void rt_mutex_adjust_prio(struct task_struct *p)
{
- struct task_struct *top_task = rt_mutex_get_top_task(task);
+ struct task_struct *pi_task = NULL;
- if (!top_task)
- return newprio;
+ lockdep_assert_held(&p->pi_lock);
- return min(top_task->prio, newprio);
-}
+ if (task_has_pi_waiters(p))
+ pi_task = task_top_pi_waiter(p)->task;
-/*
- * Adjust the priority of a task, after its pi_waiters got modified.
- *
- * This can be both boosting and unboosting. task->pi_lock must be held.
- */
-static void __rt_mutex_adjust_prio(struct task_struct *task)
-{
- int prio = rt_mutex_getprio(task);
-
- if (task->prio != prio || dl_prio(prio))
- rt_mutex_setprio(task, prio);
+ rt_mutex_setprio(p, pi_task);
}
/*
@@ -742,7 +691,7 @@ static int rt_mutex_adjust_prio_chain(st
*/
rt_mutex_dequeue_pi(task, prerequeue_top_waiter);
rt_mutex_enqueue_pi(task, waiter);
- __rt_mutex_adjust_prio(task);
+ rt_mutex_adjust_prio(task);
} else if (prerequeue_top_waiter == waiter) {
/*
@@ -758,7 +707,7 @@ static int rt_mutex_adjust_prio_chain(st
rt_mutex_dequeue_pi(task, waiter);
waiter = rt_mutex_top_waiter(lock);
rt_mutex_enqueue_pi(task, waiter);
- __rt_mutex_adjust_prio(task);
+ rt_mutex_adjust_prio(task);
} else {
/*
* Nothing changed. No need to do any priority
@@ -966,7 +915,7 @@ stat
[PATCH -v3 8/8] rtmutex: Fix more prio comparisons
There was a pure ->prio comparison left in try_to_wake_rt_mutex(),
convert it to use rt_mutex_waiter_less(), noting that greater-or-equal
is not-less (both in kernel priority view).
This necessitated the introduction of cmp_task() which creates a
pointer to an unnamed stack variable of struct rt_mutex_waiter type to
compare against tasks.
With this, we can now also create and employ rt_mutex_waiter_equal().
Reviewed-and-tested-by: Juri Lelli
Reviewed-by: Thomas Gleixner
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/locking/rtmutex.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -158,6 +158,12 @@ static inline bool unlock_rt_mutex_safe(
}
#endif
+/*
+ * Only use with rt_mutex_waiter_{less,equal}()
+ */
+#define cmp_task(p)\
+ &(struct rt_mutex_waiter){ .prio = (p)->prio, .deadline =
(p)->dl.deadline }
+
static inline int
rt_mutex_waiter_less(struct rt_mutex_waiter *left,
struct rt_mutex_waiter *right)
@@ -177,6 +183,25 @@ rt_mutex_waiter_less(struct rt_mutex_wai
return 0;
}
+static inline int
+rt_mutex_waiter_equal(struct rt_mutex_waiter *left,
+ struct rt_mutex_waiter *right)
+{
+ if (left->prio != right->prio)
+ return 0;
+
+ /*
+* If both waiters have dl_prio(), we check the deadlines of the
+* associated tasks.
+* If left waiter has a dl_prio(), and we didn't return 0 above,
+* then right waiter has a dl_prio() too.
+*/
+ if (dl_prio(left->prio))
+ return left->deadline == right->deadline;
+
+ return 1;
+}
+
static void
rt_mutex_enqueue(struct rt_mutex *lock, struct rt_mutex_waiter *waiter)
{
@@ -487,7 +512,7 @@ static int rt_mutex_adjust_prio_chain(st
* enabled we continue, but stop the requeueing in the chain
* walk.
*/
- if (waiter->prio == task->prio && !dl_task(task)) {
+ if (rt_mutex_waiter_equal(waiter, cmp_task(task))) {
if (!detect_deadlock)
goto out_unlock_pi;
else
@@ -790,7 +815,8 @@ static int try_to_take_rt_mutex(struct r
* the top waiter priority (kernel view),
* @task lost.
*/
- if (task->prio >= rt_mutex_top_waiter(lock)->prio)
+ if (!rt_mutex_waiter_less(cmp_task(task),
+ rt_mutex_top_waiter(lock)))
return 0;
/*
@@ -1055,7 +1081,7 @@ void rt_mutex_adjust_pi(struct task_stru
raw_spin_lock_irqsave(&task->pi_lock, flags);
waiter = task->pi_blocked_on;
- if (!waiter || (waiter->prio == task->prio && !dl_prio(task->prio))) {
+ if (!waiter || rt_mutex_waiter_equal(waiter, cmp_task(task))) {
raw_spin_unlock_irqrestore(&task->pi_lock, flags);
return;
}
[PATCH -v3 3/8] sched/deadline/rtmutex: Dont miss the dl_runtime/dl_period update
From: Xunlei Pang
Currently dl tasks will actually return at the very beginning
of rt_mutex_adjust_prio_chain() in !detect_deadlock cases:
if (waiter->prio == task->prio) {
if (!detect_deadlock)
goto out_unlock_pi; // out here
else
requeue = false;
}
As the deadline value of blocked deadline tasks(waiters) without
changing their sched_class(thus prio doesn't change) never changes,
this seems reasonable, but it actually misses the chance of updating
rt_mutex_waiter's "dl_runtime(period)_copy" if a waiter updates its
deadline parameters(dl_runtime, dl_period) or boosted waiter changes
to !deadline class.
Thus, force deadline task not out by adding the !dl_prio() condition.
Cc: Ingo Molnar
Cc: Juri Lelli
Acked-by: Steven Rostedt
Reviewed-by: Thomas Gleixner
Signed-off-by: Xunlei Pang
Signed-off-by: Peter Zijlstra (Intel)
Link: http://lkml.kernel.org/r/1460633827-345-7-git-send-email-xlp...@redhat.com
---
kernel/locking/rtmutex.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -488,7 +488,7 @@ static int rt_mutex_adjust_prio_chain(st
* enabled we continue, but stop the requeueing in the chain
* walk.
*/
- if (waiter->prio == task->prio) {
+ if (waiter->prio == task->prio && !dl_task(task)) {
if (!detect_deadlock)
goto out_unlock_pi;
else
