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

[Linux-stable-mirror] Patch "Revert "x86/acpi: Set persistent cpuid <-> nodeid mapping when booting"" 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 Revert "x86/acpi: Set persistent cpuid <-> nodeid mapping when booting" 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: revert-x86-acpi-set-persistent-cpuid-nodeid-mapping-when-booting.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 Mon Dec 18 14:12:34 CET 2017 From: Dou Liyang <douly.fnst(a)cn.fujitsu.com> Date: Fri, 3 Mar 2017 16:02:23 +0800 Subject: Revert "x86/acpi: Set persistent cpuid <-> nodeid mapping when booting" From: Dou Liyang <douly.fnst(a)cn.fujitsu.com> [ Upstream commit c962cff17dfa11f4a8227ac16de2b28aea3312e4 ] Revert: dc6db24d2476 ("x86/acpi: Set persistent cpuid <-> nodeid mapping when booting") The mapping of "cpuid <-> nodeid" is established at boot time via ACPI tables to keep associations of workqueues and other node related items consistent across cpu hotplug. But, ACPI tables are unreliable and failures with that boot time mapping have been reported on machines where the ACPI table and the physical information which is retrieved at actual hotplug is inconsistent. Revert the mapping implementation so it can be replaced with a less error prone approach. Signed-off-by: Dou Liyang <douly.fnst(a)cn.fujitsu.com> Tested-by: Xiaolong Ye <xiaolong.ye(a)intel.com> Cc: rjw(a)rjwysocki.net Cc: linux-acpi(a)vger.kernel.org Cc: guzheng1(a)huawei.com Cc: izumi.taku(a)jp.fujitsu.com Cc: lenb(a)kernel.org Link: http://lkml.kernel.org/r/1488528147-2279-2-git-send-email-douly.fnst@cn.fuj… Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/acpi/boot.c | 2 - drivers/acpi/acpi_processor.c | 5 -- drivers/acpi/bus.c | 1 drivers/acpi/processor_core.c | 73 ------------------------------------------ include/linux/acpi.h | 3 - 5 files changed, 1 insertion(+), 83 deletions(-) --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -720,7 +720,7 @@ static void __init acpi_set_irq_model_io #ifdef CONFIG_ACPI_HOTPLUG_CPU #include <acpi/processor.h> -int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid) +static int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid) { #ifdef CONFIG_ACPI_NUMA int nid; --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -182,11 +182,6 @@ int __weak arch_register_cpu(int cpu) void __weak arch_unregister_cpu(int cpu) {} -int __weak acpi_map_cpu2node(acpi_handle handle, int cpu, int physid) -{ - return -ENODEV; -} - static int acpi_processor_hotadd_init(struct acpi_processor *pr) { unsigned long long sta; --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -1197,7 +1197,6 @@ static int __init acpi_init(void) acpi_wakeup_device_init(); acpi_debugger_init(); acpi_setup_sb_notify_handler(); - acpi_set_processor_mapping(); return 0; } --- a/drivers/acpi/processor_core.c +++ b/drivers/acpi/processor_core.c @@ -280,79 +280,6 @@ int acpi_get_cpuid(acpi_handle handle, i } EXPORT_SYMBOL_GPL(acpi_get_cpuid); -#ifdef CONFIG_ACPI_HOTPLUG_CPU -static bool __init -map_processor(acpi_handle handle, phys_cpuid_t *phys_id, int *cpuid) -{ - int type, id; - u32 acpi_id; - acpi_status status; - acpi_object_type acpi_type; - unsigned long long tmp; - union acpi_object object = { 0 }; - struct acpi_buffer buffer = { sizeof(union acpi_object), &object }; - - status = acpi_get_type(handle, &acpi_type); - if (ACPI_FAILURE(status)) - return false; - - switch (acpi_type) { - case ACPI_TYPE_PROCESSOR: - status = acpi_evaluate_object(handle, NULL, NULL, &buffer); - if (ACPI_FAILURE(status)) - return false; - acpi_id = object.processor.proc_id; - - /* validate the acpi_id */ - if(acpi_processor_validate_proc_id(acpi_id)) - return false; - break; - case ACPI_TYPE_DEVICE: - status = acpi_evaluate_integer(handle, "_UID", NULL, &tmp); - if (ACPI_FAILURE(status)) - return false; - acpi_id = tmp; - break; - default: - return false; - } - - type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0; - - *phys_id = __acpi_get_phys_id(handle, type, acpi_id, false); - id = acpi_map_cpuid(*phys_id, acpi_id); - - if (id < 0) - return false; - *cpuid = id; - return true; -} - -static acpi_status __init -set_processor_node_mapping(acpi_handle handle, u32 lvl, void *context, - void **rv) -{ - phys_cpuid_t phys_id; - int cpu_id; - - if (!map_processor(handle, &phys_id, &cpu_id)) - return AE_ERROR; - - acpi_map_cpu2node(handle, cpu_id, phys_id); - return AE_OK; -} - -void __init acpi_set_processor_mapping(void) -{ - /* Set persistent cpu <-> node mapping for all processors. */ - acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT, - ACPI_UINT32_MAX, set_processor_node_mapping, - NULL, NULL, NULL); -} -#else -void __init acpi_set_processor_mapping(void) {} -#endif /* CONFIG_ACPI_HOTPLUG_CPU */ - #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC static int get_ioapic_id(struct acpi_subtable_header *entry, u32 gsi_base, u64 *phys_addr, int *ioapic_id) --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -276,11 +276,8 @@ bool acpi_processor_validate_proc_id(int /* Arch dependent functions for cpu hotplug support */ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, int *pcpu); int acpi_unmap_cpu(int cpu); -int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid); #endif /* CONFIG_ACPI_HOTPLUG_CPU */ -void acpi_set_processor_mapping(void); - #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr); #endif Patches currently in stable-queue which might be from douly.fnst(a)cn.fujitsu.com are queue-4.9/revert-x86-acpi-set-persistent-cpuid-nodeid-mapping-when-booting.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "RDMA/cxgb4: Declare stag as __be32" 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 RDMA/cxgb4: Declare stag as __be32 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: rdma-cxgb4-declare-stag-as-__be32.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 Mon Dec 18 14:12:35 CET 2017 From: Leon Romanovsky <leon(a)kernel.org> Date: Wed, 25 Oct 2017 07:41:11 +0300 Subject: RDMA/cxgb4: Declare stag as __be32 From: Leon Romanovsky <leon(a)kernel.org> [ Upstream commit 35fb2a88ed4b77356fa679a8525c869a3594e287 ] The scqe.stag is actually __b32, fix it. drivers/infiniband/hw/cxgb4/cq.c:754:52: warning: cast to restricted __be32 Cc: Steve Wise <swise(a)opengridcomputing.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Reviewed-by: Steve Wise <swise(a)opengridcomputing.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/cxgb4/t4.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/hw/cxgb4/t4.h +++ b/drivers/infiniband/hw/cxgb4/t4.h @@ -171,7 +171,7 @@ struct t4_cqe { __be32 msn; } rcqe; struct { - u32 stag; + __be32 stag; u16 nada2; u16 cidx; } scqe; Patches currently in stable-queue which might be from leon(a)kernel.org are queue-4.9/ib-core-fix-calculation-of-maximum-roce-mtu.patch queue-4.9/rdma-cxgb4-declare-stag-as-__be32.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "RDMA/cma: Avoid triggering undefined behavior" 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 RDMA/cma: Avoid triggering undefined behavior 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: rdma-cma-avoid-triggering-undefined-behavior.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 Mon Dec 18 14:12:35 CET 2017 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Wed, 11 Oct 2017 10:48:45 -0700 Subject: RDMA/cma: Avoid triggering undefined behavior From: Bart Van Assche <bart.vanassche(a)wdc.com> [ Upstream commit c0b64f58e8d49570aa9ee55d880f92c20ff0166b ] According to the C standard the behavior of computations with integer operands is as follows: * A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type. * The behavior for signed integer underflow and overflow is undefined. Hence only use unsigned integers when checking for integer overflow. This patch is what I came up with after having analyzed the following smatch warnings: drivers/infiniband/core/cma.c:3448: cma_resolve_ib_udp() warn: signed overflow undefined. 'offset + conn_param->private_data_len < conn_param->private_data_len' drivers/infiniband/core/cma.c:3505: cma_connect_ib() warn: signed overflow undefined. 'offset + conn_param->private_data_len < conn_param->private_data_len' Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Acked-by: Sean Hefty <sean.hefty(a)intel.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/cma.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband/core/cma.c @@ -1482,7 +1482,7 @@ static struct rdma_id_private *cma_id_fr return id_priv; } -static inline int cma_user_data_offset(struct rdma_id_private *id_priv) +static inline u8 cma_user_data_offset(struct rdma_id_private *id_priv) { return cma_family(id_priv) == AF_IB ? 0 : sizeof(struct cma_hdr); } @@ -1877,7 +1877,8 @@ static int cma_req_handler(struct ib_cm_ struct rdma_id_private *listen_id, *conn_id = NULL; struct rdma_cm_event event; struct net_device *net_dev; - int offset, ret; + u8 offset; + int ret; listen_id = cma_id_from_event(cm_id, ib_event, &net_dev); if (IS_ERR(listen_id)) @@ -3309,7 +3310,8 @@ static int cma_resolve_ib_udp(struct rdm struct ib_cm_sidr_req_param req; struct ib_cm_id *id; void *private_data; - int offset, ret; + u8 offset; + int ret; memset(&req, 0, sizeof req); offset = cma_user_data_offset(id_priv); @@ -3366,7 +3368,8 @@ static int cma_connect_ib(struct rdma_id struct rdma_route *route; void *private_data; struct ib_cm_id *id; - int offset, ret; + u8 offset; + int ret; memset(&req, 0, sizeof req); offset = cma_user_data_offset(id_priv); Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.9/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch queue-4.9/rdma-cma-avoid-triggering-undefined-behavior.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "raid5: Set R5_Expanded on parity devices as well as data." 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 raid5: Set R5_Expanded on parity devices as well as data. 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: raid5-set-r5_expanded-on-parity-devices-as-well-as-data.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 Mon Dec 18 14:12:35 CET 2017 From: NeilBrown <neilb(a)suse.com> Date: Tue, 17 Oct 2017 16:18:36 +1100 Subject: raid5: Set R5_Expanded on parity devices as well as data. From: NeilBrown <neilb(a)suse.com> [ Upstream commit 235b6003fb28f0dd8e7ed8fbdb088bb548291766 ] When reshaping a fully degraded raid5/raid6 to a larger nubmer of devices, the new device(s) are not in-sync and so that can make the newly grown stripe appear to be "failed". To avoid this, we set the R5_Expanded flag to say "Even though this device is not fully in-sync, this block is safe so don't treat the device as failed for this stripe". This flag is set for data devices, not not for parity devices. Consequently, if you have a RAID6 with two devices that are partly recovered and a spare, and start a reshape to include the spare, then when the reshape gets past the point where the recovery was up to, it will think the stripes are failed and will get into an infinite loop, failing to make progress. So when contructing parity on an EXPAND_READY stripe, set R5_Expanded. Reported-by: Curt <lightspd(a)gmail.com> Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Shaohua Li <shli(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/raid5.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -1689,8 +1689,11 @@ static void ops_complete_reconstruct(voi struct r5dev *dev = &sh->dev[i]; if (dev->written || i == pd_idx || i == qd_idx) { - if (!discard && !test_bit(R5_SkipCopy, &dev->flags)) + if (!discard && !test_bit(R5_SkipCopy, &dev->flags)) { set_bit(R5_UPTODATE, &dev->flags); + if (test_bit(STRIPE_EXPAND_READY, &sh->state)) + set_bit(R5_Expanded, &dev->flags); + } if (fua) set_bit(R5_WantFUA, &dev->flags); if (sync) Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.9/md-cluster-free-md_cluster_info-if-node-leave-cluster.patch queue-4.9/autofs-fix-careless-error-in-recent-commit.patch queue-4.9/raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch queue-4.9/nfsd-fix-nfsd_reset_versions-for-nfsv4.patch queue-4.9/nfsd-fix-nfsd_minorversion-..-nfsd_avail.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "qed: Fix mapping leak on LL2 rx 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 qed: Fix mapping leak on LL2 rx 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: qed-fix-mapping-leak-on-ll2-rx-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 Mon Dec 18 14:12:34 CET 2017 From: "Mintz, Yuval" <Yuval.Mintz(a)cavium.com> Date: Tue, 14 Mar 2017 15:26:00 +0200 Subject: qed: Fix mapping leak on LL2 rx flow From: "Mintz, Yuval" <Yuval.Mintz(a)cavium.com> [ Upstream commit 752ecb2da11124a948567076b60767dc8034cfa5 ] When receiving an Rx LL2 packet, qed fails to unmap the previous buffer. Fixes: 0a7fb11c23c0 ("qed: Add Light L2 support"); Signed-off-by: Yuval Mintz <Yuval.Mintz(a)cavium.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/qlogic/qed/qed_ll2.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/net/ethernet/qlogic/qed/qed_ll2.c +++ b/drivers/net/ethernet/qlogic/qed/qed_ll2.c @@ -187,6 +187,8 @@ static void qed_ll2b_complete_rx_packet( /* If need to reuse or there's no replacement buffer, repost this */ if (rc) goto out_post; + dma_unmap_single(&cdev->pdev->dev, buffer->phys_addr, + cdev->ll2->rx_size, DMA_FROM_DEVICE); skb = build_skb(buffer->data, 0); if (!skb) { Patches currently in stable-queue which might be from Yuval.Mintz(a)cavium.com are queue-4.9/qed-fix-interrupt-flags-on-rx-ll2.patch queue-4.9/qed-align-cids-according-to-dorq-requirement.patch queue-4.9/qed-fix-mapping-leak-on-ll2-rx-flow.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "qed: Fix interrupt flags on Rx LL2" 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 qed: Fix interrupt flags on Rx LL2 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: qed-fix-interrupt-flags-on-rx-ll2.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 Mon Dec 18 14:12:34 CET 2017 From: Ram Amrani <Ram.Amrani(a)cavium.com> Date: Tue, 14 Mar 2017 15:26:02 +0200 Subject: qed: Fix interrupt flags on Rx LL2 From: Ram Amrani <Ram.Amrani(a)cavium.com> [ Upstream commit 1df2adedcce17ad4a39fba74f0e2b611f797fe10 ] Before iterating over the the LL2 Rx ring, the ring's spinlock is taken via spin_lock_irqsave(). The actual processing of the packet [including handling by the protocol driver] is done without said lock, so qed releases the spinlock and re-claims it afterwards. Problem is that the final spin_lock_irqrestore() at the end of the iteration uses the original flags saved from the initial irqsave() instead of the flags from the most recent irqsave(). So it's possible that the interrupt status would be incorrect at the end of the processing. Fixes: 0a7fb11c23c0 ("qed: Add Light L2 support"); CC: Ram Amrani <Ram.Amrani(a)cavium.com> Signed-off-by: Yuval Mintz <Yuval.Mintz(a)cavium.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/qlogic/qed/qed_ll2.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- a/drivers/net/ethernet/qlogic/qed/qed_ll2.c +++ b/drivers/net/ethernet/qlogic/qed/qed_ll2.c @@ -443,7 +443,7 @@ qed_ll2_rxq_completion_gsi(struct qed_hw static int qed_ll2_rxq_completion_reg(struct qed_hwfn *p_hwfn, struct qed_ll2_info *p_ll2_conn, union core_rx_cqe_union *p_cqe, - unsigned long lock_flags, + unsigned long *p_lock_flags, bool b_last_cqe) { struct qed_ll2_rx_queue *p_rx = &p_ll2_conn->rx_queue; @@ -464,10 +464,10 @@ static int qed_ll2_rxq_completion_reg(st "Mismatch between active_descq and the LL2 Rx chain\n"); list_add_tail(&p_pkt->list_entry, &p_rx->free_descq); - spin_unlock_irqrestore(&p_rx->lock, lock_flags); + spin_unlock_irqrestore(&p_rx->lock, *p_lock_flags); qed_ll2b_complete_rx_packet(p_hwfn, p_ll2_conn->my_id, p_pkt, &p_cqe->rx_cqe_fp, b_last_cqe); - spin_lock_irqsave(&p_rx->lock, lock_flags); + spin_lock_irqsave(&p_rx->lock, *p_lock_flags); return 0; } @@ -507,7 +507,8 @@ static int qed_ll2_rxq_completion(struct break; case CORE_RX_CQE_TYPE_REGULAR: rc = qed_ll2_rxq_completion_reg(p_hwfn, p_ll2_conn, - cqe, flags, b_last_cqe); + cqe, &flags, + b_last_cqe); break; default: rc = -EIO; Patches currently in stable-queue which might be from Ram.Amrani(a)cavium.com are queue-4.9/qed-fix-interrupt-flags-on-rx-ll2.patch queue-4.9/qed-align-cids-according-to-dorq-requirement.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "qed: Align CIDs according to DORQ requirement" 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 qed: Align CIDs according to DORQ requirement 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: qed-align-cids-according-to-dorq-requirement.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 Mon Dec 18 14:12:34 CET 2017 From: Ram Amrani <Ram.Amrani(a)cavium.com> Date: Tue, 14 Mar 2017 15:25:58 +0200 Subject: qed: Align CIDs according to DORQ requirement From: Ram Amrani <Ram.Amrani(a)cavium.com> [ Upstream commit f3e48119b97f56fb09310c95d49da122a27003d7 ] The Doorbell HW block can be configured at a granularity of 16 x CIDs, so we need to make sure that the actual number of CIDs configured would be a multiplication of 16. Today, when RoCE is enabled - given that the number is unaligned, doorbelling the higher CIDs would fail to reach the firmware and would eventually timeout. Fixes: dbb799c39717 ("qed: Initialize hardware for new protocols") Signed-off-by: Ram Amrani <Ram.Amrani(a)cavium.com> Signed-off-by: Yuval Mintz <Yuval.Mintz(a)cavium.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/qlogic/qed/qed_cxt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/net/ethernet/qlogic/qed/qed_cxt.c +++ b/drivers/net/ethernet/qlogic/qed/qed_cxt.c @@ -373,8 +373,9 @@ static void qed_cxt_set_proto_cid_count( u32 page_sz = p_mgr->clients[ILT_CLI_CDUC].p_size.val; u32 cxt_size = CONN_CXT_SIZE(p_hwfn); u32 elems_per_page = ILT_PAGE_IN_BYTES(page_sz) / cxt_size; + u32 align = elems_per_page * DQ_RANGE_ALIGN; - p_conn->cid_count = roundup(p_conn->cid_count, elems_per_page); + p_conn->cid_count = roundup(p_conn->cid_count, align); } } Patches currently in stable-queue which might be from Ram.Amrani(a)cavium.com are queue-4.9/qed-fix-interrupt-flags-on-rx-ll2.patch queue-4.9/qed-align-cids-according-to-dorq-requirement.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "ppp: Destroy the mutex when cleanup" 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 ppp: Destroy the mutex when cleanup 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: ppp-destroy-the-mutex-when-cleanup.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 Mon Dec 18 14:12:35 CET 2017 From: Gao Feng <gfree.wind(a)vip.163.com> Date: Tue, 31 Oct 2017 18:25:37 +0800 Subject: ppp: Destroy the mutex when cleanup From: Gao Feng <gfree.wind(a)vip.163.com> [ Upstream commit f02b2320b27c16b644691267ee3b5c110846f49e ] The mutex_destroy only makes sense when enable DEBUG_MUTEX. For the good readbility, it's better to invoke it in exit func when the init func invokes mutex_init. Signed-off-by: Gao Feng <gfree.wind(a)vip.163.com> Acked-by: Guillaume Nault <g.nault(a)alphalink.fr> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ppp/ppp_generic.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/ppp/ppp_generic.c +++ b/drivers/net/ppp/ppp_generic.c @@ -958,6 +958,7 @@ static __net_exit void ppp_exit_net(stru unregister_netdevice_many(&list); rtnl_unlock(); + mutex_destroy(&pn->all_ppp_mutex); idr_destroy(&pn->units_idr); } Patches currently in stable-queue which might be from gfree.wind(a)vip.163.com are queue-4.9/ppp-destroy-the-mutex-when-cleanup.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo" 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 powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo 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: powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.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 Mon Dec 18 14:12:34 CET 2017 From: Shriya <shriyak(a)linux.vnet.ibm.com> Date: Fri, 13 Oct 2017 10:06:41 +0530 Subject: powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo From: Shriya <shriyak(a)linux.vnet.ibm.com> [ Upstream commit cd77b5ce208c153260ed7882d8910f2395bfaabd ] The call to /proc/cpuinfo in turn calls cpufreq_quick_get() which returns the last frequency requested by the kernel, but may not reflect the actual frequency the processor is running at. This patch makes a call to cpufreq_get() instead which returns the current frequency reported by the hardware. Fixes: fb5153d05a7d ("powerpc: powernv: Implement ppc_md.get_proc_freq()") Signed-off-by: Shriya <shriyak(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/platforms/powernv/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/platforms/powernv/setup.c +++ b/arch/powerpc/platforms/powernv/setup.c @@ -289,7 +289,7 @@ static unsigned long pnv_get_proc_freq(u { unsigned long ret_freq; - ret_freq = cpufreq_quick_get(cpu) * 1000ul; + ret_freq = cpufreq_get(cpu) * 1000ul; /* * If the backend cpufreq driver does not exist, Patches currently in stable-queue which might be from shriyak(a)linux.vnet.ibm.com are queue-4.9/powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/perf/hv-24x7: Fix incorrect comparison in memord" 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 powerpc/perf/hv-24x7: Fix incorrect comparison in memord 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: powerpc-perf-hv-24x7-fix-incorrect-comparison-in-memord.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 Mon Dec 18 14:12:35 CET 2017 From: Michael Ellerman <mpe(a)ellerman.id.au> Date: Mon, 9 Oct 2017 21:52:44 +1100 Subject: powerpc/perf/hv-24x7: Fix incorrect comparison in memord From: Michael Ellerman <mpe(a)ellerman.id.au> [ Upstream commit 05c14c03138532a3cb2aa29c2960445c8753343b ] In the hv-24x7 code there is a function memord() which tries to implement a sort function return -1, 0, 1. However one of the conditions is incorrect, such that it can never be true, because we will have already returned. I don't believe there is a bug in practice though, because the comparisons are an optimisation prior to calling memcmp(). Fix it by swapping the second comparision, so it can be true. Reported-by: David Binderman <dcb314(a)hotmail.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/perf/hv-24x7.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/perf/hv-24x7.c +++ b/arch/powerpc/perf/hv-24x7.c @@ -516,7 +516,7 @@ static int memord(const void *d1, size_t { if (s1 < s2) return 1; - if (s2 > s1) + if (s1 > s2) return -1; return memcmp(d1, d2, s1); Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are queue-4.9/powerpc-perf-hv-24x7-fix-incorrect-comparison-in-memord.patch queue-4.9/powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch queue-4.9/powerpc-ipic-fix-status-get-and-status-clear.patch queue-4.9/powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch

7 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror