December 2017 - Linux-stable-mirror

[Linux-stable-mirror] Patch "rpmsg: glink: Initialize the "intent_req_comp" completion variable" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rpmsg: glink: Initialize the "intent_req_comp" completion variable to the 4.14-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: rpmsg-glink-initialize-the-intent_req_comp-completion-variable.patch and it can be found in the queue-4.14 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 13:28:59 CET 2017 From: Arun Kumar Neelakantam <aneela(a)codeaurora.org> Date: Mon, 30 Oct 2017 11:11:24 +0530 Subject: rpmsg: glink: Initialize the "intent_req_comp" completion variable From: Arun Kumar Neelakantam <aneela(a)codeaurora.org> [ Upstream commit 2394facb17bcace4b3c19b50202177a5d8903b64 ] The "intent_req_comp" variable is used without initialization which results in NULL pointer dereference in qcom_glink_request_intent(). we need to initialize the completion variable before using it. Fixes: 27b9c5b66b23 ("rpmsg: glink: Request for intents when unavailable") Signed-off-by: Arun Kumar Neelakantam <aneela(a)codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/rpmsg/qcom_glink_native.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/rpmsg/qcom_glink_native.c +++ b/drivers/rpmsg/qcom_glink_native.c @@ -227,6 +227,7 @@ static struct glink_channel *qcom_glink_ init_completion(&channel->open_req); init_completion(&channel->open_ack); + init_completion(&channel->intent_req_comp); INIT_LIST_HEAD(&channel->done_intents); INIT_WORK(&channel->intent_work, qcom_glink_rx_done_work); Patches currently in stable-queue which might be from aneela(a)codeaurora.org are queue-4.14/rpmsg-glink-initialize-the-intent_req_comp-completion-variable.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "RDMA/cxgb4: Declare stag as __be32" has been added to the 4.14-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.14-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.14 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 13:28:59 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.14/ib-core-don-t-enforce-pkey-security-on-smi-mads.patch queue-4.14/ib-core-bound-check-alternate-path-port-number.patch queue-4.14/ib-core-fix-calculation-of-maximum-roce-mtu.patch queue-4.14/ib-core-fix-use-workqueue-without-wq_mem_reclaim.patch queue-4.14/ib-mlx4-fix-rss-s-qpc-attributes-assignments.patch queue-4.14/rdma-cxgb4-declare-stag-as-__be32.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "RDMA/cma: Avoid triggering undefined behavior" has been added to the 4.14-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.14-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.14 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 13:29:00 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 @@ -1540,7 +1540,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); } @@ -1942,7 +1942,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)) @@ -3440,7 +3441,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); @@ -3497,7 +3499,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.14/ib-core-fix-endianness-annotation-in-rdma_is_multicast_addr.patch queue-4.14/target-iscsi-detect-conn_cmd_list-corruption-early.patch queue-4.14/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch queue-4.14/rdma-cma-avoid-triggering-undefined-behavior.patch queue-4.14/scsi-core-fix-a-scsi_show_rq-null-pointer-dereference.patch queue-4.14/blk-mq-sched-dispatch-from-scheduler-iff-progress-is-made-in-dispatch.patch

7 years

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.14-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.14-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.14 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 13:29:00 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 @@ -1818,8 +1818,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.14/autofs-fix-careless-error-in-recent-commit.patch queue-4.14/raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch queue-4.14/kernel-make-groups_sort-calling-a-responsibility-group_info-allocators.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "raid5-ppl: check recovery_offset when performing ppl recovery" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled raid5-ppl: check recovery_offset when performing ppl recovery to the 4.14-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-ppl-check-recovery_offset-when-performing-ppl-recovery.patch and it can be found in the queue-4.14 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 13:29:00 CET 2017 From: Artur Paszkiewicz <artur.paszkiewicz(a)intel.com> Date: Fri, 29 Sep 2017 22:54:19 +0200 Subject: raid5-ppl: check recovery_offset when performing ppl recovery From: Artur Paszkiewicz <artur.paszkiewicz(a)intel.com> [ Upstream commit 07719ff767dcd8cc42050f185d332052f3816546 ] If starting an array that is undergoing rebuild, make ppl recovery honor the recovery_offset of a member disk and don't read data that is not yet in-sync. Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz(a)intel.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-ppl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/md/raid5-ppl.c +++ b/drivers/md/raid5-ppl.c @@ -758,7 +758,8 @@ static int ppl_recover_entry(struct ppl_ (unsigned long long)sector); rdev = conf->disks[dd_idx].rdev; - if (!rdev) { + if (!rdev || (!test_bit(In_sync, &rdev->flags) && + sector >= rdev->recovery_offset)) { pr_debug("%s:%*s data member disk %d missing\n", __func__, indent, "", dd_idx); update_parity = false; Patches currently in stable-queue which might be from artur.paszkiewicz(a)intel.com are queue-4.14/raid5-ppl-check-recovery_offset-when-performing-ppl-recovery.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "qtnfmac: modify full Tx queue error reporting" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled qtnfmac: modify full Tx queue error reporting to the 4.14-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: qtnfmac-modify-full-tx-queue-error-reporting.patch and it can be found in the queue-4.14 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 13:28:59 CET 2017 From: Sergey Matyukevich <sergey.matyukevich.os(a)quantenna.com> Date: Mon, 30 Oct 2017 13:13:46 +0300 Subject: qtnfmac: modify full Tx queue error reporting From: Sergey Matyukevich <sergey.matyukevich.os(a)quantenna.com> [ Upstream commit e9931f984dd1e80adb3b5e095ef175fe383bc92d ] Under heavy load it is normal that h/w Tx queue is almost full all the time and reclaim should be done before transmitting next packet. Warning still should be reported as well as s/w Tx queues should be stopped in the case when reclaim failed. Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os(a)quantenna.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c +++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c @@ -643,11 +643,11 @@ static int qtnf_tx_queue_ready(struct qt { if (!CIRC_SPACE(priv->tx_bd_w_index, priv->tx_bd_r_index, priv->tx_bd_num)) { - pr_err_ratelimited("reclaim full Tx queue\n"); qtnf_pcie_data_tx_reclaim(priv); if (!CIRC_SPACE(priv->tx_bd_w_index, priv->tx_bd_r_index, priv->tx_bd_num)) { + pr_warn_ratelimited("reclaim full Tx queue\n"); priv->tx_full_count++; return 0; } Patches currently in stable-queue which might be from sergey.matyukevich.os(a)quantenna.com are queue-4.14/qtnfmac-modify-full-tx-queue-error-reporting.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "ppp: Destroy the mutex when cleanup" has been added to the 4.14-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.14-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.14 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 13:28:59 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 @@ -959,6 +959,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.14/ppp-destroy-the-mutex-when-cleanup.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/xmon: Check before calling xive functions" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/xmon: Check before calling xive functions to the 4.14-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-xmon-check-before-calling-xive-functions.patch and it can be found in the queue-4.14 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 13:28:59 CET 2017 From: Breno Leitao <leitao(a)debian.org> Date: Tue, 17 Oct 2017 16:20:18 -0200 Subject: powerpc/xmon: Check before calling xive functions From: Breno Leitao <leitao(a)debian.org> [ Upstream commit 402e172a2ce76210f2fe921cf419d12103851344 ] Currently xmon could call XIVE functions from OPAL even if the XIVE is disabled or does not exist in the system, as in POWER8 machines. This causes the following exception: 1:mon> dx cpu 0x1: Vector: 700 (Program Check) at [c000000423c93450] pc: c00000000009cfa4: opal_xive_dump+0x50/0x68 lr: c0000000000997b8: opal_return+0x0/0x50 This patch simply checks if XIVE is enabled before calling XIVE functions. Fixes: 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE interrupt controller") Suggested-by: Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com> Signed-off-by: Breno Leitao <leitao(a)debian.org> 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/xmon/xmon.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/arch/powerpc/xmon/xmon.c +++ b/arch/powerpc/xmon/xmon.c @@ -2475,6 +2475,11 @@ static void dump_xives(void) unsigned long num; int c; + if (!xive_enabled()) { + printf("Xive disabled on this system\n"); + return; + } + c = inchar(); if (c == 'a') { dump_all_xives(); Patches currently in stable-queue which might be from leitao(a)debian.org are queue-4.14/powerpc-xmon-check-before-calling-xive-functions.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/pseries/vio: Dispose of virq mapping on vdevice unregister" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/pseries/vio: Dispose of virq mapping on vdevice unregister to the 4.14-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-pseries-vio-dispose-of-virq-mapping-on-vdevice-unregister.patch and it can be found in the queue-4.14 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 13:28:59 CET 2017 From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com> Date: Thu, 28 Sep 2017 20:19:20 -0400 Subject: powerpc/pseries/vio: Dispose of virq mapping on vdevice unregister From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com> [ Upstream commit b8f89fea599d91e674497aad572613eb63181f31 ] When a vdevice is DLPAR removed from the system the vio subsystem doesn't bother unmapping the virq from the irq_domain. As a result we have a virq mapped to a hardware irq that is no longer valid for the irq_domain. A side effect is that we are left with /proc/irq/<irq#> affinity entries, and attempts to modify the smp_affinity of the irq will fail. In the following observed example the kernel log is spammed by ics_rtas_set_affinity errors after the removal of a VSCSI adapter. This is a result of irqbalance trying to adjust the affinity every 10 seconds. rpadlpar_io: slot U8408.E8E.10A7ACV-V5-C25 removed ics_rtas_set_affinity: ibm,set-xive irq=655385 returns -3 ics_rtas_set_affinity: ibm,set-xive irq=655385 returns -3 This patch fixes the issue by calling irq_dispose_mapping() on the virq of the viodev on unregister. Fixes: f2ab6219969f ("powerpc/pseries: Add PFO support to the VIO bus") Signed-off-by: Tyrel Datwyler <tyreld(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/pseries/vio.c | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/powerpc/platforms/pseries/vio.c +++ b/arch/powerpc/platforms/pseries/vio.c @@ -1592,6 +1592,8 @@ ATTRIBUTE_GROUPS(vio_dev); void vio_unregister_device(struct vio_dev *viodev) { device_unregister(&viodev->dev); + if (viodev->family == VDEVICE) + irq_dispose_mapping(viodev->irq); } EXPORT_SYMBOL(vio_unregister_device); Patches currently in stable-queue which might be from tyreld(a)linux.vnet.ibm.com are queue-4.14/powerpc-pseries-vio-dispose-of-virq-mapping-on-vdevice-unregister.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo" has been added to the 4.14-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.14-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.14 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 13:28:59 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 @@ -319,7 +319,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.14/powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch

7 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2017