- Linux-stable-mirror - lists.linaro.org

Patch "irqchip/mips-gic: Separate IPI reservation & usage tracking" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled irqchip/mips-gic: Separate IPI reservation & usage tracking to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: irqchip-mips-gic-separate-ipi-reservation-usage-tracking.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Paul Burton <paul.burton(a)imgtec.com> Date: Thu, 20 Apr 2017 10:07:34 +0100 Subject: irqchip/mips-gic: Separate IPI reservation & usage tracking From: Paul Burton <paul.burton(a)imgtec.com> [ Upstream commit f8dcd9e81797ae24acc44c84f0eb3b9e6cee9791 ] Since commit 2af70a962070 ("irqchip/mips-gic: Add a IPI hierarchy domain") introduced the GIC IPI IRQ domain we have tracked both reservation of interrupts & their use with a single bitmap - ipi_resrv. If an interrupt is reserved for use as an IPI but not actually in use then the appropriate bit is set in ipi_resrv. If an interrupt is either not reserved for use as an IPI or has been allocated as one then the appropriate bit is clear in ipi_resrv. Unfortunately this means that checking whether a bit is set in ipi_resrv to prevent IPI interrupts being allocated for use with a device is broken, because if the interrupt has been allocated as an IPI first then its bit will be clear. Fix this by separating the tracking of IPI reservation & usage, introducing a separate ipi_available bitmap for the latter. This means that ipi_resrv will now always have bits set corresponding to all interrupts reserved for use as IPIs, whether or not they have been allocated yet, and therefore that checking it when allocating device interrupts works as expected. Fixes: 2af70a962070 ("irqchip/mips-gic: Add a IPI hierarchy domain") Signed-off-by: Paul Burton <paul.burton(a)imgtec.com> Signed-off-by: Matt Redfearn <matt.redfearn(a)imgtec.com> Cc: linux-mips(a)linux-mips.org Cc: Jason Cooper <jason(a)lakedaemon.net> Cc: Marc Zyngier <marc.zyngier(a)arm.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Link: http://lkml.kernel.org/r/1492679256-14513-2-git-send-email-matt.redfearn@im… Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/irqchip/irq-mips-gic.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) --- a/drivers/irqchip/irq-mips-gic.c +++ b/drivers/irqchip/irq-mips-gic.c @@ -55,6 +55,7 @@ static unsigned int gic_cpu_pin; static unsigned int timer_cpu_pin; static struct irq_chip gic_level_irq_controller, gic_edge_irq_controller; DECLARE_BITMAP(ipi_resrv, GIC_MAX_INTRS); +DECLARE_BITMAP(ipi_available, GIC_MAX_INTRS); static void __gic_irq_dispatch(void); @@ -746,17 +747,17 @@ static int gic_irq_domain_alloc(struct i return gic_setup_dev_chip(d, virq, spec->hwirq); } else { - base_hwirq = find_first_bit(ipi_resrv, gic_shared_intrs); + base_hwirq = find_first_bit(ipi_available, gic_shared_intrs); if (base_hwirq == gic_shared_intrs) { return -ENOMEM; } /* check that we have enough space */ for (i = base_hwirq; i < nr_irqs; i++) { - if (!test_bit(i, ipi_resrv)) + if (!test_bit(i, ipi_available)) return -EBUSY; } - bitmap_clear(ipi_resrv, base_hwirq, nr_irqs); + bitmap_clear(ipi_available, base_hwirq, nr_irqs); /* map the hwirq for each cpu consecutively */ i = 0; @@ -787,7 +788,7 @@ static int gic_irq_domain_alloc(struct i return 0; error: - bitmap_set(ipi_resrv, base_hwirq, nr_irqs); + bitmap_set(ipi_available, base_hwirq, nr_irqs); return ret; } @@ -802,7 +803,7 @@ void gic_irq_domain_free(struct irq_doma return; base_hwirq = GIC_HWIRQ_TO_SHARED(irqd_to_hwirq(data)); - bitmap_set(ipi_resrv, base_hwirq, nr_irqs); + bitmap_set(ipi_available, base_hwirq, nr_irqs); } int gic_irq_domain_match(struct irq_domain *d, struct device_node *node, @@ -1066,6 +1067,7 @@ static void __init __gic_init(unsigned l 2 * gic_vpes); } + bitmap_copy(ipi_available, ipi_resrv, GIC_MAX_INTRS); gic_basic_init(); } Patches currently in stable-queue which might be from paul.burton(a)imgtec.com are queue-4.9/irqchip-mips-gic-separate-ipi-reservation-usage-tracking.patch

7 years, 5 months

1
0
0 0

Patch "ipvs: explicitly forbid ipv6 service/dest creation if ipv6 mod is disabled" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipvs: explicitly forbid ipv6 service/dest creation if ipv6 mod is disabled to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ipvs-explicitly-forbid-ipv6-service-dest-creation-if-ipv6-mod-is-disabled.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Paolo Abeni <pabeni(a)redhat.com> Date: Thu, 20 Apr 2017 11:44:16 +0200 Subject: ipvs: explicitly forbid ipv6 service/dest creation if ipv6 mod is disabled From: Paolo Abeni <pabeni(a)redhat.com> [ Upstream commit 1442f6f7c1b77de1c508318164a527e240c24a4d ] When creating a new ipvs service, ipv6 addresses are always accepted if CONFIG_IP_VS_IPV6 is enabled. On dest creation the address family is not explicitly checked. This allows the user-space to configure ipvs services even if the system is booted with ipv6.disable=1. On specific configuration, ipvs can try to call ipv6 routing code at setup time, causing the kernel to oops due to fib6_rules_ops being NULL. This change addresses the issue adding a check for the ipv6 module being enabled while validating ipv6 service operations and adding the same validation for dest operations. According to git history, this issue is apparently present since the introduction of ipv6 support, and the oops can be triggered since commit 09571c7ae30865ad ("IPVS: Add function to determine if IPv6 address is local") Fixes: 09571c7ae30865ad ("IPVS: Add function to determine if IPv6 address is local") Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Acked-by: Julian Anastasov <ja(a)ssi.bg> Signed-off-by: Simon Horman <horms(a)verge.net.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/ipvs/ip_vs_ctl.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) --- a/net/netfilter/ipvs/ip_vs_ctl.c +++ b/net/netfilter/ipvs/ip_vs_ctl.c @@ -3092,6 +3092,17 @@ nla_put_failure: return skb->len; } +static bool ip_vs_is_af_valid(int af) +{ + if (af == AF_INET) + return true; +#ifdef CONFIG_IP_VS_IPV6 + if (af == AF_INET6 && ipv6_mod_enabled()) + return true; +#endif + return false; +} + static int ip_vs_genl_parse_service(struct netns_ipvs *ipvs, struct ip_vs_service_user_kern *usvc, struct nlattr *nla, int full_entry, @@ -3118,11 +3129,7 @@ static int ip_vs_genl_parse_service(stru memset(usvc, 0, sizeof(*usvc)); usvc->af = nla_get_u16(nla_af); -#ifdef CONFIG_IP_VS_IPV6 - if (usvc->af != AF_INET && usvc->af != AF_INET6) -#else - if (usvc->af != AF_INET) -#endif + if (!ip_vs_is_af_valid(usvc->af)) return -EAFNOSUPPORT; if (nla_fwmark) { @@ -3624,6 +3631,11 @@ static int ip_vs_genl_set_cmd(struct sk_ if (udest.af == 0) udest.af = svc->af; + if (!ip_vs_is_af_valid(udest.af)) { + ret = -EAFNOSUPPORT; + goto out; + } + if (udest.af != svc->af && cmd != IPVS_CMD_DEL_DEST) { /* The synchronization protocol is incompatible * with mixed family services Patches currently in stable-queue which might be from pabeni(a)redhat.com are queue-4.9/ipvs-explicitly-forbid-ipv6-service-dest-creation-if-ipv6-mod-is-disabled.patch

7 years, 5 months

1
0
0 0

Patch "ipmi/watchdog: fix wdog hang on panic waiting for ipmi response" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipmi/watchdog: fix wdog hang on panic waiting for ipmi response to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ipmi-watchdog-fix-wdog-hang-on-panic-waiting-for-ipmi-response.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Robert Lippert <roblip(a)gmail.com> Date: Thu, 20 Apr 2017 16:49:47 -0700 Subject: ipmi/watchdog: fix wdog hang on panic waiting for ipmi response From: Robert Lippert <roblip(a)gmail.com> [ Upstream commit 2c1175c2e8e5487233cabde358a19577562ac83e ] Commit c49c097610fe ("ipmi: Don't call receive handler in the panic context") means that the panic_recv_free is not called during a panic and the atomic count does not drop to 0. Fix this by only expecting one decrement of the atomic variable which comes from panic_smi_free. Signed-off-by: Robert Lippert <rlippert(a)google.com> Signed-off-by: Corey Minyard <cminyard(a)mvista.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/char/ipmi/ipmi_watchdog.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/drivers/char/ipmi/ipmi_watchdog.c +++ b/drivers/char/ipmi/ipmi_watchdog.c @@ -515,7 +515,7 @@ static void panic_halt_ipmi_heartbeat(vo msg.cmd = IPMI_WDOG_RESET_TIMER; msg.data = NULL; msg.data_len = 0; - atomic_add(2, &panic_done_count); + atomic_add(1, &panic_done_count); rv = ipmi_request_supply_msgs(watchdog_user, (struct ipmi_addr *) &addr, 0, @@ -525,7 +525,7 @@ static void panic_halt_ipmi_heartbeat(vo &panic_halt_heartbeat_recv_msg, 1); if (rv) - atomic_sub(2, &panic_done_count); + atomic_sub(1, &panic_done_count); } static struct ipmi_smi_msg panic_halt_smi_msg = { @@ -549,12 +549,12 @@ static void panic_halt_ipmi_set_timeout( /* Wait for the messages to be free. */ while (atomic_read(&panic_done_count) != 0) ipmi_poll_interface(watchdog_user); - atomic_add(2, &panic_done_count); + atomic_add(1, &panic_done_count); rv = i_ipmi_set_timeout(&panic_halt_smi_msg, &panic_halt_recv_msg, &send_heartbeat_now); if (rv) { - atomic_sub(2, &panic_done_count); + atomic_sub(1, &panic_done_count); printk(KERN_WARNING PFX "Unable to extend the watchdog timeout."); } else { Patches currently in stable-queue which might be from roblip(a)gmail.com are queue-4.9/ipmi-watchdog-fix-wdog-hang-on-panic-waiting-for-ipmi-response.patch

7 years, 5 months

1
0
0 0

Patch "ip6_vti: adjust vti mtu according to mtu of lower device" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ip6_vti: adjust vti mtu according to mtu of lower device to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ip6_vti-adjust-vti-mtu-according-to-mtu-of-lower-device.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Alexey Kodanev <alexey.kodanev(a)oracle.com> Date: Tue, 19 Dec 2017 16:59:21 +0300 Subject: ip6_vti: adjust vti mtu according to mtu of lower device From: Alexey Kodanev <alexey.kodanev(a)oracle.com> [ Upstream commit 53c81e95df1793933f87748d36070a721f6cb287 ] LTP/udp6_ipsec_vti tests fail when sending large UDP datagrams over ip6_vti that require fragmentation and the underlying device has an MTU smaller than 1500 plus some extra space for headers. This happens because ip6_vti, by default, sets MTU to ETH_DATA_LEN and not updating it depending on a destination address or link parameter. Further attempts to send UDP packets may succeed because pmtu gets updated on ICMPV6_PKT_TOOBIG in vti6_err(). In case the lower device has larger MTU size, e.g. 9000, ip6_vti works but not using the possible maximum size, output packets have 1500 limit. The above cases require manual MTU setup after ip6_vti creation. However ip_vti already updates MTU based on lower device with ip_tunnel_bind_dev(). Here is the example when the lower device MTU is set to 9000: # ip a sh ltp_ns_veth2 ltp_ns_veth2@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 ... inet 10.0.0.2/24 scope global ltp_ns_veth2 inet6 fd00::2/64 scope global # ip li add vti6 type vti6 local fd00::2 remote fd00::1 # ip li show vti6 vti6@NONE: <POINTOPOINT,NOARP> mtu 1500 ... link/tunnel6 fd00::2 peer fd00::1 After the patch: # ip li add vti6 type vti6 local fd00::2 remote fd00::1 # ip li show vti6 vti6@NONE: <POINTOPOINT,NOARP> mtu 8832 ... link/tunnel6 fd00::2 peer fd00::1 Reported-by: Petr Vorel <pvorel(a)suse.cz> Signed-off-by: Alexey Kodanev <alexey.kodanev(a)oracle.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_vti.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) --- a/net/ipv6/ip6_vti.c +++ b/net/ipv6/ip6_vti.c @@ -625,6 +625,7 @@ static void vti6_link_config(struct ip6_ { struct net_device *dev = t->dev; struct __ip6_tnl_parm *p = &t->parms; + struct net_device *tdev = NULL; memcpy(dev->dev_addr, &p->laddr, sizeof(struct in6_addr)); memcpy(dev->broadcast, &p->raddr, sizeof(struct in6_addr)); @@ -637,6 +638,25 @@ static void vti6_link_config(struct ip6_ dev->flags |= IFF_POINTOPOINT; else dev->flags &= ~IFF_POINTOPOINT; + + if (p->flags & IP6_TNL_F_CAP_XMIT) { + int strict = (ipv6_addr_type(&p->raddr) & + (IPV6_ADDR_MULTICAST | IPV6_ADDR_LINKLOCAL)); + struct rt6_info *rt = rt6_lookup(t->net, + &p->raddr, &p->laddr, + p->link, strict); + + if (rt) + tdev = rt->dst.dev; + ip6_rt_put(rt); + } + + if (!tdev && p->link) + tdev = __dev_get_by_index(t->net, p->link); + + if (tdev) + dev->mtu = max_t(int, tdev->mtu - dev->hard_header_len, + IPV6_MIN_MTU); } /** Patches currently in stable-queue which might be from alexey.kodanev(a)oracle.com are queue-4.9/ip6_vti-adjust-vti-mtu-according-to-mtu-of-lower-device.patch

7 years, 5 months

1
0
0 0

Patch "iommu/vt-d: clean up pr_irq if request_threaded_irq fails" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iommu/vt-d: clean up pr_irq if request_threaded_irq fails to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iommu-vt-d-clean-up-pr_irq-if-request_threaded_irq-fails.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Jerry Snitselaar <jsnitsel(a)redhat.com> Date: Wed, 20 Dec 2017 09:48:56 -0700 Subject: iommu/vt-d: clean up pr_irq if request_threaded_irq fails From: Jerry Snitselaar <jsnitsel(a)redhat.com> [ Upstream commit 72d548113881dd32bf7f0b221d031e6586468437 ] It is unlikely request_threaded_irq will fail, but if it does for some reason we should clear iommu->pr_irq in the error path. Also intel_svm_finish_prq shouldn't try to clean up the page request interrupt if pr_irq is 0. Without these, if request_threaded_irq were to fail the following occurs: fail with no fixes: [ 0.683147] ------------[ cut here ]------------ [ 0.683148] NULL pointer, cannot free irq [ 0.683158] WARNING: CPU: 1 PID: 1 at kernel/irq/irqdomain.c:1632 irq_domain_free_irqs+0x126/0x140 [ 0.683160] Modules linked in: [ 0.683163] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2 #3 [ 0.683165] Hardware name: /NUC7i3BNB, BIOS BNKBL357.86A.0036.2017.0105.1112 01/05/2017 [ 0.683168] RIP: 0010:irq_domain_free_irqs+0x126/0x140 [ 0.683169] RSP: 0000:ffffc90000037ce8 EFLAGS: 00010292 [ 0.683171] RAX: 000000000000001d RBX: ffff880276283c00 RCX: ffffffff81c5e5e8 [ 0.683172] RDX: 0000000000000001 RSI: 0000000000000096 RDI: 0000000000000246 [ 0.683174] RBP: ffff880276283c00 R08: 0000000000000000 R09: 000000000000023c [ 0.683175] R10: 0000000000000007 R11: 0000000000000000 R12: 000000000000007a [ 0.683176] R13: 0000000000000001 R14: 0000000000000000 R15: 0000010010000000 [ 0.683178] FS: 0000000000000000(0000) GS:ffff88027ec80000(0000) knlGS:0000000000000000 [ 0.683180] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.683181] CR2: 0000000000000000 CR3: 0000000001c09001 CR4: 00000000003606e0 [ 0.683182] Call Trace: [ 0.683189] intel_svm_finish_prq+0x3c/0x60 [ 0.683191] free_dmar_iommu+0x1ac/0x1b0 [ 0.683195] init_dmars+0xaaa/0xaea [ 0.683200] ? klist_next+0x19/0xc0 [ 0.683203] ? pci_do_find_bus+0x50/0x50 [ 0.683205] ? pci_get_dev_by_id+0x52/0x70 [ 0.683208] intel_iommu_init+0x498/0x5c7 [ 0.683211] pci_iommu_init+0x13/0x3c [ 0.683214] ? e820__memblock_setup+0x61/0x61 [ 0.683217] do_one_initcall+0x4d/0x1a0 [ 0.683220] kernel_init_freeable+0x186/0x20e [ 0.683222] ? set_debug_rodata+0x11/0x11 [ 0.683225] ? rest_init+0xb0/0xb0 [ 0.683226] kernel_init+0xa/0xff [ 0.683229] ret_from_fork+0x1f/0x30 [ 0.683259] Code: 89 ee 44 89 e7 e8 3b e8 ff ff 5b 5d 44 89 e7 44 89 ee 41 5c 41 5d 41 5e e9 a8 84 ff ff 48 c7 c7 a8 71 a7 81 31 c0 e8 6a d3 f9 ff <0f> ff 5b 5d 41 5c 41 5d 41 5 e c3 0f 1f 44 00 00 66 2e 0f 1f 84 [ 0.683285] ---[ end trace f7650e42792627ca ]--- with iommu->pr_irq = 0, but no check in intel_svm_finish_prq: [ 0.669561] ------------[ cut here ]------------ [ 0.669563] Trying to free already-free IRQ 0 [ 0.669573] WARNING: CPU: 3 PID: 1 at kernel/irq/manage.c:1546 __free_irq+0xa4/0x2c0 [ 0.669574] Modules linked in: [ 0.669577] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2 #4 [ 0.669579] Hardware name: /NUC7i3BNB, BIOS BNKBL357.86A.0036.2017.0105.1112 01/05/2017 [ 0.669581] RIP: 0010:__free_irq+0xa4/0x2c0 [ 0.669582] RSP: 0000:ffffc90000037cc0 EFLAGS: 00010082 [ 0.669584] RAX: 0000000000000021 RBX: 0000000000000000 RCX: ffffffff81c5e5e8 [ 0.669585] RDX: 0000000000000001 RSI: 0000000000000086 RDI: 0000000000000046 [ 0.669587] RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000023c [ 0.669588] R10: 0000000000000007 R11: 0000000000000000 R12: ffff880276253960 [ 0.669589] R13: ffff8802762538a4 R14: ffff880276253800 R15: ffff880276283600 [ 0.669593] FS: 0000000000000000(0000) GS:ffff88027ed80000(0000) knlGS:0000000000000000 [ 0.669594] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.669596] CR2: 0000000000000000 CR3: 0000000001c09001 CR4: 00000000003606e0 [ 0.669602] Call Trace: [ 0.669616] free_irq+0x30/0x60 [ 0.669620] intel_svm_finish_prq+0x34/0x60 [ 0.669623] free_dmar_iommu+0x1ac/0x1b0 [ 0.669627] init_dmars+0xaaa/0xaea [ 0.669631] ? klist_next+0x19/0xc0 [ 0.669634] ? pci_do_find_bus+0x50/0x50 [ 0.669637] ? pci_get_dev_by_id+0x52/0x70 [ 0.669639] intel_iommu_init+0x498/0x5c7 [ 0.669642] pci_iommu_init+0x13/0x3c [ 0.669645] ? e820__memblock_setup+0x61/0x61 [ 0.669648] do_one_initcall+0x4d/0x1a0 [ 0.669651] kernel_init_freeable+0x186/0x20e [ 0.669653] ? set_debug_rodata+0x11/0x11 [ 0.669656] ? rest_init+0xb0/0xb0 [ 0.669658] kernel_init+0xa/0xff [ 0.669661] ret_from_fork+0x1f/0x30 [ 0.669662] Code: 7a 08 75 0e e9 c3 01 00 00 4c 39 7b 08 74 57 48 89 da 48 8b 5a 18 48 85 db 75 ee 89 ee 48 c7 c7 78 67 a7 81 31 c0 e8 4c 37 fa ff <0f> ff 48 8b 34 24 4c 89 ef e 8 0e 4c 68 00 49 8b 46 40 48 8b 80 [ 0.669688] ---[ end trace 58a470248700f2fc ]--- Cc: Alex Williamson <alex.williamson(a)redhat.com> Cc: Joerg Roedel <joro(a)8bytes.org> Cc: Ashok Raj <ashok.raj(a)intel.com> Signed-off-by: Jerry Snitselaar <jsnitsel(a)redhat.com> Reviewed-by: Ashok Raj <ashok.raj(a)intel.com> Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iommu/intel-svm.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/drivers/iommu/intel-svm.c +++ b/drivers/iommu/intel-svm.c @@ -127,6 +127,7 @@ int intel_svm_enable_prq(struct intel_io pr_err("IOMMU: %s: Failed to request IRQ for page request queue\n", iommu->name); dmar_free_hwirq(irq); + iommu->pr_irq = 0; goto err; } dmar_writeq(iommu->reg + DMAR_PQH_REG, 0ULL); @@ -142,9 +143,11 @@ int intel_svm_finish_prq(struct intel_io dmar_writeq(iommu->reg + DMAR_PQT_REG, 0ULL); dmar_writeq(iommu->reg + DMAR_PQA_REG, 0ULL); - free_irq(iommu->pr_irq, iommu); - dmar_free_hwirq(iommu->pr_irq); - iommu->pr_irq = 0; + if (iommu->pr_irq) { + free_irq(iommu->pr_irq, iommu); + dmar_free_hwirq(iommu->pr_irq); + iommu->pr_irq = 0; + } free_pages((unsigned long)iommu->prq, PRQ_ORDER); iommu->prq = NULL; Patches currently in stable-queue which might be from jsnitsel(a)redhat.com are queue-4.9/iommu-vt-d-clean-up-pr_irq-if-request_threaded_irq-fails.patch

7 years, 5 months

1
0
0 0

Patch "iommu/omap: Register driver before setting IOMMU ops" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iommu/omap: Register driver before setting IOMMU ops to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iommu-omap-register-driver-before-setting-iommu-ops.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Suman Anna <s-anna(a)ti.com> Date: Wed, 12 Apr 2017 00:21:26 -0500 Subject: iommu/omap: Register driver before setting IOMMU ops From: Suman Anna <s-anna(a)ti.com> [ Upstream commit abaa7e5b054aae567861628b74dbc7fbf8ed79e8 ] Move the registration of the OMAP IOMMU platform driver before setting the IOMMU callbacks on the platform bus. This causes the IOMMU devices to be probed first before the .add_device() callback is invoked for all registered devices, and allows the iommu_group support to be added to the OMAP IOMMU driver. While at this, also check for the return status from bus_set_iommu. Signed-off-by: Suman Anna <s-anna(a)ti.com> Signed-off-by: Joerg Roedel <jroedel(a)suse.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iommu/omap-iommu.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -1299,6 +1299,7 @@ static int __init omap_iommu_init(void) const unsigned long flags = SLAB_HWCACHE_ALIGN; size_t align = 1 << 10; /* L2 pagetable alignement */ struct device_node *np; + int ret; np = of_find_matching_node(NULL, omap_iommu_of_match); if (!np) @@ -1312,11 +1313,25 @@ static int __init omap_iommu_init(void) return -ENOMEM; iopte_cachep = p; - bus_set_iommu(&platform_bus_type, &omap_iommu_ops); - omap_iommu_debugfs_init(); - return platform_driver_register(&omap_iommu_driver); + ret = platform_driver_register(&omap_iommu_driver); + if (ret) { + pr_err("%s: failed to register driver\n", __func__); + goto fail_driver; + } + + ret = bus_set_iommu(&platform_bus_type, &omap_iommu_ops); + if (ret) + goto fail_bus; + + return 0; + +fail_bus: + platform_driver_unregister(&omap_iommu_driver); +fail_driver: + kmem_cache_destroy(iopte_cachep); + return ret; } subsys_initcall(omap_iommu_init); /* must be ready before omap3isp is probed */ Patches currently in stable-queue which might be from s-anna(a)ti.com are queue-4.9/iommu-omap-register-driver-before-setting-iommu-ops.patch

7 years, 5 months

1
0
0 0

Patch "Input: twl4030-pwrbutton - use correct device for irq request" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: twl4030-pwrbutton - use correct device for irq request to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: input-twl4030-pwrbutton-use-correct-device-for-irq-request.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk> Date: Fri, 28 Apr 2017 10:25:51 -0700 Subject: Input: twl4030-pwrbutton - use correct device for irq request From: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk> [ Upstream commit 3071e9dd6cd3f2290d770117330f2c8b2e9a97e4 ] The interrupt should be requested for the platform device and not for the input device. Fixes: 7f9ce649d267 ("Input: twl4030-pwrbutton - simplify driver using devm_*") Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/misc/twl4030-pwrbutton.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/input/misc/twl4030-pwrbutton.c +++ b/drivers/input/misc/twl4030-pwrbutton.c @@ -70,7 +70,7 @@ static int twl4030_pwrbutton_probe(struc pwr->phys = "twl4030_pwrbutton/input0"; pwr->dev.parent = &pdev->dev; - err = devm_request_threaded_irq(&pwr->dev, irq, NULL, powerbutton_irq, + err = devm_request_threaded_irq(&pdev->dev, irq, NULL, powerbutton_irq, IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING | IRQF_ONESHOT, "twl4030_pwrbutton", pwr); Patches currently in stable-queue which might be from sebastian.reichel(a)collabora.co.uk are queue-4.9/power-supply-pda_power-move-from-timer-to-delayed_work.patch queue-4.9/power-supply-isp1704-fix-unchecked-return-value-of-devm_kzalloc.patch queue-4.9/power-supply-bq24190_charger-add-disable-reset-device-property.patch queue-4.9/input-twl4030-pwrbutton-use-correct-device-for-irq-request.patch

7 years, 5 months

1
0
0 0

Patch "Input: ar1021_i2c - fix too long name in driver's device table" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: ar1021_i2c - fix too long name in driver's device table to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: input-ar1021_i2c-fix-too-long-name-in-driver-s-device-table.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Date: Mon, 12 Dec 2016 15:32:57 -0800 Subject: Input: ar1021_i2c - fix too long name in driver's device table From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> [ Upstream commit 95123fc43560d6f4a60e74f72836e63cd8848f76 ] The name field in structure i2c_device_id is 20 characters, and we expect it to be NULL-terminated, however we are trying to stuff it with 21 bytes and thus NULL-terminator is lost. This causes issues when one creates device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the last "C", and automatic module loading by alias does not work as result. The -I2C suffix in the device name is superfluous, we know what bus we are dealing with, so let's drop it. Also, no other driver uses capitals, and the manufacturer name is normally not included, except in very rare cases of incompatible name collisions. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211 Fixes: dd4cae8bf166 ("Input: Add Microchip AR1021 i2c touchscreen") Reviewed-By: Christian Gmeiner <christian.gmeiner(a)gmail.com> Tested-by: Martin Kepplinger <martin.kepplinger(a)ginzinger.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/touchscreen/ar1021_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/input/touchscreen/ar1021_i2c.c +++ b/drivers/input/touchscreen/ar1021_i2c.c @@ -152,7 +152,7 @@ static int __maybe_unused ar1021_i2c_res static SIMPLE_DEV_PM_OPS(ar1021_i2c_pm, ar1021_i2c_suspend, ar1021_i2c_resume); static const struct i2c_device_id ar1021_i2c_id[] = { - { "MICROCHIP_AR1021_I2C", 0 }, + { "ar1021", 0 }, { }, }; MODULE_DEVICE_TABLE(i2c, ar1021_i2c_id); Patches currently in stable-queue which might be from dmitry.torokhov(a)gmail.com are queue-4.9/input-ar1021_i2c-fix-too-long-name-in-driver-s-device-table.patch queue-4.9/input-twl4030-pwrbutton-use-correct-device-for-irq-request.patch

7 years, 5 months

1
0
0 0

Patch "infiniband/uverbs: Fix integer overflows" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled infiniband/uverbs: Fix integer overflows to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: infiniband-uverbs-fix-integer-overflows.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Vlad Tsyrklevich <vlad(a)tsyrklevich.net> Date: Fri, 24 Mar 2017 15:55:17 -0400 Subject: infiniband/uverbs: Fix integer overflows From: Vlad Tsyrklevich <vlad(a)tsyrklevich.net> [ Upstream commit 4f7f4dcfff2c19debbcdbcc861c325610a15e0c5 ] The 'num_sge' variable is verfied to be smaller than the 'sge_count' variable; however, since both are user-controlled it's possible to cause an integer overflow for the kmalloc multiply on 32-bit platforms (num_sge and sge_count are both defined u32). By crafting an input that causes a smaller-than-expected allocation it's possible to write controlled data out-of-bounds. Signed-off-by: Vlad Tsyrklevich <vlad(a)tsyrklevich.net> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/uverbs_cmd.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) --- a/drivers/infiniband/core/uverbs_cmd.c +++ b/drivers/infiniband/core/uverbs_cmd.c @@ -2491,9 +2491,13 @@ ssize_t ib_uverbs_destroy_qp(struct ib_u static void *alloc_wr(size_t wr_size, __u32 num_sge) { + if (num_sge >= (U32_MAX - ALIGN(wr_size, sizeof (struct ib_sge))) / + sizeof (struct ib_sge)) + return NULL; + return kmalloc(ALIGN(wr_size, sizeof (struct ib_sge)) + num_sge * sizeof (struct ib_sge), GFP_KERNEL); -}; +} ssize_t ib_uverbs_post_send(struct ib_uverbs_file *file, struct ib_device *ib_dev, @@ -2719,6 +2723,13 @@ static struct ib_recv_wr *ib_uverbs_unma ret = -EINVAL; goto err; } + + if (user_wr->num_sge >= + (U32_MAX - ALIGN(sizeof *next, sizeof (struct ib_sge))) / + sizeof (struct ib_sge)) { + ret = -EINVAL; + goto err; + } next = kmalloc(ALIGN(sizeof *next, sizeof (struct ib_sge)) + user_wr->num_sge * sizeof (struct ib_sge), Patches currently in stable-queue which might be from vlad(a)tsyrklevich.net are queue-4.9/infiniband-uverbs-fix-integer-overflows.patch

7 years, 5 months

1
0
0 0

Patch "iio: st_pressure: st_accel: Initialise sensor platform data properly" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: st_pressure: st_accel: Initialise sensor platform data properly to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iio-st_pressure-st_accel-initialise-sensor-platform-data-properly.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Shrirang Bagul <shrirang.bagul(a)canonical.com> Date: Wed, 19 Apr 2017 22:05:00 +0800 Subject: iio: st_pressure: st_accel: Initialise sensor platform data properly From: Shrirang Bagul <shrirang.bagul(a)canonical.com> [ Upstream commit 7383d44b84c94aaca4bf695a6bd8a69f2295ef1a ] This patch fixes the sensor platform data initialisation for st_pressure and st_accel device drivers. Without this patch, the driver fails to register the sensors when the user removes and re-loads the driver. 1. Unload the kernel modules for st_pressure $ sudo rmmod st_pressure_i2c $ sudo rmmod st_pressure 2. Re-load the driver $ sudo insmod st_pressure $ sudo insmod st_pressure_i2c Signed-off-by: Jonathan Cameron <jic23(a)kernel.org> Acked-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/accel/st_accel_core.c | 7 ++++--- drivers/iio/pressure/st_pressure_core.c | 8 ++++---- 2 files changed, 8 insertions(+), 7 deletions(-) --- a/drivers/iio/accel/st_accel_core.c +++ b/drivers/iio/accel/st_accel_core.c @@ -827,6 +827,8 @@ static const struct iio_trigger_ops st_a int st_accel_common_probe(struct iio_dev *indio_dev) { struct st_sensor_data *adata = iio_priv(indio_dev); + struct st_sensors_platform_data *pdata = + (struct st_sensors_platform_data *)adata->dev->platform_data; int irq = adata->get_irq_data_ready(indio_dev); int err; @@ -853,9 +855,8 @@ int st_accel_common_probe(struct iio_dev &adata->sensor_settings->fs.fs_avl[0]; adata->odr = adata->sensor_settings->odr.odr_avl[0].hz; - if (!adata->dev->platform_data) - adata->dev->platform_data = - (struct st_sensors_platform_data *)&default_accel_pdata; + if (!pdata) + pdata = (struct st_sensors_platform_data *)&default_accel_pdata; err = st_sensors_init_sensor(indio_dev, adata->dev->platform_data); if (err < 0) --- a/drivers/iio/pressure/st_pressure_core.c +++ b/drivers/iio/pressure/st_pressure_core.c @@ -638,6 +638,8 @@ static const struct iio_trigger_ops st_p int st_press_common_probe(struct iio_dev *indio_dev) { struct st_sensor_data *press_data = iio_priv(indio_dev); + struct st_sensors_platform_data *pdata = + (struct st_sensors_platform_data *)press_data->dev->platform_data; int irq = press_data->get_irq_data_ready(indio_dev); int err; @@ -673,10 +675,8 @@ int st_press_common_probe(struct iio_dev press_data->odr = press_data->sensor_settings->odr.odr_avl[0].hz; /* Some devices don't support a data ready pin. */ - if (!press_data->dev->platform_data && - press_data->sensor_settings->drdy_irq.addr) - press_data->dev->platform_data = - (struct st_sensors_platform_data *)&default_press_pdata; + if (!pdata && press_data->sensor_settings->drdy_irq.addr) + pdata = (struct st_sensors_platform_data *)&default_press_pdata; err = st_sensors_init_sensor(indio_dev, press_data->dev->platform_data); if (err < 0) Patches currently in stable-queue which might be from shrirang.bagul(a)canonical.com are queue-4.9/iio-st_pressure-st_accel-initialise-sensor-platform-data-properly.patch

7 years, 5 months

1
0
0 0

Patch "iio: hid-sensor: fix return of -EINVAL on invalid values in ret or value" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: hid-sensor: fix return of -EINVAL on invalid values in ret or value to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iio-hid-sensor-fix-return-of-einval-on-invalid-values-in-ret-or-value.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Colin Ian King <colin.king(a)canonical.com> Date: Wed, 19 Apr 2017 15:35:48 +0100 Subject: iio: hid-sensor: fix return of -EINVAL on invalid values in ret or value From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit c894acc7bf400d039bf740420b22f0b71b7fb504 ] Ensure that when an invalid value in ret or value is found -EINVAL is returned. A previous commit broke the way the return error is being returned and instead caused the return code in ret to be re-assigned rather than be returned. Fixes: 5d9854eaea776 ("iio: hid-sensor: Store restore poll and hysteresis on S3") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Signed-off-by: Jonathan Cameron <jic23(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/common/hid-sensors/hid-sensor-attributes.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c @@ -215,7 +215,7 @@ int hid_sensor_write_samp_freq_value(str ret = sensor_hub_set_feature(st->hsdev, st->poll.report_id, st->poll.index, sizeof(value), &value); if (ret < 0 || value < 0) - ret = -EINVAL; + return -EINVAL; ret = sensor_hub_get_feature(st->hsdev, st->poll.report_id, @@ -265,7 +265,7 @@ int hid_sensor_write_raw_hyst_value(stru st->sensitivity.index, sizeof(value), &value); if (ret < 0 || value < 0) - ret = -EINVAL; + return -EINVAL; ret = sensor_hub_get_feature(st->hsdev, st->sensitivity.report_id, Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-4.9/iio-hid-sensor-fix-return-of-einval-on-invalid-values-in-ret-or-value.patch

7 years, 5 months

1
0
0 0

Patch "ibmvnic: Disable irq prior to close" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ibmvnic: Disable irq prior to close to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ibmvnic-disable-irq-prior-to-close.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Wed, 19 Apr 2017 13:45:10 -0400 Subject: ibmvnic: Disable irq prior to close From: Brian King <brking(a)linux.vnet.ibm.com> [ Upstream commit dd9c20fa07ba5cfb5a0ab3181d68530506610605 ] Add some code to call disable_irq on all the vnic interface's irqs. This fixes a crash observed when closing an active interface, as seen in the oops below when we try to access a buffer in the interrupt handler which we've already freed. Unable to handle kernel paging request for data at address 0x00000001 Faulting instruction address: 0xd000000003886824 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2048 NUMA pSeries Modules linked in: ibmvnic(OEN) rpadlpar_io(X) rpaphp(X) tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag rpcsec_ Supported: No, Unsupported modules are loaded CPU: 8 PID: 0 Comm: swapper/8 Tainted: G OE NX 4.4.49-92.11-default #1 task: c00000007f990110 ti: c0000000fffa0000 task.ti: c00000007f9b8000 NIP: d000000003886824 LR: d000000003886824 CTR: c0000000007eff60 REGS: c0000000fffa3a70 TRAP: 0300 Tainted: G OE NX (4.4.49-92.11-default) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22008042 XER: 20000008 CFAR: c000000000008468 DAR: 0000000000000001 DSISR: 40000000 SOFTE: 0 GPR00: d000000003886824 c0000000fffa3cf0 d000000003894118 0000000000000000 GPR04: 0000000000000000 0000000000000000 c000000001249da0 0000000000000000 GPR08: 000000000000000e 0000000000000000 c0000000ccb00000 d000000003889180 GPR12: c0000000007eff60 c000000007af4c00 0000000000000001 c0000000010def30 GPR16: c00000007f9b8000 c000000000b98c30 c00000007f9b8080 c000000000bab858 GPR20: 0000000000000005 0000000000000000 c0000000ff5d7e80 c0000000f809f648 GPR24: c0000000ff5d7ec8 0000000000000000 0000000000000000 c0000000ccb001a0 GPR28: 000000000000000a c0000000f809f600 c0000000fd4cd900 c0000000f9cd5b00 NIP [d000000003886824] ibmvnic_interrupt_tx+0x114/0x380 [ibmvnic] LR [d000000003886824] ibmvnic_interrupt_tx+0x114/0x380 [ibmvnic] Call Trace: [c0000000fffa3cf0] [d000000003886824] ibmvnic_interrupt_tx+0x114/0x380 [ibmvnic] (unreliable) [c0000000fffa3dd0] [c000000000132940] __handle_irq_event_percpu+0x90/0x2e0 [c0000000fffa3e90] [c000000000132bcc] handle_irq_event_percpu+0x3c/0x90 [c0000000fffa3ed0] [c000000000132c88] handle_irq_event+0x68/0xc0 [c0000000fffa3f00] [c000000000137edc] handle_fasteoi_irq+0xec/0x250 [c0000000fffa3f30] [c000000000131b04] generic_handle_irq+0x54/0x80 [c0000000fffa3f60] [c000000000011190] __do_irq+0x80/0x1d0 [c0000000fffa3f90] [c0000000000248d8] call_do_irq+0x14/0x24 [c00000007f9bb9e0] [c000000000011380] do_IRQ+0xa0/0x120 [c00000007f9bba40] [c000000000002594] hardware_interrupt_common+0x114/0x180 Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Signed-off-by: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/ibm/ibmvnic.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -511,6 +511,23 @@ alloc_napi_failed: return -ENOMEM; } +static void disable_sub_crqs(struct ibmvnic_adapter *adapter) +{ + int i; + + if (adapter->tx_scrq) { + for (i = 0; i < adapter->req_tx_queues; i++) + if (adapter->tx_scrq[i]) + disable_irq(adapter->tx_scrq[i]->irq); + } + + if (adapter->rx_scrq) { + for (i = 0; i < adapter->req_rx_queues; i++) + if (adapter->rx_scrq[i]) + disable_irq(adapter->rx_scrq[i]->irq); + } +} + static int ibmvnic_close(struct net_device *netdev) { struct ibmvnic_adapter *adapter = netdev_priv(netdev); @@ -519,6 +536,7 @@ static int ibmvnic_close(struct net_devi int i; adapter->closing = true; + disable_sub_crqs(adapter); for (i = 0; i < adapter->req_rx_queues; i++) napi_disable(&adapter->napi[i]); Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.9/ibmvnic-disable-irq-prior-to-close.patch

7 years, 5 months

1
0
0 0

Patch "IB/umem: Fix use of npages/nmap fields" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/umem: Fix use of npages/nmap fields to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-umem-fix-use-of-npages-nmap-fields.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Artemy Kovalyov <artemyko(a)mellanox.com> Date: Tue, 14 Nov 2017 14:51:59 +0200 Subject: IB/umem: Fix use of npages/nmap fields From: Artemy Kovalyov <artemyko(a)mellanox.com> [ Upstream commit edf1a84fe37c51290e2c88154ecaf48dadff3d27 ] In ib_umem structure npages holds original number of sg entries, while nmap is number of DMA blocks returned by dma_map_sg. Fixes: c5d76f130b28 ('IB/core: Add umem function to read data from user-space') Signed-off-by: Artemy Kovalyov <artemyko(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/umem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/core/umem.c +++ b/drivers/infiniband/core/umem.c @@ -357,7 +357,7 @@ int ib_umem_copy_from(void *dst, struct return -EINVAL; } - ret = sg_pcopy_to_buffer(umem->sg_head.sgl, umem->nmap, dst, length, + ret = sg_pcopy_to_buffer(umem->sg_head.sgl, umem->npages, dst, length, offset + ib_umem_offset(umem)); if (ret < 0) Patches currently in stable-queue which might be from artemyko(a)mellanox.com are queue-4.9/ib-umem-fix-use-of-npages-nmap-fields.patch

7 years, 5 months

1
0
0 0

Patch "IB/rxe: Don't clamp residual length to mtu" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/rxe: Don't clamp residual length to mtu to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-rxe-don-t-clamp-residual-length-to-mtu.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Thu, 6 Apr 2017 14:49:44 +0200 Subject: IB/rxe: Don't clamp residual length to mtu From: Johannes Thumshirn <jthumshirn(a)suse.de> [ Upstream commit d52418502e288b5c7e9e2e6cf1de5f1d3d79d2e1 ] When reading a RDMA WRITE FIRST packet we copy the DMA length from the RDMA header into the qp->resp.resid variable for later use. Later in check_rkey() we clamp it to the MTU if the packet is an RDMA WRITE packet and has a residual length bigger than the MTU. Later in write_data_in() we subtract the payload of the packet from the residual length. If the packet happens to have a payload of exactly the MTU size we end up with a residual length of 0 despite the packet not being the last in the conversation. When the next packet in the conversation arrives, we don't have any residual length left and thus set the QP into an error state. This broke NVMe over Fabrics functionality over rdma_rxe.ko The patch was verified using the following test. # echo eth0 > /sys/module/rdma_rxe/parameters/add # nvme connect -t rdma -a 192.168.155.101 -s 1023 -n nvmf-test # mkfs.xfs -fK /dev/nvme0n1 meta-data=/dev/nvme0n1 isize=256 agcount=4, agsize=65536 blks = sectsz=4096 attr=2, projid32bit=1 = crc=0 finobt=0, sparse=0 data = bsize=4096 blocks=262144, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 # mount /dev/nvme0n1 /tmp/ [ 148.923263] XFS (nvme0n1): Mounting V4 Filesystem [ 148.961196] XFS (nvme0n1): Ending clean mount # dd if=/dev/urandom of=test.bin bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 0.437991 s, 306 MB/s # sha256sum test.bin cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a test.bin # cp test.bin /tmp/ sha256sum /tmp/test.bin cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a /tmp/test.bin Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Cc: Hannes Reinecke <hare(a)suse.de> Cc: Sagi Grimberg <sagi(a)grimberg.me> Cc: Max Gurtovoy <maxg(a)mellanox.com> Acked-by: Moni Shoua <monis(a)mellanox.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rxe/rxe_resp.c | 2 -- 1 file changed, 2 deletions(-) --- a/drivers/infiniband/sw/rxe/rxe_resp.c +++ b/drivers/infiniband/sw/rxe/rxe_resp.c @@ -471,8 +471,6 @@ static enum resp_states check_rkey(struc state = RESPST_ERR_LENGTH; goto err; } - - qp->resp.resid = mtu; } else { if (pktlen != resid) { state = RESPST_ERR_LENGTH; Patches currently in stable-queue which might be from jthumshirn(a)suse.de are queue-4.9/fix-driver-usage-of-128b-wqes-when-wq_create-is-v1.patch queue-4.9/fix-express-lane-queue-creation.patch queue-4.9/ib-rxe-don-t-clamp-residual-length-to-mtu.patch

7 years, 5 months

1
0
0 0

Patch "IB/rdmavt: restore IRQs on error path in rvt_create_ah()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/rdmavt: restore IRQs on error path in rvt_create_ah() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-rdmavt-restore-irqs-on-error-path-in-rvt_create_ah.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Thu, 27 Apr 2017 12:14:20 +0300 Subject: IB/rdmavt: restore IRQs on error path in rvt_create_ah() From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit f0bb2d44ca26b7090dc7bade8877b77005f07dfc ] We need to call spin_unlock_irqrestore() instead of vanilla spin_unlock() on this error path. Fixes: 119a8e708d16 ("IB/rdmavt: Add AH to rdmavt") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Reviewed-by: Leon Romanovsky <leonro(a)mellanox.com> Acked-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rdmavt/ah.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/sw/rdmavt/ah.c +++ b/drivers/infiniband/sw/rdmavt/ah.c @@ -119,7 +119,7 @@ struct ib_ah *rvt_create_ah(struct ib_pd spin_lock_irqsave(&dev->n_ahs_lock, flags); if (dev->n_ahs_allocated == dev->dparms.props.max_ah) { - spin_unlock(&dev->n_ahs_lock); + spin_unlock_irqrestore(&dev->n_ahs_lock, flags); kfree(ah); return ERR_PTR(-ENOMEM); } Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-4.9/netfilter-x_tables-unlock-on-error-in-xt_find_table_lock.patch queue-4.9/asoc-intel-skylake-uninitialized-variable-in-probe_codec.patch queue-4.9/mmc-host-omap_hsmmc-checking-for-null-instead-of-is_err.patch queue-4.9/qed-unlock-on-error-in-qed_vf_pf_acquire.patch queue-4.9/hsi-ssi_protocol-double-free-in-ssip_pn_xmit.patch queue-4.9/cifs-small-underflow-in-cnvrtdosunixtm.patch queue-4.9/ib-rdmavt-restore-irqs-on-error-path-in-rvt_create_ah.patch

7 years, 5 months

1
0
0 0

Patch "IB/mlx5: Take write semaphore when changing the vma struct" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx5: Take write semaphore when changing the vma struct to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx5-take-write-semaphore-when-changing-the-vma-struct.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Maor Gottlieb <maorg(a)mellanox.com> Date: Wed, 29 Mar 2017 06:03:02 +0300 Subject: IB/mlx5: Take write semaphore when changing the vma struct From: Maor Gottlieb <maorg(a)mellanox.com> [ Upstream commit ecc7d83be3243835c9396a1a2fb8ce95f205207b ] When the driver disassociate user context, it changes the vma to anonymous by setting the vm_ops to null and zap the vma ptes. In order to avoid race in the kernel, we need to take write lock before we change the vma entries. Fixes: 7c2344c3bbf97 ('IB/mlx5: Implements disassociate_ucontext API') Signed-off-by: Maor Gottlieb <maorg(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx5/main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/infiniband/hw/mlx5/main.c +++ b/drivers/infiniband/hw/mlx5/main.c @@ -1313,7 +1313,7 @@ static void mlx5_ib_disassociate_ucontex /* need to protect from a race on closing the vma as part of * mlx5_ib_vma_close. */ - down_read(&owning_mm->mmap_sem); + down_write(&owning_mm->mmap_sem); list_for_each_entry_safe(vma_private, n, &context->vma_private_list, list) { vma = vma_private->vma; @@ -1327,7 +1327,7 @@ static void mlx5_ib_disassociate_ucontex list_del(&vma_private->list); kfree(vma_private); } - up_read(&owning_mm->mmap_sem); + up_write(&owning_mm->mmap_sem); mmput(owning_mm); put_task_struct(owning_process); } Patches currently in stable-queue which might be from maorg(a)mellanox.com are queue-4.9/ib-mlx4-change-vma-from-shared-to-private.patch queue-4.9/ib-mlx5-take-write-semaphore-when-changing-the-vma-struct.patch queue-4.9/ib-mlx5-change-vma-from-shared-to-private.patch queue-4.9/ib-mlx4-take-write-semaphore-when-changing-the-vma-struct.patch

7 years, 5 months

1
0
0 0

Patch "IB/mlx5: Set correct SL in completion for RoCE" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx5: Set correct SL in completion for RoCE to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx5-set-correct-sl-in-completion-for-roce.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Moni Shoua <monis(a)mellanox.com> Date: Thu, 20 Apr 2017 13:26:54 +0300 Subject: IB/mlx5: Set correct SL in completion for RoCE From: Moni Shoua <monis(a)mellanox.com> [ Upstream commit 12f8fedef2ec94c783f929126b20440a01512c14 ] There is a difference when parsing a completion entry between Ethernet and IB ports. When link layer is Ethernet the bits describe the type of L3 header in the packet. In the case when link layer is Ethernet and VLAN header is present the value of SL is equal to the 3 UP bits in the VLAN header. If VLAN header is not present then the SL is undefined and consumer of the completion should check if IB_WC_WITH_VLAN is set. While that, this patch also fills the vlan_id field in the completion if present. Signed-off-by: Moni Shoua <monis(a)mellanox.com> Reviewed-by: Majd Dibbiny <majd(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx5/cq.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) --- a/drivers/infiniband/hw/mlx5/cq.c +++ b/drivers/infiniband/hw/mlx5/cq.c @@ -172,6 +172,8 @@ static void handle_responder(struct ib_w struct mlx5_ib_srq *srq; struct mlx5_ib_wq *wq; u16 wqe_ctr; + u8 roce_packet_type; + bool vlan_present; u8 g; if (qp->ibqp.srq || qp->ibqp.xrcd) { @@ -223,7 +225,6 @@ static void handle_responder(struct ib_w break; } wc->slid = be16_to_cpu(cqe->slid); - wc->sl = (be32_to_cpu(cqe->flags_rqpn) >> 24) & 0xf; wc->src_qp = be32_to_cpu(cqe->flags_rqpn) & 0xffffff; wc->dlid_path_bits = cqe->ml_path; g = (be32_to_cpu(cqe->flags_rqpn) >> 28) & 3; @@ -237,10 +238,22 @@ static void handle_responder(struct ib_w wc->pkey_index = 0; } - if (ll != IB_LINK_LAYER_ETHERNET) + if (ll != IB_LINK_LAYER_ETHERNET) { + wc->sl = (be32_to_cpu(cqe->flags_rqpn) >> 24) & 0xf; return; + } + + vlan_present = cqe->l4_l3_hdr_type & 0x1; + roce_packet_type = (be32_to_cpu(cqe->flags_rqpn) >> 24) & 0x3; + if (vlan_present) { + wc->vlan_id = (be16_to_cpu(cqe->vlan_info)) & 0xfff; + wc->sl = (be16_to_cpu(cqe->vlan_info) >> 13) & 0x7; + wc->wc_flags |= IB_WC_WITH_VLAN; + } else { + wc->sl = 0; + } - switch (wc->sl & 0x3) { + switch (roce_packet_type) { case MLX5_CQE_ROCE_L3_HEADER_TYPE_GRH: wc->network_hdr_type = RDMA_NETWORK_IB; break; Patches currently in stable-queue which might be from monis(a)mellanox.com are queue-4.9/ib-mlx5-set-correct-sl-in-completion-for-roce.patch queue-4.9/ib-rxe-don-t-clamp-residual-length-to-mtu.patch

7 years, 5 months

1
0
0 0

Patch "IB/mlx5: Change vma from shared to private" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx5: Change vma from shared to private to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx5-change-vma-from-shared-to-private.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Maor Gottlieb <maorg(a)mellanox.com> Date: Wed, 29 Mar 2017 06:03:03 +0300 Subject: IB/mlx5: Change vma from shared to private From: Maor Gottlieb <maorg(a)mellanox.com> [ Upstream commit 1377661298d2820d675553d186c31b6f46c140d0 ] Anonymous VMA (->vm_ops == NULL) cannot be shared, otherwise it would lead to SIGBUS. Remove the shared flags from the vma after we change it to be anonymous. This is easily reproduced by doing modprobe -r while running a user-space application such as raw_ethernet_bw. Fixes: 7c2344c3bbf97 ('IB/mlx5: Implements disassociate_ucontext API') Signed-off-by: Maor Gottlieb <maorg(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx5/main.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/infiniband/hw/mlx5/main.c +++ b/drivers/infiniband/hw/mlx5/main.c @@ -1323,6 +1323,7 @@ static void mlx5_ib_disassociate_ucontex /* context going to be destroyed, should * not access ops any more. */ + vma->vm_flags &= ~(VM_SHARED | VM_MAYSHARE); vma->vm_ops = NULL; list_del(&vma_private->list); kfree(vma_private); Patches currently in stable-queue which might be from maorg(a)mellanox.com are queue-4.9/ib-mlx4-change-vma-from-shared-to-private.patch queue-4.9/ib-mlx5-take-write-semaphore-when-changing-the-vma-struct.patch queue-4.9/ib-mlx5-change-vma-from-shared-to-private.patch queue-4.9/ib-mlx4-take-write-semaphore-when-changing-the-vma-struct.patch

7 years, 5 months

1
0
0 0

Patch "IB/mlx4: Take write semaphore when changing the vma struct" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx4: Take write semaphore when changing the vma struct to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx4-take-write-semaphore-when-changing-the-vma-struct.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Maor Gottlieb <maorg(a)mellanox.com> Date: Wed, 29 Mar 2017 06:03:00 +0300 Subject: IB/mlx4: Take write semaphore when changing the vma struct From: Maor Gottlieb <maorg(a)mellanox.com> [ Upstream commit 22c3653d04bd0c67b75e99d85e0c0bdf83947df5 ] When the driver disassociate user context, it changes the vma to anonymous by setting the vm_ops to null and zap the vma ptes. In order to avoid race in the kernel, we need to take write lock before we change the vma entries. Fixes: ae184ddeca5db ('IB/mlx4_ib: Disassociate support') Signed-off-by: Maor Gottlieb <maorg(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx4/main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -1168,7 +1168,7 @@ static void mlx4_ib_disassociate_ucontex /* need to protect from a race on closing the vma as part of * mlx4_ib_vma_close(). */ - down_read(&owning_mm->mmap_sem); + down_write(&owning_mm->mmap_sem); for (i = 0; i < HW_BAR_COUNT; i++) { vma = context->hw_bar_info[i].vma; if (!vma) @@ -1186,7 +1186,7 @@ static void mlx4_ib_disassociate_ucontex context->hw_bar_info[i].vma->vm_ops = NULL; } - up_read(&owning_mm->mmap_sem); + up_write(&owning_mm->mmap_sem); mmput(owning_mm); put_task_struct(owning_process); } Patches currently in stable-queue which might be from maorg(a)mellanox.com are queue-4.9/ib-mlx4-change-vma-from-shared-to-private.patch queue-4.9/ib-mlx5-take-write-semaphore-when-changing-the-vma-struct.patch queue-4.9/ib-mlx5-change-vma-from-shared-to-private.patch queue-4.9/ib-mlx4-take-write-semaphore-when-changing-the-vma-struct.patch

7 years, 5 months

1
0
0 0

Patch "IB/mlx4: Change vma from shared to private" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx4: Change vma from shared to private to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx4-change-vma-from-shared-to-private.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Maor Gottlieb <maorg(a)mellanox.com> Date: Wed, 29 Mar 2017 06:03:01 +0300 Subject: IB/mlx4: Change vma from shared to private From: Maor Gottlieb <maorg(a)mellanox.com> [ Upstream commit ca37a664a8e4e9988b220988ceb4d79e3316f195 ] Anonymous VMA (->vm_ops == NULL) cannot be shared, otherwise it would lead to SIGBUS. Remove the shared flags from the vma after we change it to be anonymous. This is easily reproduced by doing modprobe -r while running a user-space application such as raw_ethernet_bw. Fixes: ae184ddeca5db ('IB/mlx4_ib: Disassociate support') Signed-off-by: Maor Gottlieb <maorg(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx4/main.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -1182,6 +1182,8 @@ static void mlx4_ib_disassociate_ucontex BUG_ON(1); } + context->hw_bar_info[i].vma->vm_flags &= + ~(VM_SHARED | VM_MAYSHARE); /* context going to be destroyed, should not access ops any more */ context->hw_bar_info[i].vma->vm_ops = NULL; } Patches currently in stable-queue which might be from maorg(a)mellanox.com are queue-4.9/ib-mlx4-change-vma-from-shared-to-private.patch queue-4.9/ib-mlx5-take-write-semaphore-when-changing-the-vma-struct.patch queue-4.9/ib-mlx5-change-vma-from-shared-to-private.patch queue-4.9/ib-mlx4-take-write-semaphore-when-changing-the-vma-struct.patch

7 years, 5 months

1
0
0 0

Patch "IB/ipoib: Update broadcast object if PKey value was changed in index 0" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/ipoib: Update broadcast object if PKey value was changed in index 0 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-ipoib-update-broadcast-object-if-pkey-value-was-changed-in-index-0.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Feras Daoud <ferasda(a)mellanox.com> Date: Sun, 19 Mar 2017 11:18:54 +0200 Subject: IB/ipoib: Update broadcast object if PKey value was changed in index 0 From: Feras Daoud <ferasda(a)mellanox.com> [ Upstream commit 9a9b8112699d78e7f317019b37f377e90023f3ed ] Update the broadcast address in the priv->broadcast object when the Pkey value changes in index 0, otherwise the multicast GID value will keep the previous value of the PKey, and will not be updated. This leads to interface state down because the interface will keep the old PKey value. For example, in SR-IOV environment, if the PF changes the value of PKey index 0 for one of the VFs, then the VF receives PKey change event that triggers heavy flush. This flush calls update_parent_pkey that update the broadcast object and its relevant members. If in this case the multicast GID will not be updated, the interface state will be down. Fixes: c2904141696e ("IPoIB: Fix pkey change flow for virtualization environments") Signed-off-by: Feras Daoud <ferasda(a)mellanox.com> Signed-off-by: Erez Shitrit <erezsh(a)mellanox.com> Reviewed-by: Alex Vesker <valex(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/ipoib/ipoib_ib.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c @@ -974,6 +974,19 @@ static inline int update_parent_pkey(str */ priv->dev->broadcast[8] = priv->pkey >> 8; priv->dev->broadcast[9] = priv->pkey & 0xff; + + /* + * Update the broadcast address in the priv->broadcast object, + * in case it already exists, otherwise no one will do that. + */ + if (priv->broadcast) { + spin_lock_irq(&priv->lock); + memcpy(priv->broadcast->mcmember.mgid.raw, + priv->dev->broadcast + 4, + sizeof(union ib_gid)); + spin_unlock_irq(&priv->lock); + } + return 0; } Patches currently in stable-queue which might be from ferasda(a)mellanox.com are queue-4.9/ib-ipoib-fix-deadlock-between-ipoib_stop-and-mcast-join-flow.patch queue-4.9/ib-ipoib-update-broadcast-object-if-pkey-value-was-changed-in-index-0.patch

7 years, 5 months

1
0
0 0

Patch "IB/ipoib: Fix deadlock between ipoib_stop and mcast join flow" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/ipoib: Fix deadlock between ipoib_stop and mcast join flow to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-ipoib-fix-deadlock-between-ipoib_stop-and-mcast-join-flow.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Feras Daoud <ferasda(a)mellanox.com> Date: Sun, 19 Mar 2017 11:18:55 +0200 Subject: IB/ipoib: Fix deadlock between ipoib_stop and mcast join flow From: Feras Daoud <ferasda(a)mellanox.com> [ Upstream commit 3e31a490e01a6e67cbe9f6e1df2f3ff0fbf48972 ] Before calling ipoib_stop, rtnl_lock should be taken, then the flow clears the IPOIB_FLAG_ADMIN_UP and IPOIB_FLAG_OPER_UP flags, and waits for mcast completion if IPOIB_MCAST_FLAG_BUSY is set. On the other hand, the flow of multicast join task initializes a mcast completion, sets the IPOIB_MCAST_FLAG_BUSY and calls ipoib_mcast_join. If IPOIB_FLAG_OPER_UP flag is not set, this call returns EINVAL without setting the mcast completion and leads to a deadlock. ipoib_stop | | | clear_bit(IPOIB_FLAG_ADMIN_UP) | | | Context Switch | | ipoib_mcast_join_task | | | spin_lock_irq(lock) | | | init_completion(mcast) | | | set_bit(IPOIB_MCAST_FLAG_BUSY) | | | Context Switch | | clear_bit(IPOIB_FLAG_OPER_UP) | | | spin_lock_irqsave(lock) | | | Context Switch | | ipoib_mcast_join | return (-EINVAL) | | | spin_unlock_irq(lock) | | | Context Switch | | ipoib_mcast_dev_flush | wait_for_completion(mcast) | ipoib_stop will wait for mcast completion for ever, and will not release the rtnl_lock. As a result panic occurs with the following trace: [13441.639268] Call Trace: [13441.640150] [<ffffffff8168b579>] schedule+0x29/0x70 [13441.641038] [<ffffffff81688fc9>] schedule_timeout+0x239/0x2d0 [13441.641914] [<ffffffff810bc017>] ? complete+0x47/0x50 [13441.642765] [<ffffffff810a690d>] ? flush_workqueue_prep_pwqs+0x16d/0x200 [13441.643580] [<ffffffff8168b956>] wait_for_completion+0x116/0x170 [13441.644434] [<ffffffff810c4ec0>] ? wake_up_state+0x20/0x20 [13441.645293] [<ffffffffa05af170>] ipoib_mcast_dev_flush+0x150/0x190 [ib_ipoib] [13441.646159] [<ffffffffa05ac967>] ipoib_ib_dev_down+0x37/0x60 [ib_ipoib] [13441.647013] [<ffffffffa05a4805>] ipoib_stop+0x75/0x150 [ib_ipoib] Fixes: 08bc327629cb ("IB/ipoib: fix for rare multicast join race condition") Signed-off-by: Feras Daoud <ferasda(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) --- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c @@ -487,6 +487,9 @@ static int ipoib_mcast_join(struct net_d !test_bit(IPOIB_FLAG_OPER_UP, &priv->flags)) return -EINVAL; + init_completion(&mcast->done); + set_bit(IPOIB_MCAST_FLAG_BUSY, &mcast->flags); + ipoib_dbg_mcast(priv, "joining MGID %pI6\n", mcast->mcmember.mgid.raw); rec.mgid = mcast->mcmember.mgid; @@ -645,8 +648,6 @@ void ipoib_mcast_join_task(struct work_s if (mcast->backoff == 1 || time_after_eq(jiffies, mcast->delay_until)) { /* Found the next unjoined group */ - init_completion(&mcast->done); - set_bit(IPOIB_MCAST_FLAG_BUSY, &mcast->flags); if (ipoib_mcast_join(dev, mcast)) { spin_unlock_irq(&priv->lock); return; @@ -666,11 +667,9 @@ out: queue_delayed_work(priv->wq, &priv->mcast_task, delay_until - jiffies); } - if (mcast) { - init_completion(&mcast->done); - set_bit(IPOIB_MCAST_FLAG_BUSY, &mcast->flags); + if (mcast) ipoib_mcast_join(dev, mcast); - } + spin_unlock_irq(&priv->lock); } Patches currently in stable-queue which might be from ferasda(a)mellanox.com are queue-4.9/ib-ipoib-fix-deadlock-between-ipoib_stop-and-mcast-join-flow.patch queue-4.9/ib-ipoib-update-broadcast-object-if-pkey-value-was-changed-in-index-0.patch

7 years, 5 months

1
0
0 0

Patch "IB/ipoib: Avoid memory leak if the SA returns a different DGID" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/ipoib: Avoid memory leak if the SA returns a different DGID to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-ipoib-avoid-memory-leak-if-the-sa-returns-a-different-dgid.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Erez Shitrit <erezsh(a)mellanox.com> Date: Tue, 14 Nov 2017 14:51:53 +0200 Subject: IB/ipoib: Avoid memory leak if the SA returns a different DGID From: Erez Shitrit <erezsh(a)mellanox.com> [ Upstream commit 439000892ee17a9c92f1e4297818790ef8bb4ced ] The ipoib path database is organized around DGIDs from the LLADDR, but the SA is free to return a different GID when asked for path. This causes a bug because the SA's modified DGID is copied into the database key, even though it is no longer the correct lookup key, causing a memory leak and other malfunctions. Ensure the database key does not change after the SA query completes. Demonstration of the bug is as follows ipoib wants to send to GID fe80:0000:0000:0000:0002:c903:00ef:5ee2, it creates new record in the DB with that gid as a key, and issues a new request to the SM. Now, the SM from some reason returns path-record with other SGID (for example, 2001:0000:0000:0000:0002:c903:00ef:5ee2 that contains the local subnet prefix) now ipoib will overwrite the current entry with the new one, and if new request to the original GID arrives ipoib will not find it in the DB (was overwritten) and will create new record that in its turn will also be overwritten by the response from the SM, and so on till the driver eats all the device memory. Signed-off-by: Erez Shitrit <erezsh(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/ipoib/ipoib_main.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) --- a/drivers/infiniband/ulp/ipoib/ipoib_main.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c @@ -799,6 +799,22 @@ static void path_rec_completion(int stat spin_lock_irqsave(&priv->lock, flags); if (!IS_ERR_OR_NULL(ah)) { + /* + * pathrec.dgid is used as the database key from the LLADDR, + * it must remain unchanged even if the SA returns a different + * GID to use in the AH. + */ + if (memcmp(pathrec->dgid.raw, path->pathrec.dgid.raw, + sizeof(union ib_gid))) { + ipoib_dbg( + priv, + "%s got PathRec for gid %pI6 while asked for %pI6\n", + dev->name, pathrec->dgid.raw, + path->pathrec.dgid.raw); + memcpy(pathrec->dgid.raw, path->pathrec.dgid.raw, + sizeof(union ib_gid)); + } + path->pathrec = *pathrec; old_ah = path->ah; Patches currently in stable-queue which might be from erezsh(a)mellanox.com are queue-4.9/ib-ipoib-update-broadcast-object-if-pkey-value-was-changed-in-index-0.patch queue-4.9/ib-ipoib-avoid-memory-leak-if-the-sa-returns-a-different-dgid.patch

7 years, 5 months

1
0
0 0

Patch "IB/hfi1: Fix softlockup issue" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/hfi1: Fix softlockup issue to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-hfi1-fix-softlockup-issue.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Tadeusz Struk <tadeusz.struk(a)intel.com> Date: Fri, 28 Apr 2017 10:40:02 -0700 Subject: IB/hfi1: Fix softlockup issue From: Tadeusz Struk <tadeusz.struk(a)intel.com> [ Upstream commit 22546b741af8355cd2e16739b6af4a8f17081839 ] Soft lockups can occur because the mad processing on different CPUs acquire the spin lock dc8051_lock: [534552.835870] [<ffffffffa026f993>] ? read_dev_port_cntr.isra.37+0x23/0x160 [hfi1] [534552.835880] [<ffffffffa02775af>] read_dev_cntr+0x4f/0x60 [hfi1] [534552.835893] [<ffffffffa028d7cd>] pma_get_opa_portstatus+0x64d/0x8c0 [hfi1] [534552.835904] [<ffffffffa0290e7d>] hfi1_process_mad+0x48d/0x18c0 [hfi1] [534552.835908] [<ffffffff811dc1f1>] ? __slab_free+0x81/0x2f0 [534552.835936] [<ffffffffa024c34e>] ? ib_mad_recv_done+0x21e/0xa30 [ib_core] [534552.835939] [<ffffffff811dd153>] ? __kmalloc+0x1f3/0x240 [534552.835947] [<ffffffffa024c3fb>] ib_mad_recv_done+0x2cb/0xa30 [ib_core] [534552.835955] [<ffffffffa0237c85>] __ib_process_cq+0x55/0xd0 [ib_core] [534552.835962] [<ffffffffa0237d70>] ib_cq_poll_work+0x20/0x60 [ib_core] [534552.835964] [<ffffffff810a7f3b>] process_one_work+0x17b/0x470 [534552.835966] [<ffffffff810a8d76>] worker_thread+0x126/0x410 [534552.835969] [<ffffffff810a8c50>] ? rescuer_thread+0x460/0x460 [534552.835971] [<ffffffff810b052f>] kthread+0xcf/0xe0 [534552.835974] [<ffffffff810b0460>] ? kthread_create_on_node+0x140/0x140 [534552.835977] [<ffffffff81696418>] ret_from_fork+0x58/0x90 [534552.835980] [<ffffffff810b0460>] ? kthread_create_on_node+0x140/0x140 This issue is made worse when the 8051 is busy and the reads take longer. Fix by using a non-spinning lock procure. Reviewed-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com> Reviewed-by: Mike Marciszyn <mike.marciniszyn(a)intel.com> Signed-off-by: Tadeusz Struk <tadeusz.struk(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/hfi1/chip.c | 86 ++++++++++++++++++++++---------------- drivers/infiniband/hw/hfi1/hfi.h | 7 +-- drivers/infiniband/hw/hfi1/init.c | 2 3 files changed, 57 insertions(+), 38 deletions(-) --- a/drivers/infiniband/hw/hfi1/chip.c +++ b/drivers/infiniband/hw/hfi1/chip.c @@ -6379,18 +6379,17 @@ static void lcb_shutdown(struct hfi1_dev * * The expectation is that the caller of this routine would have taken * care of properly transitioning the link into the correct state. + * NOTE: the caller needs to acquire the dd->dc8051_lock lock + * before calling this function. */ -static void dc_shutdown(struct hfi1_devdata *dd) +static void _dc_shutdown(struct hfi1_devdata *dd) { - unsigned long flags; + lockdep_assert_held(&dd->dc8051_lock); - spin_lock_irqsave(&dd->dc8051_lock, flags); - if (dd->dc_shutdown) { - spin_unlock_irqrestore(&dd->dc8051_lock, flags); + if (dd->dc_shutdown) return; - } + dd->dc_shutdown = 1; - spin_unlock_irqrestore(&dd->dc8051_lock, flags); /* Shutdown the LCB */ lcb_shutdown(dd, 1); /* @@ -6401,35 +6400,45 @@ static void dc_shutdown(struct hfi1_devd write_csr(dd, DC_DC8051_CFG_RST, 0x1); } +static void dc_shutdown(struct hfi1_devdata *dd) +{ + mutex_lock(&dd->dc8051_lock); + _dc_shutdown(dd); + mutex_unlock(&dd->dc8051_lock); +} + /* * Calling this after the DC has been brought out of reset should not * do any damage. + * NOTE: the caller needs to acquire the dd->dc8051_lock lock + * before calling this function. */ -static void dc_start(struct hfi1_devdata *dd) +static void _dc_start(struct hfi1_devdata *dd) { - unsigned long flags; - int ret; + lockdep_assert_held(&dd->dc8051_lock); - spin_lock_irqsave(&dd->dc8051_lock, flags); if (!dd->dc_shutdown) - goto done; - spin_unlock_irqrestore(&dd->dc8051_lock, flags); + return; + /* Take the 8051 out of reset */ write_csr(dd, DC_DC8051_CFG_RST, 0ull); /* Wait until 8051 is ready */ - ret = wait_fm_ready(dd, TIMEOUT_8051_START); - if (ret) { + if (wait_fm_ready(dd, TIMEOUT_8051_START)) dd_dev_err(dd, "%s: timeout starting 8051 firmware\n", __func__); - } + /* Take away reset for LCB and RX FPE (set in lcb_shutdown). */ write_csr(dd, DCC_CFG_RESET, 0x10); /* lcb_shutdown() with abort=1 does not restore these */ write_csr(dd, DC_LCB_ERR_EN, dd->lcb_err_en); - spin_lock_irqsave(&dd->dc8051_lock, flags); dd->dc_shutdown = 0; -done: - spin_unlock_irqrestore(&dd->dc8051_lock, flags); +} + +static void dc_start(struct hfi1_devdata *dd) +{ + mutex_lock(&dd->dc8051_lock); + _dc_start(dd); + mutex_unlock(&dd->dc8051_lock); } /* @@ -8418,16 +8427,11 @@ static int do_8051_command( { u64 reg, completed; int return_code; - unsigned long flags; unsigned long timeout; hfi1_cdbg(DC8051, "type %d, data 0x%012llx", type, in_data); - /* - * Alternative to holding the lock for a long time: - * - keep busy wait - have other users bounce off - */ - spin_lock_irqsave(&dd->dc8051_lock, flags); + mutex_lock(&dd->dc8051_lock); /* We can't send any commands to the 8051 if it's in reset */ if (dd->dc_shutdown) { @@ -8453,10 +8457,8 @@ static int do_8051_command( return_code = -ENXIO; goto fail; } - spin_unlock_irqrestore(&dd->dc8051_lock, flags); - dc_shutdown(dd); - dc_start(dd); - spin_lock_irqsave(&dd->dc8051_lock, flags); + _dc_shutdown(dd); + _dc_start(dd); } /* @@ -8534,8 +8536,7 @@ static int do_8051_command( write_csr(dd, DC_DC8051_CFG_HOST_CMD_0, 0); fail: - spin_unlock_irqrestore(&dd->dc8051_lock, flags); - + mutex_unlock(&dd->dc8051_lock); return return_code; } @@ -11849,6 +11850,10 @@ static void free_cntrs(struct hfi1_devda dd->scntrs = NULL; kfree(dd->cntrnames); dd->cntrnames = NULL; + if (dd->update_cntr_wq) { + destroy_workqueue(dd->update_cntr_wq); + dd->update_cntr_wq = NULL; + } } static u64 read_dev_port_cntr(struct hfi1_devdata *dd, struct cntr_entry *entry, @@ -12004,7 +12009,7 @@ u64 write_port_cntr(struct hfi1_pportdat return write_dev_port_cntr(ppd->dd, entry, sval, ppd, vl, data); } -static void update_synth_timer(unsigned long opaque) +static void do_update_synth_timer(struct work_struct *work) { u64 cur_tx; u64 cur_rx; @@ -12013,8 +12018,8 @@ static void update_synth_timer(unsigned int i, j, vl; struct hfi1_pportdata *ppd; struct cntr_entry *entry; - - struct hfi1_devdata *dd = (struct hfi1_devdata *)opaque; + struct hfi1_devdata *dd = container_of(work, struct hfi1_devdata, + update_cntr_work); /* * Rather than keep beating on the CSRs pick a minimal set that we can @@ -12097,7 +12102,13 @@ static void update_synth_timer(unsigned } else { hfi1_cdbg(CNTR, "[%d] No update necessary", dd->unit); } +} + +static void update_synth_timer(unsigned long opaque) +{ + struct hfi1_devdata *dd = (struct hfi1_devdata *)opaque; + queue_work(dd->update_cntr_wq, &dd->update_cntr_work); mod_timer(&dd->synth_stats_timer, jiffies + HZ * SYNTH_CNT_TIME); } @@ -12333,6 +12344,13 @@ static int init_cntrs(struct hfi1_devdat if (init_cpu_counters(dd)) goto bail; + dd->update_cntr_wq = alloc_ordered_workqueue("hfi1_update_cntr_%d", + WQ_MEM_RECLAIM, dd->unit); + if (!dd->update_cntr_wq) + goto bail; + + INIT_WORK(&dd->update_cntr_work, do_update_synth_timer); + mod_timer(&dd->synth_stats_timer, jiffies + HZ * SYNTH_CNT_TIME); return 0; bail: --- a/drivers/infiniband/hw/hfi1/hfi.h +++ b/drivers/infiniband/hw/hfi1/hfi.h @@ -475,7 +475,7 @@ struct rvt_sge_state; #define HFI1_PART_ENFORCE_OUT 0x2 /* how often we check for synthetic counter wrap around */ -#define SYNTH_CNT_TIME 2 +#define SYNTH_CNT_TIME 3 /* Counter flags */ #define CNTR_NORMAL 0x0 /* Normal counters, just read register */ @@ -929,8 +929,9 @@ struct hfi1_devdata { spinlock_t rcvctrl_lock; /* protect changes to RcvCtrl */ /* around rcd and (user ctxts) ctxt_cnt use (intr vs free) */ spinlock_t uctxt_lock; /* rcd and user context changes */ - /* exclusive access to 8051 */ - spinlock_t dc8051_lock; + struct mutex dc8051_lock; /* exclusive access to 8051 */ + struct workqueue_struct *update_cntr_wq; + struct work_struct update_cntr_work; /* exclusive access to 8051 memory */ spinlock_t dc8051_memlock; int dc8051_timed_out; /* remember if the 8051 timed out */ --- a/drivers/infiniband/hw/hfi1/init.c +++ b/drivers/infiniband/hw/hfi1/init.c @@ -1078,11 +1078,11 @@ struct hfi1_devdata *hfi1_alloc_devdata( spin_lock_init(&dd->uctxt_lock); spin_lock_init(&dd->hfi1_diag_trans_lock); spin_lock_init(&dd->sc_init_lock); - spin_lock_init(&dd->dc8051_lock); spin_lock_init(&dd->dc8051_memlock); seqlock_init(&dd->sc2vl_lock); spin_lock_init(&dd->sde_map_lock); spin_lock_init(&dd->pio_map_lock); + mutex_init(&dd->dc8051_lock); init_waitqueue_head(&dd->event_queue); dd->int_counter = alloc_percpu(u64); Patches currently in stable-queue which might be from tadeusz.struk(a)intel.com are queue-4.9/ib-hfi1-fix-softlockup-issue.patch

7 years, 5 months

1
0
0 0

Patch "ia64: fix module loading for gcc-5.4" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ia64: fix module loading for gcc-5.4 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ia64-fix-module-loading-for-gcc-5.4.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Sergei Trofimovich <slyfox(a)gentoo.org> Date: Mon, 1 May 2017 11:51:55 -0700 Subject: ia64: fix module loading for gcc-5.4 From: Sergei Trofimovich <slyfox(a)gentoo.org> [ Upstream commit a25fb8508c1b80dce742dbeaa4d75a1e9f2c5617 ] Starting from gcc-5.4+ gcc generates MLX instructions in more cases to refer local symbols: https://gcc.gnu.org/PR60465 That caused ia64 module loader to choke on such instructions: fuse: invalid slot number 1 for IMM64 The Linux kernel used to handle only case where relocation pointed to slot=2 instruction in the bundle. That limitation was fixed in linux by commit 9c184a073bfd ("[IA64] Fix 2.6 kernel for the new ia64 assembler") See http://sources.redhat.com/bugzilla/show_bug.cgi?id=1433 This change lifts the slot=2 restriction from the kernel module loader. Tested on 'fuse' and 'btrfs' kernel modules. Cc: Markus Elfring <elfring(a)users.sourceforge.net> Cc: H J Lu <hjl.tools(a)gmail.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Bug: https://bugs.gentoo.org/601014 Tested-by: Émeric MASCHINO <emeric.maschino(a)gmail.com> Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> Signed-off-by: Tony Luck <tony.luck(a)intel.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/ia64/kernel/module.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/ia64/kernel/module.c +++ b/arch/ia64/kernel/module.c @@ -153,7 +153,7 @@ slot (const struct insn *insn) static int apply_imm64 (struct module *mod, struct insn *insn, uint64_t val) { - if (slot(insn) != 2) { + if (slot(insn) != 1 && slot(insn) != 2) { printk(KERN_ERR "%s: invalid slot number %d for IMM64\n", mod->name, slot(insn)); return 0; @@ -165,7 +165,7 @@ apply_imm64 (struct module *mod, struct static int apply_imm60 (struct module *mod, struct insn *insn, uint64_t val) { - if (slot(insn) != 2) { + if (slot(insn) != 1 && slot(insn) != 2) { printk(KERN_ERR "%s: invalid slot number %d for IMM60\n", mod->name, slot(insn)); return 0; Patches currently in stable-queue which might be from slyfox(a)gentoo.org are queue-4.9/ia64-fix-module-loading-for-gcc-5.4.patch

7 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror